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 <robinsona@us.ibm.com> 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
>
>