Tuesday Apr 08, 2008

OpenPortal WSRP 1.0 FCS binary download


The WSRP version 1.0 FCS is the latest stable binary from the WSRP v1 project. This is expected to be the last binary release from the WSRP v1 Project and this project will remain in maintenance mode, only serious issues reported will be fixed from now on. This same binary is integrated into the following releases.

  1. Sun Java System Portal Server 7.2 release and
  2. Java Application Platform SDK Update 5.
From now on all future developments and feature integration will happen only on the WSRP version 2.0 project. 

A. Binary download

  1. WSRP version 1.0 FCS bits  requires
  2. Portlet Container 2.0 RC2

B. WSRP documents:

  1. Install Instructions
  2. User Guide
  3. FAQ

C. Portlet Container documents:

  1. Install Instructions

D. See Also:

  1. Portlet Repository binary

Wednesday Aug 22, 2007

OpenPortal WSRP Project consumed by OpenPortal


The OpenPortal WSRP project is consumed or integrated into the OpenPortal project, Here is a note on some of the integration that was done.

Java Persistence API based (JPA) based datastore :

Added a new datastore for storing WSRP Producer and WSRP Consumer related configurations The file based datastore that OpenPortal WSRP Project is unacceptable as the configurations stored in file would be local to specific portal server node. The JPA based WSRP datastore implementation by default uses derby as backend to store all the WSRP Producer and Consumer related configuration information.


Note : The source code for this resides in the OpenPortal WSRP Project as this can be used outside of the OpenPortal. Watch this space for more details on how to use it in OpenPortal WSRP Project.

User Management:

The OpenPortal project customizes the user datastore of the OpenPortal WSRP Project, its provides user store where WSRP users are created and managed on to the LDAP server that is used by the OpenPortal installation. OpenPortal project creates creates people container under organizational units for each consumer registration The people container is used for creating phantom users that are specific to a consumer registration.


Note : Pls see the other entries on WSRP User Identity Propagation to know more about phantom users and identity propagation techniques

Role Management :

OpenPortal uses roles in LDAP/Access Manager to store explicitly cloned portlets. Explicit clones are portlet clones that are created by consumers that needs to be shared by all the users. Hence the cloned portlet is stored on to the role and all users under that consumer registration are assigned to this role, which makes the portlet clone available to all the users under this consumer registration.


Here is a simple representation, the WSRP Producer and WSRP Consumer stores configuration onto a database. The WSRP Producer uses the AM /LDAP  server to create users and roles for the above mentioned functionalities.


Single SignOn Token(SSOToken) Identity Propagation:

OpenPortal uses AccessManager(AM) to authenticate users, authenticated users are represented by a Single SignOn Token(SSOToken) in AM. Since SSOToken is used only in OpenPortal, the SSO identity propagation is added as an extension by the OpenPortal Project to WSRP Project.


When this option is selected the SSOToken associated with the user is propagated as an UserContext extension by the WSRP Consumer to the WSRP Producer which represents a user. 


Note : This identity propagation mechanism assumes that both Consumer and Producer Portal are OpenPortal installations. Pls see this entry for more details

WSRP Mbeans :

The OpenPortal WSRP Project Mbeans are consumed by the OpenPortal and integrated into the OpenPortal Portal Administration Server (PAS) module, the WSRP Mbeans are deployed on to the Common Agent Container for APG and Orion/Common Agent Container (CACAO/CAC) management server. The OpenPortal administrative console (psconsole) provides a user interface for WSRP administrative purposes using the above Mbeans.


Note: Pls see the architecture here and the intent of this design.

WebService Single Sign On (WSSSO) Portlet :

The OpenPortal project provides a portlet/user-interface that allows users to add/provide Single SignOn information in the form of a username and password. This portlet stores the user credentials that is used by the WSRP Consumer to create a OASIS Username Token profile and propagate the user identity to the WSRP Producer portal.


Note : The WSSSO Portlet uses the SSOAdapter infrastructure to store user credentails, Pls see here for more information on SSO Adapter.


Wednesday Mar 14, 2007

Deploying WSRP Producer and Consumer independently

Here are the steps for deploying WSRP Producer and WSRP Consumer separately on two different boxes or instances.  The deployment diagram is as shown below

To create this deployment configuration, Lets say we have 2 boxes
  1. Producer box
  2. Consumer box

as shown in the below image. We install just the WSRP Producer on the Producer box and WSRP Consumer on the Consumer box




Note on WSRP binary :

When you build the WSRP trunk binary. It would have create a "dist" directory with the following contents

  1. wsrp-configurator.jar
  2. wsrp - binary directory
The wsrp-configurator.jar is for the Java App Platform SDK distribution of the wsrp binaries that  are under the "wsrp" directory.  The configurator provides a java wrapper over the setup.xml that would be invoked by the Java App Platform SDK installer.

The wsrp-configurator.jar has a wsrp.zip file that has all the content of the "wsrp" binary directory.  You can choose to directly use the wsrp binary directory or even unzip the contents from wsrp-configurator.jar and use it.

For sake of simplicity choose to copy the dist/wsrp directory to a machine where you want to install the WSRP Producer and WSRP Consumer and follow the below mentioned  instructions.

Deploying the WSRP Producer :

On the Producer box
  1. Deploy glassfish
  2. Deploy portlet container
  3. To deploy WSRP Producer follow the below instructions
Use the following command to deploy the WSRP Producer :
ant -verbose -f setup.xml deploy-producer -DSERVER_HOME=/opt/SDK1/  -DSERVER_DOMAIN=/opt/SDK1/domains/domain1/

Use the following command to deploy the WSRP Producer admin portlet
ant -verbose -f setup.xml deploy-producer-admin-portlet -DSERVER_HOME=/opt/SDK1/  -DSERVER_DOMAIN=/opt/SDK1/domains/domain1/

Deploying the WSRP Consumer:

On the Consumer box
  1. Deploy glassfish
  2. Deploy portlet container
  3. To deploy WSRP Consumer follow the below instructions
Use the following command to deploy the WSRP Consumer :
ant -verbose -f setup.xml deploy-consumer -DSERVER_HOME=/opt/SDK2/  -DSERVER_DOMAIN=/opt/SDK2/domains/domain1/

Use the following command to deploy the WSRP Consumer admin portlet
ant -verbose -f setup.xml deploy-consumer-admin-portlet -DSERVER_HOME=/opt/SDK2/  -DSERVER_DOMAIN=/opt/SDK2/domains/domain1/

That's it you can access the http://<your-host>:<your-port>/portletdriver/dt on the WSRP Consumer and Producer boxes and administer the respective components.  You can point the Consumer to the Producer installation and render the remote portlets exported by the WSRP Producer.

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