axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ann Robinson <robins...@us.ibm.com>
Subject Re: [AXIS2] Proposal for saving the message context
Date Tue, 02 Jan 2007 23:27:36 GMT


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

Mime
View raw message