Introduction to Web Services for Remote Portlets

developerWorks  >  SOA and Web services | XML  >
Introduction to Web Services for Remote Portlets
Use WSRP in a Service-Oriented Architecture

Document options

Print this page

E-mail this page
Free software for rapid results

Kick-start your Java apps
Rate this page

Help us improve this content
Level: Intermediate
Bryan Castle (castle_bryan@bah.com), Senior Consultant, Booz Allen Hamilton
15 Apr 2005
Get an introduction to Web Services for Remote Portlets (WSRP), a specification which defines how to leverage SOAP-based Web services that generate mark-up fragments within a portal application. By defining a set of common interfaces, WSRP allows portals to display remotely-running portlets inside their pages without requiring any additional programming by the portal developers. To the end-user, it appears that the portlet is running locally within their portal, but in reality the portlet resides in a remotely-running portlet container, and interaction occurs through the exchange of SOAP messages. Leveraging WSRP within a Service-Oriented Architecture provides a powerful combination whereby presentation-oriented portlet applications can be discovered and reused without engaging in additional development or deployment activities.
Over the past couple of years, the term Service Oriented Architecture (SOA) has become a pervasive buzz word, although fundamentally there is nothing new about the concept. While SOA is often talked about within the technical community, how does SOA impact an end-user? Is an end-user going query a service directory to find a Web service that meets their needs? And then how would an end-user communicate with a Web service, even if he was aware of its existence? Is he going to write a client or a UI to interact with a Web service? Probably not. So, does a SOA provide any direct advantages to the end service user? Again, probably not -- that is, until now. WSRP is an emerging technology which has recently begun to garner industry support from all of the portal market‘s major players, including IBM®, BEA, Oracle, and Microsoft®. The ultimate goal of WSRP is to bring Web services and the benefits of Service-Oriented Architecture to the end-user.
The WSRP Specification is a product of the Organization for the Advancement of Structured Information Standards (OASIS), which is a consortium that facilitates the adoption of technical standards. Version 1.0 of the WSRP Specification was finalized in August of 2003, and work is currently underway on version 2.0, which is due out in the middle of 2005. Since all of the major players in the portal market are represented on OASIS‘ WSRP Technical Committee, the technology should continue to enjoy broad acceptance in the industry. The OASIS WSRP specification defines a common, well-defined interface for communicating with pluggable, presentation-oriented Web services. These services process user interactions and provide mark-up fragments for aggregation by portals.
A couple of the most important terms in the above definition warrant special attention. First, the services are presentation-oriented which means that they provide a user interface that allows an end-user to interact directly with the service. This is starkly different from a traditional Web service which focuses on processing a request and generating a response at a more programmatic level. Second, the specification defines a common, well-defined interface governing how a portal communicates with the service and collects the mark-up fragments it needs to present a page to the end-user. It is precisely this common interface which allows portal applications to generically consume portlets running in remotely-running containers.
It is worth noting that WSRP is built upon existing Web services standards like SOAP, WSDL, and UDDI (seeResources). Although this paper focuses on the most common WSRP usage scenario -- the generation of HTML mark-up fragments to be consumed within a portal -- there is nothing to prevent WSRP from transporting other mark-up languages as well.Figure 1 shows how WSRP fits into the technology stack.

Before delving into the world of WSRP, I should first clarify what exactly is meant by the terms portal and portlet. The definition of a portal is subject to interpretation; a survey of ten software engineers would likely elicit ten different definitions. For the purposes of this paper, a portal can be thought of as a Web-based application that is customizable by the end-user both in the look and feel of the portal and in the available content and applications which the portal contains. A portal, furthermore, can be thought of as an aggregator of content and applications or a single point of entry to a user‘s set of tools and applications.
Now that you know what a portal is, what exactly is a portlet? A portlet can be thought of as a miniature Web application that is running inside of a portal page along side any number of similar entities. A portlet is a Web component which is managed by a container and can process requests and generate dynamic content. Portlets come in many flavors -- some are standards-based, while others are proprietary to the portal which hosts them. The Java Portlet Specification (JSR-168), approved in October of 2003, defines a standard API for J2EE-based portal platforms. The goal of JSR-168 is to provide a set of standards so that any compliant portlet can be deployed on any portal which supports the specification.Figure 2 shows a traditional portal model where the portal has a portlet container which hosts any number of discrete portlets. Each of these portlets generates fragments of mark-up which the portal ultimately pieces together to create a complete page that is presented to the user.

