Return-Path: Delivered-To: apmail-ws-sandesha-dev-archive@www.apache.org Received: (qmail 82498 invoked from network); 31 Jul 2006 18:47:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 Jul 2006 18:47:57 -0000 Received: (qmail 87890 invoked by uid 500); 31 Jul 2006 18:47:56 -0000 Delivered-To: apmail-ws-sandesha-dev-archive@ws.apache.org Received: (qmail 87855 invoked by uid 500); 31 Jul 2006 18:47:56 -0000 Mailing-List: contact sandesha-dev-help@ws.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list sandesha-dev@ws.apache.org Received: (qmail 87844 invoked by uid 99); 31 Jul 2006 18:47:56 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jul 2006 11:47:56 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of jnekanayake@gmail.com designates 64.233.184.230 as permitted sender) Received: from [64.233.184.230] (HELO wr-out-0506.google.com) (64.233.184.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jul 2006 11:47:53 -0700 Received: by wr-out-0506.google.com with SMTP id 70so342690wra for ; Mon, 31 Jul 2006 11:47:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:reply-to:from:to:cc:references:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=SW5EKIbDDG/MnblDKmzrmOH54t2pjJCW767Ob8pLgFcyPYwuGR7nTB1eqxsWSWHi5xOOnfuaU4HDEPLyDuZuUyB4qj3jKNeqU0h8AaES/ix/hgqJiNvc4xenF0EDmMAy7UozAj1B9Aks5e3nVeH3F/Rdxkrrxe1wWxdko86nuRU= Received: by 10.65.122.20 with SMTP id z20mr2163988qbm; Mon, 31 Jul 2006 11:47:31 -0700 (PDT) Received: from BLRHJEKANAYA1 ( [149.159.1.154]) by mx.gmail.com with ESMTP id 15sm5335812nzo.2006.07.31.11.47.30; Mon, 31 Jul 2006 11:47:31 -0700 (PDT) Message-ID: <001301c6b4d1$c7214a10$9a019f95@ads.iu.edu> Reply-To: "Jaliya Ekanayake" From: "Jaliya Ekanayake" To: "Chamikara Jayalath" Cc: References: <9d4ec10b0607280523m7d3d3b29w960caab84645a75c@mail.gmail.com> <9d4ec10b0607281825h7aebb918qc0e4ef0a1d76ba39@mail.gmail.com> <1154177322.29323.3.camel@scylla.watson.ibm.com> <9d4ec10b0607301740w78db1197sf31dfea7967babe4@mail.gmail.com> <001301c6b43b$bfeae3f0$9a019f95@ads.iu.edu> <9d4ec10b0607301958x79131156p95c3798a70d1e7af@mail.gmail.com> <001701c6b499$acbd2230$9a019f95@ads.iu.edu> <9d4ec10b0607311054l2b5ddc05vf6154fbe5a1db750@mail.gmail.com> Subject: Re: [AXIS2] [Sandesha2] Saving the message context Date: Mon, 31 Jul 2006 14:47:29 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C6B4B0.3F6C1710" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_NextPart_000_0010_01C6B4B0.3F6C1710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 -----=20 From: Chamikara Jayalath=20 To: Jaliya Ekanayake=20 Cc: sandesha-dev@ws.apache.org=20 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).=20 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 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 -----=20 From: Chamikara Jayalath=20 To: Jaliya Ekanayake=20 Cc: sandesha-dev@ws.apache.org ; axis-dev@ws.apache.org=20 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 wrote:=20 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 -----=20 From: Chamikara Jayalath=20 To: nagy@watson.ibm.com=20 Cc: sandesha-dev@ws.apache.org=20 Sent: Sunday, July 30, 2006 8:40 PM=20 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.=20 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:=20 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=20 > 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=20 > 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=20 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=20 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.=20 > 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=20 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.=20 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=20 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=20 > 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=20 > 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=20 > 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=20 > 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.=20 > 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 > > > >=20 > "Chamikara = Jayalath" < chamikaramj@gmail.com > > 07/28/2006 = 07:23 AM > Please = respond to > = axis-dev@ws.apache.org=20 > > > > To=20 > > Ann > Robinson/Austin/IBM@IBMUS >=20 > cc > > axis-dev@ws.apache.org , = sandesha-dev@ws.apache.org > > Subject > > Re: [AXIS2] > [Sandesha2] > Saving the > message > context > > > > Hi Ann,=20 > > 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 =3D 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:=20 > 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=20 ------=_NextPart_000_0010_01C6B4B0.3F6C1710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Chamikara,
 
Don't know whether it is an efficient = way; how=20 about this - we can save the SOAP message after security handler using a = custom=20 handler that will only be deployed in the persistent mode.
 
-Jaliya
----- Original Message -----
From:=20 Chamikara=20 Jayalath
Sent: Monday, July 31, 2006 = 1:54 PM
Subject: Re: [AXIS2] = [Sandesha2] Saving=20 the message context

Hi Jaliya,

Well, not exactly. In Sandesha2 = scenario we=20 process the message in several transactions. Processing of a message = within a=20 handler will be done in one transaction while the invocation will be = done in=20 another transaction. So we cannot simply abandon the message. We have = to=20 reinject it into our system (thats what we do).

But if we = serialize=20 the message in the very begining of the handler chain we can asume = that the=20 context would not have been changed and saving the SOAP envelope would = be=20 enough. But this is not always a practicle solution since handlers = like=20 security will sometimes have to be present before=20 RM.

Chamikara



On 7/31/06, Jaliya=20 Ekanayake <jnekanayake@gmail.com>=20 wrote:
Hi Chamikara,
 
What I am suggesting is this. If we = get the QoS=20 information stored properly that will enable us to build a definite = state=20 after a crash.
e.g. We don't need transport info = because RM=20 will handle it by way of re-transmissions.
    =    =20 ServiceContext and ServiceGroupeContext; IMHO WS-Transaction should = handle=20 this.
 
So if we keep the states of QoS = layer then we=20 can avoid this heavy serialization.
 
Any thoughts?
 
-Jaliya
-----=20 Original Message -----
From:=20 Chamikara = Jayalath=20 Cc:=20 sandesha-dev@ws.apache.org ; axis-dev@ws.apache.org=20 Sent:=20 Sunday, July 30, 2006 10:58 PM Subject:=20 Re: [AXIS2] [Sandesha2] Saving the message context

Hi Jaliya,

Thats good news. But only the properties will = not be=20 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=20 (serviceContext, serviceGroupContext) from the Message Context and = we will=20 not want to loose these connections when the Message Context is=20 deserialized.
 
However if it can be declared that the referenced contexts will = not be=20 serialized when serializing one context, that paves the way for a = solution.=20 But not sure weather this is valid for all cases.(Still have to = think more=20 on reconstructing the context=20 hierarchy)

Chamikara


On 7/31/06, Jaliya=20 Ekanayake <jnekanayake@gmail.com> wrote:=20
Hi All,
 
As far as I remember we spent = some=20 time during the design of axis2 to solve this problem. The = final=20 conclusion we made was to do our own serialization by = serializing only=20 the properties (serializable objects) in the property bag = not the=20 entire message context which = has pointers=20 to other contexts.
 
Thanks,
-Jaliya
 
 
-----=20 Original Message -----
From:=20 Chamikara = Jayalath=20
To:=20 nagy@watson.ibm.com=20
Cc:=20 sandesha-dev@ws.apache.org
Sent:=20 Sunday, July 30, 2006 8:40 PM Subject:=20 Re: [AXIS2] [Sandesha2] Saving the message context

Hi Bill,

I agree that doing serialization = within=20 context objects is the best approach in a design perspective. = The=20 approach I followed was only possible due to MessageContext = already=20 having made its useful state public.

I also originally = tried to=20 follow Externalizable approach and introduced externalizable = methods to=20 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=20 the whole context hierarchy.

Every message context has a = pointer=20 to the configurationContext so to be general (not to be specific = to our=20 scenario) in the serialization method we would have to serialize = this=20 object as well.Since this has pointers to all other contexts = they will=20 be serialied too. What I am saying is that when adding the=20 externalizable method to the axis2 codebase we would have to = serialize=20 the configContext and other contexts as well (because some = people may=20 actually want to serialize the whole context hierarchy). But in = our case=20 it seemed like this would be a burden. Every deserialized = message=20 context with come up with its own context hierarchy and maching = between=20 two deserialized Message contexts will be extremely = difficult.

If=20 you find a solution to this problem I agree that your and Anns = approach=20 is the best way to go and I would like to use that in my code=20 :-)

Chamikara


On 7/29/06, Bill=20 Nagy < = nagy@watson.ibm.com=20 > wrote:
On=20 Fri, 2006-07-28 at 23:46 -0400, Rajith Attapattu = wrote:
>=20 Anne,
>
> Again I will advice again serializing = the=20 contexts using any form of
> serialization. This will = not scale=20 at all in a production environment.

Hi = Rajith,

Could you=20 please explain this last comment?

> Again this = approach will=20 be error prone and as chamikara mentioned
> there will = be too=20 many information saved in the database.

I don't = understand why=20 you and Chamikara keep saying that there will be
too much=20 information serialized.  You have the option of = taking=20 complete
control of the serialization, thereby = writing/reading=20 only the
information that you want and in the form that you = want it=20 to be in.  I
don't believe that Ann is arguing = for simply=20 using the default
serialization, only about who should be = in=20 control of making the
decisions as to what should be=20 saved.


>
> I am looking at clustering = certain=20 information within the ctx heirachy
> for high = availability and=20 I would only do with the bare minimum.
>
> In my = opinion=20 the performance overhead of serializing and
> = deserializing (and=20 validations to avoid erros) is a lot more than
> saving = the=20 required info in a bean like what chamikara does for
> = Sandesha=20 and then reconstructing it.
>

