Standards

Web portal software has emerged as one of the most important components of software enterprises over the last few years. That success has carried with it the challenge of how to integrate disparate software services into the portal - services that can live across multiple platforms, operating systems, and networks. Solving that challenge is a key reason for the development of the new WSRP specification.

WSRP, or Web Services for Remote Portlets, is an OASIS standard whose goal is to provide Web service-based access capability for portal servers. Up to this point, most efforts to add capabilities or features to portal servers have involved the use of proprietary APIs and protocols that differ from vendor to vendor. WSRP will standardize the way that portals communicate remotely with remote services that can extend the portal's core capabilities.

One unique facet of the specification is that it is a presentation-oriented Web service. Most Web services are expected to just carry raw data as the result of a request, and the caller is responsible for determining how it is used. While in an abstract sense this is also true of WSRP, it is different in the sense that WSRP generally carries fully rendered markup that is to be included within a portal page, with very few changes to be made by the consumer.

The recent release of the JSR-168 specification - called Portlets for short - is also noteworthy. The portlets specification is a Java-based API for creating an open standards-based portlet interface. This standard was developed at the same time as WSRP, and each expert group made it a priority to ensure the two would be able to co-exist. This is important, since the two standards are a natural fit to work together.

The Basic Portal

At this stage in the evolution of WSRP, the specification addresses some very basic use cases for integration of portlet services through the use of Web services. Chief among these are the proprietary standards for integrating remote content, as described earlier. Standardizing the protocol enables developers and end users to more easily populate their portals with content from a variety of sources, with very little or no custom programming required.

A typical scenario can be seen in Figure 1, which shows how a user has selected a portlet from the list of available ones and placed the portlet within the portal page. In our example, the portal has two remote content sources via WSRP and one local source available through the local JSR-168 container. This is a fairly simple scenario showing that WSRP can be used to include remote portlets seamlessly into a portal that also pulls portal content from local sources.

Some of the advanced scenarios that WSRP can help solve will be discussed in detail later in this article. For now, let's start with some basic background on what comprises WSRP.

The Details

WSRP is made up of four distinct Web service interfaces: service description, registration, portlet management, and markup. To allow for varying levels of support by producers (generally the remote portlet server) and consumers (generally the end user-facing portal), not all of these interfaces are required to be implemented by the producer or to be used by the consumer.

Due to space constraints, the level of detail required to truly understand the protocol cannot be discussed in this article. Those interested in a more complete overview should visit the WSRP Web site (www.oasis-open.org/committees/tc_ home.php?wg_abbrev=wsrp). Examining the WSRP primer and specification there will help yield a better understanding of what the protocol offers and requires of its users.

Service Description
The ability to determine what services a producer has available for use is the first step for a consumer to integrate these services into the portal. When requesting the service description, a consumer has the option to supply its registration credentials to the producer. While this information isn't required, a producer could use it to change the services for which it returns a description.

The purpose of the service description structure is to inform the consumer, or portal, of the capabilities of each portlet it offers. This is important because it affects whether or not a portal can display the markup contents of the portlet along with what modes and window states it advertises as being available. In addition to these functional details, the producer also returns a list of locales that each portlet supports.

The service description structure, like every other structure in WSRP, supports an extensions field consisting of an array of type Object that allows both the client and server to support custom features that weren't included in 1.0.

Registration
When a consumer registers with the producer, it submits two types of data as part of the process. The first set of data describes the capabilities of the consumer. An example of this is the window states and modes the consumer supports. The second set of data is the registration properties, described in the producer's service description, that it requires for registration.

Registration is an optional interface that producers are not required to support. Producers that don't support registration at all, or those that only support registration in an out-of-band process, will not expose the interface to consumers.

The end result of registration, be it from an in-band or out-of-band process, is a registration handle that is unique to that consumer and from which all portlets created under this registration will be scoped.

Portlet Management
Portlet management is the second optional interface in WSRP. Its purpose is to allow the consumer to manage the portlets exposed in the producer's service description. When this interface is exposed, it allows the consumer to clone one of the producer's portlets for the purpose of customization. The original portlets exposed in a producer's service description are non-modifiable, which in effect means that if a producer does not expose this interface, its portlets can't be configured on the consumer portal. This limits the types of services that can be exposed but allows for a much simpler producer in cases where this level of functionality is not required.

