Friday Dec 14, 2007

WSRP version 2.0 implementation on OpenPortal WSRP project

The implementation of the WSRP version 2.0 is in full swing in the OpenPortal WSRP Project community. Here is the link to the project wiki page that tracks this project.
Apart form this the following documents are also available for review
  1. WSRP v2 FSD
  2. WSRP Consumer Admin Usecases
  3. Eventing Usecases
  4. Architecture changes for WSRP v2
  5. Project Plan
If you have comments or questions, pls join the project and post your queries or comments. Stay tuned for the milestone 1 drop which is expected in the next few weeks also for more features in the future drops.

Friday Nov 16, 2007

Uninstalling OpenPortal WSRP and PortletContainer

Here is how you uninstall OpenPortal WSRP and OpenPortal PortletContainer projects after successful installation without having to uninstall the whole glassfish application server. Recently I came across this issue since someone asked about it and this information was not available or documented anywhere.


Uninstall OpenPortal WSRP :

Upon successful install of OpenPortal WSRP, The installer would have created a 'wsrp' directory as <glassfish_install>/domains/domain1/wsrp. There is a setup.xml under this directory, invoking the 'uninstall-wsrp' ant target does the job. Here is the example

# ant -f setup.xml uninstall-wsrp.

Make sure you restart the glassfish application server after this.


Uninstall OpenPortal PortletContainer :

Similar instructions apply the OpenPortal PortletContainer uninstall procedure. Upon successful install of OpenPortal PortletContainer, the installer would have created a 'portlet-container' directory as <glassfish_install>/domains/domain1/portlet-container. There is a setup.xml under this directory, invoking the 'uninstall-pc' ant target does the job. Here is the example


# ant -f setup.xml uninstall-pc.

 Make sure you restart the glassfish application server after this.

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 May 23, 2007

Article on WSRP

We have put together an article on the Open Portal WSRP Project titled "Open-Source Portal Initiative at Sun, Part 4: Web Services for Remote Portlets".  This article provides an overview about the Open Portal WSRP Project and some details about its architecture, deployment, build process and usage instructions.

Following are the links to all the article in this series

Thursday Apr 26, 2007

WSRP 2.0 - A Sneak Peek

Here is the list of features that WSRP 2.0  addresses or adds over WSRPv1 specification. We'll try to contrast and compare with the JSR286 specification in some places and see how these two specifications compliment each other. Here is the list of new stuffs that WSRP v2 brings to the table.

[Read More]

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 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 Dec 26, 2006

A proposal for Portlet Repository Protocol

Here is the excerpt on the proposal that I wrote earlier on using the existing Registry Information Model (RIM) and Maven repository for the Portlet Repository Protocol (PRP) definition. Note : The following content is just a proposal for PRP that I sent earlier on the PRP mailing list by no means a agreed interface.

The Portlet Repository Protocol (PRP) is a initiative that tries to define a set of agreed interfaces and meta-data for implementing portlet repositories. The intent of PRP is facilitate distribution of portlets binaries over the wire, where an administrator or a user can download and install portlets by a look-up or search on a PRP based repository.  Its a cross-vendor initiative and more vendors interested in the definition. We encourage you to join the alias and contribute to this definition.

The proposal is based on using the existing standard's and infrastructure rather than building everything from scratch. The proposal uses/builds-upon on the the following infrastructure.

  1. Maven repository infrastructure and its dependency resolution mechanism for download and install &
  2. The standard webservices (WS) registry infrastructure for meta-data definition/search/publish functionalities.

Here are more details/steps of the proposal on PRP in using the existing WS & maven infrastructure.

A. Steps for publishing a portlet:

  1. The portlet-binary /war would be published to a maven repository.
  2. A meta data about the above portlet would be published to the standard WS registry.

B. Download & install:

  1. If the client knows the artifact id i.e not interested in searching the repository.
  2. It can use the standard maven way of downloading the artifact by specifying it in the pom.
  3. A mvn plugin can be provided to install the above artifact on to the portal server ( Note:  Each vendor can provide their own maven plugin for installation, hence it also solve the problem of where each vendor have their own way of deploying a portlet)

C. Search, Download and Install :

  1. A WS client may search the registry based on various query parameters and search for a portlet on the WS registry (this would be a maven plugin too)
  2. It obtains the maven repository and the artifact id as the response of the query.
  3. The client uses the search results to download the maven artifact from the maven repository.
  4. As indicated above the maven plugin to deploy the portlet could be used

D. Supporting preview for a portlet :

  1. While publishing a portlet the administrator could publish the WebService for Remote Portlets(WSRP) artifacts associated with the portlet  (WSRP artifact meaning WSRP Registry Information Model-RIM defined by OASIS). We can even think even about PRP as an add-on to the WSRP RIM or vice versa.
  2. The WSRP artifact points to the WSRP Producer which offers this portlet
  3. The client which is interested in a preview of the portlet could use the standard WSRP interfaces to get the content.

Note : The above need not be limited to preview mode as WSRP supports all modes. So rather than a preview we could call it as "test drive" a portlet.

Note : The above could be a extension and not mandated in the RIM. So this would be a optional meta-data.

E. Cross referencing.

  1. It MAY be possible to cross reference registries that would allow us to import all the data from other vendor hence offering more portlet (Need to check on cross referencing feature in registry)
  2. Worst case importing the meta-data from other registries and importing to our registry would work.

Advantages :

  1. We'd using the standard WS infrastructure (defining metadata, searching and publishing to the registry)
  2. We can take advantage of the maven dependency resolution mechanism ie. a portlet may depended on some software that needs to be in the server classpath etc which can be resolved by the POM.
  3. No need to invent any on the wire protocol rather use maven + WS registry infrastructure.
  4. We can take advantage of the mvn distribution (i.e. we need not write new client or cli etc)
  5. Everything defined above are based on standards so any one can implement their own solution . All we have to agree upon is the meta data.

Items to be done:

  1. Define a meta data for the PRP
  2. Write maven plugins for
    1. publish
    2. search
    3. install of the portlet

If you have any comments or want to see the responses for the above proposal. Pls join the mailing list for PRP.




« July 2016