If Web services offer a mechanism to create platform-independent services, and JSR-168 defines a standard by which to develop portlets, why do you need WSRP? The answer is simple. While Web services give you the ability to reuse back-end services, WSRP lets you reuse the entire user interface!
For example, you might want to provide end-users of a portal the ability to look-up the price of a stock by entering a ticker symbol. You know that there is likely already a Web service which provides precisely this capability. You could search for stock-quote services in UDDI registries for a Web service that performs this service. Upon finding such a service, you would next need to code a client to bind to and consume the Web service, as well as develop a portlet to allow portal users to interact with the service. Using a Web service toolkit might make developing the Web service client relatively painless; however, developing the user interface might not be such a trivial endeavor. Additionally, you must go through the process of deploying the newly developed portlet and Web services client on your portal server. By the end of the day, you‘ve been forced to develop, compile, and deploy a substantial amount of new code to bring the stock quote service functionality to the end-user. While leveraging a stock quote service developed by a third-party does cut down on development time, the process of developing and deploying the front-end application needed to make the functionality usable by a portal user is tedious and time-consuming.
Building on this same example with WSRP in the mix, you could much more easily integrate a stock quote portlet into your portal. You could browse the UDDI directory for portlets themselves or alternatively provide end-users with the ability to browse a registry of portlets. Once the Stock Quote Portlet has been discovered, the process of adding it to the portal takes just a few clicks of the mouse and you are done. You don‘t need to perform any custom coding or deployment activities since the portlet is being consumed through WSRP. The end-user doesn‘t need to understand anything about WSRP or even that their portlet is actually being hosted by a remote producer! The end-user only knows that they have a directory of available portlets from which they can pick and choose. What could be easier?


Back to top
Before digging in to how WSRP actually works, let‘s briefly investigate the different moving parts within a WSRP architecture.Figure 3 below illustrates each of the primary actors within a WSRP architecture and the role a portal plays in aggregating the mark-up fragments. Although this diagram shows a portal consuming WSRP portlets from only a single producer, there is no reason why a portal couldn‘t consume portlets from any number of WSRP producers. The WSRP Specification defines the following actors within a WSRP architecture:
WSRP producer: This is a Web service that offers one or more portlets and implements a set of WSRP interfaces, thus providing a common set of operations for consumers. Depending on the implementation, a producer could offer just one portlet, or could provide a run-time (or a container) for deploying and managing several portlets. The WSRP producer is a true Web service, complete with a WSDL and a set of endpoints. Every producer in WSRP is described using a standardized WSDL document. WSRP portlet: A WSRP portlet is a pluggable user interface component that lives inside of a WSRP producer and is accessed remotely through the interface defined by that producer. A WSRP portlet is not a Web service in its own right (it cannot be accessed directly, but instead must be accessed through its parent producer). WSRP consumer: This is a Web service client that invokes producer-offered WSRP Web services and provides an environment for users to interact with portlets offered by one or more such producers. The most common example of a WSRP consumer is a portal.

As alluded to previously, WSRP defines a set of common interfaces that all WSRP Producers are required to implement and which WSRP Consumers must use to interact with remotely-running portlets. Standardizing these interfaces allows a portal to interact with remotely-running portlets generically, since it has a well-defined mechanism for communicating with any WSRP-compliant producer. The WSRP Specification requires that every producer implement two required interfaces, while allowing them to optionally implement two others as well:
Service Description Interface (required): The Service Description Interface allows a WSRP producer to advertise its capabilities to perspective consumers. A WSRP consumer can use this interface to query a producer to discover what portlets the producer offers, as well as additional metadata about the producer itself. This interface can act as a discovery mechanism to determine the set of offered portlets, but also importantly allows consumers to determine additional information about the producer‘s technical capabilities. The producer‘s metadata might include information about whether the producer requires registration or cookie initialization before a consumer can interact with any of the portlets. Mark-up Interface (required): The Markup Interface allows a WSRP consumer to interact with a remotely running portlet on a WSRP producer. For example, a consumer would use this interface to perform some interaction when an end-user submits a form from the portal page. Additionally, a portal might need to simply obtain the latest mark-up based on the current state of the portlet (for example when the user clicks refresh or interaction with another portlet on the same page takes place). Registration Interface (optional): The Registration Interface allows a WSRP producer to require that WSRP consumers perform some sort of registration before they can interact with the service through the Service Description and Mark-up interfaces. Through this mechanism a producer can customize its behavior to a specific type of consumer. For example, a producer might filter the set of offered portlets based on a particular consumer. In addition, the Registration Interface serves as a mechanism to allow the producer and consumer to open a dialogue so that they can exchange information about each others‘ technical capabilities. Portlet Management Interface (optional): The Portlet Management Interface gives the WSRP consumer access to the life cycle of the remotely-running portlet. A consumer would have the ability to customize a portlet‘s behavior or even destroy an instance of a remotely-running portlet using this interface.
Listing 1 shows an example WSDL definition of a service which supports both the required and optional interfaces"



