next up previous contents
Next: Content Aggregation: WSRP, RSS, Up: Portlet Standards: JSR-168 and Previous: WSRP   Contents

JSR-168 vs. WSRP

JSR-168 and WSRP work at different levels. JSR-168 specifies the interfaces for local portlets into their container (e.g. Jetspeed, uPortal) whilst WSRP specifies the interfaces for accessing portlets across portal frameworks. These have to be aligned using the same notion of the objects and ability to instantiate portlets locally and remotely. Details of the portlet API have to be exposed via WSRP in order to do this. The use of WSRP and JSR-168 in a typical portal architecture is shown in Figure 2.

Figure 2: Relationship between WSRP and JSR-168

\begin{picture}(0,0)%
\includegraphics{standards.ps}%
\end{picture}
picture(7449,4374)(214,-4273)

It is important to note that you don't need a portal framework to serve WSRP compliant content. It can be served as any Web service would be (e.g. using Apache with C gSOAP, Perl SOAP::Lite, etc.). This avoids content providers having to tackle issues of installing additional software like Tomcat. This is also an important aspect of wrapping more traditional applications for presentation via a portal framework. For Java programmers, WSRP4J [69] can act as a bridge either to publish a JSR-168 compliant portlet as a Web service or to ingest the WSDL referring to a WSRP service and produce the required JSR-168 interface to plug into a portlet container such as uPortal, Jetspeed or LifeRay.


next up previous contents
Next: Content Aggregation: WSRP, RSS, Up: Portlet Standards: JSR-168 and Previous: WSRP   Contents
Rob Allan 2005-05-09