[ http://issues.apache.org/jira/browse/MUSE-25?page=comments#action_12421895 ] Dan Jemiolo commented on MUSE-25: ---------------------------------
After working on this for a few days, I've realized that there are really two main use cases, and together they require less infrastructure than the more comprehensive framework outlined above. The two cases I see are: 1. Persisting the routing table - all of the EPRs that point to ws-resources. This will allow Muse to reboot and reload the EPRs and instantiate resources. The resource implementor will be responsible for recording/reloading the state of any individual capabilities. 2. Persisting certain capability data structures, particularly those that aren't backed by a real IT resource's management interface. Examples include WSN SubscriptionManager and WSSG ServiceGroup entries. I believe these capabilties should be persisted on an individual basis, using the lifecycle events defined by the programming model. Most other capabilities are pass-throughs to more concrete APIs on the resource, or are stateless. If we cover these use cases - persisting and reloading the routing table and WSN/WSSG collections - I think we will have met the needs of 90% of requesters and be in position to offer advice for anyone who wants to write persistence code for another capability. I am defining a ResourcePersistence interface, which extends ResourceManagerListener, and provides three functions: 1. Serialize the type and EPR of a resource instance upon creation. 2. Remove the above serialization upon destruction. 3. Reload the above serialization after reboots. 4. Carefully distinguishes between platform shutdown and resource destruction. I will provide a default ResourcePersistence implementation, FilePersistenceListener, that records the above info into XML files. This class and any init params for it will be specified in a way that is similar to the descriptor addition I described originally. Users can always provide alternate implementations that right to a RDB (or something). I will also implement persistence for the NotificationProducer and ServiceGroup capabilities, which mainly involves finding the re-created subscriptions/entries by EPR and then re-setting their property values to what they were before reboot. > 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]