Having the objects = persist=20 their own state is far less error prone than
having a = third-party=20 piece of code do the persistence.  For one,=20 anytime
someone changes or adds a piece of information that = needs=20 to be saved in
order to correctly restore the state, they = have to=20 remember to modify
the external code.  It's = generally=20 hard enough to remember to modify
code embedded in the = class=20 itself, much less having to remember to
modify a completely = separate piece of code.

Secondly, you require the = objects that=20 need to be saved to expose
methods, to return the portions = that you=20 want to have serialized, that
you may not have to expose=20 otherwise.

In effect, the approach that you've chosen = has=20 abandoned encapsulation
and created fragile dependencies = -- this=20 is bad design.

-Bill

> = Regards,
>
>=20 Rajith
>
>
> On 7/28/06, Chamikara Jayalath = <=20 chamikaramj@gmail.com >=20 wrote:
>         = Hi=20 = Ann,
>
>        =20 Yes. We had introduced Externalizable implementaitons for=20 all
>         of = the=20 Context hierarchy objects sometime back. But=20 this
>         = approach=20 seemed to be saving too much information on the=20
>        =20 = database.
>
>        = =20 For example at some point there may be following=20 = context
>        =20 objects available in a running axis2=20 = instance.
>         1.=20 configuration context=20 object
>         = 2.=20 service group context=20 = objects
>         3=20 service context=20 = objects
>         4.=20 Operation context=20 = objects
>         5. A=20 lot of message context=20 = objects
>
>        =20 If we try serializing starting from a message context, since=20
>         we = have to=20 serialize every incoming message context all=20 these
>         = objects=20 will be serialized every time (recall that the=20 = message
>        =20 context hs a link to the configuration context which has links =
>         to = all other=20 context objects). Think how deficult=20 the
>        =20 reconstruction would be. Every deserialized message=20 = context
>         will=20 come up with its own hierarchy of context objects which=20
>         may = not map=20 with the context objects reconstructed=20 by
>        =20 deserializing others message=20 = contexts.
>
>        = =20 Thats why I went for this approach of saving only the=20 = relavent
>        =20 information. It seemed to be much cleaner and it was=20
>         = working=20 = :-)
>
>        =20 You had mentioned about serializing the AxisOperaion=20 = object.
>         All=20 the 'Axis*'  objects in Axis2=20 = (AxisConfiguration,
>       &nbs= p;=20 AxisServiceGroupt etc.) contains deployment time information.=20
>         So we = can=20 safely ignore them in the serializing=20 = process.
>
>
>       = ; =20 = Chamikara
>
>
>
>
>    =     =20 On 7/29/06, Ann Robinson <=20 robinsona@us.ibm.com>=20 = wrote:
>          = ;      =20 Hi=20 = Chamikara,
>         &= nbsp;      =20 Thanks for the=20 = information.
>
>       &nb= sp;        =20 Did you consider using java.io.Externalizable for=20 = the
>          &n= bsp;     =20 AXIS2 message context-related classes? (Having=20 = the
>          &n= bsp;     =20 work done by the AXIS2 objects would have=20 = simplified
>         &= nbsp;      =20 the actions that Sandesha needed to take in order=20 = to
>          &nb= sp;     =20 save the message context, so I am curious about=20 = any
>          &n= bsp;     =20 issues that were=20 = encountered.
>
>
>      &= nbsp;         =20 In the MessageStoreBean, how much of the=20 = various
>         &nbs= p;      =20 objects do you store as Strings? For example,=20 = the
>          &n= bsp;     =20 AxisOperation object contains several lists and=20 = the
>          &n= bsp;     =20 executionChain object contains a list of handlers=20 = and
>          &n= bsp;     =20 = phases.
>
>
>
>
>    &n= bsp;           =20 = Ann
>
>
>       &nbs= p;        =20 WebSphere Development, Web Services=20 = Engine
>
>        &nb= sp;       =20 = IBM
>          &n= bsp;     =20 11501 Burnet Rd IZip=20 = 9035G021
>         &nb= sp;      =20 Austin, TX=20 = 78758
>          =       =20 (512)838-9438 TL=20 = 678-9438
>
>
>
>     &nb= sp;          =20 Inactive hide details for=20 = Chamikara"Chamikara
>       &nbs= p;        =20 Jayalath" < chamikaramj@gmail.com = >
>
>
>=20 =
>           = ;            =             &= nbsp;           &n= bsp;=20 "Chamikara Jayalath" <=20 chamikaramj@gmail.com=20 = >
>         &nb= sp;           &nbs= p;            = ;            =   =20 07/28/2006 07:23=20 = AM
>          &nb= sp;           &nbs= p;            = ;            =  =20 Please respond=20 = to
>          &nb= sp;           &nbs= p;            = ;            =  =20 axis-dev@ws.apache.org=20 =
>
>
>
>      &= nbsp;           &n= bsp;         To=20 =
>
>         &nb= sp;      =20 = Ann
>          &n= bsp;     =20 Robinson/Austin/IBM@IBMUS
>=20 =
>           = ;            =      cc
>
>    &= nbsp;           =20 axis-dev@ws.apache.org , sandesha-dev@ws.apache.org
>
>  = ;            =         =20 = Subject
>
>        &n= bsp;       =20 Re:=20 = [AXIS2]
>         &nbs= p;      =20 = [Sandesha2]
>         =        =20 Saving=20 = the
>          &n= bsp;     =20 = message
>         &nbs= p;      =20 = context
>
>
>
>     &nbs= p;          =20 Hi Ann,=20 =
>
>         &nb= sp;      =20 I did some work on serializing message contexts=20 = and
>          &n= bsp;     =20 reconstructing them. This was done as a part of=20 = the
>          &n= bsp;     =20 Sandesha2 Persistent Storage Manager=20 = implementation.
>        &n= bsp;       =20 Unfortunately could not commit the code into=20 = Apache
>          = ;      =20 due to a license issue (it was dependent=20 = on
>          &nb= sp;     =20 Hibernate). But will try to host it somewhere=20 = else
>          &= nbsp;     =20 = soon.
>
>        &nbs= p;       =20 The approach i took was extracting the=20 = relevant
>         &nb= sp;      =20 information from the message context, and saving=20 = them
>          &= nbsp;     =20 in a java bean. Later this bean was used to=20 = recostruct
>         &= nbsp;      =20 the message context. The format of this bean was=20 = as
>          &nb= sp;     =20 = follows.
>
>        &= nbsp;       =20 public class MessageStoreBean=20 = {
>
>         &n= bsp;      =20 private String=20 = SOAPEnvelopeString;
>       &nbs= p;        =20 private String=20 = storedKey;
>         &= nbsp;      =20 private int SOAPVersion =3D=20 = 0;
>          &nb= sp;     =20 private String=20 = transportOut;
>        &nbs= p;       =20 private String=20 = axisServiceGroup;
>        =         =20 private String=20 = axisService;
>         = ;       =20 private String=20 = axisOperation;
>        &nb= sp;       =20 private String=20 = axisOperationMEP;
>        =         =20 private String=20 = toURL;
>          = ;      =20 private String=20 = transportTo;
>         = ;       =20 private int=20 = flow;
>          =       =20 private String=20 = executionChainString;
>       &n= bsp;        =20 private String=20 = messageReceiverString;
>       &= nbsp;        =20 private boolean=20 = serverSide;
>         =        =20 private String=20 = inMessageStoreKey;
>        = ;        =20 private String=20 = messageID;
>         &= nbsp;      =20 private String=20 = persistentPropertyString;
>      &nbs= p;         =20 private String=20 = callbackClassName;
>        = ;        =20 private String=20 = action;
>
>        &n= bsp;       =20 = }
>
>         &n= bsp;      =20 As you can see the aim was to avoid=20 = Java
>          &= nbsp;     =20 serialization. One defect here is SOAP envelope=20 = being
>          =       =20 saved as a string, which may not be possible in the=20 = RM
>          &nb= sp;     =20 +MTOM scenario. I guess we can support that when=20 = a
>          &nbs= p;     =20 better serialization mechanism gets available for=20 = SOAP
>          &= nbsp;     =20 = envelopes.
>
>        = ;        =20 = Chamikara
>
>
>
>     &n= bsp;          =20 On 7/27/06, Ann Robinson < = robinsona@us.ibm.com=20 = >
>         &nb= sp;      =20 wrote:=20 =
>           = ;            =  =20 Hi=20 = all,
>
>         = ;            =    =20 I have posted this note to both the AXIS2=20 = and
>          &n= bsp;           &nb= sp; =20 SANDESHA developer discussion lists, so=20 = I
>          &nbs= p;            = ; =20 apologize in advance to those folks who=20 = get
>          &n= bsp;           &nb= sp; =20 multiple copies of this=20 = note.
>
>        &nbs= p;            = ;   =20 I am investigating how to save and restore=20 = the
>          &n= bsp;           &nb= sp; =20 message context in AXIS2. This=20 = is
>          &nb= sp;           &nbs= p; =20 functionality that would be used by=20 = other
>          =             &= nbsp; =20 quality-of-service layers, for example, by=20 = a
>          &nbs= p;            = ; =20 WS-ReliableMessaging implementation=20 = -
>          &nbs= p;            = ; =20 particularly one that is composed=20 = with
>          &= nbsp;           &n= bsp; =20 WS-Security, to save the message in=20 = persistent
>         &= nbsp;           &n= bsp;  =20 storage and later resume the=20 = message
>         &nbs= p;            = ;  =20 = processing.
>
>       &nbs= p;            = ;    =20 The AXIS2 message context is very complex=20 = (it
>          &n= bsp;           &nb= sp; =20 includes references to several=20 = complicated
>         =             &= nbsp;  =20 objects) and does not lend itself to=20 = the
>          &n= bsp;           &nb= sp; =20 default java serialization=20 = mechanism
>         &n= bsp;           &nb= sp;  =20 (java.io.Serializable). In order to save=20 = the
>          &n= bsp;           &nb= sp; =20 message context, the possible=20 = solutions
>         &n= bsp;           &nb= sp;  =20 include the=20 = following:
>
>        = ;            =     =20 (A) Internal Message Context=20 = option
>
>        &nb= sp;           &nbs= p;   =20 Do a customized serialization=20 = using
>          =             &= nbsp; =20 java.io.Externalizable in the complex=20 = objects
>         &nbs= p;            = ;  =20 and use the default serialization=20 = mechanism
>         &n= bsp;           &nb= sp;  =20 (java.io.Serializable) in the simple=20 = objects.
>         &nb= sp;           &nbs= p;  =20 - - This keeps the knowledge of the=20 = object's
>         &nb= sp;           &nbs= p;  =20 internals in the object and keeps=20 = the
>          &n= bsp;           &nb= sp; =20 responsibility in the object for=20 = persisting
>         &= nbsp;           &n= bsp;  =20 and resurrecting its own=20 = state.
>          = ;            =   =20 - - This lets an object have a plugpoint=20 = where
>          =             &= nbsp; =20 needed to manage "user" data. This would=20 = apply
>          =             &= nbsp; =20 to the situation where an object maintains=20 = a
>          &nbs= p;            = ; =20 set of properties or attributes that=20 = are
>          &n= bsp;           &nb= sp; =20 supplied by users of the object. The=20 = plugpoint
>         &n= bsp;           &nb= sp;  =20 would define an interface so that the users=20 = of
>          &nb= sp;           &nbs= p; =20 the object could save=20 = their
>          =             &= nbsp; =20 properties/attributes=20 = appropriately.
>
>       &= nbsp;           &n= bsp;    =20 (B) External Layer=20 = option
>
>        &nb= sp;           &nbs= p;   =20 Put in get/set methods in all of the=20 = objects
>         &nbs= p;            = ;  =20 related to the message context in order=20 = to
>          &nb= sp;           &nbs= p; =20 allow another layer or quality of=20 = service
>         &nbs= p;            = ;  =20 (QoS) to extract sufficient information=20 = from
>          &= nbsp;           &n= bsp; =20 the message context in order to save=20 = and
>          &n= bsp;           &nb= sp; =20 resurrect the=20 = information.
>         = ;            =    =20 - - The simplest form of this technique=20 = is
>          &nb= sp;           &nbs= p; =20 saving just the message (and the=20 = message
>         &nbs= p;            = ;  =20 attachments). However, this means that=20 = any
>          &n= bsp;           &nb= sp; =20 processing on the message has to be=20 = re-done
>         &nbs= p;            = ;  =20 from the=20 = beginning.
>         &= nbsp;           &n= bsp;  =20 - - If there is a requirement to maintain=20 = the
>          &n= bsp;           &nb= sp; =20 security context with the message, then=20 = the
>          &n= bsp;           &nb= sp; =20 security layer would need to=20 = provide
>         &nbs= p;            = ;  =20 additional interfaces to allow that=20 = message's
>         &n= bsp;           &nb= sp;  =20 security context to be acquired by that=20 = other
>          =             &= nbsp; =20 = layer.
>
>        &nb= sp;           &nbs= p;   =20 (C) Core Plugpoint=20 = option
>
>        &nb= sp;           &nbs= p;   =20 Have a plugpoint in the AXIS2 core that=20 = would
>          =             &= nbsp; =20 provide an interface to capture=20 = essential
>         &n= bsp;           &nb= sp;  =20 message context data for saving and=20 = restoring
>         &n= bsp;           &nb= sp;  =20 = it.
>          &n= bsp;           &nb= sp; =20 - - This solution would be a=20 = compromise
>         &= nbsp;           &n= bsp;  =20 between (A) and=20 = (B)
>          &n= bsp;           &nb= sp; =20 - - This requires knowledge of message=20 = context
>         &nbs= p;            = ;  =20 object-related internals inside of=20 = the
>          &n= bsp;           &nb= sp; =20 plugpoint implementation, which is not=20 = good
>          &= nbsp;           &n= bsp; =20 object oriented=20 = design
>
>
>       &= nbsp;           &n= bsp;    =20 Any other suggestions or=20 = comments?
>
>        =             &= nbsp;   =20 I understand that there has been a=20 = previous
>         &nb= sp;           &nbs= p;  =20 attempt to do this in AXIS2 based on=20 = Sandesha
>         &nb= sp;           &nbs= p;  =20 requirements and that this attempt did=20 = not
>          &n= bsp;           &nb= sp; =20 work. I was wondering if anyone remembers=20 = what
>          &= nbsp;           &n= bsp; =20 problems were encountered and what=20 = issues
>          = ;            =   =20 ultimately blocked that=20 = solution?
>
>
>      &nbs= p;            = ;     =20 = Thanks,
>         &nbs= p;            = ;  =20 = Ann
>
>
>       &nbs= p;            = ;    =20 WebSphere Development, Web Services=20 = Engine
>
>        &nb= sp;           &nbs= p;   =20 = IBM
>          &n= bsp;           &nb= sp; =20 11501 Burnet Rd IZip=20 = 9035G021
>         &nb= sp;           &nbs= p;  =20 Austin, TX=20 = 78758
>          =             &= nbsp; =20 (512)838-9438 TL=20 = 678-9438
>
>
>
>
>
>
>
><= BR>

--------------------------------------------------------------= -------
To=20 unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For = additional=20 commands, e-mail: axis-dev-help@ws.apache.org=20


=


------=_NextPart_000_0010_01C6B4B0.3F6C1710--