[ http://issues.apache.org/jira/browse/MUSE-25?page=all ]
Dan Jemiolo updated MUSE-25:
----------------------------
Component/s: Core Engine - Resource and Capability APIs
Fix Version/s: 2.0.0 M2
Affects Version/s: 2.0.0 M1
Due Date: 21/Jul/06
Assignee: Dan Jemiolo
> Persistence API and implementation for standard capabilities
> ------------------------------------------------------------
>
> Key: MUSE-25
> URL: http://issues.apache.org/jira/browse/MUSE-25
> Project: Muse
> Issue Type: New Feature
> Components: Core Engine - Resource and Capability APIs
> Affects Versions: 2.0.0 M1
> Environment: Axis2 and OSGi
> Reporter: Dan Jemiolo
> Assigned To: Dan Jemiolo
> Fix For: 2.0.0 M2
>
>
> 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]
