Here is some of the issues that we encountered during migration of the OpenPortal WSRP Project from JAX-RPC to JAX-WS. The following note does not go into details on why these changes are required and the concepts behind it, rather helps you to deal with migrating your application from the older webservice stack to new stack.

Consider leaving a note if you have faced a different issue and solved it, so that it would benefit other.

[Read More]

 

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.

 

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

• Open-Source Portal Initiative at Sun, Part 1: Overview
• Open-Source Portal Initiative at Sun, Part 2: Portlet Repository
• Open-Source Portal Initiative at Sun, Part 3: Portlet Container
• Open-Source Portal Initiative at Sun, Part 4: Web Services for Remote Portlets
  

The Enterprise class Portal Server Project now has a new name, its called OpenPortal. It also has a brand new logo. All the subproject are now referred with OpenPortal prefixed to them. For e.g. the Enterprise-class WSRP Open Source Project is now called OpenPortal WSRP Project.

 

Apart from this, the Sun Java System Portal Server 7.1 source code is also available for download on the OpenPortal Project, check out the download page for more details.  Please keep a watch on the Portal Post for announcements related to the OpenPortal Project. 

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]

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.

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 

• Netunity - http://wsrp.netunitysoftware.com/WSRPTestService/WSRPTestService.asmx?Operation=WSDL
  

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.

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.

Aligned with the announcement on WSRP milestone build 1, the milestone 1 "preview" is available. This preview delivers a installable WSRP components that allows users to try out the planned features of milestone 1. As the project stabilizes we plan to tag the codebase as milestone 1 build by end of December. The milestone 1 build tries to deliver a implementation that consists of

1. WSRP Producer    -  Allows creation of multiple producers.
   
2. WSRP Consumer   - Deliver a Container API implementation  that can be used by any aggregators
3. WSRP Test Driver  - Use the above WSRP Consumer Container API and deliver a test driver based on portlet container test driver
4. WSRP Admin Portlets - Provide an user interface for the WSRP Mbeans.
5. WSRP Mbeans with sample admin server - Export WSRP administrative interface as Mbeans and provide a sample Mbean server.

The WSRP functionality is built over the  Portlet Container Open Source Project.

You can get the Install and User guide for this preview build which is available at the project site.  If you have questions on how to use the WSRP Project and other comments/suggestions/requests, we urge you to join the Project mailing alias.

Screencast and other materials would be available soon.

The following section describes the refactoring that we are in the process of doing to the Portlet Container Open source Project (OSP) and the dependencies between the WSRP OSP and the Portlet Container OSP. The design of WSRP OSP to some extent addresses the possibility of supporting other portlet container and not just Portlet Container OSP.

The Container API is the common abstraction that the portlet container and the WSRP Consumer implements. The Container API abstracts the local or remote execution of the portlet and provides a uniform interface for the content aggregators. The Portlet Container driver which is a test environment for these portlet uses this abstraction and display content of local or remote portlets.

The Container Context is the newly refactored abstraction on which is work in progress, this abstracts the dependencies of WSRP (producer and consumer) on the content aggregator. WSRP depends certain functionality of the aggregator rather than just depending the Container API.

The Portlet Container which is the implementation of the Container API provides the execution environment for local portlets. The WSRP Consumer provides another implementation for the Container API which executes/routes request to remote producers and provides content to the aggregators. Apart from providing an implementation of the Container API the  WSRP Consumer also provides the following functionality's.

1. An implementation of Container API which any aggregators can use (where Container API is the exposed/public interface)
2. A Resource Proxy Servlet - Which is responsible for getting resources that a portlet refers too ( for fetching images, scripts etc. from the producer)
3. Some implementation of the portlet container test driver interfaces - This can be replaced by other aggregators.

The following diagram shows the web-apps that are deployed on an web container and some of the high level component dependency with interfaces that are defined in the system. The direction of arrow shows the dependency.

 

Here is a note on the administrative structure that is planned for the Enterprise class WSRP Open Source Project (OSP) on java.net. The intent is to provide flexibility in system composition such that the WSRP component could be used without much modification to adapt to new environments.

The administrative interface is provided in terms of Mbeans. These Mbeans that can be deployed on any/existing Mbean server that enables management of the WSRP component.  The user interface (UI)  for these Mbeans (clients) are provided as portlets. Since the user interface is provided as portlets, these portlets can be deployed on to any standard portlet container.

The above componentization provides flexibility in terms of recomposing  and integrating the WSRP project into any environment or existing system that suites a variety of needs. For e.g. it allows the Mbeans to be deployed on an existing Mbean server that manages a larger set of services which is integrated with WSRP.

