Previous columns have separately addressed Web services and also enterprise portals. This month's column bridges both topics and discusses the use of Web services within enterprise portals through specification of Web services for remote portals (WSRP). For this and following months' columns, I have drawn on the WSRP specifications and also the "WSRP Overview" presentation on the OASIS Web site at, as published by the OASIS WSRP Technical Committee. Their excellent work with WSRP is acknowledged here. With their permission, a number of figures from that presentation are included here. Please note that these figures are sourced from OASIS, copyright 2002-2003 OASIS, all rights reserved.

Many content providers publish their content live on the Internet using HTTP or FTP servers, or they provide client software that replicates and caches content via proprietary protocols. In each case, integrating content into an enterprise portal is a difficult task. While portals provide some portlets supporting particular content providers out of the box, it is often necessary to develop and install additional portlets for the remaining content providers.

The organization that runs the portal spends much money and effort to integrate a rich set of content from different providers. This is not only a bad situation for portal owners, but also for content providers. It is relatively difficult to include content in portals, and this limits business growth. It also limits the capability to exert some control over the way that content is rendered by the subscriber's portal.

With the definition and development of interoperable Web services for remote portals, WSRP offers the promise of easily accessible Web services to provide access to any data source for easy incorporation in any enterprise portal product.

Web services for remote portals (WSRP) is a standard specification for interactive, user-facing Web services that are designed to be plug-and-play adapters for portals.

WSRP defines a Web services description language (WSDL) interface description for invocation of WSRP services. It defines how to publish, find and bind WSRP services and meta data. WSRP specifies rules for using markup that is emitted by WSRP services, along with applicable security mechanisms, billing information and so on.

Many companies are involved in the definition of WSRP and the development of portal adapters using WSRP. These companies include: BEA, Bowstreet, Divine, Epicentric, Factiva, France Telecom, Fujitsu, HP, IBM, Interwoven, Lexis-Nexis, Lotus, Moravia IT, Netegrity, Oracle, PeopleSoft, Plumtree, Silverstream, Stellent, SUN, Sybase, Tibco, WebCollage, SAP Portals and SeeBeyond.

To allow for easy integration of their content in portals, content providers can use WSRP to surface the content as remote portlets, publishing them as WSRP services in the public, global UDDI directory.

To provide this value-add to subscribers, the content provider serves remote portlets via the desired bindings in addition to the classical content server. Once the content provider has published a WSRP service in the UDDI registry, administrators of portals who wish to use content from the content provider can look up the content provider's business entry in the universal universal description, discovery and integration (UDDI) registry and bind to the WSRP service that offers the desired content. Portlets on the content provider's server are available without any programming or installation effort and can be used immediately by the portal users as shown in Figure 1.

Figure 1: WSRP used for Plug-and-Play Portal Adapters (Source: OASIS)

Portal administrators can find and integrate the WSRP services they need with just a few mouse clicks. They can use their portal's administration facility to browse a registry for WSRP services and select them for automatic integration into the portal. This plug-and-play approach enables content providers to write one interface to their source content for Web services and then describe that Web service using WSDL and WSRP. Similarly, portal vendors only have to develop one generic adapter that is designed to recognize WSRP and WSDL and then incorporate that generic adapter into their portal product. The goals that have been defined for WSRP so this can be achieved are to:

  • Enable interactive, user-facing Web services to be easily plugged into standards-compliant portals.
  • Let anybody create and publish content and applications as Web services.
  • Let administrators browse directories for WSRP services to plug into their portals without programming effort.
  • Let portals publish portlets so that they can be consumed by other portals without programming.
  • Make the Internet a marketplace of visual Web services ready to be integrated into portals.

Figure 2: WSRP Allows Portlets to be Dynamically Added (Source: OASIS)

Figure 2 shows how WSRP adapters can be provided by many content providers as WSRP producers. A portal vendor extracts from the WSRP markup fragments the information that it needs to incorporate the adapter into the enterprise portal. Portals can aggregate presentation from many WSRP services. Additionally, the WSRP services can also be aware of portal context, such as the user's profile, desired locale and markup type, and the user's device type from the portal.

Figure 3 shows a WSRP portlet that has been selected. Its WSRP wrapper describes the source content in a standard way so the portal can incorporate that new adapter into the enterprise portal.

Figure 3: WSRP Allows Portlets to be Dynamically Added (Source: OASIS)

Portals are intermediaries between end users and WSRP services. Figure 3 shows how WSRP aggregates services from different content providers as follows:

  1. The portal administrator of the content provider first publishes a portlet as a WSRP service to UDDI using the content provider's administration user interface.
  2. The administrator of another enterprise portal finds a WSRP service using the portal's UDDI browser, and binds to it with a few mouse clicks.
  3. Users of this second portal can now select remote portlets as they would any local portlet and add them to their tailored portal pages.
  4. The portal providing the portlet as a WSRP service and the portal consuming the portlet, both adhere to the WSRP protocol and contracts, just like any other WSRP service.

Portals off-load significant traffic from content providers by caching content, thereby enabling content providers to serve a huge number of users with little IT infrastructure. By providing WSRP services, content and application providers can leverage portals as multiplying intermediaries to reach end users that they could not reach otherwise.
While portals traditionally have operated in isolation from each other, large corporations are now demanding cooperation between their portal installations. Very soon, enterprise portals will also need to cooperate with supplier or customer portals. Therefore, ultimately portals will need to cooperate over the Internet as well as within intranets.

Next month's column will continue with Part 2 of this discussion of WSRP.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access