Wednesday Mar 26, 2008

OpenPortal WSRP 2.0 interoperability


We just completed the WSRP version 2.0 interoperability test cases with OpenPortal WSRP Project Consumer and IBM Producer.  Here are some screenshots and details about this interoperability test cases.

A. WSRP 2.0 Eventing Interoperability:

IBM interoperability server exports the following 2 portlets that communicate with each other using events:

  1. FlightBookingPortlet
  2. HotelBookingPortlet

Using the FlightBookingPortlet and booking a flight results in an event that is caught by the HotelBookingPortlet and blocks a hotel in the same city. Here is a screenshot of these portlets on the OpenPortal WSRP driver.



B. WSRP 2.0 Shared Render Interoperability:

IBM interoperability server exports the following 3 portlets that communicate with each other using shared or public render paramters:

  1. PublicParamCityInfo
  2. PublicParamCitySelect
  3. PublicParamCityWeather

Using the PublicParamCitySelect and selecting a city results in setting of a shared render parameter that is received by the PublicParamCityInfo and PublicParamCityWeather which display the city information and weather respectively. Here is a screenshot of these portlets on the OpenPortal WSRP driver.



C. WSRP 2.0 Resource Serving:

There is not special portlets for this, if you observe the above eventing and shared render parameter portlet, you could see the image that is being displayed by these portlets are fetched inband or using the getResource() method call on the portlet, which validates the getResource WSRP version 2.0 implementation on the OpenPortal WSRP Project

This interoperability tests all the major WSRP version 2.0 features, stay tuned for more information on the OpenPortal WSRP Project mailing lists.

Tuesday Jan 23, 2007

Interoperability with Netunity

The Enterprise class WSRP Open Source Project is in a reasonable shape so decided to do some interoperability testing with other vendors. Interoperability is a key to any WSRP implementation and we have done such exercise with most of the vendors for Sun Portal Server releases in the past. Eventhough the Enterprise class WSRP OSP Project code base is derived from Sun Portal Server 7.x, there is some considerable changes in the code to support a light weight driver and to be integrated in the future releases of Sun Portal Server, so decided to try some interop tests.

Considering that I am behind a firewall,  I could test only the consumer interoperability to start with, since there is no need to host a producer machine external to the firewall. The initial try is to point the Consumer implementation to Netunity interop server, here is the WSDL URL 

To get the initial consumer creation going, I had to do 2 things which is not different from my previous blog entry on configuring proxies for WSRP.

  1. Set proxies for webcontainer (add -D http parameters to domain.xml of glassfish)
  2. Set the proxies for the admin mbean server (required only if you are running the Mbean server)
    •  Eg : ant -f run.xml -Dhttp.proxyHost=<proxyHost> -Dhttp.proxyPort=<proxyPort> 

The above steps are required only if you are running a consumer behind a proxy i.e. the consumer can reach the producer directly but it can reach it only via a proxy server.

Netunity hosts a producer which supports in-band registration with no registration properties, The registration with the producers went fine and I could create a consumer one pointing to Netunity interop server.  This test validated that there are no issues with both Registration and ServiceDescription Ports.

The next step was to create remote channels,  Upon channel creation was running some basic tests discovered the following issues and fixed them

Issue 1:  For any operation that involves saving preferences both the producers were throwing PortletStateChange required. This is obvious since I was accessing the portlets  as a authless user. The portlet container driver provides a option to login as a user by providing a FORM based authentication. So this was NOT really a issue, upon user login the issue vanishes.

Issue 2:  There were some problem with templates that a consumer generate for rewriting. This problem was easily reproducible with the local producer itself, the fix for this issue is checked in to the code base.

Issue 3: The last issue was a bit hard to crack, since any changes that a users does by editing the portlet did not get saved, nailed the issue to persisting of portletHandle. The fix is to allow persistence of portletHandle for each user. The fix for this is also checked into the code based.

Here is screenshot of the rendered portlets from Netunity producer.

If you are interested in trying the above interop tests. Make sure you have the bits/code after 22nd Jan. The next step is to reiterate the above process for other vendors, will try to post on how stuff goes.




« July 2016