ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <>
Subject Re: [AXIS2] [Sandesha2] Saving the message context
Date Fri, 28 Jul 2006 12:23:36 GMT
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.


On 7/27/06, Ann Robinson <> 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 ( In order to save the
> message context, the possible solutions include the following:
> (A) Internal Message Context option
> Do a customized serialization using in the complex
> objects and use the default serialization mechanism (
> 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
> 11501 Burnet Rd IZip 9035G021
> Austin, TX 78758
> (512)838-9438 TL 678-9438

View raw message