axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ann Robinson <>
Subject Re: [AXIS2] [Sandesha2] Saving the message context
Date Fri, 28 Jul 2006 21:09:03 GMT

Hi Chamikara,
Thanks for the information.

Did you consider using 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

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.


WebSphere Development, Web Services Engine

11501 Burnet Rd   IZip 9035G021
Austin, TX   78758
(512)838-9438                TL 678-9438

             <chamikaramj@gmai                                          To 
   >                    Ann Robinson/Austin/IBM@IBMUS       
             07/28/2006 07:23,             
                                       Re: [AXIS2] [Sandesha2] Saving the  
             Please respond to         message context                     

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

  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?


  WebSphere Development, Web Services Engine

  11501 Burnet Rd IZip 9035G021
  Austin, TX 78758
  (512)838-9438 TL 678-9438

View raw message