WebSphere Portal Server and Web Services
Figure 9: Portals and web services
Another scenario for use of web services by portals is sharing of portlets with other portals. In this scenario, a remote server, e.g. another portal publishes portlets as remote portlet web services in a UDDI directory. The portal can now find the remote portlet services in the directory and bind to them. As a result, the remote portlets become available for portal users without requiring local installation of portlet code on the portal itself (see Figure 9, portlet proxies for stocks and banking).
Web Services used by Portlets - Today
In the past, portlets could access applications and information in different ways. In the intranet this typically happens using database connections, LDAP connections, Java RMI, DCOM, CORBA, etc. Over the Internet, in most cases the HTTP protocol is used to send requests to remote applications and receive results. Within short time, SOAP will be the primary communication mechanism for invocation of remote services by portlets and will incrementally replace the mechanisms listed above.
With SOAP and UDDI, communication between web services and their clients and management of web services in global and corporate directories is unified. This allows programmatic finding, binding and usage of web services. Web services can be formally described using WSDL descriptions that can be used by appropriate tools to generate SOAP proxies for specific programming languages. Also, there are tools that can create web services and WSDL descriptions from existing code.
Figure 10 shows how a portlet that uses a web service. When a portlet receives a request that requires invocation of a remote service, the portlet 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 service 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 portet in the form of an appropriate object.