Portals provide personalized access to information, applications, processes, and people. Typically, portals get information from local or remote data sources such as databases, transaction systems, syndicated content providers, and remote Web sites. They render and aggregate this information into composite pages to provide information in a compact and easily consumable form. Many portals include applications like e-mail, calendars, organizers, banking, and bill presentment, just to name a few.

Different rendering and selection mechanisms are required for different information and applications, but they all rely on the portal's infrastructure and 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 portlets into the portal infrastructure. Typically, portlets run on the portal server, processing input data and rendering output. Figure 1 shows a typical portal page.

Often, content is displayed by local portlets running on the portal. While this is useful for portlets that are used frequently and are under high load, it's not well suited to dynamic integration of business applications and information sources into portals.

Consider the following scenario. An employee portal manager wants to include a human resources service calculating variable pay for employees and an external weather service providing weather forecasts. One solution for this scenario is depicted in Figure 2 ­ a human resources portlet and a weather portlet run locally on the portal server and access remote Web services to obtain the required information.

The HR portlet uses an HR Web service to calculate the variable pay. By default, it displays a form to query the required input data, for example, the employee's position. When the employee provides the data to the HR portlet, it invokes the remote Web service to calculate the variable pay 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 users to select locations in an edit mode. When the weather portlet is invoked during page aggregation, it gets the most recent forecasts for the selected locations and renders a page fragment that displays those forecasts.

This approach works only if all portlets are physically installed at the employee portal; the process of making new portlets available is tedious and expensive. To integrate HR information in the portal, either the HR department would implement the HR portlet and give it to one of the administrators 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 problems would occur for the weather portlet. In each case, significant effort is required to make the portlets available.

Obviously, it would be much more convenient if remote Web services would appear as remote portlets that include presentation and application logic, as shown in Figure 3.

Instead of just providing raw data or single business functions that require special rendering on the portal side, remote portlet Web services (RPWS) are user-facing Web services including presentation. They're aggregatable Web applications that can be invoked through a standard interface using generic portlet proxies on the portal side. No special portlet code needs to be installed on the portal. Generic portlet proxies eliminate the need for specific portlets for each Web service.

The administrator's task is made much 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. Additional remote portlets can be included in a portal. Simply find them and bind to them by creating a new portlet proxy instance bound to the RPWS. Through the use of generic portlet proxies, the RPWS appears to portals just like a local portlet and can easily be selected.

WebSphere Portal Architecture
To allow for systems using remote portlets, WebSphere Portal provides an open architecture. Figure 4 shows a high-level view of the relevant components, interfaces, and protocols.

Portal clients access the portal via the HTTP protocol, either directly or through appropriate proxies or gateways, such as WAP or voice gateways. The markup languages used by these devices may be very different. Typically, WAP phones use WML, iMode phones use cHTML, voice browsers use VoiceXML, and PC Web browsers use HTML

When aggregating pages for portal users, the portal invokes all portlets that belong to a user's page through the Portlet API.

Portlets
Portlets are pluggable components running inside a portal's portlet container; they're written to a Portlet API that extends the Servlet API. However, portlets run in a portal environment while servlets run standalone in a servlet container. While servlets communicate directly with their clients, portlets are invoked indirectly via the portal application. In order to properly run in the context of a portal, portlets must produce content suited for aggregation in larger pages, i.e. portlets must produce markup fragments that can be aggregated. There are two kinds of portlets:

• Local Portlets: Run on the portlet server, local portlets are deployed by installing Portlet Archive files on portal servers and are invoked by the portal server through local method calls. Local portlets provide minimal latency times. However, installation usually requires assurance that the portlets are not erroneous or even malicious.
• Remote Portlets: Run as Web services on remote servers, remote portals are published as Web services in a Universal Description, Discovery, and Integration (UDDI) directory to be easy to find and bind to. An RPWS is bound by adding a portlet proxy to the portal's portlet registry when an administrator finds and selects the RPWS in the UDDI directory. Portlet proxies are generic, local placeholders that invoke portlets located on remote servers through a Remote Portlet Invocation (RPI) protocol based on the Simple Object Access Protocol (SOAP).

When the portal receives a servlet request, it generates and dispatches an action for the portlet affected by parameters in the request and then invokes all portlets that have to be displayed through the portlet invocation interface in a second step (see Figure 5). While portlets must implement the invocation methods required by the Portlet API, internally they may be implemented differently. A good pattern for portlet programming is Model-View-Controller, which separates the portlet functionality as follows:

• A controller receives incoming requests.
• Commands are invoked, operating on a model that encapsulates application data and logic.
• Views are called for presentation of the results.

Web Services
The Web services concept allows business applications to communicate and cooperate over the Internet. Web services implies a paradigm shift from how the Internet used to work. While traditional applications interacting with services in the Internet know those services a-priori and need to be pointed to them manually, the Web services concept allows applications to find Web services in a standardized directory structure and bind to these services with minimal human interaction.

