WebSphere Portal Server and Web Services
The SOAP wrapper marshals the response into a SOAP response and sends it back as the reply to the SOAP proxy that in turn unmarshals the reponse for the portlet proxy that finally returns a PortletResponse object to the portal engine that initiated the request.
Use of Web Services in IBM WebSphere Portal Server
In order to be easy to use, the mechanisms for publishing portlets as remote portlet web services, finding remote portlet web services, binding to them and using remote portlets must be integrated seamlessly into portal products. We can dentify four different dialog flows that need to be provided (see Figure 13).
Publishing portlets: Administrators can publish portlets to make them available for use by other portals as remote portlet web services.
Finding and binding portlets: Administrators can find remote portlet web services and bind to these portlets.
Using remote portlets: Users must be able to select and use remote portlets transparently, just as easily as local portlets.
Finding and using remote portlets: “Power users” should be able to find remote portlet web services by browsing the directory themselves.
Publishing portlets may either include two or three steps, depending on whether the portal has already been associated with a UDDI business. If this is not the case, WebSphere Portal Server prompts the administrator to enter the required business descriptions and publishes a business entry to the UDDI directory and associates the portal with that entry. Once the portal is associated with a business entry in UDDI, publishing portlets only requires two steps – in the first step, the administrator selects the portlet to be published and in the second step he provides a description for the new UDDI service entry to be created for the portlet.