WebSphere Portal Server and Web Services
Portlet Archive Files
HTML, WML, VoiceXML, ...
Portlet API (Java)
Remote Portlet Web Service
Invocation Protocol (SOAP)
XML Cont. Form.
Content Provider Web Services
Publish/Find Web Services (SOAP)
Figure 6: WebSphere Portal Server architecture including web services and remote portlets
Portal clients access portals via the HTTP protocol, either directly or through appropriate proxies or gateways like WAP gateways or voice gateways. The mark-up languages used by these devices may be very different. WAP phones typically use WML, iMode phones use cHTML, voice browsers mostly use VoiceXML while the well-known PC web browsers use HTML. To accommodate different devices, portals need to support different mark-up languages.
When aggregating pages for portal users, the portal invokes all portlets that belong to a user’s page through the Portlet API. We differentiate two different kinds of portlets:
Local Portlets run on the portal server itself. They are deployed by installing Portlet Archive files on portal servers and are invoked by the portal server directly through local method calls. As local portlets run on the portal server itself, they provide minimal latency times. However, installing portlets usually requires assurance that the portlets are not erroneous or even malicious.
Remote Portlets run as web services on remote servers. They are published as web services in a Universal Description, Discovery and Integration (UDDI) directory to be easy to find and bind to. A remote portlet web service is bound by adding a Portlet Proxy to the portal’s portlet registry when an administrator finds and selects the remote portlet web service 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).
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 large number of remote portlet services without any installation effort or code running locally on the portal server.