Web services allows objects to be distributed across Web sites so clients can access them via the Internet. Global service registries promote and discover distributed services. Clients needing a particular service can query the global service registry to find services that suit their needs. They can select a service, bind to it, and use it for a certain period of time. As service discovery, and selection in some cases, can be performed without human interaction, services can be switched quickly. Automated service discovery also allows robust service networks. If multiple Web services provide identical functions, clients can easily switch to a back-up system when a service fails.

The most important standards in this area are UDDI for registration and discovery of Web services; the Simple Object Access Protocol (SOAP) for communication between Web services; and the associated Web Services Description Language (WSDL) for formal description of Web service interfaces.

Web Services Used by Portlets
Web services can be formally described using WSDL descriptions that can be used to generate SOAP proxies for specific programming languages. Also, there are tools that can create Web services and WSDL descriptions from existing code.

When a portlet receives a request that requires invocation of a remote service, it makes calls on a SOAP proxy object. The proxy takes the parameters, marshals them into a programming language­independent SOAP request, and sends this request to the remote Web service. The Web ser-vice has a SOAP wrapper that receives the SOAP request, unmarshals the parameters, and invokes the local service implementation with these parameters. When the service returns the result, the SOAP wrapper marshals the result data into a programming language­independent SOAP response and sends it back to the SOAP proxy. The SOAP proxy finally unmarshals the result data and returns it to the calling portlet in the form of an appropriate object.

To simplify writing portlets using Web services, IBM provides a service proxy generator tool that automatically produces client code from a WSDL interface document, and optionally a service implementation document. If only a service interface document is used, the service proxy generator tool generates a generic service proxy that can be used to access any implementation of the given service interface. If both a service interface and a service implementation are used, the service proxy generator tool generates a service proxy that will access only the specified service implementation. The service proxy contains code specific to a binding within the service interface. For example, if the binding is a SOAP binding, the service proxy will contain SOAP client code to invoke the service.

Remote Portlet Web Services
To allow for dynamic integration of portlets in portals without installing portlet code locally, portlets themselves have to be provided as Web services. This requires an RPWS interface description in WSDL, which defines a common set of methods for all remote portlets and the required parameters, as well as the return values, corresponding to the Portlet API. Remote portlet services don't have to be implemented in Java; they can be implemented in other languages as long as they adhere to the same WSDL description.

Web service providers who want to publish RPWS must publish appropriate entries to a UDDI directory, referencing the RPWS interface WSDL description.

Once a remote portlet has been published, portal administrators can use portal administration tools to search the UDDI directory for Web services that implement the RPWS interface and make some of the matching portlet Web services available to users by adding them to the portal's portlet registry.

Once the portlets are in the registry, users can select them to be displayed on their personal pages.

When a page that references a remote portlet is rendered, the portal uses a portlet proxy to invoke the RPWS. The portlet invokes the portlet proxy exactly as it would invoke a local portlet, passing PortletRequest and PortletResponse objects. The portlet proxy internally invokes a SOAP proxy to marshal all parameters into a SOAP request and sends it to the remote server hosting the RPWS. The SOAP wrapper on the Web service side unmarshals all information in the incoming request and calls on the remote portlet.

For the remote portlet, it's transparent whether it's invoked directly by a portal engine or indirectly through the Web service interface. In each case, it processes the input parameters and returns a PortletResponse object.

The SOAP wrapper marshals the response into a SOAP response and sends it back as the reply to the SOAP proxy, which in turn unmarshals the response for the portlet proxy that finally returns a PortletResponse object to the portal engine that initiated the request.

Web Services in IBM WebSphere Portal
The mechanisms for publishing portlets as RPWS, finding RPWS, binding to them, and using remote portlets must be integrated seamlessly into portal products. Five different dialog flows need to be provided (see Figure 6).

Using remote portlets: Users select and use remote portlets transparently, just as easily as local portlets. Before publishing portlets or looking for remote portlets, one or more UDDI servers must be configured. WebSphere Portal manages these configurations, stores the user name and password securely in the system-wide credential vault, and makes use of the registered servers in the publish-and-find dialogs.

REGISTERING A UDDI SERVER
The administrator can register a new UDDI server using the "Manage Web services" dialog. WebSphere Portal prompts for a display name for this registry, the inquiry URL and the RPWS tModel key that is valid in the scope of the UDDI server. If the server is used for publishing as well, a publish URL can be supplied.

