You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-dev@ws.apache.org by "Dan Jemiolo (JIRA)" <ji...@apache.org> on 2006/07/10 05:19:29 UTC
[jira] Created: (MUSE-25) Persistence API and implementation for
standard capabilities
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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
[jira] Commented: (MUSE-25) Persistence API and implementation for
standard capabilities
Posted by "Dan Jemiolo (JIRA)" <ji...@apache.org>.
[ 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
[jira] Closed: (MUSE-25) Persistence API and implementation for
standard capabilities
Posted by "Dan Jemiolo (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/MUSE-25?page=all ]
Dan Jemiolo closed MUSE-25.
---------------------------
Resolution: Fixed
I have completed the first part of this item - persistence of resource instances and the routing table - and am going to close it and open individual issues for both WSN and WSSG persistence.
In order to set up persistence, one must:
1. Add the <persistence/> element to the muse.xml file, and fill in the "location" and the class that is handling the persistence.
a. The class muse be an instance of org.apache.muse.core.routing.RouterPersistence
b. There is a default, org.apache.muse.core.routing.FilePersistence, that writes EPRs to disk as little XML files. These files are grouped by resource type (context path).
c. When using FilePersistence, a new EPR XML file will be created for each resoruce instance, and will be deleted if/when the resource is destroyed.
d. When the app server reboots and the Muse app is started again, the FilePersistence class will look in the directory specified (and resource type subdirectories below that) for XML files with EPRs in them. It will create a resource instance for each one it finds and assign it this pre-existing EPR.
2. If one wishes to auto-create N instances of a particular resource type, he should no longer use the instances-at-startup attribute - it has been removed. Instead, simply create the appropriate number of XML files with unique EPRs and put them in $persistence-location/$context-path, where $context-path is the same value in the /resource-type/context-path element in muse.xml.
Example:
/test-wsrf
/WEB-INF
/services
/muse
/META-INF
/wsdl
/router-entries <-------------- value from persistence-location
/WsResource <----------- a context-path from muse.xml
resource-instance-1.xml <------- XML file with EPR in it
resource-instance-2.xml
> 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org
[jira] Updated: (MUSE-25) Persistence API and implementation for
standard capabilities
Posted by "Dan Jemiolo (JIRA)" <ji...@apache.org>.
[ 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: muse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-dev-help@ws.apache.org