[ http://issues.apache.org/jira/browse/AXIS2-1567?page=comments#action_12447562 ] Ann Robinson commented on AXIS2-1567: -------------------------------------
Rajith, Here are some comments on your specific concerns: 1.) WS-ReliableMessaging implementations can vary - some may choose to persist the message while in progress, others may choose to restart the message from the beginning. This proposal does not dictate the design of a WS-ReliableMessaging implementation. This proposal does not replace a WS-ReliableMessaging implementation, but it does give a WS-ReliableMessaging implementation a way to persist the AXIS2 MessageContext. This proposal also follows object-oriented design practices: an object is responsible for its own state. An object is best suited to deciding what parts of its state need to be saved/restored. If an external component is responsible for saving/restoring an object, the external component takes the risk of having that object getting changed in an incompatible way to the save/restore support. 2.) Any WS-ReliableMessaging implementation will have a cost associated with its level of reliability and durability. Some WS-ReliableMessaging implementations will choose to support server crashes/restarts - some customers need the guarantee for that level of reliability/durability. 3.) If an AXIS2 handler has message-specific data or state information, then the handler should keep that information in the MessageContext in the form of properties. Then, when the MessageContext is saved/restore, the MessageContext will try to save/restore the properties. So, if the handler has a need to preserve the information across the save/restore, the handler should make sure that the data is serializable (java.io.Serializable or java.io.Externalizable). The proposed solution also provides an additional interface to handlers if they need further customization of what they save/restore. 4) Sandesha2 can continue to use its implementation of MessageContext persistence, or it can make use of the facility provided by this proposal. The advantage to Sandesha2 in making use of this proposed solution is that Sandesha2 won't need to monitor changes to the MessageContext and this proposed solution may help with Sandesha2 composition with a security implementation. 5) For those users who don't care about Reliable Messaging, this solution will not affect them. MessageContext persistence is not automatic. Regards, Ann > Need to save and restore the AXIS2 MessageContext > ------------------------------------------------- > > Key: AXIS2-1567 > URL: http://issues.apache.org/jira/browse/AXIS2-1567 > Project: Apache Axis 2.0 (Axis2) > Issue Type: New Feature > Components: kernel > Reporter: Ann Robinson > Attachments: patch.txt > > > There is an AXIS2 requirement to save the message context at some point in > the handler chain, store it away, and restore it later. This requirement > also includes the need to let handlers manage message-specific data when the > message context is saved and restored. > In particular, this feature can be used by a WS-ReliableMessaging > implementation to persist and re-send messages and to recover from a server > restart. The idea being to save a message context, then later restore the > message context and pick up the message processing at the point at which the > message context was saved (that is, without having to completely restart the > message from the beginning). > Refer to the wiki page > http://wiki.apache.org/ws/FrontPage/Axis2/MessageContextSaveRestore > for a description of a proposal on how to accomplish this feature. -- 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]