To be more specific the WSRP OSP project would provide the following MBeans for managing the WSRP Producer and Consumer separately. These Mbeans could be reused when deploying or recomposing the system other than the default bundled configuration/deployment.

1. WSRP Producer Mbeans
• WSRPProducerManagerMBean
• WSRPProducerMBean
2. WSRP Consumer
• ConsumerMbean
• ConfiguredProducerMBean
• RemotePortletManagerMBean

Apart from providing the above Mbeans.  The WSRP OSP project as such will provide a default sample Mbean server that demonstrates the deployment and management of these Mbeans on to a Mbean server which runs as a separate process.

The user interface for above Mbeans is provided in terms of portlets namely

1. WSRP Producer Admin  Portlet and
2. WSRP Consumer Admin  Portlet.
   

The administrative portlets could be deployed on to any standard Portlet Container that  provides an environment for executing these portlets. Again providing the UI in terms as portlets also provides the flexibility to reuse and recompose the system to suite various needs.

The portlet administrative interface is a demonstration on the usage of public WSRP OSP Mbeans that are exported by the system. Its be possible to write a CLI (command line interface) that uses these same Mbeans also opens up the possibility of integrating the WSRP OSP with existing systems where an unified admin console of CLI would be required.

The default deployment architecture of the WSRP OSP project is as follows.

1. The system provides a default Mbean server where the WSRP OSP Mbeans are deployed, this runs as an independent process.
2. The WSRP Producer and the Consumer are deployed over a web container along with the Portlet Container. This is where the WSRP environment exists.
3. The WSRP OSP admin portlets are deployed over any standard portlet container that provides the UI for the above deployed Mbeans.
   

The pictorial representation is as shown below :

This is the continuation to the previous entry on WSRP and User Identity Propagation. Sun Java System Portal Server provides a two step/phase configuration for the identity propagation mechanism it supports. In the first phase the administrator of the WSRP Consumer sets up the relationship with the WSRP Producer and allows the end user to do federation with the remote WSRP Producer service. In the second phase the end-user may optionally federate his remote identity with the local identity for Single-Signon with the remote producer. This two phase configuration provides control to both the administrator and the enduser in federating the identity of the enduser.

    The following sections specifically talks about the identity propagation mechanism setup at the WSRP Consumer end. This is because the Consumer is the one which has the knowledge about the actual user and decides to propagate the user identity. The two phase configuration along with the subsequent request/response is as follows.

Phase 1 : Administrator Setup

• The administrator of the Consumer Portal discovers that the Producer Portal supports certain identity propagation mechanism.
• The Consumer Portal administrator setups the system that may optionally allows the user to use identity propagation mechanism.
  

Phase 2 : User setup

• The enduser see that he has access to a remote WSRP Producer services and may decide to federate his identity.
• The enduser federates his identity by populating his remote credentials
  

This normal request/response  processing :

• The Consumer Portal WSRP infrastructure uses the user remote credentials and propagates the identity to the WSRP Producer upon user specific operations.
• The Producer Portal WSRP infrastructure accepts/validates and provides content for the propagated remote identity.
• The Consumer Portal presents the content delivered by the  Producer Portal  to the enduser.

    In essence the two phase configuration allows the administrator decides whether to use an identity propagation mechanism available at the Producer Portal and he also determines the type of identity propagation mechanism that the Consumer Portal should use. The user decides whether he want to use the identity propagation mechanism made available to him by the administrator and federates his identity if required.
Sun Java System Portal Servers WSRP implementation support the following different types of identity propagation mechanisms,

1. SSO Token:  Where the SSOToken associated with the user is propagated from the WSRP Consumer to the WSRP Producer
2. WSS User Name Token Profile (Username only): It uses the WSS (Webservices Security) specification where the user name is propagated as WS Security headers from the WSRP Consumer to the WSRP Producer.
3. WSS User Name Token Profile (With password digest): The WS Security headers contain user name in plain text and password in the digest form to the WSRP Producer.
4. WSS User Name Token Profile (With password text): The WS Security headers contain user name and password in the plain text form to the WSRP Producer.
5. No Identity Propagation : This defaults to the behavior where  there will be no user identity propagation mechanism from the WSRP Consumer to the WSRP Producer

No Identity Propagation :

    This is the default behavior of WSRP as indicated in the WSRP specification, The WSRP consumer propagates a notion of user to the WSRP Producer and there is no real user identity play in the system when this option is used. This is the default option in Sun Java System Portal Server, so any consumer that is created by default will not have any identity propagation mechanism.

