Keywords: WSRP, remote portlet, web service, standard
My group at IBM Research is involved in the development and promotion of standards targeting the portal market. I am the chair of the OASIS WSRP (Web Services for Remote Portlets) Technical Committee and serve as the lead editor for the specifications this committee is producing. The v1.0 specification became an OASIS standard 1 September 2003.
Thomas Schaeck is lead architect for for WebSphere Portal and leading portal standards activities at IBM; he initiated the WSRP and JSR 168 standardization efforts.
The OASIS ( Organization for the Advancement of Structured Information Standards) WSRP (Web Services for Remote Portlets) v1.0 specification (an OASIS approved standard) defines an interface and the semantics necessary for content services to be rapidly added to the set of available content at aggregating intermediaries, such as portals. By using web services as the underlying infrastructure, the platform and technologies used to produce this content and handle user interactions with it become independent choices of the content producer and consumer. WSRP uses WSDL to define the interface such that consumers will be able to interact with all such content services using generic means that are service independent. This enables the rapid addition of these services to the set of available content that can be aggregated into end-user pages as it only requires administrative set-up rather than developer effort. WSRP defines the semantics and information exchange required for such areas as; producing presentation markup fragments that can be composed into a page with other fragments (e.g. same mime type, character set), production of URLs within the presentation markup, processing the activation of such URLs and state management of various types (e.g. sessions, navigational state, portlet configuration, etc.).
The first version of the specification has focused on making these items work in a manner that can run on today's most popular web stacks (in all cases some bugs were reported and fixes made available). In addition, care has been taken to ensure the concepts and available data are aligned with the requirements of the Java community portlet API specification that was being developed during the same time frame. There currently are vendor implementations interoperating using each of the most popular web stacks.
A brief glimpse will also be provided into the ongoing work for defining follow-on versions of the specification. Areas of ongoing work include providing mechanisms for the consumer to coordinate updates to multiple portlets from a single user interaction and defining the markup fragment rules needed in order to aggregate various additional presentation markup types.
3. WSRP Actors
4. WSRP Functional areas
4.1 Producer/Portlet Description
4.2 Generating and Interacting with Markup
4.4 Look and Feel
4.5 Namespacing for the Aggregated Page
4.6 Types of State
4.9 Portlet Lifecycle
5. Future Work
6. Useful References
Portals provide personalized access to information, applications, processes and people. Typically, portals get information from local or remote data sources, e.g. from databases, transaction systems, syndicated content providers, or remote web sites. They render and aggregate this information into composite pages to provide information to users in a compact and easily consumed form. In addition to pure information, many portals also include applications like e-mail, calendar, organizers, banking, bill presentment, host integration, etc.
While different rendering and selection mechanisms may be required for different kinds of information or applications, all of them rely on the portals infrastructure and many operate on data or resources owned by the portal, like user profile information, persistent storage or access to managed content. Consequently, most of today's portal implementations provide a component model that allows plugging components, referred to as portlets, into the portal infrastructure. Portlets are presentation-oriented, interactive web application components rendering markup fragments to be aggregated and displayed by the portal.
Often content is provided by external services and displayed by specific local portlets running on the portal. While this approach is feasible for establishing the base functionality of a portal, it is not well suited to enabling dynamic integration of business applications and information sources into portals. As an example, let us consider the following scenario: An employee portal manager wants to include a human resources service calculating estimated retirement benefits for employees and an external weather service providing weather forecasts. One solution for this scenario is depicted in Figure 1 where a human resources portlet and a weather portlet run locally on the portal server and access remote web services to obtain the required information, i.e. the web services provide data and the presentation layer is implemented in specific portlets.
The HR portlet uses a HR web service to calculate the estimated retirement benefits. By default, it displays a form to query the required input data, e.g. the employee's id. When the employee provides the data to the HR portlet, it invokes the HR web service to calculate the estimated retirement benefits based on that data. It receives the result from the web service and displays it as a page fragment. The weather portlet by default displays weather forecasts for configurable locations and allows the user to select locations in an edit mode. When the weather portlet is invoked during page aggregation, it requests the most recent forecasts for the selected locations from the weather web service and renders a page fragment that displays those forecasts.
This approach only works if all portlets are physically installed at the employee portal; the process of making new portlets available is tedious and expensive; the presentation layer has to be re-developed for each portal. To integrate HR information in the portal using local portlets as described above, either the HR department would implement the HR portlet and give it to an administrator of the employee portal to install, or an employee portal developer would implement the HR portlet according to the interface description of the HR web service, similar effort would be required for the weather portlet. In each case, there is significant cost and loss of time.
Obviously, it would be much more convenient if the HR and weather web services would include application and presentation logic and directly produce markup fragments that are easy to aggregate at the consuming portal, as shown in Figure 2 .
Figure 2: A portal using WSRP
Instead of just providing raw data or single business functions that require special rendering on the portal side, WSRP enables remote presentation-oriented, interactive web services. These services are easy to aggregate and can be invoked through a common interface using generic, portlet-independent means that are built into the portal. In addition, re-implementation of the presentation layer on each portal is avoided. The use of generic portlet proxies consuming all WSRP services conforming to the common interface eliminates the need to develop service-specific portlets to run on the portal.
The task of the administrator is also made easier because portlets can be added dynamically to the environment, and users benefit by having more services made available to them in a timely manner. Administrators can integrate WSRP services into a portal using their portal's administration user interface to find and bind these services with just a few mouse clicks. As a result, the portal binds a portlet proxy to the WSRP services so that they are available to users in the same manner as local portlets. The remainder of this paper explains the WSRP vision, the actors defined by the WSRP specification, provides an overview of the basic WSRP functional area and current efforts for follow-on versions.
Web services have introduced a standardized means of integrating business logic via the Internet. The WSRP standard leverages this to provide the means for integrating of web service based presentation components. WSRP provides a standard that enables all content and application providers to provide their services in a manner where they can easily be discovered and plugged into all compliant portals without additional programming effort on the portals side.
Portal implementations can enable portal administrators to find and integrate WSRP services with just a few mouse clicks, typically by using their portals administration user interface to locate WSRP services and then select some for automatic integration into the portal. Portals act as intermediaries between end users and WSRP services and aggregate services from many different content providers. They often offload significant traffic from content providers by caching content, thereby enabling content providers to serve a huge number of users with little IT infrastructure.
This vision is being realized as a number of vendors have been participating in interoperability testing. As these products become deployed and WSRP used to access remote portlets, a number of benefits can be expected to accrue quickly, namely:
WSRP defines three actors for the interchange needed to generate, aggregate and then process interactions with the markup presented to an end-user. These actors are called Portlets, Producers and Consumers and will be discussed individually in the following sections.
Portlets are presentation-oriented, interactive web application components designed to be aggregated and to communicate with users through the hosting portal server. Typically, portal servers maintain a catalog of available portlets from which end users can select portlets for placement on portal pages. WSRP enables portal servers to use generic means for accessing portlets not hosted locally. This significantly reduces the cost of moving to a portal server deployment model where many portlets are hosted remotely, often to reduce deployment and maintenance issues.
All Portlets, whether local or remote, support a View mode, in which they provide their primary functionality; ranging from rendering static markup to a highly interactive application with a sophisticated screen flow. In addition, portlets may support an Edit mode that provides a portlet specific user interface to edit their configuration data, a Help mode that explains how the portlet should be used and a Preview mode that renders a preview of the portlets appearance. In addition to the different modes, portlets can typically be displayed in different sizes, namely Minimized, Normal, Maximized and Solo.
A typical example for a portlet with multiple views that can be rendered in varying sizes is the market report portlet depicted in Figure 3 . In the view mode in normal size, it displays stock quotes for a list of stock symbols; if the user wants to view details, s/he clicks on the Market Details link which directs the portlet to display an expanded set of information, but remain in the view mode. In the edit mode, accessed by clicking on the Edit button, the user can customize the list of stock quotes displayed. In the help mode, accessed by clicking on the question mark in this example, the portlet informs the user how it works. By clicking on the minimize or maximize buttons, the user can switch the portlet to a minimized or maximized size, respectively.
Portlets can maintain state at different levels: Transient Session State is typically used to reflect conversational state with a particular end user and persistent Configuration State is used to remember settings to reuse in later sessions as well. In the example above, the portlet uses transient session state to remember whether it is in the stock quote list screen or the details screen for each end user and persistent configuration state to store both the list of stock symbols a user is interested in and the stock quotes feed to use. WSRP defines these types of state as well as others related to navigation and interaction.
Portlets may be local or remote to a portal server. We envision that typically, portals will use a mix of local and remote portlets depending on individual tradeoffs between proximity to the portal server and ease of integration. Local portlets are usually tightly integrated with the portal server and typically run on the same physical server or cluster of servers. WSRP services run on remote servers at other places in the intranet or the Internet and are loosely coupled to the portal server.
Most portal clients access the portal via the HTTP protocol, either directly or through appropriate gateways like WAP gateways or voice gateways. The mark-up languages used by these devices may be very different. WAP phones typically use WML, iMode phones use cHTML, voice browsers use VoiceXML while the well-known PC web browsers use HTML. WSRP defines a required field which carries the possible mime types the Consumer can aggregate into the page it is preparing for presenting the interface to its portlets.
WSRP models Producers as "containers of Portlets". In additions to any local services the Producer may offer these portlets, it provides a set of web service interfaces for the use of WSRP Consumers, including:
In order to allow different levels of sophistication for both the Producer and Consumer, parts of this functionality are optional. Various examples of how a Producer might implement particular functionality for varying levels of sophistication are being developed by the TC in the form of Use Profiles.
The Producer optionally manages Consumer registrations. The Producer may require Consumers to register prior to discovering and interacting with Portlets. A registration represents a relationship (often including both technical and business aspects) between the Consumer and Producer. When such a relationship exists, it scopes all the interactions between the Producer and Consumer.
A Consumer is an intermediary system that communicates with Producers (and indirectly, the Portlets they host) on behalf of its users. It gathers and aggregates the markup delivered by the Portlets and presents the aggregated page to its user. Because of this intermediary role, Consumers are often compared to message switches that route messages between various parties. One typical Consumer is a portal, which mediates generation of markup and the interaction with this markup between users and presentation-oriented web application components.
Since the Consumer is an intermediary, aggregating system, the markup sent for display to the user and most interactions with that markup flow through the Consumer. This often results in situations where the user implicitly trusts the Consumer to respect their privacy and security concerns with regards to this information flow.
While the following does not cover all the details of WSRP 's functional areas, it does attempt to organize and provide a high level view of what each functional area provides.
This area involves means by which a Consumer can discover the capabilities of both the Producer and the Portlets it hosts. This information is made available as metadata which the Consumer can get using either the getServiceDescription (for the Producer's metadata) or getPortletDescription operations. Examples of the available information include:
The basic operation for generating markup is getMarkup. This operation is supplied all of the stateful information discussed below and data needed for generating markup that can be aggregated into the page for the end-user. Examples of this data are:
When the MarkupContext structure is returned to the Consumer, it may contain information controlling the cacheability of the markup. The basic caching definitions in WSRP v1.0 are that markup can be supplied from a cache provided:
Interactions with markup in general fall into two categories:
How to specify which of these two types of interactions is discussed in the next section as it involves the "wsrp-urlType" portlet url parameter.
The difficulty with URLs is that in general they need to point at the Consumer so that the Consumer can supply any stateful data needed for interacting with the Portlet and the Consumer then needs to direct the interaction to the proper Producer/Portlet. This results in a scenario where the Portlet knows the details needed for this particular URL while the Consumer controls the overall format and target of such URLS. WSRP defines two solutions to this issue:
Another aspect of generating proper URLs relates to what the Consumer should do when the URL is activated. WSRP defines a portlet url parameter called "wsrp-urlType" to carry this information. This parameter can take one of three values:
As the markup from a portlet gets included on different pages from different Consumers using different layouts and color/font schemes, a reasonable means for producing markup that adapts to these differences is important. WSRP has defined a set of CSS classes which each Consumer is required to support. Use of these classes therefore allows the Consumer control of the overall look and feel while the portlet retains control of its content and fine-grained layout questions.
In the process of defining WSRP , a number of different types of state were defined:
As the WSRP Technical Committee examined the security aspects of the protocol, it was determined that there was significant, and likely sufficient efforts happening to define security layers that would operate below to protocol to provide the necessary security measures. For the v1.0 specification, it was determined that the message level security standards (see the OASIS Web Services Security TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss) were still under development and not sufficiently supported by the common web stacks for WSRP v1.0 to require support for them. As a result, the underlying transport level security is the defined means to achieve secure communications for WSRP v1.0 though it is expected that messgae level support will also be specified in a future version.
There are two forms of extensibility for WSRP :
The portlet lifecycle starts with its declaration in the Producer's metadata to be a hosted portlet. In general these published portlets should be considered to not be configurable, though one could envision a scenario where a unique configuration per Consumer registration is possible (requires pushing the portlet state to the Consumer or doing a multi-key lookup on the Producer). In general, unique configurations happen when a portlet is cloned, either by an explicit invocation of the clonePortlet operation or by the "clone-on-write" semantics of the performBlockingInteraction operation. In either case, once a clone is generated it may be uniquely configured in any of several ways. These include the Consumer invoking the portlet property operations, the user interacting with the portlet in "Edit" mode or normal invocations of performBlockingInteraction causing configuration updates.
A cloned portlet's lifecycle ends either when the Producer decides to throw away the clone or when the Consumer invokes either destroyPortlets against the cloned portletHandle or deregister against the scoping registrationHandle,
Even as vendors are working on implementing WSRP v1.0 (eight known implementations to-date) and the TC works on use profile definitions and conformance assertions to help guide both the production and marketing of those implementations, the TC has also started work on a number of areas where time was lacking relative to defining these things in the v1.0 specification. A few of these areas are:
The following is a list of useful references for those seeking additional information:
The members of the OASIS WSRP Technical Committee have worked hard over the past couple of years to achieve a common understanding of the needs and possible solutions which then drove the production of the WSRP v1.0 specification.
XHTML rendition created by gcapaper Web Publisher v2.1, © 2001-3 Schema Software Inc.