Portlets 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 page is created. An example is a news/financial portal that displays a single page that includes 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 consists of one or more portlets.

Portlets rely on APIs to communicate with the portal and access various types of information, such as a 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.

The Java Portlet Specification JSR 168 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.

The Java Portlet Specification establishes interoperability between portlets and portals. All portlets written to the JSR 168 Portlet API will run on all compliant portal servers. This 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.

Similarly, WSRP will enable interoperability between portals and WSRP-compliant Web services for portals. 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 can easily 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; UDDI), 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, whether as a 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 the middle of this year.

The 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.

Conclusion
The Java Portlet API and WSRP standards will enable interoperability of portal servers; local portlets; and remote, interactive, user-facing Web services, respectively. The ultimate goal is that a large number of portlets that can run on any compliant portal server locally, as well as remote WSRP services that plug and play with all compliant portal servers, will be available, and that a portal component market comes into existence in which a large variety of application providers, ISVs, and the open-source community offer readily available portlets or visual Web services.

Author Bios
Thomas Schaeck is an architect in WebSphere Portal Server development. He has published various papers and filed 20 patents, and coauthored Smart Card Application Development in Java (Springer 2000) and Pervasive Computing (Addison-Wesley). schaeck@de.ibm.com

Stefan Hepper joined IBM in 1998 and is now engaged in the IBM WebSphere Portal Server project and is the colead of JSR 168 to standardize the Portlet API. He has lectured at international conferences, published papers, and filed patents, and he coauthored Pervasive Computing (Addison-Wesley). SThepper@de.ibm.com