Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 5335 invoked from network); 31 Jul 2006 12:06:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 Jul 2006 12:06:25 -0000 Received: (qmail 77545 invoked by uid 500); 31 Jul 2006 12:06:21 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 77502 invoked by uid 500); 31 Jul 2006 12:06:21 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 77491 invoked by uid 99); 31 Jul 2006 12:06:21 -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 05:06:21 -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.237 as permitted sender) Received: from [64.233.184.237] (HELO wr-out-0506.google.com) (64.233.184.237) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jul 2006 05:06:19 -0700 Received: by wr-out-0506.google.com with SMTP id 70so270403wra for ; Mon, 31 Jul 2006 05:05:58 -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=IBTbRrQdb//ugq/cOniOyQNDJVQ9XSVDmP+sKNdWOjlkx7Einm948LEOUSuuT9d0315lf4u/IiZLFs2w4o5GgTVvikErHcPxrTZuy4dRfueM3q3z3Oh9Rh2jkuK61Sq0mz/PyDNnI8Cqc4WOtSBJuJz00tysEmwKW/1XCg8agIk= Received: by 10.65.139.9 with SMTP id r9mr3570952qbn; Mon, 31 Jul 2006 05:05:55 -0700 (PDT) Received: from BLRHJEKANAYA1 ( [149.159.1.154]) by mx.gmail.com with ESMTP id 10sm8800252nzo.2006.07.31.05.05.55; Mon, 31 Jul 2006 05:05:55 -0700 (PDT) Message-ID: <001701c6b499$acbd2230$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> Subject: Re: [AXIS2] [Sandesha2] Saving the message context Date: Mon, 31 Jul 2006 08:05:54 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C6B478.254FA690" 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_0014_01C6B478.254FA690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: 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 = > 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=20 > 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" > 07/28/2006 07:23 = AM > Please respond = to > = axis-dev@ws.apache.org > > > > 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 > 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_0014_01C6B478.254FA690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
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 after=20 a crash.
e.g. We don't need transport info = because RM will=20 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 can=20 avoid this heavy serialization.
 
Any thoughts?
 
-Jaliya
----- Original Message -----
From:=20 Chamikara=20 Jayalath
Cc: sandesha-dev@ws.apache.org= ; axis-dev@ws.apache.org =
Sent: Sunday, July 30, 2006 = 10:58=20 PM
Subject: Re: [AXIS2] = [Sandesha2] Saving=20 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,=20 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 not=20 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 on=20 reconstructing the context=20 hierarchy)

Chamikara


On 7/31/06, Jaliya=20 Ekanayake <jnekanayake@gmail.com>=20 wrote:
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 the=20 properties (serializable objects) in the property bag not the=20 entire message context which has = pointers to=20 other contexts.
 
Thanks,
-Jaliya
 
 
-----=20 Original Message -----
From:=20 Chamikara = Jayalath=20 To:=20 nagy@watson.ibm.com=20 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 = approach I=20 followed was only possible due to MessageContext already having made = its=20 useful state public.

I also originally tried to follow = Externalizable=20 approach and introduced externalizable methods to all the contexts = (they hv=20 now been removed due to not having any usages). The main problem I = had in=20 this approach was having to serialize the whole context hierarchy.=20

Every message context has a pointer to the = configurationContext so=20 to be general (not to be specific to our scenario) in the = serialization=20 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=20 is that when adding the externalizable method to the axis2 codebase = we would=20 have to serialize the configContext and other contexts as well = (because some=20 people may actually want to serialize the whole context hierarchy). = But in=20 our case it seemed like this would be a burden. Every deserialized = message=20 context with come up with its own context hierarchy and maching = between two=20 deserialized Message contexts will be extremely difficult.

If = you=20 find a solution to this problem I agree that your and Anns approach = is the=20 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 = contexts=20 using any form of
> serialization. This will not scale at = all in a=20 production environment.

Hi Rajith,

Could you please = explain=20 this last comment?

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

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


>
> I am looking at = clustering=20 certain information within the ctx heirachy
> for high = availability=20 and 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 = required=20 info in a bean like what chamikara does for
> Sandesha and = then=20 reconstructing it.
>

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

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

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

-Bill

> Regards,
>
>=20 Rajith
>
>
> On 7/28/06, Chamikara Jayalath = < = chamikaramj@gmail.com=20 > = wrote:
>         Hi=20 = Ann,
>
>         = Yes.=20 We had introduced Externalizable implementaitons for=20 all
>         of the = Context=20 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
>         = objects=20 available in a running axis2=20 instance.
>         = 1.=20 configuration context=20 object
>         2. = service=20 group context=20 objects
>         3 = service=20 context = objects
>         4.=20 Operation context=20 objects
>         5. = A lot=20 of message context=20 = objects
>
>         = If=20 we try serializing starting from a message context, since=20
>         we have = to=20 serialize every incoming message context all=20 these
>         = objects will=20 be serialized every time (recall that the=20 message
>         = context hs=20 a link to the configuration context which has links=20
>         to all = other=20 context objects). Think how deficult=20 the
>         = reconstruction=20 would be. Every deserialized message=20 context
>         = will come=20 up with its own hierarchy of context objects which=20
>         may not = map with=20 the context objects reconstructed=20 by
>         = deserializing=20 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 = :-)
>
>         You=20 had mentioned about serializing the AxisOperaion=20 object.
>         = All the=20 'Axis*'  objects in Axis2=20 = (AxisConfiguration,
>       &nbs= p;=20 AxisServiceGroupt etc.) contains deployment time information.=20
>         So we can = safely=20 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 >
>
>
>=20 =
>           = ;            =             &= nbsp;           &n= bsp;=20 "Chamikara Jayalath" <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
>
>
>
>= ;            =             &= nbsp;   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_0014_01C6B478.254FA690--