Portlets constitute interactive Web application components whose presentation markup is aggregated and displayed by a portal server like WebSphere Portal. In a previous WebSphere Journal article, we introduced you to the Java Specification Request for the portlet specification (JSR 168), which lays out the plans for a standard for portlets that will enable them to be deployed to any JSR 168 compliant portal.

In this article, we will further our study of portlet portability. In particular, we will focus our discussion on the Web services for remote portals (WSRP) standard. The vision of WSRP is to allow portlets to be exposed as Web services. The resulting Web service will be user-facing and interactive. Unlike traditional data-oriented Web services, a WSRP-compliant Web service will carry within its payload the presentation logic necessary to display and interact with the portlet; consequently, portlets can be readily plugged into remote portals.

How Things Are Done Without WSRP
Before WSRP, there was simply no concept of being able to access a remote portlet as if it was a local portlet. Portlets had to be physically installed at a portal. As a result of this architectural limitation, enterprises wanting to bring remote content into their own portal typically faced a significant programming effort. They ended up having to run a portlet locally in their own portal infrastructure, which often required a painful development and integration effort involving the redevelopment of a presentation layer.

Let's say, for example, that we are an enterprise that wants our employees to be able to access an employee 401K retirement portlet. The 401K services are provided by a third-party financial institution. Without WSRP we'd end up having to install the 401K portlet into our own portal. The installation effort would probably involve having our portlet access data sources housed in the financial institution. In short, we would have a potentially daunting application development effort on our hands, especially if we are shorthanded in the area of portlet developers. In some cases, "we" might not even have portlet developers on our staff, e.g., if we are a small nontech firm. Then we end up having to worry about security issues and cringe at the reality that the financial institution wants to provide periodical updates to the portlet to better serve its constituents (a.k.a. your employees). Wouldn't life be much easier if the financial institution could provide us with the portlet remotely?

Plug-and-Play Remote Portlets
WSRP is being commandeered by the Organization for the Advancement of Structured Information Standards, OASIS (www.oasis-open.org/). The vision of OASIS is for a portal administrator to be able to choose to incorporate pluggable, remote portlets wrapped as Web services into their own portal. The process of incorporating remote portlets will require no programming effort; OASIS envisions a discovery and installation process involving "a few clicks." The portlets will be user-facing and interactive. The main offering ­ the portlets ­ will not be housed locally, they are remote (residing on different parts of an enterprise's intranet or the Internet). Because they are Web services, they will be loosely coupled to the consuming portal server. Unlike traditional Web services though, Web services for remote portals will carry both application and presentation logic that can be displayed by a consuming portal. To the end user, remote portlets will look like and interact with the user just as local portlets would.

Consuming WSRP Services
WSRP-compliant portals will not have to be trained in how to consume a particular remote Web service. WSRP-compliant portals will use a single generic adapter through which they can integrate with any WSRP-compliant portlet. The generic adapter is actually portlet proxy code that knows how to consume a remote portal Web service as if it were a local portlet (See Figure 1).

WSRP taps into the advancements made by the Web services community. It is a presentation layer built on the Web services stack. The interfaces of WSRP are laid out in WSDL (Web Services Description Language). Portlets compliant with the WSRP standard can publish metadata to describe themselves to portlet registries from which they can be discovered and integrated into remote portals.

User-Facing Web Services versus Data-Oriented Web Services
Those savvy with Web services might be wondering what the difference is between the Web services they are used to dealing with and presentation-oriented, user-facing, interactive Web services offered by WSRP. Data-oriented Web services typically return data objects encoded in XML as responses to SOAP (Simple Object Access Protocol) requests. Though our encoding is SOAP, each data-oriented service might be quite different (expecting different request parameters and returning a different response) from the semantics of the interaction with the Web service being described in WSDL. Due to the variety of Web services and associated descriptions, data-oriented Web services require service-specific proxies.

Juxtaposing user-facing Web services in our payload that we return to our Web services client, we include markup fragments that can be aggregated by a consumer.

Backing the Standard
As with practically any standard, the standard is rendered worthless unless it has buy-in from the major players of the industry. The WSRP 1.0 specification is a collaborative effort of nearly 25 OASIS member companies and has been approved by key industry front-runners like:

• IBM
• Apache Foundation
• BEA
• Microsoft
• Oracle
• Sun
• Plumtree
• Vignette

IBM in particular has played a major role in promoting the WSRP standard. Big Blue initiated the Apache WSRP4J project to catalyze adoption of the WSRP standard. At the time of this article's writing, the WSRP4J project was still an "incubated" subproject under the Apache Software Foundation's Web services project. Nevertheless, WSRP's vision is gaining the attention of huge audiences who see the user-facing pluggable Web services offerings of WSRP to mean cost savings.

IBM WebSphere Portal Version 5.0.2 currently provides support for WSRP through a WebSphere portal technology preview in the form of IBM WebSphere Portal Version 5.0.2 Cumulative Fix 2 (5.0.2.2). With the cumulative fix, you can enable WSRP in WebSphere Portal and provide your portlets as WSRP services, and also integrate other WSRP-enabled services into your portal as remote portlets. For more information about WebSphere Portal's WSRP support, see "Using WSRP Services with IBM WebSphere Portal Version 5.0.2 Cumulative Fix 2", http://publib.boulder.ibm.com/pvc/wp/5022/ent/en/standards/wsrp.html

JSR 168 Relationship with WSRP
You may begin to wonder what the relationship is between JSR 168 and WSRP. The two standards are not competing. In fact, in some cases, they might be considered complementary. JSR 168 portlets can be deployed to any JSR 168 portal. These portlets are local to the portal. Portlets exposed as Web services (using WSRP) run remote to the portal. They may or may not be JSR 168 compliant portlets. JSR 168 portlets might be exposed as pluggable Web services for other portals to consume. As discussed earlier, the consuming portal interacts with the remote portal service through a proxy.

Conclusion
The WSRP vision will allow for enterprises to consume and publish portlets as Web services. These portlets will carry with them the user experience intended by the creator of the portlet. WSRP aims to allow enterprises to save time and costs by being able to leverage portlets created by others. Since we are still talking Web services, we get the added benefit of being able to code our remote portlets in any programming language, given that we adhere to the interface laws laid down by the WSDL interface description. It is the job of a remote portlet Web service to deliver HTML, WML, VoiceXML, or whatever content an end portal client might expect.

In reality, what we will probably see in the future are WSRP-compliant portals displaying a heterogeneous mix of local and remote portlets to better serve end users. As mentioned in this article, WSRP adds a presentation layer to the Web services stack. As the Web services realm is itself evolving (with standards emerging in key areas such as security and transaction support), it will be interesting to see how or even if the WSRP standard will need to change. Oasis has already begun working to define a new WSRP 2.0 standard.

The JSR 168 specification addressed in the previous article and the WSRP standard have the support of key players in the portal arena including IBM. IBM WebSphere Portal 5 provides support for both WSRP and JSR168. The ability of these technologies to lower costs for companies leveraging portals makes the JSR 168 specification and the WSRP standard key architectural and design considerations for your enterprise.

• Figure 1