You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by Ann Robinson <ro...@us.ibm.com> on 2006/07/27 17:50:35 UTC
[AXIS2] [Sandesha2] Saving the message context
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
Fwd: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Forgot axis-dev :-(
---------- Forwarded message ----------
From: Chamikara Jayalath <ch...@gmail.com>
Date: Jul 31, 2006 6:10 AM
Subject: Re: [AXIS2] [Sandesha2] Saving the message context
To: nagy@watson.ibm.com
Cc: sandesha-dev@ws.apache.org
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 <ro...@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
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
Well, the idea we originally had was to ignore the security handlers in
re-injection. The best way would be to drop the 'security' phase (assuming
that we do the storing after that). Once we security verify a message there
is no need to do it again so we can safely ignore this 'security' phase.
But still there is a catch. Security handlers may be putting some stuff to
the Message Context which may need to be used by some post-RM handlers. So
we need to serialyze those information as well. (remember, we do all these
in the RM-Persistent plugin. So core RM code does not have any of these
dependent information).
Chamikara
On 8/1/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> That approach will probably need to be revisited once we get the security
> stuff running. If the inbound security handler authenticates the user, and
> puts the user identity onto the current thread (or into message context)
> then simply serialising the message would lose this identity by the time
> we re-inject the message. Equally, running through the security handler a
> second time (with the original message payload) won't work, as the
> timestamps on the message might make the re-injection fail.
>
> I think this case helps explain why we need a proper architecture for
> serialising context, so that the owners of state can make their own
> decisions about what is important. I also agree 100% that we should
> serialise the bare minimum, and that Java serialisation isn't the way to
> go either!
>
> Cheers
>
> Matt
>
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 01/08/2006 03:34:58:
>
> > 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 <jn...@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
> > To: Jaliya Ekanayake
> > 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 <jn...@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
> > To: Jaliya Ekanayake
> > 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
> > 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
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
Well, the idea we originally had was to ignore the security handlers in
re-injection. The best way would be to drop the 'security' phase (assuming
that we do the storing after that). Once we security verify a message there
is no need to do it again so we can safely ignore this 'security' phase.
But still there is a catch. Security handlers may be putting some stuff to
the Message Context which may need to be used by some post-RM handlers. So
we need to serialyze those information as well. (remember, we do all these
in the RM-Persistent plugin. So core RM code does not have any of these
dependent information).
Chamikara
On 8/1/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> That approach will probably need to be revisited once we get the security
> stuff running. If the inbound security handler authenticates the user, and
> puts the user identity onto the current thread (or into message context)
> then simply serialising the message would lose this identity by the time
> we re-inject the message. Equally, running through the security handler a
> second time (with the original message payload) won't work, as the
> timestamps on the message might make the re-injection fail.
>
> I think this case helps explain why we need a proper architecture for
> serialising context, so that the owners of state can make their own
> decisions about what is important. I also agree 100% that we should
> serialise the bare minimum, and that Java serialisation isn't the way to
> go either!
>
> Cheers
>
> Matt
>
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 01/08/2006 03:34:58:
>
> > 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 <jn...@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
> > To: Jaliya Ekanayake
> > 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 <jn...@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
> > To: Jaliya Ekanayake
> > 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
> > 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
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Matthew Lovett wrote:
> Aleksander Slominski <as...@cs.indiana.edu> wrote on 02/08/2006 13:42:25:
>
>
>> hi,
>>
>> one way to get around this problem and allow for easy load balancing
>> is to allow serialize context into XML - this is really handy when
>> you need to move processing to another node [1] or just restart
>> processing in case of RM.
>>
>> best,
>>
>> alek
>> [1] http://www.extreme.indiana.edu/labpubs.html#lifang:den:gw2005
>> Liang Fang, Aleksander Slominski, and Dennis Gannon. Web Services
>> Security and Load Balancing in Grid Environment.
>>
>>
>
> Hi Aleksander,
>
> The debate isn't about the format of the saved data (be it XML, comma
> separated, or some proprietary form). The debate is about which pieces of
> state should be saved, and how the code helps or hinders discovery of that
> state.
>
they are both very much related: what you save and how you save it - i
think that using built-in java serialization is not the best way to do
it as the most of information saved will be XML (as most of it is XML
message and its decorations)
> OO design suggests that the owner of the state (e.g. the object in
> question) knows more about the state then anyone else, and should provide
> methods to allow others to call save/restore processing. The current
> Sandesha persistent storage keeps a separate class, which 'knows' what
> state matters, and persists it itself. Obviously that is more fragile, and
> I think it really runs into trouble when there are 3rd party modules (e.g.
> not core axis ones) in the processing chains. Of course, 90% of the time
> the 3rd party modules run before Sandesha outbound, and after Sandesha
> inbound, so they are unaffected. However, a 3rd party security module is
> all out of luck!
>
yes - all modules need to contribute and say what they want to save by
storing it in message context and marking as "persistable" in some way -
runtime (axis2) should take care of persisting and then restoring
message context when a message is to be re-injected.
> In addition, the class that 'knows' which state to save doesn't seem to be
> in the apache repository, so anyone creating another persistent store
> needs to duplicate its logic. If we defined a proper mechanism along the
> lines I mentioned earlier then we would be able to reuse the code.
>
yes - clearly the problem requires to have it solved on higher level so
solution can be shared by sandesha with other axis modules ...
best,
alek
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Matthew Lovett wrote:
> Aleksander Slominski <as...@cs.indiana.edu> wrote on 02/08/2006 13:42:25:
>
>
>> hi,
>>
>> one way to get around this problem and allow for easy load balancing
>> is to allow serialize context into XML - this is really handy when
>> you need to move processing to another node [1] or just restart
>> processing in case of RM.
>>
>> best,
>>
>> alek
>> [1] http://www.extreme.indiana.edu/labpubs.html#lifang:den:gw2005
>> Liang Fang, Aleksander Slominski, and Dennis Gannon. Web Services
>> Security and Load Balancing in Grid Environment.
>>
>>
>
> Hi Aleksander,
>
> The debate isn't about the format of the saved data (be it XML, comma
> separated, or some proprietary form). The debate is about which pieces of
> state should be saved, and how the code helps or hinders discovery of that
> state.
>
they are both very much related: what you save and how you save it - i
think that using built-in java serialization is not the best way to do
it as the most of information saved will be XML (as most of it is XML
message and its decorations)
> OO design suggests that the owner of the state (e.g. the object in
> question) knows more about the state then anyone else, and should provide
> methods to allow others to call save/restore processing. The current
> Sandesha persistent storage keeps a separate class, which 'knows' what
> state matters, and persists it itself. Obviously that is more fragile, and
> I think it really runs into trouble when there are 3rd party modules (e.g.
> not core axis ones) in the processing chains. Of course, 90% of the time
> the 3rd party modules run before Sandesha outbound, and after Sandesha
> inbound, so they are unaffected. However, a 3rd party security module is
> all out of luck!
>
yes - all modules need to contribute and say what they want to save by
storing it in message context and marking as "persistable" in some way -
runtime (axis2) should take care of persisting and then restoring
message context when a message is to be re-injected.
> In addition, the class that 'knows' which state to save doesn't seem to be
> in the apache repository, so anyone creating another persistent store
> needs to duplicate its logic. If we defined a proper mechanism along the
> lines I mentioned earlier then we would be able to reuse the code.
>
yes - clearly the problem requires to have it solved on higher level so
solution can be shared by sandesha with other axis modules ...
best,
alek
--
The best way to predict the future is to invent it - Alan Kay
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Aleksander Slominski <as...@cs.indiana.edu> wrote on 02/08/2006 13:42:25:
> hi,
>
> one way to get around this problem and allow for easy load balancing
> is to allow serialize context into XML - this is really handy when
> you need to move processing to another node [1] or just restart
> processing in case of RM.
>
> best,
>
> alek
> [1] http://www.extreme.indiana.edu/labpubs.html#lifang:den:gw2005
> Liang Fang, Aleksander Slominski, and Dennis Gannon. Web Services
> Security and Load Balancing in Grid Environment.
>
Hi Aleksander,
The debate isn't about the format of the saved data (be it XML, comma
separated, or some proprietary form). The debate is about which pieces of
state should be saved, and how the code helps or hinders discovery of that
state.
OO design suggests that the owner of the state (e.g. the object in
question) knows more about the state then anyone else, and should provide
methods to allow others to call save/restore processing. The current
Sandesha persistent storage keeps a separate class, which 'knows' what
state matters, and persists it itself. Obviously that is more fragile, and
I think it really runs into trouble when there are 3rd party modules (e.g.
not core axis ones) in the processing chains. Of course, 90% of the time
the 3rd party modules run before Sandesha outbound, and after Sandesha
inbound, so they are unaffected. However, a 3rd party security module is
all out of luck!
In addition, the class that 'knows' which state to save doesn't seem to be
in the apache repository, so anyone creating another persistent store
needs to duplicate its logic. If we defined a proper mechanism along the
lines I mentioned earlier then we would be able to reuse the code.
Cheers,
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Aleksander Slominski <as...@cs.indiana.edu> wrote on 02/08/2006 13:42:25:
> hi,
>
> one way to get around this problem and allow for easy load balancing
> is to allow serialize context into XML - this is really handy when
> you need to move processing to another node [1] or just restart
> processing in case of RM.
>
> best,
>
> alek
> [1] http://www.extreme.indiana.edu/labpubs.html#lifang:den:gw2005
> Liang Fang, Aleksander Slominski, and Dennis Gannon. Web Services
> Security and Load Balancing in Grid Environment.
>
Hi Aleksander,
The debate isn't about the format of the saved data (be it XML, comma
separated, or some proprietary form). The debate is about which pieces of
state should be saved, and how the code helps or hinders discovery of that
state.
OO design suggests that the owner of the state (e.g. the object in
question) knows more about the state then anyone else, and should provide
methods to allow others to call save/restore processing. The current
Sandesha persistent storage keeps a separate class, which 'knows' what
state matters, and persists it itself. Obviously that is more fragile, and
I think it really runs into trouble when there are 3rd party modules (e.g.
not core axis ones) in the processing chains. Of course, 90% of the time
the 3rd party modules run before Sandesha outbound, and after Sandesha
inbound, so they are unaffected. However, a 3rd party security module is
all out of luck!
In addition, the class that 'knows' which state to save doesn't seem to be
in the apache repository, so anyone creating another persistent store
needs to duplicate its logic. If we defined a proper mechanism along the
lines I mentioned earlier then we would be able to reuse the code.
Cheers,
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Matthew Lovett wrote:
> Hi all,
>
> That approach will probably need to be revisited once we get the security
> stuff running. If the inbound security handler authenticates the user, and
> puts the user identity onto the current thread (or into message context)
> then simply serialising the message would lose this identity by the time
> we re-inject the message. Equally, running through the security handler a
> second time (with the original message payload) won't work, as the
> timestamps on the message might make the re-injection fail.
>
> I think this case helps explain why we need a proper architecture for
> serialising context, so that the owners of state can make their own
> decisions about what is important. I also agree 100% that we should
> serialise the bare minimum, and that Java serialisation isn't the way to
> go either!
>
hi,
one way to get around this problem and allow for easy load balancing is
to allow serialize context into XML - this is really handy when you need
to move processing to another node [1] or just restart processing in
case of RM.
best,
alek
[1] http://www.extreme.indiana.edu/labpubs.html#lifang:den:gw2005
Liang Fang, Aleksander Slominski, and Dennis Gannon. Web Services
Security and Load Balancing in Grid Environment
<http://www.extreme.indiana.edu/xpola/wsslbgrids.pdf>.
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 01/08/2006 03:34:58:
>
>
>> 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 <jn...@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
>> To: Jaliya Ekanayake
>> 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 <jn...@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
>> To: Jaliya Ekanayake
>> 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
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Matthew Lovett wrote:
> Hi all,
>
> That approach will probably need to be revisited once we get the security
> stuff running. If the inbound security handler authenticates the user, and
> puts the user identity onto the current thread (or into message context)
> then simply serialising the message would lose this identity by the time
> we re-inject the message. Equally, running through the security handler a
> second time (with the original message payload) won't work, as the
> timestamps on the message might make the re-injection fail.
>
> I think this case helps explain why we need a proper architecture for
> serialising context, so that the owners of state can make their own
> decisions about what is important. I also agree 100% that we should
> serialise the bare minimum, and that Java serialisation isn't the way to
> go either!
>
hi,
one way to get around this problem and allow for easy load balancing is
to allow serialize context into XML - this is really handy when you need
to move processing to another node [1] or just restart processing in
case of RM.
best,
alek
[1] http://www.extreme.indiana.edu/labpubs.html#lifang:den:gw2005
Liang Fang, Aleksander Slominski, and Dennis Gannon. Web Services
Security and Load Balancing in Grid Environment
<http://www.extreme.indiana.edu/xpola/wsslbgrids.pdf>.
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 01/08/2006 03:34:58:
>
>
>> 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 <jn...@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
>> To: Jaliya Ekanayake
>> 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 <jn...@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
>> To: Jaliya Ekanayake
>> 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
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
That approach will probably need to be revisited once we get the security
stuff running. If the inbound security handler authenticates the user, and
puts the user identity onto the current thread (or into message context)
then simply serialising the message would lose this identity by the time
we re-inject the message. Equally, running through the security handler a
second time (with the original message payload) won't work, as the
timestamps on the message might make the re-injection fail.
I think this case helps explain why we need a proper architecture for
serialising context, so that the owners of state can make their own
decisions about what is important. I also agree 100% that we should
serialise the bare minimum, and that Java serialisation isn't the way to
go either!
Cheers
Matt
"Chamikara Jayalath" <ch...@gmail.com> wrote on 01/08/2006 03:34:58:
> 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 <jn...@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
> To: Jaliya Ekanayake
> 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 <jn...@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
> To: Jaliya Ekanayake
> 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
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
That approach will probably need to be revisited once we get the security
stuff running. If the inbound security handler authenticates the user, and
puts the user identity onto the current thread (or into message context)
then simply serialising the message would lose this identity by the time
we re-inject the message. Equally, running through the security handler a
second time (with the original message payload) won't work, as the
timestamps on the message might make the re-injection fail.
I think this case helps explain why we need a proper architecture for
serialising context, so that the owners of state can make their own
decisions about what is important. I also agree 100% that we should
serialise the bare minimum, and that Java serialisation isn't the way to
go either!
Cheers
Matt
"Chamikara Jayalath" <ch...@gmail.com> wrote on 01/08/2006 03:34:58:
> 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 <jn...@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
> To: Jaliya Ekanayake
> 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 <jn...@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
> To: Jaliya Ekanayake
> 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
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@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 <ch...@gmail.com>
> *To:* Jaliya Ekanayake <ja...@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 <jn...@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 <ch...@gmail.com>
> > *To:* Jaliya Ekanayake <ja...@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 <jn...@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 <ch...@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
> > > >
> > > >
> > >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@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 <ch...@gmail.com>
> *To:* Jaliya Ekanayake <ja...@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 <jn...@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 <ch...@gmail.com>
> > *To:* Jaliya Ekanayake <ja...@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 <jn...@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 <ch...@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
> > > >
> > > >
> > >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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
To: Jaliya Ekanayake
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 <jn...@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
To: Jaliya Ekanayake
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 <jn...@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
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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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
To: Jaliya Ekanayake
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 <jn...@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
To: Jaliya Ekanayake
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 <jn...@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
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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@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 <ch...@gmail.com>
> *To:* Jaliya Ekanayake <ja...@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 <jn...@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 <ch...@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
> > >
> > >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@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 <ch...@gmail.com>
> *To:* Jaliya Ekanayake <ja...@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 <jn...@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 <ch...@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
> > >
> > >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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
To: Jaliya Ekanayake
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 <jn...@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
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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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
To: Jaliya Ekanayake
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 <jn...@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
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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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
To: Jaliya Ekanayake
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 <jn...@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
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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@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 <ch...@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 <ro...@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
> >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@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 <ch...@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 <ro...@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
> >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <jn...@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 <ch...@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 <ro...@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
> >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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
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" <ch...@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 <ro...@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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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
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" <ch...@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 <ro...@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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <na...@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 <ro...@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
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Bill,
comments inline.
Regards,
Rajith
On 7/29/06, Bill Nagy <na...@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?
[RA] Sorry I should have been more specific [appologies]. I was refering to
the option (A) in Ann's reply.
Ann mentioned "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." , so I assume that Ann is
planning to save the ctx hierarchy, with complex objects in a customized
form and use simple java serialization for the simple objects.
In a production environment with 1000s of Msg Ctxs, saving and re-creating
these complex object structures will be very expensive Vs saving only the
message essential in a bean and reprocessing it again.
Remember we always optimize the system to process the messages efficiently
and we scale better with large number of messages than the serializable
approach. So recreating the message and re-processing it is not expensive
compared to the more memory intensive serializing and deserializing complex
object hierarchies.
IMHO the serialization approach will not scale in a production environment.
YMMV
> 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.
[RA] Bill as Ann has rightly pointed out " The AXIS2 message context is very
complex (it includes references to several complicated objects)" , it would
be pointless to save the message ctx in isolation. So invariably u would be
serializing a hierarchy of contexts.
Now I agree that with java.io.Externalizable you can control what can be
saved and in what form, but still u have to maintain the complex hierarchy
in what ever form u plan to serialize. So u can get away with not
serializing everything, but u will have to ensure the bare minimum to ensure
the hierarchy is maintained properly.
Now this could still mean more information than the external approach that
Chamikara use for sandesha.
>
> > 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.
[RA] Yes, I totaly agree with you on this point. But again I should have
explained more clearly [appologies for not doing so].
I was refering to another problem.
As chamikara pointed out each MC deserialization could result it's own copy
of ctx hierarchy which may not map with the hierarchy of another MC.
So we might end up doing more validations to eradicate these error states.
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
[RA] Bill I totaly agree here from a design POV. But as we all know, design
that looks perfect on paper sometimes fail w.r.t performance and
scalability.
I guess we need to maintain a delicate balance btw design elegance and
performance.
We should try to maintain encapsulation as much as possible, no question
about that.
Btw as Sanjiva mentioned all data that we are interested in the MC were
already exposed by the object by design. So atleast there we are not in
violation of encapsulation.
I value object oriented principles very much, but nothing is written in
stone and sometimes u need to bend the rules a bit to achive performance and
scalability.
How much we do so depends on the fragile balance btw accepted design
principles vs performance.
IMHO, having the MC (and ctx objects) manage their sate is very nice design,
but the saving the message and then reprocessing is more scalable.
YMMV.
On a seperate note, saving the messages in the format described by Chamikara
has the added benifit of allowing querries on the message table in case of
failure or for other management reports. This is just an added frill that I
thought would be useful.
> Regards,
> >
> > Rajith
> >
> >
> > On 7/28/06, Chamikara Jayalath <ch...@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 <ro...@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 <ro...@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
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Hi Bill,
> 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.
+1.
> 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.
I don't think that was done - that is, the MC did expose everything that
was interesting already. But +1 to the principle.
> In effect, the approach that you've chosen has abandoned encapsulation
> and created fragile dependencies -- this is bad design.
OK so there's another reason .. what Sandesha does is not Java
serialization. If we use Externalizable then yes we get control of what
to write but you still have to write to a Java object stream right? In
the case of Sandesha Chamikara has introduced a persistency abstraction
layer to support both in-memory and persistent operation. The persistent
stuff can be impl'ed with anything but so far we've only done a
Hibernate impl (which cannot be committed to Apache due to license
issues; so the code is currently on a WSO2 repo - Chamikara is putting
the code out).
Can we do the same stuff using Externalizable? If so I agree that's a
better approach for maintaining encapsulation.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <na...@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 <ro...@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
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Bill Nagy <na...@watson.ibm.com>.
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 <ch...@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 <ro...@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" <ch...@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 <ro...@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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Rajith Attapattu <ra...@gmail.com>.
Anne,
Again I will advice again serializing the contexts using any form of
serialization. This will not scale at all in a production environment.
Again this approach will be error prone and as chamikara mentioned there
will be too many information saved in the database.
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.
Regards,
Rajith
On 7/28/06, Chamikara Jayalath <ch...@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 <ro...@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
> >
> >
> > [image: Inactive hide details for "Chamikara Jayalath"
> > <ch...@gmail.com>]"Chamikara Jayalath" < chamikaramj@gmail.com>
> >
> >
> >
> > *"Chamikara Jayalath" <ch...@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*<ro...@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
> >
> >
> >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ro...@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
>
>
> [image: Inactive hide details for "Chamikara Jayalath"
> <ch...@gmail.com>]"Chamikara Jayalath" <ch...@gmail.com>
>
>
>
> *"Chamikara Jayalath" <ch...@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* <ro...@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
>
>
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ro...@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
>
>
> [image: Inactive hide details for "Chamikara Jayalath"
> <ch...@gmail.com>]"Chamikara Jayalath" <ch...@gmail.com>
>
>
>
> *"Chamikara Jayalath" <ch...@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* <ro...@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
>
>
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ro...@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
>
>
> [image: Inactive hide details for "Chamikara Jayalath"
> <ch...@gmail.com>]"Chamikara Jayalath" <ch...@gmail.com>
>
>
>
> *"Chamikara Jayalath" <ch...@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* <ro...@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
>
>
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Rajith Attapattu <ra...@gmail.com>.
I think Chamikaras approach of extracting the info into a seperate bean and
then persisting it is a much cleaner approach and I belive it's less error
prone as well.
I think it's way better than trying to serialize the MessageContext.
Regards,
Rajith
On 7/28/06, Chamikara Jayalath <ch...@gmail.com> wrote:
>
> 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 <ro...@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
> >
> >
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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
"Chamikara
Jayalath"
<chamikaramj@gmai To
l.com> Ann Robinson/Austin/IBM@IBMUS
cc
07/28/2006 07:23 axis-dev@ws.apache.org,
AM sandesha-dev@ws.apache.org
Subject
Re: [AXIS2] [Sandesha2] Saving the
Please respond to message context
axis-dev@ws.apach
e.org
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 <ro...@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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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
"Chamikara
Jayalath"
<chamikaramj@gmai To
l.com> Ann Robinson/Austin/IBM@IBMUS
cc
07/28/2006 07:23 axis-dev@ws.apache.org,
AM sandesha-dev@ws.apache.org
Subject
Re: [AXIS2] [Sandesha2] Saving the
Please respond to message context
axis-dev@ws.apach
e.org
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 <ro...@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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Ann Robinson <ro...@us.ibm.com>.
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
"Chamikara
Jayalath"
<chamikaramj@gmai To
l.com> Ann Robinson/Austin/IBM@IBMUS
cc
07/28/2006 07:23 axis-dev@ws.apache.org,
AM sandesha-dev@ws.apache.org
Subject
Re: [AXIS2] [Sandesha2] Saving the
Please respond to message context
axis-dev@ws.apach
e.org
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 <ro...@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
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ro...@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
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ro...@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
>
>
Re: [AXIS2] [Sandesha2] Saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <ro...@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
>
>