There is a difference in saving the message versus saving the message context.
Saving just the message text means that the message processing needs to be redone from the beginning. There is no runtime state associated with the message. There are no properties associated with the message. There is no security associated with the message. Saving the message context means getting the runtime state and the properties associated with the message. The message context is actually an object graph, where several objects in the graph have runtime properties and runtime state. In addition, message handlers can have runtime properties and runtime state associated with a specific message - for example, a security handler can have a security token or other security objects associated with encrypting/decrypting the message. There has been a question as to whether the saving of the message context can be done in a component external to AXIS2. Obviously, anything can be done external to AXIS2 if the right infrastructure exists AND if the restrictions and limitations of such a solution are acceptable. The restrictions and limitations of using an external component to save/restore the context of a message include: - The external component must know the object graph and stay in sync with the changes to the object graph. - The external component must know the state definitions for the various objects that make up the message context object graph and must stay in sync with the evolution of those various objects. - All data in the objects in the object graph associated with the message context must be public, that is, there can be no private data in those objects, and no private data can ever be added to those objects. - The objects in the object graph must maintain accurate version identitifiers in order for the external component to manage object evolution. - The objects in the object graph must have public (not private, not protected) constructors so that the external component can create objects and restore them based on saved information. The benefits of using the current proposal include: - Objects that have runtime data are responsible for their own data and control their own evolution - Objects can have private fields - The changes to linkages in the object graph only affect those objects in those links, so changes can be made with less disruption - The Java Serializable interface can be used for simple objects, the Externalizable interface can be used for complex objects - Changes don't have to be communicated to external components - The level of control over changes to objects and the object graph is less rigorous since the changes are encapsulated by the objects So, I think it is important to keep control over object evolution to within AXIS2 and the current proposal is better for that reason. Ann WebSphere Development, Web Services Engine IBM
