Hi Chamikara,
Thanks for the information.
Did you consider using java.io.Externalizable for the AXIS2 message context-related classes? (Having the work done by the AXIS2 objects would have simplified the actions that Sandesha needed to take in order to save the message context, so I am curious about any issues that were encountered.)
In the MessageStoreBean, how much of the various objects do you store as Strings? For example, the AxisOperation object contains several lists and the executionChain object contains a list of handlers and phases.
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
![Inactive hide details for "Chamikara Jayalath" <[EMAIL PROTECTED]>](gifv1oRivKxA4.gif){kind=small}
"Chamikara Jayalath" <[EMAIL PROTECTED]>
07/28/2006 07:23 AM
|
|
Hi Ann,
I did some work on serializing message contexts and reconstructing them. This was done as a part of the Sandesha2 Persistent Storage Manager implementation. Unfortunately could not commit the code into Apache due to a license issue (it was dependent on Hibernate). But will try to host it somewhere else soon.
The approach i took was extracting the relevant information from the message context, and saving them in a java bean. Later this bean was used to recostruct the message context. The format of this bean was as follows.
public class MessageStoreBean {
private String SOAPEnvelopeString;
private String storedKey;
private int SOAPVersion = 0;
private String transportOut;
private String axisServiceGroup;
private String axisService;
private String axisOperation;
private String axisOperationMEP;
private String toURL;
private String transportTo;
private int flow;
private String executionChainString;
private String messageReceiverString;
private boolean serverSide;
private String inMessageStoreKey;
private String messageID;
private String persistentPropertyString;
private String callbackClassName;
private String action;
}
As you can see the aim was to avoid Java serialization. One defect here is SOAP envelope being saved as a string, which may not be possible in the RM+MTOM scenario. I guess we can support that when a better serialization mechanism gets available for SOAP envelopes.
Chamikara
On 7/27/06, Ann Robinson <[EMAIL PROTECTED]> wrote:
- Hi all,
I have posted this note to both the AXIS2 and SANDESHA developer discussion lists, so I apologize in advance to those folks who get multiple copies of this note.
I am investigating how to save and restore the message context in AXIS2. This is functionality that would be used by other quality-of-service layers, for example, by a WS-ReliableMessaging implementation - particularly one that is composed with WS-Security, to save the message in persistent storage and later resume the message processing.
The AXIS2 message context is very complex (it includes references to several complicated objects) and does not lend itself to the default java serialization mechanism (java.io.Serializable). In order to save the message context, the possible solutions include the following:
(A) Internal Message Context option
Do a customized serialization using java.io.Externalizable in the complex objects and use the default serialization mechanism (java.io.Serializable) in the simple objects.
- - This keeps the knowledge of the object's internals in the object and keeps the responsibility in the object for persisting and resurrecting its own state.
- - This lets an object have a plugpoint where needed to manage "user" data. This would apply to the situation where an object maintains a set of properties or attributes that are supplied by users of the object. The plugpoint would define an interface so that the users of the object could save their properties/attributes appropriately.
(B) External Layer option
Put in get/set methods in all of the objects related to the message context in order to allow another layer or quality of service (QoS) to extract sufficient information from the message context in order to save and resurrect the information.
- - The simplest form of this technique is saving just the message (and the message attachments). However, this means that any processing on the message has to be re-done from the beginning.
- - If there is a requirement to maintain the security context with the message, then the security layer would need to provide additional interfaces to allow that message's security context to be acquired by that other layer.
(C) Core Plugpoint option
Have a plugpoint in the AXIS2 core that would provide an interface to capture essential message context data for saving and restoring it.
- - This solution would be a compromise between (A) and (B)
- - This requires knowledge of message context object-related internals inside of the plugpoint implementation, which is not good object oriented design
Any other suggestions or comments?
I understand that there has been a previous attempt to do this in AXIS2 based on Sandesha requirements and that this attempt did not work. I was wondering if anyone remembers what problems were encountered and what issues ultimately blocked that solution?
Thanks,
Ann
WebSphere Development, Web Services Engine
IBM
11501 Burnet Rd IZip 9035G021
Austin, TX 78758
(512)838-9438 TL 678-9438
