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 Sat, 29 Jul 2006 01:25:40 GMT
Hi Ann,

Yes. We had introduced Externalizable implementaitons for all of the Context
hierarchy objects sometime back. But this approach seemed to be saving too
much information on the database.

For example at some point there may be following context objects available
in a running axis2 instance.
1. configuration context object
2. service group context objects
3 service context objects
4. Operation context objects
5. A lot of message context objects

If we try serializing starting from a message context, since we have to
serialize every incoming message context all these objects will be
serialized every time (recall that the message context hs a link to the
configuration context which has links to all other context objects). Think
how deficult the reconstruction would be. Every deserialized message context
will come up with its own hierarchy of context objects which may not map
with the context objects reconstructed by deserializing others message

Thats why I went for this approach of saving only the relavent information.
It seemed to be much cleaner and it was working :-)

You had mentioned about serializing the AxisOperaion object. All the
'Axis*'  objects in Axis2 (AxisConfiguration, AxisServiceGroupt etc.)
contains deployment time information. So we can safely ignore them in the
serializing process.


On 7/29/06, Ann Robinson <> wrote:
> 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 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
> 11501 Burnet Rd IZip 9035G021
> Austin, TX 78758
> (512)838-9438 TL 678-9438
> [image: Inactive hide details for "Chamikara Jayalath"
> <>]"Chamikara Jayalath" <>
>     *"Chamikara Jayalath" <>*
>             07/28/2006 07:23 AM Please respond to
> To
> Ann Robinson/Austin/IBM@IBMUS
> cc
> Subject
> Re: [AXIS2] [Sandesha2] Saving the 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.
> Chamikara
> 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
>    IBM
>    11501 Burnet Rd IZip 9035G021
>    Austin, TX 78758
>    (512)838-9438 TL 678-9438

View raw message