[prev in list] [next in list] [prev in thread] [next in thread]
List: sandesha-dev
Subject: Re: [AXIS2] [Sandesha2] Saving the message context
From: "Jaliya Ekanayake" <jnekanayake () gmail ! com>
Date: 2006-07-31 18:47:29
Message-ID: 001301c6b4d1$c7214a10$9a019f95 () ads ! iu ! edu
[Download RAW message or body]
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 <jnekanayake@gmail.com> wrote:
Hi Chamikara,
What I am suggesting is this. If we get the QoS information stored properly that \
will enable us to build a definite state after a crash. e.g. We don't need transport \
info because RM will handle it by way of re-transmissions.
ServiceContext and ServiceGroupeContext; IMHO WS-Transaction should \
handle this.
So if we keep the states of QoS layer then we can avoid this heavy serialization.
Any thoughts?
-Jaliya
----- Original Message -----
From: Chamikara Jayalath
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
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2722" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hi Chamikara,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>-Jaliya</FONT></DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 \
2px solid; MARGIN-RIGHT: 0px"> <DIV style="FONT: 10pt arial">----- Original Message \
----- </DIV> <DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=chamikaramj@gmail.com href="mailto:chamikaramj@gmail.com">Chamikara
Jayalath</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=jaliya@apache.org
href="mailto:jaliya@apache.org">Jaliya Ekanayake</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=sandesha-dev@ws.apache.org
href="mailto:sandesha-dev@ws.apache.org">sandesha-dev@ws.apache.org</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, July 31, 2006 1:54 PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [AXIS2] [Sandesha2] Saving
the message context</DIV>
<DIV><BR></DIV>Hi Jaliya,<BR><BR>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). <BR><BR>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.<BR><BR>Chamikara<BR><BR><BR>
<DIV><SPAN class=gmail_quote><BR>On 7/31/06, <B class=gmail_sendername>Jaliya
Ekanayake</B> <<A
href="mailto:jnekanayake@gmail.com">jnekanayake@gmail.com</A>>
wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) \
1px solid"> <DIV>
<DIV bgcolor="#ffffff">
<DIV><FONT face=Arial size=2>Hi Chamikara,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2>e.g. We don't need transport info because RM
will handle it by way of re-transmissions.</FONT></DIV>
<DIV><FONT face=Arial size=2>
ServiceContext and ServiceGroupeContext; IMHO WS-Transaction should handle
this.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>So if we keep the states of QoS layer then we
can avoid this heavy serialization.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Any thoughts?</FONT></DIV></DIV>
<DIV><SPAN class=sg>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>-Jaliya</FONT></DIV></SPAN></DIV>
<DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: \
rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px"></BLOCKQUOTE></DIV> <DIV><SPAN class=q>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: normal">-----
Original Message ----- </DIV>
<DIV
style="BACKGROUND: rgb(228,228,228) 0% 50%; FONT: 10pt arial; font-size-adjust: \
none; font-stretch: normal; moz-background-clip: initial; moz-background-origin: \
initial; moz-background-inline-policy: initial"><B>From:</B> <A \
title="chamikaramj@gmail.com (mailto:chamikaramj@gmail.com)" onclick="return \
top.js.OpenExtLink(window,event,this)" href="mailto:chamikaramj@gmail.com" \
target=_blank>Chamikara Jayalath</A> </DIV></SPAN></DIV>
<DIV><SPAN class=e id=q_10cc479e7097f54d_4>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: normal"><B>To:</B> \
<A title="jaliya@apache.org (mailto:jaliya@apache.org)"
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:jaliya@apache.org" target=_blank>Jaliya Ekanayake</A> </DIV>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: normal"><B>Cc:</B> \
<A title="sandesha-dev@ws.apache.org (mailto:sandesha-dev@ws.apache.org)"
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:sandesha-dev@ws.apache.org"
target=_blank>sandesha-dev@ws.apache.org</A> ; <A
title="axis-dev@ws.apache.org (mailto:axis-dev@ws.apache.org)"
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:axis-dev@ws.apache.org" target=_blank>axis-dev@ws.apache.org
</A></DIV>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: \
normal"><B>Sent:</B> Sunday, July 30, 2006 10:58 PM</DIV>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: \
normal"><B>Subject:</B> Re: [AXIS2] [Sandesha2] Saving the message context</DIV>
<DIV><FONT face=Arial size=2></FONT><BR></DIV>
<DIV>Hi Jaliya,<BR><BR>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</DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>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.</DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>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)<BR><BR>Chamikara<BR><BR><BR></DIV></SPAN></DIV>
<DIV></DIV>
<DIV><SPAN class=e id=q_10cc479e7097f54d_6>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: \
rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px">
<DIV><SPAN class=gmail_quote>On 7/31/06, <B class=gmail_sendername>Jaliya
Ekanayake</B> <<A title=mailto:jnekanayake@gmail.com
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:jnekanayake@gmail.com"
target=_blank>jnekanayake@gmail.com</A>> wrote:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: \
rgb(204,204,204) 1px solid"> <DIV>
<DIV bgcolor="#ffffff">
<DIV><FONT face=Arial size=2>Hi All,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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</FONT><FONT face=Arial size=2> message context which has pointers
to other contexts.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Thanks,</FONT></DIV></DIV>
<DIV><SPAN>
<DIV><FONT face=Arial size=2>-Jaliya</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV></SPAN></DIV>
<DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: \
rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px"></BLOCKQUOTE></DIV> <DIV><SPAN>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: normal">-----
Original Message ----- </DIV>
<DIV
style="BACKGROUND: rgb(228,228,228) 0% 50%; FONT: 10pt arial; \
font-size-adjust: none; font-stretch: normal; moz-background-clip: initial; \
moz-background-origin: initial; moz-background-inline-policy: initial"><B>From:</B> \
<A
title="chamikaramj@gmail.com (mailto:chamikaramj@gmail.com) \
(mailto:chamikaramj@gmail.com)" onclick="return \
top.js.OpenExtLink(window,event,this)"
href="mailto:chamikaramj@gmail.com" target=_blank>Chamikara Jayalath
</A></DIV>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: \
normal"><B>To:</B> <A
title="nagy@watson.ibm.com (mailto:nagy@watson.ibm.com) \
(mailto:nagy@watson.ibm.com)" onclick="return \
top.js.OpenExtLink(window,event,this)"
href="mailto:nagy@watson.ibm.com" target=_blank>nagy@watson.ibm.com</A>
</DIV></SPAN></DIV>
<DIV><SPAN>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: \
normal"><B>Cc:</B> <A
title="sandesha-dev@ws.apache.org (mailto:sandesha-dev@ws.apache.org) \
(mailto:sandesha-dev@ws.apache.org)" onclick="return \
top.js.OpenExtLink(window,event,this)" href="mailto:sandesha-dev@ws.apache.org"
target=_blank>sandesha-dev@ws.apache.org</A> </DIV>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: \
normal"><B>Sent:</B> Sunday, July 30, 2006 8:40 PM </DIV>
<DIV
style="FONT: 10pt arial; font-size-adjust: none; font-stretch: \
normal"><B>Subject:</B> Re: [AXIS2] [Sandesha2] Saving the message context</DIV>
<DIV><BR></DIV>Hi Bill,<BR><BR>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.<BR><BR>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. <BR><BR>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.<BR><BR>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
:-)<BR><BR>Chamikara<BR><BR><BR>
<DIV><SPAN class=gmail_quote>On 7/29/06, <B class=gmail_sendername>Bill
Nagy</B> <<A
title="mailto:nagy@watson.ibm.com (mailto:nagy@watson.ibm.com) \
(mailto:nagy@watson.ibm.com)" onclick="return \
top.js.OpenExtLink(window,event,this)"
href="mailto:nagy@watson.ibm.com" target=_blank> nagy@watson.ibm.com
</A>> wrote: </SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: \
rgb(204,204,204) 1px solid">On Fri, 2006-07-28 at 23:46 -0400, Rajith Attapattu \
wrote:<BR>> Anne,<BR>><BR>> Again I will advice again serializing the
contexts using any form of <BR>> serialization. This will not scale
at all in a production environment.<BR><BR>Hi Rajith,<BR><BR>Could you
please explain this last comment?<BR><BR>> Again this approach will
be error prone and as chamikara mentioned <BR>> there will be too
many information saved in the database.<BR><BR>I don't understand why
you and Chamikara keep saying that there will be<BR>too much
information serialized. You have the option of taking
complete <BR>control of the serialization, thereby writing/reading
only the<BR>information that you want and in the form that you want it
to be in. I<BR>don't believe that Ann is arguing for simply
using the default<BR>serialization, only about who should be in
control of making the <BR>decisions as to what should be
saved.<BR><BR><BR>><BR>> I am looking at clustering certain
information within the ctx heirachy<BR>> for high availability and
I would only do with the bare minimum.<BR>><BR>> In my opinion
the performance overhead of serializing and<BR>> deserializing (and
validations to avoid erros) is a lot more than<BR>> saving the
required info in a bean like what chamikara does for<BR>> Sandesha
and then reconstructing it. <BR>><BR><BR>Having the objects persist
their own state is far less error prone than<BR>having a third-party
piece of code do the persistence. For one,
anytime<BR>someone changes or adds a piece of information that needs
to be saved in <BR>order to correctly restore the state, they have to
remember to modify<BR>the external code. It's generally
hard enough to remember to modify<BR>code embedded in the class
itself, much less having to remember to<BR>modify a completely
separate piece of code. <BR><BR>Secondly, you require the objects that
need to be saved to expose<BR>methods, to return the portions that you
want to have serialized, that<BR>you may not have to expose
otherwise.<BR><BR>In effect, the approach that you've chosen has
abandoned encapsulation <BR>and created fragile dependencies -- this
is bad design.<BR><BR>-Bill<BR><BR>> Regards,<BR>><BR>>
Rajith<BR>><BR>><BR>> On 7/28/06, Chamikara Jayalath <<A
title="mailto:chamikaramj@gmail.com (mailto:chamikaramj@gmail.com) \
(mailto:chamikaramj@gmail.com)" onclick="return \
top.js.OpenExtLink(window,event,this)" href="mailto:chamikaramj@gmail.com" \
target=_blank> chamikaramj@gmail.com </A>>
wrote:<BR>> Hi
Ann,<BR>><BR>>
Yes. We had introduced Externalizable implementaitons for
all<BR>> of the
Context hierarchy objects sometime back. But
this<BR>> approach
seemed to be saving too much information on the
<BR>>
database.<BR>><BR>>
For example at some point there may be following
context<BR>>
objects available in a running axis2
instance.<BR>> 1.
configuration context
object<BR>> 2.
service group context
objects<BR>> 3
service context
objects<BR>> 4.
Operation context
objects<BR>> 5. A
lot of message context
objects<BR>><BR>>
If we try serializing starting from a message context, since
<BR>> we have to
serialize every incoming message context all
these<BR>> objects
will be serialized every time (recall that the
message<BR>>
context hs a link to the configuration context which has links
<BR>> to all other
context objects). Think how deficult
the<BR>>
reconstruction would be. Every deserialized message
context<BR>> will
come up with its own hierarchy of context objects which
<BR>> may not map
with the context objects reconstructed
by<BR>>
deserializing others message
contexts.<BR>><BR>>
Thats why I went for this approach of saving only the
relavent<BR>>
information. It seemed to be much cleaner and it was
<BR>> working
:-)<BR>><BR>>
You had mentioned about serializing the AxisOperaion
object.<BR>> All
the 'Axis*' objects in Axis2
(AxisConfiguration,<BR>> \
AxisServiceGroupt etc.) contains deployment time information.
<BR>> So we can
safely ignore them in the serializing
process.<BR>><BR>><BR>> \
Chamikara<BR>><BR>><BR>><BR>><BR>> \
On 7/29/06, Ann Robinson <<A
title="mailto:robinsona@us.ibm.com (mailto:robinsona@us.ibm.com) \
(mailto:robinsona@us.ibm.com)" onclick="return \
top.js.OpenExtLink(window,event,this)" href="mailto:robinsona@us.ibm.com" \
target=_blank> robinsona@us.ibm.com</A>>
wrote:<BR>> \
Hi
Chamikara,<BR>> \
Thanks for the
information.<BR>><BR>> \
Did you consider using java.io.Externalizable for
the<BR>> \
AXIS2 message context-related classes? (Having
the<BR>> \
work done by the AXIS2 objects would have
simplified<BR>> \
the actions that Sandesha needed to take in order
to<BR>> \
save the message context, so I am curious about
any<BR>> \
issues that were
encountered.<BR>><BR>><BR>> \
In the MessageStoreBean, how much of the
various<BR>> \
objects do you store as Strings? For example,
the<BR>> \
AxisOperation object contains several lists and
the<BR>> \
executionChain object contains a list of handlers
and<BR>> \
phases.<BR>><BR>><BR>><BR>><BR>> \
Ann<BR>><BR>><BR>> \
WebSphere Development, Web Services
Engine<BR>><BR>> \
IBM<BR>> \
11501 Burnet Rd IZip
9035G021<BR>> \
Austin, TX
78758<BR>> \
(512)838-9438 TL
678-9438<BR>><BR>><BR>><BR>> \
Inactive hide details for
Chamikara"Chamikara<BR>> \
Jayalath" < <A
title="mailto:chamikaramj@gmail.com (mailto:chamikaramj@gmail.com) \
(mailto:chamikaramj@gmail.com)" onclick="return \
top.js.OpenExtLink(window,event,this)" href="mailto:chamikaramj@gmail.com"
target=_blank>chamikaramj@gmail.com </A>><BR>><BR>><BR>>
<BR>> &n \
bsp; &nbs \
p; \
"Chamikara Jayalath" <<A
title="mailto:chamikaramj@gmail.com (mailto:chamikaramj@gmail.com) \
(mailto:chamikaramj@gmail.com)" onclick="return \
top.js.OpenExtLink(window,event,this)" href="mailto:chamikaramj@gmail.com" \
target=_blank> chamikaramj@gmail.com
</A>><BR>> \
&n \
bsp; \
07/28/2006 07:23
AM<BR>> \
&n \
bsp; \
Please respond
to<BR>> \
&n \
bsp; \
<A
title="mailto:axis-dev@ws.apache.org (mailto:axis-dev@ws.apache.org) \
(mailto:axis-dev@ws.apache.org)" onclick="return \
top.js.OpenExtLink(window,event,this)" href="mailto:axis-dev@ws.apache.org"
target=_blank>axis-dev@ws.apache.org
</A><BR>><BR>><BR>><BR>> &nbs \
p; To \
<BR>><BR>> \
Ann<BR>> \
Robinson/Austin/IBM@IBMUS<BR>>
<BR>> &n \
bsp; &nbs \
p; cc<BR>><BR>> \
<A
title="mailto:axis-dev@ws.apache.org (mailto:axis-dev@ws.apache.org) \
(mailto:axis-dev@ws.apache.org)" onclick="return \
top.js.OpenExtLink(window,event,this)" href="mailto:axis-dev@ws.apache.org"
target=_blank>axis-dev@ws.apache.org </A>, <A
title="mailto:sandesha-dev@ws.apache.org \
(mailto:sandesha-dev@ws.apache.org) (mailto:sandesha-dev@ws.apache.org)" \
onclick="return top.js.OpenExtLink(window,event,this)" \
href="mailto:sandesha-dev@ws.apache.org" \
target=_blank>sandesha-dev@ws.apache.org</A><BR>><BR>> &n \
bsp; \
Subject<BR>><BR>> \
Re:
[AXIS2]<BR>> \
[Sandesha2]<BR>> \
Saving
the<BR>> \
message<BR>> \
context<BR>><BR>><BR>><BR>> \
Hi Ann,
<BR>><BR>> \
I did some work on serializing message contexts
and<BR>> \
reconstructing them. This was done as a part of
the<BR>> \
Sandesha2 Persistent Storage Manager
implementation.<BR>> \
Unfortunately could not commit the code into
Apache<BR>> \
due to a license issue (it was dependent
on<BR>> \
Hibernate). But will try to host it somewhere
else<BR>> \
soon.<BR>><BR>> \
The approach i took was extracting the
relevant<BR>> \
information from the message context, and saving
them<BR>> \
in a java bean. Later this bean was used to
recostruct<BR>> \
the message context. The format of this bean was
as<BR>> \
follows.<BR>><BR>> \
public class MessageStoreBean
{<BR>><BR>> \
private String
SOAPEnvelopeString;<BR>> \
private String
storedKey;<BR>> \
private int SOAPVersion =
0;<BR>> \
private String
transportOut;<BR>> \
private String
axisServiceGroup;<BR>> \
private String
axisService;<BR>> \
private String
axisOperation;<BR>> \
private String
axisOperationMEP;<BR>> \
private String
toURL;<BR>> \
private String
transportTo;<BR>> \
private int
flow;<BR>> \
private String
executionChainString;<BR>> \
private String
messageReceiverString;<BR>> \
private boolean
serverSide;<BR>> \
private String
inMessageStoreKey;<BR>> \
private String
messageID;<BR>> \
private String
persistentPropertyString;<BR>> \
private String
callbackClassName;<BR>> \
private String
action;<BR>><BR>> \
}<BR>><BR>> \
As you can see the aim was to avoid
Java<BR>> \
serialization. One defect here is SOAP envelope
being<BR>> \
saved as a string, which may not be possible in the
RM<BR>> \
+MTOM scenario. I guess we can support that when
a<BR>> \
better serialization mechanism gets available for
SOAP<BR>> \
envelopes.<BR>><BR>> \
Chamikara<BR>><BR>><BR>><BR>> \
On 7/27/06, Ann Robinson <<A
title="mailto:robinsona@us.ibm.com (mailto:robinsona@us.ibm.com) \
(mailto:robinsona@us.ibm.com)" onclick="return \
top.js.OpenExtLink(window,event,this)"
href="mailto:robinsona@us.ibm.com" target=_blank> robinsona@us.ibm.com
</A>><BR>> \
wrote:
<BR>> \
Hi
all,<BR>><BR>> &n \
bsp; \
I have posted this note to both the AXIS2
and<BR>> \
SANDESHA developer discussion lists, so
I<BR>> \
apologize in advance to those folks who
get<BR>> \
multiple copies of this
note.<BR>><BR>> & \
nbsp; \
I am investigating how to save and restore
the<BR>> \
message context in AXIS2. This
is<BR>> \
functionality that would be used by
other<BR>> &nb \
sp; \
quality-of-service layers, for example, by
a<BR>> \
WS-ReliableMessaging implementation
-<BR>> \
particularly one that is composed
with<BR>> \
WS-Security, to save the message in
persistent<BR>> &nbs \
p; \
storage and later resume the
message<BR>> & \
nbsp; \
processing.<BR>><BR>>   \
; \
The AXIS2 message context is very complex
(it<BR>> \
includes references to several
complicated<BR>> &nb \
sp; \
objects) and does not lend itself to
the<BR>> \
default java serialization
mechanism<BR>>   \
; \
(java.io.Serializable). In order to save
the<BR>> \
message context, the possible
solutions<BR>>   \
; \
include the
following:<BR>><BR>> &n \
bsp; \
(A) Internal Message Context
option<BR>><BR>> \
\
Do a customized serialization
using<BR>> &nb \
sp; \
java.io.Externalizable in the complex \
objects<BR>> \
and use the default serialization
mechanism<BR>>   \
; \
(java.io.Serializable) in the simple
objects.<BR>> \
\
- - This keeps the knowledge of the
object's<BR>> \
\
internals in the object and keeps \
the<BR>> \
responsibility in the object for
persisting<BR>> &nbs \
p; \
and resurrecting its own
state.<BR>> &n \
bsp; \
- - This lets an object have a plugpoint
where<BR>> &nb \
sp; \
needed to manage "user" data. This would \
apply<BR>> \
to the situation where an object maintains
a<BR>> \
set of properties or attributes that
are<BR>> \
supplied by users of the object. The
plugpoint<BR>>   \
; \
would define an interface so that the users
of<BR>> \
the object could save
their<BR>> &nb \
sp; \
properties/attributes \
appropriately.<BR>><BR>> &n \
bsp; \
(B) External Layer
option<BR>><BR>> \
\
Put in get/set methods in all of the
objects<BR>> & \
nbsp; \
related to the message context in order
to<BR>> \
allow another layer or quality of
service<BR>> & \
nbsp; \
(QoS) to extract sufficient information \
from<BR>> \
the message context in order to save
and<BR>> \
resurrect the
information.<BR>> &n \
bsp; \
- - The simplest form of this technique
is<BR>> \
saving just the message (and the
message<BR>> & \
nbsp; \
attachments). However, this means that \
any<BR>> \
processing on the message has to be
re-done<BR>> & \
nbsp; \
from the beginning.<BR>> &nb \
sp; \
- - If there is a requirement to maintain
the<BR>> \
security context with the message, then
the<BR>> \
security layer would need to
provide<BR>> & \
nbsp; \
additional interfaces to allow that \
message's<BR>> \
security context to be acquired by that
other<BR>> &nb \
sp; \
layer.<BR>><BR>> \
(C) Core Plugpoint
option<BR>><BR>> \
\
Have a plugpoint in the AXIS2 core that
would<BR>> &nb \
sp; \
provide an interface to capture \
essential<BR>> \
message context data for saving and
restoring<BR>>   \
; \
it.<BR>> \
- - This solution would be a
compromise<BR>> &nbs \
p; \
between (A) and
(B)<BR>> \
- - This requires knowledge of message
context<BR>> & \
nbsp; \
object-related internals inside of \
the<BR>> \
plugpoint implementation, which is not
good<BR>> \
object oriented
design<BR>><BR>><BR>> &nbs \
p; \
Any other suggestions or
comments?<BR>><BR>> &nb \
sp; \
I understand that there has been a
previous<BR>> \
\
attempt to do this in AXIS2 based on \
Sandesha<BR>> \
requirements and that this attempt did
not<BR>> \
work. I was wondering if anyone remembers
what<BR>> \
problems were encountered and what
issues<BR>> &n \
bsp; \
ultimately blocked that \
solution?<BR>><BR>><BR>>   \
; \
Thanks,<BR>> \
Ann<BR>><BR>><BR>> &nb \
sp; \
WebSphere Development, Web Services
Engine<BR>><BR>> \
\
IBM<BR>> \
11501 Burnet Rd IZip
9035G021<BR>> \
\
Austin, TX 78758<BR>> \
\
(512)838-9438 TL 678-9438<BR>><BR>><BR>><BR>><BR>><BR>><BR>><BR \
>><BR><BR><BR>---------------------------------------------------------------------<BR>To \
>
unsubscribe, e-mail: <A
title="mailto:axis-dev-unsubscribe@ws.apache.org \
(mailto:axis-dev-unsubscribe@ws.apache.org) \
(mailto:axis-dev-unsubscribe@ws.apache.org)" onclick="return \
top.js.OpenExtLink(window,event,this)" \
href="mailto:axis-dev-unsubscribe@ws.apache.org"
target=_blank>axis-dev-unsubscribe@ws.apache.org</A><BR>For additional
commands, e-mail: <A
title="mailto:axis-dev-help@ws.apache.org \
(mailto:axis-dev-help@ws.apache.org) (mailto:axis-dev-help@ws.apache.org)" \
onclick="return top.js.OpenExtLink(window,event,this)" \
href="mailto:axis-dev-help@ws.apache.org" target=_blank>axis-dev-help@ws.apache.org \
</A><BR><BR></BLOCKQUOTE></DIV><BR></SPAN></DIV>
<DIV></DIV></DIV></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></SPAN></DIV>
<DIV></DIV></DIV></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic