next up previous contents
Next: JSR-168 vs. WSRP Up: Portlet Standards: JSR-168 and Previous: JSR-168   Contents

WSRP

WSRP, the Web Services for Remote Portlets API defines a standard for interactive, user-facing Web services that plug and play with portals.

The portlet JSR-168 specification handles the presentation end of information enabling re-use of portlets in different containers. In order for containers to present their contents as services IBM and Sun have taken the lead on WSRP, the Web Services for Remote Portlets standard (also ratified in August 2003), which is based on XML and Web services. WSRP will allow portals to retrieve content from other portals and other data sources. The use of WSRP and JSR-168 in a typical portal architecture is shown in Figure 2. More information on WSRP can be found at http://xml.coverpages.org/ni2002-01-21-b.html.

WSRP emerged from the world of Web services which uses WSDL to publish service information after it was taken by an OASIS technical committee (which also reviewed the proposed JSR-168 standard). OASIS is the Organization for the Advancement of Structured Information Standards, a world-wide consortium that drives the development, convergence and adoption of e-Business standards. WSRP was combined with input from the proposed Web Service for Interactive Applications before a final specification was agreed in late 2002. Following a public review in May 2003, WSRP was also adopted as a full OASIS standard in the third week of July 2003.

WSRP seeks to establish a portlet abstraction with a WSDL description for how to publish, find and bind to remote WSRP-compliant services with metadata about related things such as security mechanisms, billing, etc. It is now a platform-independent bridge leveraging the language-independence of Web services and interfacing to the Java portlet API JSR-168, C# .NET API, and other WSRP implementations on J2EE or .NET. If a portlet is written to the portlet API it should be possible to publish it as a WSRP service either via a portal framework or by a WSRP4J wrapper in a UDDI registry and import it into another portal using a portlet proxy or WSRP4J. See [68] and [69].

We note that WSRP services can also be consumed in different ways, for instance it is possible to use and portal framework or to use Swing [70] to render portlet services in a GUI.


next up previous contents
Next: JSR-168 vs. WSRP Up: Portlet Standards: JSR-168 and Previous: JSR-168   Contents
Rob Allan 2005-05-09