Back to top
One of the primary benefits of using a portal is that a portal user can customize the set of applications (portlets) that are available to him. The user can create his own pages and add in new portlets as he sees fit. However, to customize the portal in such a manner, he must first be aware of what portlets are available. If there is a central registry (or potentially several registries), portal users can dynamically discover and bind to new portlets, thus creating a work environment tailored to their specific needs.
From the portlet providers‘ point of view, a centralized registry is equally important since it allows them to publish and describe the portlets which they offer. Providers can provide textual descriptions, categorizations, and other meaningful metadata which richly describe their portlets so that consumers can more effectively discover these services. After all, what is the point of offering portlets to a community if no one knows that they exist?
Universal Description Discovery Interface (UDDI) provides just such a mechanism to bring together WSRP producers who have portlet services to share and WSRP consumers who are seeking to leverage new applications within their work environment. Since UDDI has become the standard for Web services discovery, it is only natural that UDDI also serves as the backbone for portlet discovery. Portlet discovery, however, does throw a few quirks into the mix -- a portlet is not a true Web service after all.
As mentioned above, in the WSRP world there are WSRP producers which are true Web services and WSRP portlets which can only be accessed through the API provided by their producer. While a WSRP portlet can be logically thought of as a service, it is not a true Web service since it does not offer an API by which a consumer could invoke it directly. However, the most common use case when dealing with portlet discovery would involve an end-user looking to find a portlet to add into one of his portal pages. The end-user has no concept of a WSRP producer, nor should he have any reason to understand the underpinnings of WSRP. However, since a portlet can be only be accessed through its producer, both the WSRP portlet and the WSRP producer must be published in the registry.
It should be noted that once a consumer has discovered a portlet service within the registry, the portlet‘s metadata will contain all of the information necessary for the consumer to directly contact the producer and consume the portlet. Portlet discovery strictly acts as a mechanism to allow producers to describe their portlet services in a central location where potential consumers can discover them.

Figure 4 shows a typical usage scenario, which normally has the following steps:
A provider has developed a set of portlets which have been made available by setting up a WSRP producer and exposing them as WSRP portlets. The provider wants to make these portlets available to the community, so he publishes them to a central UDDI directory. Since UDDI exposes a Web service interface itself, the provider would likely perform this task either through a custom built UI or through one provided by the UDDI Server. An end-user is looking to add a portlet to his portal. Using the tools provided by his portal (or a custom-written tool specifically for the purpose), he performs a search for portlets. Once the user has found a portlet that he wishes to add to his portal, he easily adds the new portlet application to one of his portal pages. Alternatively, a portal administrator could search the UDDI registry for portlets and make them available to end-users by adding them to the portal‘s internal registry. When the user now accesses the page to which he added the new portlet, it now contains the remotely-running portlet. Behind the scenes the portal is making a Web service request to the remote producer, and the producer is returning a mark-up fragment for the portal to integrate into the portal page. However, the end-user is completely shielded from the nitty-gritty details of WSRP -- all he knows is that he was able to seamlessly and easily integrate a new application into his portal.


Back to top
This paper introduced Web Services for Remote Portlets (WSRP) and showed how you can utilize the power of WSRP to easily integrate a new application into an existing portal. The advent of WSRP means that you are no longer limited to being able to reuse only back-end services, but can instead reuse presentation-oriented services as well. Imagine how WSRP could be used to facilitate the development of an entire network of presentation-oriented Web services. Once in place, portal users can easily discover and use any number of these services. There is no need to have a developer create custom adapters, build client code, or spend time locally deploying the portlets. Adding portlets to a portal work environment is simply just a couple of mouse-clicks away.
While this paper just touched the surface of the technical details behind WSRP, hopefully you now have a general idea of how WSRP could become a powerful mechanism to foster sharing and reuse of front-end applications. For more information on WSRP please refer to the resources below.


Back to top
Download theWSRP Conformance Test Kit from alphaWorks.
Find theWSRP Specification 1.0 on the OASIS Web site.
Learn more about WSRP in theWSRP Primer from OASIS .
For more information on the Java Portlet Specification, Sun‘sIntroduction to JSR-168 Whitepaper is a nice starting point.
You can find the JSR-168 Specification and API can be found onthe Java Community Process Web site.
Get a good overview of Web services in Arthur Ryman‘s"Understanding Web Services" (developerWorks, July 2003).
To learn more about UDDI and the role is plays in a Service Oriented Architecture, visit the"The role of private UDDI nodes in Web services" series by Steve Graham (developerWorks, May 2001).
Browse for books on these and other technical topics.
Get involved in the developerWorks community by participating indeveloperWorks blogs.
The IBM developerWorks team hosts hundreds oftechnical briefings around the world which you can attend at no charge.
Want more? The developerWorksSOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.


Back to top


Bryan Castle is a Senior Consultant with Booz Allen Hamilton. He specializes in developing Web-based technology solutions, including Service-Oriented Architecture and distributed computing technologies using the J2EE platform.


Back to top
_xyz