Tips for using WSRP with the portal
These are some hints and tips for using WSRP with the portal.
Registration
The WSRP Producer for IBM WebSphere Portal does not support the WSRP Registration interface. This means that WSRP registration is not supported.
Remote portlets on unauthenticated pages
If we add remote portlets to unauthenticated pages that have public sessions switched off, this has the following two consequences:
- Session data is lost for each request.
- An additional request to the Producer is submitted to establish a session.
If we add remote portlets to unauthenticated pages, switch on public sessions. This way we can benefit portal performance and avoid unexpected behavior resulting from the lost session data.
Render URLs for forms
Submitting data to a portlet through forms is semantically an action as the state of the portlet is changed by this request. WSRP strongly enforces the separation of action and render requests according to the corresponding semantics. It prevents the submission of form data through render requests. This means that portlets that use render URLs to submit form data do not work remotely.
Portlets using portal internals
With WSRP we cannot use portal internals in portlets, such as engine objects or engine tags. Portlets that use such internals do not work remotely as WSRP does not supply the infrastructure required for this.
Compatibility of portlets with WSRP
Some of the portlets shipped with WebSphere Portal cannot be provided as WSRP services. The reason is that some additional and more advanced WebSphere Portal concepts and features are not reflected by the current WSRP standard yet. This includes all portal administration portlets, the Portal Search portlets Manage Search and Search Center, and some other portlets provided with the portal.
If portlets contain URLs to other resources, the URLs need to be encoded according to the Java portlet specification to work with WSRP. You might have portlets that serve or link to resources such as images, CSS files, Javascript files or servlets packaged with the portlet. To work in an distributed environment such as WSRP, these portlets need to handle the URLs correctly. The WebSphere Portal WSRP Producer runtime hooks into the URL generation code used by the Java Portlet Specification APIs. In such cases the portal can generate WSRP compliant URLs to allow resources to be proxied by the WRSP Consumer server. In other words, this allows URLs in the browser to point to a resource proxy provided by the WSRP Consumes that routes the request to the appropriate resource provided by the WSRP Producer host.
For example, portlets might contain URLs that include CSS or Javascript files, and to have these portlets provided by WSRP. In such a case, you need to verify the URLs point to the correct locations by encoding them in compliance with the Java portlet specification. If you do not encode the URLs using the JSR API calls, the portlets might not work properly.
The WebSphere Portal resource proxy implementation also supports the serving of relative URLs. Example: A URL points to a CSS file and is encoded using the Java Portlet Specification API. The CSS file in turn contains relative links to further resources such as images. In such a case, requests for those images are also routed and served via the WSRP Consumer resource proxy.
Dynamic titles for remote portlets
The WSRP proxy portlet is written according to the standard portlet API. As the implementation of the standard API portlet container does not support dynamic titles for WebSphere Portal, dynamic titles do not work, even if the remote portlet is written according to the IBM portlet API. This includes calls to the methods of the IBM portlet API PortletTitleListener interface.
Invocation of minimized portlets
The WSRP proxy portlet is written according to the standard portlet API. As the implementation of the standard API portlet container does not support the invocation of minimized portlets for WebSphere Portal, a minimized portlet is not called even if the remote portlet is written according to the IBM portlet API.
Consumer-side configuration of consumed portlets that do not support shared configuration is not supported with WSRP
The configuration of the edit_defaults_compatibility portlet mode is not supported for portlets that are consumed using WSRP.
The PUMA SPI cannot be used with WSRP
The PUMA SPI does not allow use with remote portlets.
Tag Cloud, Tag Center, and Results List portlets do not support WSRP
The Tag Cloud and Tag Center portlets, including the Result List portlet, do not support WSRP. This means that it is not possible for a Producer portal to provide these portlets as remote Web services, or for a Consumer portal to consume them so that its users can use them.
Remote Portlet Web Services (RPWS)
WebSphere Portal v8.0 does not support the IBM proprietary Remote Portlet Web Services (RPWSo that WebSphere Portal Version 4 supported. (This is not the same as WSRP - Web Services for Remote Portlets.)