10:59 a.m.
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#consu...
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#produ...
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
4:25 p.m.
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#consu...
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#produ...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
3:52 a.m.
Hi Chris,
all data is persisted in JCR in GateIn portal so far (except the user
identity but that's different kind of data, not really owned by the
portal).
So we want to do the same for WSRP.
Before JCR data used to be mapped by hand which can become complex and
hard to maintain but since this summer we can use Chromattic as
mapping layer which makes the development of JCR backend easier and
faster to do. We can discuss about details later.
As for the data, there are a few important principles to respect to
get it right (according to my experience):
- determine the life cycle of the data: when the data is created /
destroyed, what triggers it
- determine the degree of coupling of your data with other entities :
does you data need other entities ? does other entities depends on
your data ?
- design your model and map it to the backend
- design your model for extensibility in mind
- have an authority review your model and approve it because it can be
potentially used for years and this is the most important piece in the
migration
As for the initial data creation for some consumer / producer, usually
it is done using XML that is inserted in the database under some
condition (the absence of an entity). It used to be like that too in
JBoss Portal and it is the same in GateIn. It works that way because
we do not have an install process in the portal in order to simplify
its installation.
Administration wise, specific tools need to be developped as usual.
Nevertheless it is possible to use a generic JCR explorer to see what
is persisted and change it but it is somewhat low level. We have also
plans for making the edition of persisted JCR data via webdav
providing an XML view of the data (the same that would be in the
initial configuration file) but that is just a feature in mind and not
a reality yet.
hope it helps you to get you started on this.
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#consu...
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#produ...
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
5810
days inactive
5811
days old
2 comments
2 participants
participants (2)
-
Christophe Laprun -
Julien Viet