ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <chamikar...@gmail.com>
Subject Re: [AXIS2] [Sandesha2] Saving the message context
Date Tue, 01 Aug 2006 02:34:58 GMT
Hi Jaliya,

Yes. Thats similar to what we are doing currently. We save the message
context in the Sandesha Global In Handler and re-inject it into the handler
chain after a failure.

Chamikara


On 8/1/06, Jaliya Ekanayake <jnekanayake@gmail.com> wrote:
>
>  Hi Chamikara,
>
> Don't know whether it is an efficient way; how about this - we can save
> the SOAP message after security handler using a custom handler that will
> only be deployed in the persistent mode.
>
> -Jaliya
>
> ----- Original Message -----
> *From:* Chamikara Jayalath <chamikaramj@gmail.com>
> *To:* Jaliya Ekanayake <jaliya@apache.org>
> *Cc:* sandesha-dev@ws.apache.org
> *Sent:* Monday, July 31, 2006 1:54 PM
> *Subject:* Re: [AXIS2] [Sandesha2] Saving the message context
>
> Hi Jaliya,
>
> Well, not exactly. In Sandesha2 scenario we process the message in several
> transactions. Processing of a message within a handler will be done in one
> transaction while the invocation will be done in another transaction. So we
> cannot simply abandon the message. We have to reinject it into our system
> (thats what we do).
>
> But if we serialize the message in the very begining of the handler chain
> we can asume that the context would not have been changed and saving the
> SOAP envelope would be enough. But this is not always a practicle solution
> since handlers like security will sometimes have to be present before RM.
>
> Chamikara
>
>
>
> On 7/31/06, Jaliya Ekanayake <jnekanayake@gmail.com> wrote:
> >
> >  Hi Chamikara,
> >
> > What I am suggesting is this. If we get the QoS information stored
> > properly that will enable us to build a definite state after a crash.
> > e.g. We don't need transport info because RM will handle it by way of
> > re-transmissions.
> >         ServiceContext and ServiceGroupeContext; IMHO WS-Transaction
> > should handle this.
> >
> > So if we keep the states of QoS layer then we can avoid this heavy
> > serialization.
> >
> > Any thoughts?
> >
> > -Jaliya
> >
> >  ----- Original Message -----
> > *From:* Chamikara Jayalath <chamikaramj@gmail.com>
> >  *To:* Jaliya Ekanayake <jaliya@apache.org>
> > *Cc:* sandesha-dev@ws.apache.org ; axis-dev@ws.apache.org
> > *Sent:* Sunday, July 30, 2006 10:58 PM
> > *Subject:* Re: [AXIS2] [Sandesha2] Saving the message context
> >
> > Hi Jaliya,
> >
> > Thats good news. But only the properties will not be anough. There are
> > other things like the state of the options object, transports and callback
> > object that also have to be
> >
> > serialized. There are also references to the other contexts
> > (serviceContext, serviceGroupContext) from the Message Context and we will
> > not want to loose these connections when the Message Context is
> > deserialized.
> >
> > However if it can be declared that the referenced contexts will not be
> > serialized when serializing one context, that paves the way for a solution.
> > But not sure weather this is valid for all cases.(Still have to think more
> > on reconstructing the context hierarchy)
> >
> > Chamikara
> >
> >
> >   On 7/31/06, Jaliya Ekanayake <jnekanayake@gmail.com> wrote:
> > >
> > >  Hi All,
> > >
> > > As far as I remember we spent some time during the design of axis2 to
> > > solve this problem. The final conclusion we made was to do our own
> > > serialization by serializing only the properties (serializable objects) in
> > > the property bag not the entire message context which has pointers to
> > > other contexts.
> > >
> > > Thanks,
> > >  -Jaliya
> > >
> > >
> > >
> > >  ----- Original Message -----
> > > *From:* Chamikara Jayalath <chamikaramj@gmail.com>
> > > *To:* nagy@watson.ibm.com
> > >  *Cc:* sandesha-dev@ws.apache.org
> > > *Sent:* Sunday, July 30, 2006 8:40 PM
> > > *Subject:* Re: [AXIS2] [Sandesha2] Saving the message context
> > >
> > > Hi Bill,
> > >
> > > I agree that doing serialization within context objects is the best
> > > approach in a design perspective. The approach I followed was only possible
> > > due to MessageContext already having made its useful state public.
> > >
> > > I also originally tried to follow Externalizable approach and
> > > introduced externalizable methods to all the contexts (they hv now been
> > > removed due to not having any usages). The main problem I had in this
> > > approach was having to serialize the whole context hierarchy.
> > >
> > > Every message context has a pointer to the configurationContext so to
> > > be general (not to be specific to our scenario) in the serialization method
> > > we would have to serialize this object as well.Since this has pointers
> > > to all other contexts they will be serialied too. What I am saying is that
> > > when adding the externalizable method to the axis2 codebase we would have to
> > > serialize the configContext and other contexts as well (because some people
> > > may actually want to serialize the whole context hierarchy). But in our case
> > > it seemed like this would be a burden. Every deserialized message context
> > > with come up with its own context hierarchy and maching between two
> > > deserialized Message contexts will be extremely difficult.
> > >
> > > If you find a solution to this problem I agree that your and Anns
> > > approach is the best way to go and I would like to use that in my code :-)
> > >
> > > Chamikara
> > >
> > >
> > > On 7/29/06, Bill Nagy < nagy@watson.ibm.com > wrote:
> > > >
> > > > On Fri, 2006-07-28 at 23:46 -0400, Rajith Attapattu wrote:
> > > > > Anne,
> > > > >
> > > > > Again I will advice again serializing the contexts using any form
> > > > of
> > > > > serialization. This will not scale at all in a production
> > > > environment.
> > > >
> > > > Hi Rajith,
> > > >
> > > > Could you please explain this last comment?
> > > >
> > > > > Again this approach will be error prone and as chamikara mentioned
> > > >
> > > > > there will be too many information saved in the database.
> > > >
> > > > I don't understand why you and Chamikara keep saying that there will
> > > > be
> > > > too much information serialized.  You have the option of taking
> > > > complete
> > > > control of the serialization, thereby writing/reading only the
> > > > information that you want and in the form that you want it to be
> > > > in.  I
> > > > don't believe that Ann is arguing for simply using the default
> > > > serialization, only about who should be in control of making the
> > > > decisions as to what should be saved.
> > > >
> > > >
> > > > >
> > > > > I am looking at clustering certain information within the ctx
> > > > heirachy
> > > > > for high availability and I would only do with the bare minimum.
> > > > >
> > > > > In my opinion the performance overhead of serializing and
> > > > > deserializing (and validations to avoid erros) is a lot more than
> > > > > saving the required info in a bean like what chamikara does for
> > > > > Sandesha and then reconstructing it.
> > > > >
> > > >
> > > > Having the objects persist their own state is far less error prone
> > > > than
> > > > having a third-party piece of code do the persistence.  For one,
> > > > anytime
> > > > someone changes or adds a piece of information that needs to be
> > > > saved in
> > > > order to correctly restore the state, they have to remember to
> > > > modify
> > > > the external code.  It's generally hard enough to remember to modify
> > > > code embedded in the class itself, much less having to remember to
> > > > modify a completely separate piece of code.
> > > >
> > > > Secondly, you require the objects that need to be saved to expose
> > > > methods, to return the portions that you want to have serialized,
> > > > that
> > > > you may not have to expose otherwise.
> > > >
> > > > In effect, the approach that you've chosen has abandoned
> > > > encapsulation
> > > > and created fragile dependencies -- this is bad design.
> > > >
> > > > -Bill
> > > >
> > > > > Regards,
> > > > >
> > > > > Rajith
> > > > >
> > > > >
> > > > > On 7/28/06, Chamikara Jayalath < chamikaramj@gmail.com > wrote:
> > > > >         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 contexts.
> > > > >
> > > > >         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.
> > > > >
> > > > >
> > > > >         Chamikara
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >         On 7/29/06, Ann Robinson < robinsona@us.ibm.com> wrote:
> > > > >                 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"Chamikara
> > > > >                 Jayalath" < chamikaramj@gmail.com >
> > > > >
> > > > >
> > > > >
> > > > >                                                 "Chamikara
> > > > Jayalath" < chamikaramj@gmail.com >
> > > > >                                                 07/28/2006 07:23
> > > > AM
> > > > >                                                 Please respond to
> > > > >                                                 axis-dev@ws.apache.org
> > > >
> > > > >
> > > > >
> > > > >
> > > > >                            To
> > > > >
> > > > >                 Ann
> > > > >                 Robinson/Austin/IBM@IBMUS
> > > > >
> > > > >                            cc
> > > > >
> > > > >                 axis-dev@ws.apache.org ,
> > > > sandesha-dev@ws.apache.org
> > > > >
> > > > >                       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 < 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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-dev-help@ws.apache.org
> > > >
> > > >
> > >
> >
>

Mime
View raw message