Previous columns have separately addressed Web services and also enterprise portals. Last month's column) bridged both topics and discussed the use of Web services within enterprise portals, through specification of Web services for remote portals (WSRP). For this and last month's columns, I have drawn on the WSRP specifications and also the "WSRP Overview" presentation on the OASIS Web site at http://www.xml.org/, 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 in this column. Please note that these figures are sourced from OASIS, copyright 2002-2003 OASIS, all rights reserved.

In Part 1 of this WSRP column, we discussed a scenario where an employee portal consumes a service provided by the human resources (HR) function within a corporation. Now let us assume the human resources department runs a portal that provides various HR related portlets. Some are intended for use only by HR staff, such as a payroll portlet or a staff record portlet. However, there are other portlets that are of interest to all employees. For example, a variable pay portlet calculates the variable pay based on current revenue and an HR information portlet providing HR related news.

Assuming that the enterprise has a corporate registry only accessible from the intranet, an HR portal administrator uses the portal publish function to create remote portlet Web service entries for the variable pay portlet and the HR information portlet in the corporate registry. Thus, these portlets become available for integration in other portals in the corporation. For example, the administrator of the corporation's employee portal can find the remote portlets' Web services published by the HR portal using the portal's built-in registry browser and can integrate them into the portal with a single click.


Figure 4: WSRP Enables Web Services in Applications (Source: OASIS)

Figure 4 shows that applications can also use WSRP services with plug-in mechanisms such as standard simple object access protocol (SOAP) and Web services description language (WSDL) Web services, or by using COM components or ActiveX controls. In this case, the client application plug-in adheres to WSRP protocol and contracts, just as a portal does.

It is expected that WSRP will lead to a more flexible market for Web services. Much of the complexity in adding Web services to portals or to applications is removed by the use of WSRP. Web Services will typically be charged on an annual or monthly subscription, or alternatively on a per-use basis. Some Web Services may only be needed occasionally. Figure 5 illustrates that Web Services can be added and removed dynamically using WSRP.


Figure 5: WSRP Enables Web Services to be Added and Removed Dynamically (Source: OASIS)

When an end user dynamically adds a portlet to a page in the portal, the portal invokes the WSRP service. This specifies a new portlet instance (shown as "I" in Figure 5) that allocates a newly created portlet instance on the portal side.

When the user views the page containing the new portlet instance, the portal gets the portlet WSRP markup defining the fragment that is to be displayed. The returned markup may contain portlet action links "A" and/or a portlet session identifier "S" if the WSRP service wants to maintain the session state to store details about the session for later reference. The portal may need to rewrite some action links to make them work in the final markup sent to the browser, and must store any returned session details to use for later reference with each subsequent request.

When the user clicks on a link in the markup, a request is sent from the browser to the portal. The portal intercepts the request to map it to the invocation of the WSRP service. It passes the session identifier to allow the WSRP service to look up the previously stored session details. The WSRP service then can restore those details and change the state back to what it was when the session was previously active.

When the Web service has completed its operation, the portal refreshes the page and a new user-interaction cycle can start again. Alternatively, when an end user does not need a portlet instance anymore, Figure 5 shows that it can be discarded from the portal page. The portal identifies the WSRP Web service that is not needed and destroys the portlet instance. All related resources are released.

Figure 6 shows that WSRP fits into the context of the Web Services standards. It uses WSDL to formally describe the WSRP service interfaces; SOAP can be used for invocations of WSRP services. Furthermore, Figure 6 shows that WSRP has overlap with Web services for interactive applications (WSIA) with which it shares a common base of interface and protocol definitions.


Figure 6: WSRP and Related XML Standards (Source: OASIS)

WSRP defines the notion of valid fragments of markup based on the existing markup languages such as hypertext markup language (HTML), extensible hypertext markup language (XHTML), VoiceXML and compact hypertext markup language (cHTML). For markup languages that support style definitions, WSRP also defines a set of standard style names to allow portlets to generate markup using styles that are provided by WSRP-compliant portals so that their markup fits nicely into the look and feel of the consuming portal.

Figure 7 is an example of a high-level portal architecture that may be employed for combined use of local and remote portlets as well as making local portlets available via WSRP for use by other portals.


Figure 7: Enterprise Portal Architecture Using WSRP (Source: OASIS)

Most portal clients access the portal via the hypertext transfer protocol (HTTP), either directly or through appropriate gateways such as wireless application protocol (WAP) phones or voice gateways. The markup languages used by these devices may be very different. WAP phones typically use wireless markup language (WML), iMode phones use cHTML, voice browsers mostly use VoiceXML and the well-known PC Web browsers use HTML.

When aggregating pages for end users as shown in Figure 8, the portal invokes all portlets that belong to a user's page through a local portlet application programming interface (API). This may be a portal vendor-specific API, or via WSRP or its Java counterpart, the portlet API defined in JSR 168. This is a competing approach to WSRP. WSRP has been developed and refined through OASIS, while JSR 168 has been developed largely by SUN and submitted to the W3C. Further details are available from http://www.w3c.org/.


Figure 8: Enterprise Portal Adapters Using WSRP (Source: Peter Mimno)

While local portlets can be expected to provide a large part of the base functionality for portals, the remote portlet concept allows dynamic binding of a variety of remote portlet Web services without any installation effort or code running locally on the portal server. Also, portals may wrap local portlets and publish them as remote portlet Web services for integration by other portals. Conversely, remote portlet Web services can be integrated into portals by wrapping them in a proxy written to the local portlet API.

Web Services can be used by enterprise portal vendors to provide ready access in real time to related data sources without having to build specific gadgets or portlets written for each data source format. This expands the access to different data sources that are available to the enterprise portal product. The single sign-on capability of the enterprise portal also provides central access control by Web Services to different data sources, resulting in more effective and potentially more powerful central security control.

However, the greatest benefit that the use of Web services offers over EAI in this situation is that real-time access to Web services enables data Last month's column – accessed from the enterprise portal – to also be changed in real time to reflect relevant updates. It is then possible to use the enterprise portal for initiation of application processing that updates relevant data sources with appropriate control and in real time. Obviously, the performance implications and other control implications of this real-time update also must be taken into account.

In summary, enterprise portals benefit from WSRP Web services as follows:

  • Personalized, real-time access through Web services to both structured and unstructured sources.
  • Automatic content population from existing applications and ERP applications in real time via Web services.
  • Content dynamically presented based on the user's role, tasks and security authorization.
  • Dynamic execution, viewing and direct access to relevant information – with real-time update via Web services, if appropriate.
  • Integration with back-end content sources, such as SAP R/3, PeopleSoft, other ERP, CRM and BI applications via Web services support in these products.
  • Assignment of access rights by group or role as defined by administrators.
  • Platform independence, multiple servers and load balancing.
  • Support for alerts, exceptions, notifications and subscriptions over the Internet, intranet and extranet.
  • Single sign-on authentication server, lightweight directory access protocol (LDAP) support, domain server support and trusted user support.
  • Security at the level of information objects, with external authentication using customizable drivers (LDAP, NT or other standards).

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