[gatein-dev] Persistence needs for WSRP

[Julien Viet]

I need more time to read that carefully.

On Nov 4, 2009, at 5:59 PM, Christophe Laprun wrote:

> 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
>
> _______________________________________________
> gatein-dev mailing list
> gatein-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev