WebSphere Portal Server and Web Services
aggregation, it gets the most recent forecasts for the selected locations and renders a page fragment that displays those forecasts.
This approach only works 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 it, or an employee portal developer would implement the HR portlet according to the interface description of the HR web service. For the weather, an employee portal developer would have to implement a special weather portlet according to the content cache interfaces and install a content cache instance that replicates data with the weather web service. 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 including presentation and application logic as shown in Figure 4. Instead of just providing raw data or single business functions that still require special rendering on the portal side, Remote Portlet Web Services are visual web services including presentation. They are aggregatable web applications that can be invoked through a standard interface using generic portlet proxies on the portal side.
This means that no special portlet code at all needs to be installed on the portal. Use of generic portlet proxies eliminates the need to develop specific portlets for each web service to run on the portal. The task of the administrator 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 into a portal just by finding them and binding to them by creating a new portlet proxy instance bound to the remote portlet web service. Through the use of portlet proxies, remote portlet web services appear to portals just like local portlets and can be selected by users as easily.
Weather Web Service
Figure 4: Example of a portal using remote portlets
In the near future, portals must not only be able to run local portlets, but also to include remote portlets and share local portlets by making them available to other portals as remote portlet web services. Figure 5 gives an example of a corporation that owns an employee portal, a supplier portal and a human resources portal. The employee portal has a weather portlet that runs on the local portlet container while the account, stock, search, variable pay and news portlets run remotely and are accessed by the employee portal through portlet proxies. The account and stock