WSRP and the Enterprise Portal
A strong, and important, start
By: Ed Anuff
Apr. 30, 2004 12:00 AM
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 PortalAt 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 DetailsWSRP 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.
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 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.
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.
Dynamic/Advanced ProducersWhat 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 NextAs 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.
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.
ConclusionMultiple 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.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week