SSOToken Identity Propagation :

    Sun Java System Portal Server uses Sun Java System Access Manager for authenticating users and for Single Signon. This options assumes that both the Producer and Consumer are Sun Java System Portal Server, Make sure you use this option only  if both the Producer portal and Consumer portal are configured to use the same Access Manager instance. Typically recommended in configurations where both the Producer Portal and Consumer Portal are  deployed within the same organization.

    This option does not provide the end users with the options to federate their identities. This is because the same user identity is accepted by both the Consumer and the Producer portal as they point to the same Access Manager instance.

    Note this identity propagation mechanism will not interoperate with other Portal vendors and also will not work if the Producer Portal and Consumer Portal are not pointing to the same Access Manager.


WSS User Name Token Profiles :

    The following options are implementations of the OASIS WSS Username token profile specification.  This specification describes how to use the UsernameToken with the Web Services Security (WSS) specification; more specifically, it describes how a web service consumer can supply a UsernameToken as a means of identifying the requester by 'username', and optionally using a password, to authenticate that identity to the web service producer.

1. WSS User Name Token Profile (Username only)
2. WSS User Name Token Profile (With password digest)
3. WSS User Name Token Profile (With password text)
   

    Since this is a standard specification from OASIS, various portal vendors support and implement it. Use one of the above options when interpretability is required. i.e., it allows portal implementations from 2 different vendors to exchange user identity.

    This option provides both the end user and the administrator the flexibility to configure  and control the identity propagation scheme that is in effect.  The following section details with the step by step instructions for doing the above mentioned configurations in Sun Java System Portal Server

Administrator Setup :
 
  Here are the specific steps for administrator to do the administrator setup phase explained above

1. Log on to portal server admin console (psconsole)
2. Click on the WSRP Tab
3. Choose the org on to which you want create a consumer
4. Click on new consumer
5. Enter the name of the consumer
6. Specify the identity propagation mechanism
7. Continue with the rest of the  wizard to create a consumer
   

Step 6 is the choice where the  administrator chooses an sets up an  identityppropagationmechanism for the end-users.  Once the consumer is created. The administrator has to create remote channels based on the above created consumer


User setup : Federating  identity

    The end user logs on to the portal server, clicks on edit of the WS-SSO (Web Services Single Signon Portlet) to provide the the remote WSRP Producers credentials for Single Sign on

WS-SSO Portlet :

    The WS-SSO Portlet is based on the SSOAdapter service that is available on the Sun Java System Portal Server. The SSOAdapter service provides a mechanism to manage and authenticate users to the remote services that are used by the Sun Java System Portal Server.

    The WS-SSO Portlet provides a user interface that allows end users to populate values on to the SSOAdapter. The WS-SSO Portlet uses an SSOAdapter named OASIS-USERNAME-TOKENPROFILE. The values populated by the end user are stored in this SSOAdapter which is used by the WSRP Consumer to obtain the user credentials if exists and propagate to the WSRP Producer service.

WSRP Request/Response :

    Once the credentials are made available by the user, For the subsequent requests when the user views any of the remote portlets that are available on the desktop the user identity is propagated by the WSRP Consumer to the Producer. The Producer based on the identity generates contents for the user

Configuring the WSRP Producer :

 This section specifically talks about the WSRP Producer configuration.

    The identity propagation mechanism is set at the producer automatically, no need for the administrator to set it manually. The Producer checks for user identity headers in the following order 

1. Sun SSO Token,
2. OASIS user name token profile (all the variants of it )
3. No Identity Propagation mode. (default behavior if none of the headers are found).

Notes/Recommendations :

• Sun Java System Portal Server provides both a WSRP Producer and a WSRP Consumer implementation. This section deals with the support for each of the above mentioned options 
  • Sun Java System Portal Server WSRP Producer supports all the above mentioned Identity Propagation Mechanisms except  WSS User Name Token Profile (Username only).
  • Sun Java System Portal Server WSRP Consumer supports all the above mentioned Identity Propagation Mechanisms. i.e..  Sun SSO Token,  WSS User Name Token Profile (With password text), WSS User Name Token Profile (With digest text), WSS User Name Token Profile (Username only) and no identity propagation.
• When using the WSS User Name Token Profile (With password text) it is recommended that the communication between the producer portal and consumer portal is secured via HTTPS, this is essential as the password is sent in plain text between the consumer and the producer.
• It is not recommended to have 2 different consumers that point to the same producer URL to have different identity propagation mechanism types.   
• It would not be recommended to switch identity propagation types once the consumer is created and used, this is because the users portlets preferences are stored based on the identification of user, switching the identity propagation mechanism would mean loss of user customization.

    Quite frequently we hit this problem while developing code for enterprise class systems. Finally decided to term this as an "Antipattern" and write a blog about it. Not necessarily following any template for documenting this antipattern but in random order. The problem becomes eminent especially when we are trying to develop a client application which itself is a server.

