|Apache | Portals | WSRP4J|
WSRP Producer Architecture
Producer and consumer are provided with a very modular architecture enabling an easy exchange of module implementations. All modules excel by interfaces based on the WSRP object model hiding the runtime environment's (portal's) object model and thus gaining independence of changes in the environment's implementation or design.
The WSRPEngine is the WSRP implementation endpoint. This class must be deployed in the app server (Tomcat) as a web service. The WSRPEngine implements the WSRP protocol specific ports (=interfaces) and does the corresponding protocol handling. There are four WSRP ports:
To be able to reuse Portal functionality regarding session and request handling when invoking a portlet the WSRPEngine must be able to access the HttpServletRequest.
This component manages and provides access to the registered Consumers.
This component is responsible for generating IDs / handles required for the WSRP protocol handling.
WSRP Object Model
The WSRP object model is being generated from the WSRP specification's WSDL types.
The Provider is the access point for the WSRPEngine to the Provider components which hide the provider (portal) implementation's components required to handle and invoke portlets. All Subcomponents wrap corresponding provider components and map the WSRP object model to the provider object model.
The PortletInvoker wraps the Provider's invocation mechanisms and provides the Provider with the required environment.
The DescriptionHandler manages and provides the description of the provider regarding configuration properties like registration or session handling policy, etc. It moreover provides the descriptions of the provided portlets depending on the registration.
The PortletPool manages the portlet instances and is responsible for the portlets' lifecycle management (clone, destroy).
Portlet State Manager
The PortletStateMananger enables a Producer to access a portlet's state as a blob that than can be delegate to the consumer to be stored on consumer side.
No additional session handling implementation for the Pluto provider is required as the session handling concept is completely HTTP (cookie) based and relies on consumer' cookie handling.
The URLComposer must be used for WSRP triggered portlet invocation to create WSRP URLs instead of the portal's URL handling implementation. Therefore the URLComposer is being used by WSRP's version of the DynamicInformationProvider which is being used by the Portlet API implementation to generate portlet URLs. There are two ways how URLs can be composed in a WSRP environment: