SharePoint Gets a WSRP Toolkit

More news on the interoperability front - at least for Microsoft Office SharePoint 2007. Microsoft has finally listened to its customers and released a WSRP (Web Services for Remote Portlets) Toolkit designed to help them pull MOSS content into other portals.

You have always been able to consume web services within SharePoint. But before now, you haven't been able to pull content out of SharePoint using web services for display in some other portal (at least not something coming from Microsoft directly). That has now changed with the release of the WSRP Toolkit. Now SharePoint can be a producer of web services as well as a consumer.

What's in The Toolkit?

Never one to just tell you what you can do, the toolkit gives you information as well as samples of working Web Services. The toolkit contains several things, including:

  • A whitepaper - Microsoft loves their whitepapers. This one discusses portal to portal interoperability, specifically outlining how SharePoint will produce web services
  • A sample WSRP Producer Visual Studio Project using a SharePoint Web Part
  • A sample WSRP Producer Visual Studio Project using SharePoint Web Services
  • Screencasts demonstrating the functionality

The toolkit is based on the OASIS Web Services for Remote Portlets specification.

Two Methods to Expose SharePoint Data

Microsoft does not provide examples of WSRP Producers out the box, thus the need for the toolkit. The toolkit provides two examples for exposing SharePoint data. These samples are provided by the Microsoft Public License (Ms-PL), thus allowing developers to customize the solution to meet their specific requirements.

 

SP_WSRPtoolkit.jpg

 

SharePoint Web Part

This method of extracting SharePoint content keeps the content tied tightly to SharePoint. Called the SharePointWSRPProducer, it serves a List Web Part's HTML code. 

The example demonstrates integration at the User Interface Level. It uses the SharePoint Object Model to get the Web Part that SharePoint would normally send to the browser. This web part is then reprocessed and transformed to maintain WSRP fidelity. The resulting content is then sent to the consumer portal.

This is supposed to be the more complex approach to getting SharePoint content as the underlying architecture of a Web Part is a mixture of HTML and Javascript.

SharePoint Web Services

This method provides the developers with the ability to have more control over the output rendered from SharePoint. This sample is called the ASPNetWSRPProducer and it uses the SPGridView page to expose the content of List Web Parts to a WSRP Consumer.

The example retrieves the content of a SharePoint list using the XML web service and renders it onto an ASP.Net page. The content is then processed and exposed to the consuming portal using WSRP. This is a less complex approach because the HTML is simpler to process.

Both project solutions are built for Visual Studio 2008.

Tighter Integration With SharePoint Not in the Mix

It is good to finally see some examples of exposing SharePoint content through other portals. The important thing to understand here though is that the user interface is completely dictated by SharePoint still. Neither of these methods exposes a direct connection to the underlying data stored in the SharePoint repository. What this means is that the consumer will need to work closely with the producer to design the appropriate architecture.

And although Microsoft has been thinking about it, their whitepaper suggests that this is something they aren't working on right now. Data integration is the best approach to sharing content between two parties. Service Oriented Architectures are built on this approach, providing consumers with the raw data, usually in XML format, to do with what they please.

Microsoft says they offer several entry-points to SharePoint that would work with this type of integration: Web Services, RSS and WebDAV. And eventually, we should see CMIS in this list as well.

A Step in the Right Direction

Many will see this as a continued effort by Microsoft to keep control over content and a further example of how complicated the inter workings of SharePoint must be.

Interesting to note that we have already seen Mainsoft do this type of integration with their Mainsoft SharePoint Federator for WebSphere Portal. Maybe they shared some their trade secrets.

For now though, most are probably excited to see some level of integration that will help them pull SharePoint content into their portal applications. 

You can download the toolkit from the MSDN website.