Portlets are published via the "Publish portlets" dialog. The user can select one or more portlets to be published using the standard "Get portlets" dialog. By default, the name under which the portlet is published to the UDDI registry is taken from its registration information within WebSphere Portal. However, the administrator can modify the name and description for each portlet per supported locale. Once the naming is ready, the administrator selects a UDDI registry to publish to. This registry must have already been configured via the "Manage Web services" dialog. The publishing dialog automatically displays a list of all business entities in the selected UDDI registry that the current user has the right to publish to. If none of the existing businesses are appropriate or if there is no such business entity, the user can create a new business on the fly.

Finding and integrating remote Web services as portlets is simple: the "Integrate a Web service as a remote portlet"option lets the user select one of the preconfigured UDDI registries to search in. The administrator can search for all portlets, all portlets in a business entity, or portlets by name. The dialog will find only those portlets that are compliant with the RPWS interface by making use of the associated tModel key.

From the search results, the administrator can select the RPWS to integrate. Finally, WebSphere Portal adds the remote portlet to its portlet registry, making it available for portal users.

Using a remote portlet is as simple as using a locally installed portlet ­ users can select remote portlets in the "Work with pages" dialog.

Publishing Portlets as Remote Portlet Web Services in UDDI
Only portal administrators are allowed to publish portlets as RPWS into a UDDI directory. After logging in for the first time, the administrator must configure a list of UDDI registries to use by selecting the "Manage Web services" dialog (see Figure 7). For security reasons, user credentials are omitted in this dialog. They're only required for the publish operation and can be ignored for the integration and inquiry operations. The "Provide registry authentication information" dialog lets the administrator provide the required credentials (see Figure 8).

To make a portlet available in UDDI the administrator uses the "Publish portlets" dialog. He or she can select the portlet or portlets to publish in addition to the destination registry and business (see Figure 9).

To publish a particular portlet to UDDI as an RPWS, the administrator presses the Publish button.

Finding and Binding to Remote Portlet Web Services
Finding and binding to RPWS is allowed for administrators. To find an RPWS, the administrator selects the "Integrate a Web service as remote portlet" dialog.

When the administrator presses the "OK" button, WebSphere Portal queries the UDDI directory for all RPWS that meet the search criteria.

To add the remote portlet to the WebSphere Portal portlet registry and make it available to users, the administrator checks the portlets from the search result list and presses the "OK" button. As a result, WebSphere Portal gets the relevant information about the RPWS and creates a new portlet proxy entry in its portlet registry to make the remote portlet available to users.

In addition, the administrator can specify whether or not user information may be transferred to the RPWS.

Using Remote Portlet Web Services
For the user, an RPWS is entirely transparent. After logging in, the user can click on the "Work with Pages" link to navigate to the WebSphere Portal Customizer screen.

This screen lets the user select portlets and put them onto a selected page. The screenshot demonstrates that an integrated remote portlet (IBM Proxy Portlet World Clock) is handled exactly like a local portlet (Welcome or Dilbert portlet).

The user can select a proxy for a remote portlet like any local portlet. After the remote portlet is selected in the customizer, it's displayed on the user's page. The left portlet in this screen is remote; the right one comes from a local source.

Conclusion
The concept of remote portlet Web services allows deployment of distributed portals cooperating within an intranet or over the Internet. IBM WebSphere Portal 4.1 supports this concept to allow publishing of local portlets as RPWS and integration of RPWS in WebSphere Portal­based portals with just a few clicks by an administrator, without programming.

At the same time, the ability to host portlets and publish them as RPWS that can be integrated into portals will easily turn WebSphere Portal into a platform that allows content and application providers to offer their services to their customers ­ portals ­ in the most easily consumable form.

Published Jul. 31, 2002— Reads 15,289
Copyright © 2002 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Links

▪ Figure 1

▪ Figure 2

▪ Figure 3

▪ Figure 4

▪ Figure 5

▪ Figure 6

▪ Figure 7

▪ Figure 8

▪ Figure 9

About Thomas Schaeck
After graduating in computer sciences at the University of Karlsruhe, Thomas Schaeck joined IBM to work in JavaTM technology-based development projects related to smart cards, including the OpenCard Framework (the de-facto standard for smart card applications in Java technology), Internet payments, and a digital signature solution. He is now working as an architect in WebSphere Portal Server development. He published various papers, filed 20 patents and was a coauthor of the books "Smart Card Application Development in JavaTM" (Springer 2000) and "Pervasive Computing" (Addison-Wesley 2001).

About Stefan Hepper
After graduating in Computer Science at the University of Karlsruhe, Stefan worked for three years in the Research Center Karlsruhe in the area of medical robotics and component-based software architectures for real-time systems. In 1998 he joined the IBM where he worked with Java Cards in the areas of security and card management. After joining the IBM Pervasive Computing division, he worked on the SyncML reference implementation and is now engaged in the IBM WebSphere Portal Server project and co-leads the JSR 168 to standardize the Portlet API.
He has held lectures at international conferences, published papers, filed patents and was a co-author of the book "Pervasive Computing" (Addison-Wesley 2001).