What Developers Need to Know About Windows SharePoint Services, Page 2
SharePoint Services Architecture
SharePoint Services is built on the twin foundations of Microsoft SQL Server (or MSDE), and ASP.NET. SharePoint Services is implemented largely as a set of Web Parts, which are ASP.NET controls that run on the server. Web Parts can display lists or images, retrieve stock quotes or weather forecasts, and perform a host of other tasks. Web Parts are grouped into Web part pages, which can be built and modified in an HTML editor, FrontPage or directly in the browser.
For the developer, SharePoint Services offers a number of ways to tie in to the collaborative process. I'll briefly introduce three of these in this article (and then dig into them further in future articles):
- Web Services
Using SharePoint Web Services
You've certainly noticed Microsoft pushing Web Services as a means of application connectivity over the last year or so -- and with good reason. The loosely-coupled model of Web Services, where the client needs very little prior knowledge of the server, is an ideal way to manage platform-agnostic component software from multiple vendors distributed across networks. For version 2.0, Microsoft has added a comprehensive Web Services API to SharePoint Services. Just about any task that can be done from the browser-based user interface can also be done by making an appropriate Web Services call. Figure 2 shows the test page for the Meetings Web Service, which is one of a dozen Web Services supported by SharePoint Services.
The Web Services API for SharePoint Services is important for several reasons. First, it provides easy access to SharePoint functionality for other Microsoft applications that can consume Web Services -- notably, Visual Studio .NET and Office 2003 (or Office XP) equipped with the Web Services Toolkit. But even more importantly, thsi ties SharePoint Services to the open standards that support Web Services, including SOAP and WSDL. This will make it possible to write applications on a variety of platforms that work with SharePoint Services data.
Using SharePoint Lists
SharePoint lists are not new in this version of SharePoint. Lists are the basic data structure of SharePoint Services; everything from meetings to contacts is stored as a list, which is very similar to an Access table or an Excel range. What is new is tight integration of SharePoint lists with the applications in Microsoft Office 2003. You can, for example, save an Excel 2003 range as a SharePoint list, or open a SharePoint list in Excel. You can import, export, and link data from Access to SharePoint and vice versa. This makes SharePoint a very useful tool for data interchange with Office 2003 applications.
For example, suppose that most of your employees work with Microsoft Access, but that you have a few roaming employees who need to be able to get to the same data with nothing more than a Web browser. Rather than layer a Web interface on top of the Access data, you could store the data in SharePoint Services, link it back to an Access database for the majority of your workers, and let the rest use it through the standard browser-based SharePoint interface.
Using SharePoint Workspaces
SharePoint Services 2.0 introduces "Meeting Workspaces" and "Document Workspaces" - these are SharePoint sites organized around particular tasks and accessed mainly through Office 2003 documents instead of Web sites. A Meeting Workspace lets you organize the documents and tasks surrounding a meeting, while a Document Workspace provides you with a document-centric collaboration model. Figure 3 shows a Document Workspace open in the task pane of Microsoft Word 2003.
Workspaces provide another way for users to interact with SharePoint -- one in which SharePoint isn't even evident to the end user. In addition, Office 2003 supplies an object model for workspaces, so you can use Office VBA code to tie into SharePoint directly.
Is There Collaboration In Your Future?
Microsoft is betting heavily on collaboration in general, and SharePoint Services in particular, to drive the adoption of Office 2003. You should expect a steady stream of technical and marketing material to come out of Redmond, demonstrating the usefulness of these features. Of course, you should evaluate SharePoint Services in terms of your own organization's needs, not strictly based on marketing. The key questions are whether you're doing anything that can benefit from collaborative features, and whether those features can be easily supplied by the SharePoint Services infrastructure. If the answer to both of those questions is "yes," then it's definitely worth your while to find out more about the nuts and bolts of these features.
Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the lead developer for Larkware. Check out his MCAD 70-305, MCAD 70-306, and MCAD 70-310 Training Guides from Que Publishing. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.