Static Configuration Antipattern:

Context:

    There are instances where an API or infrastructure software that are used by clients depends on certain configuration information The configuration information is provided in some form of properties which can be configured by the client system. There instances where such configurations inhibits the usage of the API or the infrastructure in multi threaded environments where each thread would need to have a different configuration.

Problem:

    The usage of system wide configuration inhibits the ability of the client to specify multiple configurations per client thread and also does not allow dynamic changes to these configuration during runtime rather requiring the whole system to be brought down in event of an changed configuration to take effect.

Solution:

    Whenever providing API that depend on configurations, also provide additional API that allow each client thread to set the configuration property rather than assuming that there exists only one configuration per process or per thread. These additional API should allow the the client to set the context in which the actual API's are invoked and it should be possible to set these configuration for each thread from within the client application.

    It should be possible for the client to use the API in different context within the same process without each context interfering with each other. Also it should support the  possibility of creating and associating these context dynamically at runtime without requiring a restart or some sort of shutdown, redeploy etc.

Citation:

    Until J2SE 1.4 The -Dhttp.proxy parameters that are used by the protocol handlers were the only way a proxy can be set, this is a best examples of this Antipattern. This inhibits the ability for the client to specify different proxies for each destination server dynamically.

Note: J2SE 5.0 has overcome this problem by providing API's for doing the same. Pls see the note here.

Variants:

     There are many variants of this antipattern, there are instances where some of these configurations require the whole  system to be brought down or redeployed for the changed configuration to take place and does not allow per client thread customizations.

The initial version of WSRP Consumer source code is now available on  Java.net repository.  The repository already hosts the WSRP Producer source code.

This initial WSRP Consumer implementation provides

1. A WSRP Consumer in the form of a Container for portal to consume WSRP (Container is an implementation of the Container API right now exposed by the portlet container project ).
2. A file store implementation for creating and storing 'n' number of  Consumer.
3. A resource proxy for fetching resources from the Producer.
4. The Consumer rewriting infrastructure.
   
5. Some infrastructure for providing a WSRP test driver.

Here is the official project announcement.

Soon we'll have an infrastructure for managing/creating both the WSRP Consumer and Producer and ofcourse a UI for the same.

There has been quite a number of queries on proxy setting for WSRP, so decided to write a note about it. This blog talks about setting proxies for various usecases of the WSRP implementation provided by Sun Java System Portal server.

Case 1 : External Producer :

    In this cases the the Sun Portal could be used as WSRP Consumer which is deployed in an internal network and the WSRP Producer resides outside the firewall.

a. Setting the proxy for CACAO:

    Sun Portal uses the CACAO as the management server for managing all of the portal functionality. When an administrator creates a WSRP Consumer it a management functionality. These as handled by the Mbeans that run inside the CACAO.

Hence for creating a a WSRP Consumer in Sun Java System Portal set the proxies for the

CACAO. Here is the recommended way to set these proxies

• Stop the cacaoadm
• cacaoadm get-param java-flags
• cacaoadm set-param java-flags="<above-returned-value> -Dhttp.proxyHost=<your_proxy> -Dhttp.proxyPort=<your_proxy_port>"
• Start the cacaoadm
  

With the above setting you should be able to create a WSRP Consumer

b. Setting the proxy for Webcontainer :

    Once the WSRP Consumer is created, You could create "Remote channels"  WSRP channels on the Portal desktop. The Portal server runs inside the webcontainer. Hence to fetch the contents from the remote WSRP Producer. The webcontainer needs to have the same proxy settings in its configuration.

    Adding proxy settings to the webcontainer is specific to the container on which your are running. In most of the cases its a matter of adding -Dhttp.proxyHost and -Dhttp.proxyPort as JVM parameters to the configuration files of the webcontainer.

Case 2 : External Registry Server

    In this case the Sun Java System Service Registry (ebXML implementation) may be residing in a network that is not the same as that of the Portal Server. Sun Portal Server uses the Registry Server for publishing and discovering WSRP artifacts on the Registry Server.  

    For Registry Server configuration, The Sun Java System Portal uses the SSOAdapter configuration to specify the proxy settings.

Logon to psconsole.--> Choose the SSOAdapter tab --> Choose JES-REGISTRY-SERVER Meta adapter

Specify the proxy setting in the provided UI and use the psadmin cli for publish and discovery.