The recent buzz around cloud computing is a new business phenomenon, but Windows SharePoint Services (WSS) 3.0 has always come out of the box with web services and protocols designed to be location-independent. The functionality offered by these web services isn’t a new idea, and SharePoint’s HTTP client/server communication functions the same way whether the client and server are located in the same room, or if the server is a virtualized guest machine in a cloud datacenter. Furthermore, Microsoft Office SharePoint Server (MOSS) 2007 adds additional web services to the base package provided by WSS 3.0 that interact with specific office applications, and SharePoint supports the addition of customized services and assemblies to its global assembly cache so that any web application can take advantage of the SharePoint environment.
In this column I discuss the components and protocols that enable SharePoint’s integration with client programs and outline some of the most-used functions that are exposed as web services by WSS 3.0 and MOSS 2007. These web services are a powerful method that SharePoint users and developers can use to extend the functionality of the collaboration environment as well as develop custom applications accessible from anywhere, but the architecture is complicated by the myriad components required to enable comprehensive client functionality. Despite the standard of a web service as an ASP.NET page (in .asmx format) that exposes methods to clients, SharePoint’s Office 2007 client integration also uses ActiveX browser controls, .aspx APIs, directly called assemblies, and legacy protocols that are more ancestors of modern web services than true web services themselves. While SharePoint’s core web service functionality is encapsulated in .asmx pages, the necessity of retaining backward compatibility with older applications—and the popularity of third party APIs—makes the SharePoint web services world an often-confusing one. If you would like to follow the explanations in this article in a test environment, see the companion material for this article at technetmagazine.com.
HTTP-based Communication with SharePoint
The model currently used by WSS 3.0 for client-server communication is based on the philosophy that not only Microsoft’s own clients but also ASP.NET web parts and third party applications will make calls on the server’s exposed web services. The underpinning technologies of this interoperability are SOAP and XML. The actual information of a web service call is encapsulated in XML, which is then placed in a SOAP wrapper and sent via HTTP to the WSS 3.0 server. For example, a Microsoft Office 2007 Application that needs to modify a SharePoint list will call the Lists (/_vti_bin/lists.asmx) web service’s methods by encapsulating the method calls in XML. What each method of each web service returns is obviously variable, and beyond the scope of this article (but see http://msdn.com/en-us/library/ms445292.aspx and http://msdn.com /en-us/library/ms542012.aspx to get started). As I discussed in previous articles, simple HTTP requests are caught by ISAPI filters on the server so that the client’s requests for virtualized URLs can be handled seamlessly. By using HTTP requests and web service method calls, remote client applications can programmatically perform the same site provisioning, architecting, and document management tasks accessible from the SharePoint browser interface.
Of course, there is more to the story than just straightforward HTTP requests to virtualized URLs and method calls to web services. Office 2007 applications make calls directly to the FrontPage server extensions (through /_vti_bin/ossvr.dll, author.dll, and admin.dll) and use the WebDAV protocol for document management. Some web parts viewable directly in the browser also call web services to generate standard HTML (such as Excel Web Access), while others run ActiveX browser controls that require client-side components installed as part of Microsoft Office 2007 (such as Access Web Datasheet). SharePoint also makes extensive use of the StsSync protocol, which is unique in that it is simply a URI read by a client handler control, which then passes the encapsulated instructions to a client application. The actual communication between the client and server is handled entirely by the standard web service protocols such as Lists.asmx. In the context of this article, I focus specifically on ASP.NET web service pages and only cover the other protocols as necessary to explain the functionality of specific Office applications. If you are interested in learning more about the full spectrum of protocols used by Microsoft Office 2007 client applications, see http://msdn.com/en-us/library/cc339482.aspx.
WSS 3.0 Web Services
Programmatic interaction with the SharePoint environment means putting HTTP requests to the web services that WSS 3.0 exposes. A full list of these services can be found at http://msdn.com/en-us/library/ms445292.aspx, but a few are commonly called by every program that interfaces with SharePoint. The Lists web service (/_vti_bin/lists.asmx, http://msdn.com/en-us/library/lists.aspx) exposes methods for creating, editing, deleting, and accessing SharePoint lists. Every client application that uses lists or document libraries (which are a type of list) uses it. Similarly, the Webs web service (/_vti_bin/lists.asmx, http://msdn.com/en-us/library/webs.aspx) exposes methods that are used to get information about a SharePoint site, such as the activated features and content types. Other services such as the Admin web service (/_vti_bin/admin.asmx, http://msdn.com/en-us/library/administration.admin.aspx), which exposes the methods to create and delete site collections in SharePoint, are used infrequently (if ever), but demonstrate the scope of the functions available to remote clients in WSS 3.0.
Microsoft Office Access 2007 extracts all of its SharePoint integration from the WSS 3.0 web services package, without any need for additional components. Access can publish database files directly to SharePoint and benefit from the environment’s document versioning and workflow systems. Access also has the ability to open a SharePoint list, update it dynamically, and use all of the Access client functions to search or edit it. From the user’s perspective, a SharePoint list opened in Access or an Access database converted into a SharePoint list and then opened in the client is no different than a locally stored database. Although SharePoint cannot enforce true referential integrity in its lists (users moving databases with referential cells to SharePoint will receive a warning message to that effect), it does allow references between lists as though they were tables. Behind the scenes, Access calls the Lists and Webs services on the server every time the user modifies a record to ensure that the SharePoint data is synchronized with what the user sees.
Access also supports browser-based access to SharePoint lists with the Access Web Datasheet control. This control is installed on the client computer with Office 2007 and renders lists in a spreadsheet-like format when the user opens the Actions menu on any list in SharePoint and clicks Edit in Datasheet. The Web Datasheet control also calls web services so that the information changes can be incrementally posted back to the server rather than requiring .aspx forms be filled out and posted, but it is not a truly interoperable client. The Access Web Datasheet control is installed as a component of Microsoft Office 2007 (by default, at C:\Program Files\Microsoft Office\Office12\stslist.dll), so thin clients without that software do not support it (and the menu option is removed in SharePoint). This contrasts with the Excel Web Access browser client, which is discussed in the next section.
WSS 3.0 also supports blogging out of the box with a blog site template and management web interface. Microsoft Office Word 2007 gives an alternative to the browser interface through the MetaWeblog API, which is called through /_vti_bin/metaweblog.aspx on the server. The API only exposes a handful of methods, but it still communicates over HTTP using XML remote procedure calls. However, the MetaWeblog API was developed by a third party (read the specification at http://www.xmlrpc.com/metaWeblogApi), so it does not conform to Microsoft standards. Word 2007 also supports the Atom Publishing Protocol and Atom Syndication format, but these protocols are not used by SharePoint.
MOSS 2007 Web Services
WSS 3.0’s standard web services offer many tools for accessing and modifying SharePoint data with powerful client applications. However, WSS 3.0 is also a platform for more specialized and powerful web services, and those added by installing Microsoft Office SharePoint Server 2007 are good examples of how web services can expand the functionality of SharePoint from being a collaboration environment to a true platform for web applications.
A simple expression of a specialized web service can be found in MOSS 2007’s Slide Library service (/_vti_bin/slidelibrary.asmx, http://msdn.com/en-us/library/bb862916.aspx), which is called by Microsoft Office PowerPoint 2007 to break up PowerPoint decks with many slides into files that contain only a single slide each, and then upload them to a SharePoint slide document library. These slides can then be re-used in future presentations from an interface within the PowerPoint client, with their content dynamically updated to reflect changes to the SharePoint version. This is accomplished by use of the Slide Library Protocol (http://msdn. com/en-us/library/cc313135.aspx) which is used only by the SlideLibrary.asmx web service. The protocol enables the PowerPoint 2007 client to query metadata such as the ID numbers of individual slides (both within the slide library and scoped to the entire SharePoint server), authoring information, and the name of the PowerPoint presentation from which the slide originated.
Other Office applications are associated with more expansive web services. Microsoft Office InfoPath 2007 has its own specialized web service (/_vti_bin/FormsServices.asmx, view the SDK documentation at http://msdn.microsoft.com/en-us/library/bb877920.aspx) which is included both in MOSS 2007 and also a separate SKU, Microsoft Office Forms Server 2007. The included functionality is the same in either case. Form templates uploaded to a SharePoint site can pull data from other web services, run declarative business logic on the server, and post data to web services from the form. For example, an InfoPath form could require that a user enter their SharePoint user name into a field, which would be posted to the /_vti_bin/usergroup.asmx web service in order to return a SOAP message containing the requested information. Form templates that are approved by a farm level administrator can also contain managed code in addition to simple web service requests. The data-gathering capabilities of Form Services are further extended by the ability to deliver forms to clients with only a web browser.
When a client makes a request for a form on the SharePoint site, Forms Services detects whether the client has InfoPath 2007 installed, and if not directs them to /_layouts/FormServer.aspx. FormServer.aspx contains the XMLFormView web part, which renders InfoPath forms so that only a web browser is needed to fill them in and post the information back to the server. If the form needs to interact with data or business logic, XMLFormView posts back the user-entered information so that the necessary calculations can be executed on the server. Regardless of whether the user fills out a form in the InfoPath 2007 client or in a web browser, Forms Services offers integrated access to all of the SharePoint web services and data available, including the calculation engine in Excel Calculation Services.
This calculation engine, exposed through the Excel Services web service (/_vti_bin/ExcelService.asmx, http://msdn.com/en-us/library/microsoft.office.excel.server.webservices.excelservice.aspx), provides the same calculation functions as the Microsoft Office Excel 2007 desktop application. But because Excel Calculation Services (ECS) is run as a shared service across the entire SharePoint server farm, it is automatically load balanced across all servers that have it enabled. Resource intensive calculation tasks and reports can be compiled in live Excel workbooks by using the processing power of a dedicated (or multiple dedicated) application servers. MOSS 2007 also includes an Excel Web Access web part, which makes these functions accessible to browser-based clients, without any need for client-side components (as is the case for Access Web Datasheet). For more information about Excel Services, including step-by-step guides, see TechNet’s white paper on the subject from March of last year (http://technet.microsoft.com/en-us/library/cc263430.aspx).
Custom Web Services
WSS 3.0 and MOSS 2007 expose a lot of functionality through their web services, but SharePoint also supports custom web services and applications that can be deployed into the global assembly cache and function the same way as native SharePoint services. A web service is registered on a server with WSS 3.0 enabled by its discovery files and asmx file, which are found in the web directory http://serverhost/_vti_bin/. On the server’s hard drive, this maps to \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI. There is also a subfolder of this directory named \_vti_adm\. Web service files deployed to this directory will only be accessible to users and clients with farm administrator credentials. Finally, the web service must also be registered in \Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\ISAPI\spdisco.aspx. For a procedural walkthrough of the deployment process and instructions on how to implement the SharePoint object model into your custom services (and creating client applications that consume those services), see http://msdn.com/en-us/library/ms464040.aspx.
Developing custom web services and client applications requires knowledge of the protocols by which clients communicate with the existing web services. The MSDN protocol reference documents (http://msdn.com/en-us/library/cc341379.aspx) contain all of the information about the protocols used in client/server communication and what components are the traffic endpoints for each protocol. You will also need a working knowledge of ASP.NET 2.0 and the existing WSS 3.0 and MOSS 2007 APIs. A custom SharePoint solution (web services being one example) consists of the .NET assemblies to power it, any resources such as images, XML schema, or new SharePoint templates needed to display the solution, the configuration information added to the server’s web.config file and elsewhere (depending on what the solution contains), and a manifest file that gives WSS instructions on how to deploy your solution. Visual Studio packages all of these components into a .wsp file for easy deployment and testing. Detailed information about the development requirements, skill sets, and deployment capabilities of SharePoint environments can be found in Patrick Tisseghem’s how-to guide, “Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0.” (http://msdn.com/en-us/library/bb530302.aspx)
In this simple example solution, I developed
Web Services and Web Applications
As a web service platform, SharePoint is “solution ready” for custom services as well as coming out of the box with many ready-to-use services. MOSS 2007 expands this functionality to include specialized web services designed to extend the functionality of the 2007 Office suite with powerful remote computing and business logic capabilities thanks to Excel Services and Forms Services. These technologies are leveraged by companies that want to move their IT operations into a cloud computing model, but the actual functionality doesn’t change no matter where they are deployed.
The real utility of SharePoint’s model of web services and applications isn’t that they can be deployed in a cloud computing environment, but rather that they are accessible by browser-based clients as well as third party software. Custom extensions to these features can potentially give every application the SharePoint integration that makes Microsoft Office 2007’s interaction with SharePoint so seamless.
The introduction of web applications based on web part pages (such as Excel Web Access) takes this concept of interoperability one step further. Instead of deploying a client application to every work station that might conceivably need to access a workbook, even if only to look at it or run parameterized calculations, the ubiquitous web browser becomes the client application. With all of the content stored solely in the SharePoint content database and all of the calculations run on the application server, there is no longer any need to disseminate information to potentially unsecure workstation computers. Furthermore, those clients no longer need the hardware to perform resource-intensive, enterprise-level calculations. The information stays on the most secure, most powerful hardware available, while thin clients get “rich-client functionality” from their web browsers.
No comments:
Post a Comment