WSRP Interoperability with BEA Weblogic Portal

These are notes based on interoperability testing with BEA's public producer. More testing will be performed.

• portal-wsrp.sar/default-wsrp.xml contains an example of configuration to access BEA's public producer from JBoss Portal, including an example of registration properties.

• BEA Weblogic Portal versions anterior to 9.2 do not handle producer-sent cookies correctly and do not properly react to InvalidCookie faults. A workaround is provided in JBoss Portal 2.4.2 and 2.6.Beta1 and above.

Custom Data from WLP 10.2 consumer to a JBoss Portal 2.6.4 producer

Sending custom data from WLP 10.2 consumer

BEA has a proprietary mechanism for sending custom data from a consumer to a producer (outside of WSRP's scope, see http://edocs.bea.com/wlp/docs102/federation/Chap-Cust_Data_Trans.html). Bassically you can send data from a WLP consumer down to a producer by adding the object you want to transfer on the request, using the MarkupRequestState.KEY, like:

request.setAttribute(MarkupRequestState.KEY, "TEST");

The WLP consumer will serialize, encode this object (Base64) and add an extension to the SOAP message (getMarkup) with the result, something like:

<v1:extensions>
         <ext1:MarkupRequestState xmlns:ext1='urn:bea:wsrp:ext:v1:types'>
                  <ext1:state>
                               rO0ABXQAC0dFT1JHRSBURVNU
                  </ext1:state>
         </ext1:MarkupRequestState>
</v1:extensions>

You can see the entire SOAP message:

• at JBoss producer side - by using the WSRPExtensionHandler with the debug flag set on true - uncomment the debug init param for MarkupService in JBOSS-PORTAL\server\default\deploy\jboss-portal.sar\portal-wsrp.sar\portal-wsrp.war\WEB-INF\webservices.xml. The SOAP message will be displayed in JBoss Portal's console.
• at WLP consumer side - navigate to http://localhost:7001/YourConsumerApp/monitor and enable the monitor

Handling custom data at JBoss Portal producer level

You can write your own JAX-RPC handler in order to extract the custom data from the SOAP message and to make it available in the remote portlet request. You have to extend javax.xml.rpc.handler.GenericHandler and to override the handleRequest method (see org.jboss.portal.wsrp.handler.WSRPExtensionHandler for reference and the code snippet below - shows how to handle the transfer of a java.util.Map object)

public boolean handleRequest(MessageContext messageContext) {

     ....

     //get the SOAP body

     SOAPBody body = message.getSOAPBody();

     // parse the SOAP body and extract the encoded value

     String markupRequestState = extractMarkupRequestState(body);

     // decode the value

     Map requestAttributes = (Map) org.jboss.util.Base64.decodeToObject(markupRequestState);

     // do something with these values, iterate the map eventually and bind the attributes in WSRP current request       org.jboss.portal.wsrp.servlet.ServletAccess.getRequest().setAttribute(key,requestAttributes.get(key));

....

}

Configure your custom handler for the MarkupService in JBOSS-PORTAL\server\default\deploy\jboss-portal.sar\portal-wsrp.sar\portal-wsrp.war\WEB-INF\webservices.xml file.

Sending custom data from JBoss Portal producer to WLP 10.2 consumer

Using the same proprietary mechanism, a WLP producer can send data to a WLP consumer by adding the object to transfer on the request, using the MarkupResponseState.KEY, like:

request.setAttribute(MarkupResponseState.KEY, "TEST");

A WLP producer will Base64 encode to object and will add the value as an extension in the response SOAP message (getMarkupResponse), something like:

<v1:extensions>
         <ext1:MarkupResponseState xmlns:ext1='urn:bea:wsrp:ext:v1:types'>
                  <ext1:state>
                               rO0ABXQAC0dFT1JHRSBURVNU
                  </ext1:state>
         </ext1:MarkupResponseState>
</v1:extensions>

The same behaviour can be accomplished in a WLP consumer - JBoss Portal producer scenario using the custom JAX-RPC handler: override the handleResponse method, use org.jboss.util.Base64.encodeObject(serializableObject) and add the extension to the SOAP message.

DOWNSIDE:

However, a downside of this approach is that, in case of sending custom objects, you need to have the same version of the class on the producer as well, otherwise the deserialization will fail. Therefore is safer to use primitives and common java objects