Persistence API and implementation for standard capabilities
------------------------------------------------------------
Key: MUSE-25
URL: http://issues.apache.org/jira/browse/MUSE-25
Project: Muse
Type: New Feature
Environment: Axis2 and OSGi
Reporter: Dan Jemiolo
The requirements are that:
1. On shutdown, addressable resource instances be saved so that they can be
reloaded the next time the Muse-based application is started.
a. The reloaded instances should have the same identity (in terms of
WS-A EPR) and state (WSRP and other internal values).
b. The reloaded instances should be created before any new
instantiations are performed and any requests are handled.
2. The format of the persisted resources should be XML.
a. The persisted resources should be grouped under one root element
that will contain all of the resource instances at the time of persistence.
b. Authors of capabilities should be able to control the way their
state is persisted without affecting the persistence of other capabilities.
They can control how much is stored in the XML representation vs. stored in
some other data store; similarly, on re-load, they may retrieve some values
from the XML and some from the other data store.
c. In the case where all of a capability's state is persisted in
another data store, the user can override the default persistence mechanism to
perform these read/write tasks, and the XML representation of the capability
will be empty.
3. The persistence feature should reuse Muse's Serializer API to find out how
to read/write the values of each capability. This will allow us to add in the
persistence feature without modifying the deployment descriptor schema.
4. Users should be able to invoke the persistence API to write/save data during
non-shutdown times to make sure important changes are recorded.
5. It should be possible to provide an optional persistence implementation
using XStream. The muse-util-xstream module could be updated to contain
serializers for all of the standard capabilities. The XStreamSerializer class
could be the foundation for this simple implementation.
a. XStream has a means of preventing duplicate object instantiation (if
the object tree turns out to be a graph), but we should be extra diligent in
our investigation of this to make sure we don't introduce bugs that will take a
long time to fix.
i. WS-N NotificationProducer and SubscriptionManager is the
test case I'm think of.
I propose that the API and schema additions for persistence look something like
the ones below. Note that most users should not have to interact much with
these lower-level APIs - they will use the current Serializer interface to
provide serialization of their capabilities for the persistence framework.
In the Muse deployment descriptor:
<muse>
<router>
<java-router-class/>
<logging/>
<!-- ADDITION TO CURRENT DESCRIPTOR -->
<persistence>
<persistence-file>some-file-name.xml</persistence-file>
</persistence>
</router>
...
</muse>
This file would be overwritten each time the resources were saved. The format
of the file would be:
<router-instance>
<resource-instance>
<context-path>/the-unique-path</context-path>
<endpoint-reference>
some epr type (WSA or derivation)
</endpoint-reference>
<capability>
<capability-uri>the-unique-uri</capability-uri>
<java-capability-class>the-impl-class</java-capability-class>
<capability-instance>
- capability-specific XML that stores properties and other state
- the user has control over how this looks
- our XStream serializer could provide this
</capability-instance>
</capability>
...
</resource-instance>
...
</router-instance>
Recording the context-path of the resource allows us to associate with the
resource-type element in muse.xml, and we can fill in all of the other resource
fields using that descriptor. the EPR and capability fields are what change at
runtime, so they are the actual state preservation.
At initialization time, the resource router would look for the persistence file
named. If it existed, for each resource instance it found, it would create the
given resource type and set the resource's EPR to the one in the file. The
capabilities would then be re-initialized from XML (using serializers
registered for those types) and added to the resource (using the
addCapability() method). This whole process would be very similar to the
auto-creation of new resources at startup.
At shutdown time, the reverse of these tasks could be used to create the file.
Once again, the serializer for the capability type would be used to create the
XML.
We should try to implement the capability serializers using the
XStreamSerializer class because it would save us a lot of time, and any
idiosyncracies would be hidden because the persisted XML is not avaiable to
remote clients.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
