Portal standards for Web services

Portlets, or portal applets, are visual components that make up a Web page residing in a Web portal. Typically, when an end user requests a personalized Web page, multiple portlets are invoked when that pages is created.

An example is a news/financial portal that displays a single page including updated financial news, a report on how the stock market is doing and the latest information on stocks of interest to the end user. Each component has its own portlet.

Portlets rely on APIs to access various types of information, such as user profile. The lack of standards has led portal server platform vendors to define proprietary APIs for local portal components and for invocation of remote components. This creates interoperability problems for portal customers, application vendors, content providers and portal software vendors.

Java Portlet API and Web Services for Remote Portals (WSRP) standards are being developed to overcome these problems, providing interoperability between portlets and portals, and between portals and user-facing Web services.

Java Portlet API establishes interoperability between portlets and portals. All portlets written to a portlet API will run on all compliant portal servers.

Similarly, WSRP will enable interoperability between portals and WSRP-compliant Web services for portals.

Java Portlet API will cleanly separate portlets from the surrounding portal server infrastructure so that the portlets can run on different portal servers, just as servlets can run on different application servers.

WSRP services are presentation-oriented, user-facing Web services that plug and play with portals or other applications. They are designed to let businesses provide content or applications in a form that does not require any manual adaptation. Portals easily can aggregate WSRP services without programming effort.

Because WSRP includes presentation features, WSRP service providers can determine how end users see their content and applications, and to what degree adaptation, transcoding and translation might be allowed.

WSRP services can be published into public or corporate service directories (Universal Description, Discovery and Integration), where portals that want to display their content can find them easily.

Using WSRP, portals can easily integrate content and applications from internal and external content providers. A portal administrator simply picks desired services from a list and integrates them.

The WSRP standard will define a Web services interface using Web Services Description Language. The standard lets WSRP services be implemented in different ways, be it as a Java/Java 2 Platform Enterprise Edition (J2EE)-based Web service, a Web service implemented on the .Net platform or a portlet published as a WSRP service by a portal.

The standard enables use of generic adapter code to plug any WSRP service into intermediary applications rather than requiring specific proxy code. This will allow implementation of WSRP services on any Web services-capable platform, be it J2EE or .Net. The WSRP technical committee plans to have Version 1.0 ready by year-end.

Java Portlet API and WSRP will be able to cooperate in a beneficial way. WSRP services could be integrated in portals through portlet proxies written to the Java Portlet API. Conversely, portlets could be wrapped in and published as WSRP services.

Once a portlet entry is listed in the UDDI directory, other portals can find and bind to the referenced WSRP service. To make a WSRP service available as a portlet, the portal’s administration may create an entry in the local portlet registry with the information obtained from UDDI.

For example, once the entry is in the local portlet registry users might select it and put copies of it on their pages. When a portlet proxy is invoked during page aggregation, the portlet proxy will generate a Simple Object Access Protocol (SOAP) request and send it to the WSRP service. Then it receives the SOAP response from the WSRP service and provides the result to the portal.

Schaeck is an architect in WebSphere Portal Server development at IBM Corp. and chair of the WSRP technical committee. Hepper is part of the IBM WebSphere Portal Server project and co-leads the group standardizing Java Portlet API.