Markup
Markup is a required interface as well as the one that will be invoked the most by the consumer. The interface has operations that support markup generation and interaction processing.

Both markup generation and interaction methods require very similar parameters for their operations to succeed; therefore, everything discussed in this section applies to both methods unless otherwise noted. Along with the normal identification and request-related context information (such as registration, request parameters, and portlet state), the consumer generally will send across end-user profile data such as first name, last name, username, and e-mail address so that the service can adequately personalize the consumer's offerings.

The key difference between a call for markup content and interaction is that the call to markup is just for markup, and is not allowed to affect state that the consumer keeps for the particular portlet for the particular end user. Interaction, however, allows the portlet to update its state along with returning markup when the call completes. To better illustrate this concept: clicking on a portlet or interacting with it will trigger a call to the interaction operation, while a refresh of the page will cause each WSRP portlet to just request markup, since it is not the current target of action on the page.

Another important capability is the format of the markup that is returned by these calls. The producer generally will have to encode all URLs that refer to content within the portlet so that the producer can rewrite them and put them in the context of the portlet for later proxy to the producer when needed.

Example
Declare a secure interaction back to the portlet:

wsrp-rewrite?wsrp-urlType=
blockingAction & wsrp-secureURL=true&
wsrp-navigationalState=a8h4K5JD9&
interactionState=fg4h923mdk/wsrp-rewrite

Dynamic/Advanced Producers

What follows is a more interesting case about how WSRP can be used to create some very powerful portal services from formerly nonportal-centric services.

One of the most compelling reasons for adopting the use of WSRP is that it allows portals to integrate services and content into the portal. These services and content can be exposed on just about any platform or operating system and implemented in just about any language that supports XML-based Web services.

These producers can be like the simple case illustrated earlier, where the producer returns essentially static content with a static service description. That's all that is required in some cases. But for more compelling and useful applications, the need for a dynamic producer becomes greater. Dynamic producers offer a larger degree of flexibility and the ability to create new offerings on the fly. For example, imagine that an integration engine and application generator are exposed via WSRP, and that each newly configured integration component is then added to the service description. This provides a means for exposing any integration component directly into a portal, regardless of the integration platform, as long as it supports WSRP production.

The ability to quickly and easily add existing applications and services directly into the portal is a very compelling objective for companies trying to leverage existing applications inside their enterprise portal.

What's Next

As with all first versions of a specification, there is always a laundry list of items that couldn't be fit in; otherwise, 1.0 would still be in committee. The items below are planned for inclusion in the upcoming 1.1 and 2.0 versions of WSRP. The 1.1 version is scheduled to be completed sometime in 2004, while 2.0 is likely to arrive toward the end of 2005 or the first half of 2006.

Security
Security was not addressed at all in the 1.0 specification, other than allowing a portlet to be marked as requiring the connection be secure. There is no provision for passing along, say, a user token from an SSO system or other means of authenticating a user to the producer. The current plan is to incorporate support for WS-Security along with guidelines on how it should be used within WSRP to ensure interoperability among vendors. In 1.0 it is left up to each individual vendor to determine how to attempt to secure WSRP usage. This will potentially lead to a number of issues when trying to interoperate between vendors and address application security. Support for this is planned in the 2.0 version.

UDDI Support
UDDI support will allow producers to post information about their services on UDDI servers to make it easier for consumers to search for and find their offerings when the location of the server that hosts these servers is not known. Version 1.1 will add simple support of UDDI so that a producer can describe its presence as well as each of the services it offers. This is essentially a subset of the data that is found in the service description.

Version 2.0 is expected to introduce more detailed structures to provide support for categorization, among other things. There are still some questions among the technical committee as to what role the specification should take in describing how UDDI should be used by producers.

Cross-Portlet Communication
This is the next large feature planned for introduction in WSRP 2.0. It will provide a mechanism that allows portlets to broadcast event information to other portlets spread across multiple producers if required. The key use case for this feature is so that portlets can post contextual information about their interaction, and other portlets can use that information to tailor the content that they generate.

Conclusion

Multiple vendors including Citrix, Oracle, Sun, Vignette, IBM, BEA, and Plumtree have expressed support for the first version of the WSRP specification and announced plans to provide implementations within their product offerings. This is a very strong vote of confidence among portal vendors. Developers and other IT organizations should investigate the use of WSRP when integrating their various service offerings into the enterprise portal.