[gatein-dev] Persistence needs for WSRP

[Christophe Laprun]

Now that the WSRP integration with Portal is starting to shape up, I  
need to move to the second phase of the integration which is  
persistence of WSRP-related state.

Caution: wall of text incoming! :(

There are several aspects that need to be considered:

1. Definition of WSRP consumers (i.e. definition of connection to  
remote producers):

This entails data that wouldn't change too often but can still be  
dynamic, especially during the initial registration process (if  
required). The data that is needed here is the URL for the WSDL file  
published by the remote producer, a cache expiration duration in  
seconds and data pertaining to registration as required by the remote  
producer, which in most instances, is determined dynamically during  
the initial negotiation with the producer. This data needs then to be  
presented to the user and filled out then persisted. This data is  
stored on the consumer side of things. To get a sense of that  
interactive process, have a look at how this was done in JBoss Portal: http://docs.jboss.com/jbportal/v2.7.1/referenceGuide/html/wsrp.html#consumer_configuration

While a GUI tool to perform that operation is the ultimate goal, this  
is currently done using an XML configuration file that is located in  
the wsrp-consumer-1.0.0-Beta01.jar under conf/wsrp-consumers- 
config.xml. Ideally, I would like to get rid of that file but I  
understand that some people might need to configure their consumers  
without using a graphical interface.

The question then is, based on how Portal deals with similar  
configuration issues (which I need to be educated on), what is the  
best persistence strategy for this user editable data?

2. Configuration of the WSRP producer:

The behavior of the WSRP producer is controlled by some user-definable  
configuration as well, in particular with respect to whether or not  
consumers are required to register with it and how registration  
properties are validated. This is currently done via another XML file  
located in wsrp-producer.war/WEB-INF/conf/producer/config.xml. Again,  
ideally, this data would be edited graphically and persisted. See http://docs.jboss.com/jbportal/v2.7.1/referenceGuide/html/wsrp.html#producer_config 
  for how it was done in JBoss Portal.

Again, what is the best strategy to persist this user editable data  
and how does it fit with the existing administration tools?

3. Registration data sent by remote consumers to the WSRP producer:

If the WSRP producer has been configured to require consumers to  
register with it before any further interaction, the data associated  
with that registration must be persisted across server restarts so  
that an already registered consumer is not faced with errors. More to  
the point, any portlet state that is created within the scope of a  
valid registration life should also be associated with that  
registration. More precisely, if a consumer is registered with our  
producer and during its interaction with it, portlets are cloned, the  
resulting state should be scoped to the registration between the  
consumer and the producer so that if that registration ever becomes  
invalid, the associated state can be destroyed.

As a result, we need to be able to not only persist the data  
associated to the registration itself (i.e. consumer name, provided  
values for expected registration properties, etc.) but we also need to  
be able to reference portlet state as defined by the portlet  
container. Note that local persistence of consumer configured state  
(cloned portlets) is not mandated by the specification and it is  
possible to send that state back to the consumer for it to manage.

Again, what is the best strategy to persist such data within GateIn?  
Note that this data should not require user edits, though it might be  
useful for administrators to be able to look at that data and possible  
perform maintenance operations on it.

How were these issues managed in eXo Portal?

Cordialement / Best,
Chris

==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm