Return-Path: Delivered-To: apmail-ws-sandesha-dev-archive@www.apache.org Received: (qmail 82450 invoked from network); 6 Jul 2006 23:19:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jul 2006 23:19:59 -0000 Received: (qmail 33793 invoked by uid 500); 6 Jul 2006 23:19:22 -0000 Delivered-To: apmail-ws-sandesha-dev-archive@ws.apache.org Received: (qmail 33636 invoked by uid 500); 6 Jul 2006 23:19:22 -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 33572 invoked by uid 99); 6 Jul 2006 23:19:21 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 16:19: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.162.197 as permitted sender) Received: from [64.233.162.197] (HELO nz-out-0102.google.com) (64.233.162.197) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 16:19:20 -0700 Received: by nz-out-0102.google.com with SMTP id 34so1181761nzf for ; Thu, 06 Jul 2006 16:18:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:reply-to:from:to:references:subject:date:mime-version:content-type:x-priority:x-msmail-priority:x-mailer:x-mimeole; b=tH11fkyUhg0KAzFF9t3wlQb02+KUzI1c9x6z9IYvU99c6yQgU7xyrCnuVGtVAopEo9kICAms9Zyc4JFL3rOYFC0+CGmmfH2Z804u9Bgve8ZmnxHFeW0mD0QRg2dVXLeJRa7AdMMXZfIBLsqTYiPK4mhBvxF9DlvPUy1sy/8uwt8= Received: by 10.36.24.20 with SMTP id 20mr1662496nzx; Thu, 06 Jul 2006 16:18:59 -0700 (PDT) Received: from BLRHJEKANAYA1 ( [149.159.1.154]) by mx.gmail.com with ESMTP id 19sm16688529nzp.2006.07.06.16.18.58; Thu, 06 Jul 2006 16:18:59 -0700 (PDT) Message-ID: <001f01c6a152$8f735b90$9a019f95@ads.iu.edu> Reply-To: "Jaliya Ekanayake" From: "Jaliya Ekanayake" To: "Chamikara Jayalath" , References: <000f01c6a03a$044dc230$e74ae70a@ads.iu.edu> <9d4ec10b0607052225t1dea899aqb798b6b88030a8c2@mail.gmail.com> Subject: Re: RM message processing Date: Thu, 6 Jul 2006 19:18:58 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C6A131.07DE33B0" 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_001C_01C6A131.07DE33B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That is good. +1 for the change. -Jaliya ----- Original Message -----=20 From: Chamikara Jayalath=20 To: sandesha-dev@ws.apache.org=20 Sent: Thursday, July 06, 2006 1:25 AM Subject: Re: RM message processing Hi Jaliya,=20 Currently RMMessageReceiver is only added for clarity. It never get = called. All the control messages get paused at the RM layer and those = are not passed to the phases after that. Matt, Yes, now I see that there is a problem when it comes to MustUnderstand = processing :-) Unfortunately AxisEngine MustUnderstand processing will done only for = non-paused messages so our control messages which get paused in the RM = Phase will not be subjected to this.=20 So we have to pick one of the two models. 1. Pausing the control messages at the RM Phase and sending the = response. MustUnderstand processing would hv to be done by ourself. 2. Letting the control message go to the RM Message Receiver hoping = that the other layers would ignore that and sending the response from = there. MustUnderstand processing will be done by the AxisEngine for us. It seems that the second model as proposed by you is much cleaner. So = please go ahead and do the change. Thanks, Chamikara On 7/5/06, Jaliya Ekanayake wrote: Hi Matt, I agree with you regarding the MustUnderstand processing. We should = do it at the SandeshaGlobalInHandler process the RM headers and if we = understand the headers take the messages inside. However the message receiver that = we use=20 in Sandesha is not the message receiver of the Web Service. It is = the RMMessageReceiver and it is used to handle the RM specific messages = and the order we process them is in consistent with the model explained by=20 Chamikara. So we will not get must understand errors for application messages or any other protocol messages by handling them in RMMessageReceiver. Thanks, -Jaliya ----- Original Message -----=20 From: "Matthew Lovett" To: < sandesha-dev@ws.apache.org> Cc: "Chamikara Jayalath" < chamikaramj@gmail.com> Sent: Wednesday, July 05, 2006 6:58 AM Subject: Re: RM message processing > Hi Chamikra, > > Your explanation makes sense, and I agree that the stack should = provide=20 > the layering that your diagram illustrates, but we still have a = problem > with mustUnderstand processing. The current implementation = achieves the > layering without enough attention to the soap processing model.=20 > > The simple way to code mustUnderstand while still keeping the = current > design would be to call out to a mustUnderstand check from each of = the > msgprocessors that handles the soap body. However, I'm sure we = won't be=20 > the only WS-* spec that needs to do stuff like this, so it would = be nice > to try and come up with a cleaner way of modelling the situation. = Perhaps > it's a design point that has to be resolved in Axis2? At the least = we=20 > should try and be consistent. > > Thoughts? > > Matt > > "Chamikara Jayalath" < chamikaramj@gmail.com> wrote on 05/07/2006 = 04:46:21:=20 > >> Hi Matt, >> >> As I can remember there was some discussion abt this on the = mailing >> list sometime back. >> >> In my mind Axis2 Message Processing is not only about a set of=20 >> handlers that work on a Message Context that is passed through = which >> is more close to the Axis1 model. What I feel is that Axis2 = message >> processing engine consist of a set of layers each doing a well=20 >> defined work on a message context. A layer will be more close to = a >> Phase and each layer can consist of a multiple set of handlers. >> >> For example there can be a security layer which does some = security=20 >> specific functions on the message, a RM layer that does some RM >> specific work on the message and Transaction layer which would do >> some Transactional work on the message. Application message = exchange=20 >> would be done end to end (i.e. between a ServiceClient and a >> MessageReceiver). But there can be control message exchanges = between >> two layers and those messages do not have to go through layers = after=20 >> that and go to the ends (for e.g. to the MessageReceiver). >> >> For example think of what would happen if SecureConversation = think >> of sending some of its control messages to the RM layer. RM may=20 >> consider these as application messages and would try to add them = to >> a sequence which should not be the correct behaviour. Because of >> this problem as I can remember the RM layer in Axis1 (Sandesha1) = had=20 >> to skip other control messages by pre-knowing their actions which >> does not seem to be the correct model. >> >> I guess this diagram will further clarify my point. >> = http://people.apache.org/~chamikara/images/axis2_layered_model.png >> >> >> Chamikara >> >> > >> On 7/4/06, Matthew Lovett < MLOVETT@uk.ibm.com> wrote: >> Hi all, >> >> I've been taking a look at the way that (java) sandesha2 = processes the > RM >> protocol messages. Essentially, all the processing is done by the = > handlers >> (indirectly, via the msgprocessor classes). That wasn't quite how = I >> expected it to be: in an ideal world I'd expect the handlers to = process >> header elements (Sequence, Ack, and AckRequest) and a = MessageReceiver=20 >> should be dealing with the RM bodies (CreateSequence & response, >> CloseSequence & response, TerminateSequence & response). >> >> The reasons why I'd expect that are twofold:=20 >> - it ensures that soap:mustUnderstand processing can be done on = the >> headers before we process the bodies >> - it just seems cleaner >> >> I also think that this reorganisation could clean up the codepath = in the=20 >> current handlers, and would probably simplify the code. I'm happy = to > start >> working on the restructure, if people feel that this is the right = way to > >> go. >> >> Comments? Is this an approach that has been tried before?=20 >> >> Matt >> >> >> = --------------------------------------------------------------------- >> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org >> For additional commands, e-mail: sandesha-dev-help@ws.apache.org=20 > > > = ---------------------------------------------------------------------=20 > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org > For additional commands, e-mail: sandesha-dev-help@ws.apache.org > ------=_NextPart_000_001C_01C6A131.07DE33B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That is good. +1 for the = change.
 
-Jaliya
----- Original Message -----
From:=20 Chamikara=20 Jayalath
Sent: Thursday, July 06, 2006 = 1:25=20 AM
Subject: Re: RM message = processing

Hi Jaliya,

Currently RMMessageReceiver is only = added=20 for clarity. It never get called. All the control messages get paused = at the=20 RM layer and those are not passed to the phases after=20 that.

Matt,
Yes, now I see that there is a problem when it = comes to=20 MustUnderstand processing :-)

Unfortunately AxisEngine = MustUnderstand=20 processing will done only for non-paused messages so our control = messages=20 which get paused in the RM Phase will not be subjected to this. =

So we=20 have to pick one of the two models.

1. Pausing the control=20 messages  at the RM Phase and sending the response. = MustUnderstand=20 processing would hv to be done by ourself.

2. Letting the = control=20 message go to the RM Message Receiver hoping that the other layers = would=20 ignore that and sending the response from there. MustUnderstand = processing=20 will be done by the AxisEngine for us.

It seems that the second = model=20 as proposed by you is much cleaner. So please go ahead and do the=20 change.


Thanks,
Chamikara


On 7/5/06, Jaliya=20 Ekanayake <jnekanayake@gmail.com=20 > wrote:
Hi=20 Matt,

I agree with you regarding the MustUnderstand = processing. We=20 should do it at
the SandeshaGlobalInHandler process the RM = headers and if=20 we understand the
headers take the messages inside. However the = message=20 receiver that we use
in Sandesha is not the message receiver of = the Web=20 Service. It is the
RMMessageReceiver and it is used to handle the = RM=20 specific messages and the
order we process them is in consistent = with the=20 model explained by
Chamikara. So we will not get must understand = errors=20 for application
messages or any other protocol messages by = handling them=20 = in
RMMessageReceiver.

Thanks,
-Jaliya



-----=20 Original Message -----
From: "Matthew Lovett" <MLOVETT@uk.ibm.com>
To: <=20 sandesha-dev@ws.apache.org>
Cc: "Chamikara Jayalath" < = chamikaramj@gmail.com>
Sent: Wednesday, = July 05,=20 2006 6:58 AM
Subject: Re: RM message processing


> = Hi=20 Chamikra,
>
> Your explanation makes sense, and I agree = that the=20 stack should provide
> the layering that your diagram = illustrates,=20 but we still have a problem
> with mustUnderstand processing. = The=20 current implementation achieves the
> layering without enough=20 attention to the soap processing model.
>
> The simple = way to=20 code mustUnderstand while still keeping the current
> design = would be=20 to call out to a mustUnderstand check from each of the
> = msgprocessors=20 that handles the soap body. However, I'm sure we won't be
> = the only=20 WS-* spec that needs to do stuff like this, so it would be = nice
> to=20 try and come up with a cleaner way of modelling the situation.=20 Perhaps
> it's a design point that has to be resolved in = Axis2? At the=20 least we
> should try and be consistent.
>
>=20 Thoughts?
>
> Matt
>
> "Chamikara Jayalath" = <=20 chamikaramj@gmail.com> wrote on 05/07/2006 04:46:21:=20
>
>> Hi Matt,
>>
>> As I can = remember=20 there was some discussion abt this on the mailing
>> list = sometime=20 back.
>>
>> In my mind Axis2 Message Processing is = not=20 only about a set of
>> handlers that work on a Message = Context=20 that is passed through which
>> is more close to the Axis1 = model.=20 What I feel is that Axis2 message
>> processing engine = consist of a=20 set of layers each doing a well
>> defined work on a = message=20 context. A layer will be more close to a
>> Phase and each = layer=20 can consist of a multiple set of handlers.
>>
>> = For=20 example there can be a security layer which does some security =
>>=20 specific functions on the message, a RM layer that does some = RM
>>=20 specific work on the message and Transaction layer which would=20 do
>> some Transactional work on the message. Application = message=20 exchange
>> would be done end to end (i.e. between a = ServiceClient=20 and a
>> MessageReceiver). But there can be control message = exchanges between
>> two layers and those messages do not = have to=20 go through layers after
>> that and go to the ends (for = e.g. to=20 the MessageReceiver).
>>
>> For example think of = what=20 would happen if SecureConversation think
>> of sending some = of its=20 control messages to the RM layer. RM may
>> consider these = as=20 application messages and would try to add them to
>> a = sequence=20 which should not be the correct behaviour. Because of
>> = this=20 problem as I can remember the RM layer in Axis1 (Sandesha1) had =
>>=20 to skip other control messages by pre-knowing their actions=20 which
>> does not seem to be the correct=20 model.
>>
>> I guess this diagram will further = clarify my=20 point.
>> http://people.apache.org/~chamikara/images/axis2_layered_= model.png
>>
>>
>>=20 Chamikara
>>
>>
>
>> On 7/4/06, = Matthew=20 Lovett < = MLOVETT@uk.ibm.com>=20 wrote:
>> Hi all,
>>
>> I've been taking = a look=20 at the way that (java) sandesha2 processes the
> = RM
>>=20 protocol messages. Essentially, all the processing is done by the =
>=20 handlers
>> (indirectly, via the msgprocessor classes). = That wasn't=20 quite how I
>> expected it to be: in an ideal world I'd = expect the=20 handlers to process
>> header elements (Sequence, Ack, and=20 AckRequest) and a MessageReceiver
>> should be dealing = with the RM=20 bodies (CreateSequence & response,
>> CloseSequence = &=20 response, TerminateSequence & response).
>>
>> = The=20 reasons why I'd expect that are twofold:
>> - it ensures = that=20 soap:mustUnderstand processing can be done on the
>> = headers before=20 we process the bodies
>> - it just seems=20 cleaner
>>
>> I also think that this = reorganisation could=20 clean up the codepath in the
>> current handlers, and = would=20 probably simplify the code. I'm happy to
> start
>> = working=20 on the restructure, if people feel that this is the right way=20 to
>
>> go.
>>
>> Comments? Is this = an=20 approach that has been tried before?
>>
>>=20 Matt
>>
>>
>>=20 = ---------------------------------------------------------------------
= >>=20 To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> = For=20 additional commands, e-mail: sandesha-dev-help@ws.apache.org =
>
>
>=20 = ---------------------------------------------------------------------=20
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> = For=20 additional commands, e-mail: sandesha-dev-help@ws.apache.org
>


------=_NextPart_000_001C_01C6A131.07DE33B0--