[ http://issues.apache.org/jira/browse/AXIS2-1567?page=comments#action_12447528 ] Ann Robinson commented on AXIS2-1567: -------------------------------------
Hi Rajith, The current design/implementation of the MessageContext and the related context object graph does not make it easy to persist the MessageContext. The proposed implementation is the best approach based on object-oriented design practices, trying to minimize what is saved/restored, and facilitating the requirement for surviving server restart and reliable messaging. Other approaches for the implementation were considered but the disadvantages to those other approaches outweighed their benefits. There is value in being able to save/restore the AXIS2 MessageContext in progress, as opposed to only saving the actual message and having to restart the message processing from the beginning. This is going to be more useful to WS-ReliableMessaging implementations that are composed with a WS-Security implementation - this helps keep message-specific security information together with the message. In the proposed solution, if AXIS2 handlers need to keep message-specific information with the message, then the handlers should place that message-specific information in the properties of the MessageContext, and make sure that those properties can be saved/restored. For more complicated message-specific information, the handler can implement an additional interface which will allow the handler to control what it wants to save/restore when the MessageContext is saved/restored. Note that the additional interface is not required to be implemented by a handler - it is only for a handler that has some complex message-specific information to keep track of. An example of a handler that might have complex message-specific information is a WS-Security handler. Note that, in the proposed solution, the saving/restoring of a MessageContext requires an explicit action - it is not automatically performed. This means that the save/restore support is available to components that use the AXIS2 kernel. For those users who don't care about Reliable Messaging, those users aren't affected - the MessageContext save/restore never happens. At the other end of the spectrum, there will be users who do care about Reliable Messaging and who do want the guarantee of surviving a server crash/restart. The proposed solution provides a facility that can be used by such external components as a WS-ReliableMessaging implementation but the proposed solution is not a replacement for a WS-ReliableMessaging implementation. 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]
