Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 12100 invoked from network); 27 Sep 2006 16:02:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 27 Sep 2006 16:02:16 -0000 Received: (qmail 24131 invoked by uid 500); 27 Sep 2006 16:02:11 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 24083 invoked by uid 500); 27 Sep 2006 16:02:11 -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 24072 invoked by uid 99); 27 Sep 2006 16:02:11 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 27 Sep 2006 09:02:11 -0700 Authentication-Results: idunn.apache.osuosl.org smtp.mail=chamikaramj@gmail.com; spf=pass Authentication-Results: idunn.apache.osuosl.org header.from=chamikaramj@gmail.com; domainkeys=good X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates 72.14.214.236 as permitted sender) DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from [72.14.214.236] ([72.14.214.236:26245] helo=hu-out-0506.google.com) by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP id 93/00-29243-F70AA154 for ; Wed, 27 Sep 2006 09:02:09 -0700 Received: by hu-out-0506.google.com with SMTP id 34so2191hud for ; Wed, 27 Sep 2006 09:02:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=Ja83vwgOp4x5ov9U8+hBETStr5daqIflCsXsTeJtLGM5bGmIqk8ihTRAqAwxkivNzH/qr2lV9YuDDzliqQHjLTCsvoUR2W4+mcZyyQC4meu9RLEEjwgi5L75kK/wNeTkhh05QmeMZRnUqY2L668L751NEalzYdbJsFkVpiMqeF0= Received: by 10.82.190.2 with SMTP id n2mr14832buf; Wed, 27 Sep 2006 09:02:04 -0700 (PDT) Received: by 10.82.114.13 with HTTP; Wed, 27 Sep 2006 09:02:04 -0700 (PDT) Message-ID: <9d4ec10b0609270902n6a9ead58t1199d59a8ced8f52@mail.gmail.com> Date: Wed, 27 Sep 2006 21:32:04 +0530 From: "Chamikara Jayalath" To: axis-dev@ws.apache.org Subject: Re: [Axis2] Allowing users to set their own replyTo value In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2083_5234199.1159372924407" References: <9d4ec10b0609270721g74e7af64v8bd04124322782b4@mail.gmail.com> X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_2083_5234199.1159372924407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Matt, We will not be asking the user to know anything about polling. They will simply tell Axis2 not to use its internal listner ( may be the environment does not support a listner) and let the message go with what ever the replyTo value user set. In the polling scenario this will be the anonymous address. Sandesha2 will jump in the middle and use polling to get the reply message. But doing it the way u segest is also possible, but this will break the current symantics of useSeperateListner being false. Which is that the reply message will come in the back channel. Chamikara On 9/27/06, Matthew Lovett wrote: > > Hi all, > > Sorry, but I'm coming into this one a bit late... must read the list more > regularly :) > > For the case of WS-RM and polling, I don't think that the user should need > to know about it. I'd assume that the sandesha polling code can jump into > action any time that the user is trying to send a message that has an > anonymous reply to. Here's an attempt to explain further: > > isUseSeperateListner=true: RM need not worry about polling, there is a > real replyTo anyway. > > isUseSeperateListner=false: The user just wants their reply message, and > they don't want to (or cannot) open up a listener. The RM layer can jump > in here and replace the WS-A anon ReplyTo with the RM polling mechanism, > and so long as the user's message gets pumped back through we should be > ok. I'd hope we can contain that in the RM impl, though I guess it might > need some Axis2 changes to avoid the problem that Chamikara ran into as > well. > > I'd hope that the above is the most usable way to do this stuff. I think > this is what David was hinting at earlier - the fact that RM is capable of > polling is really implementation detail. The user just wants to make their > call and get the message back. > > Comments? > > Matt > > > "Chamikara Jayalath" wrote on 27/09/2006 15:21:22: > > > Hi Chinthaka, > > > > Please see below. > > > On 9/27/06, Eran Chinthaka wrote: > > Hang on a bit. > > > > Ok, I agree to include this property. But we need to do following while > > implementing it. > > > > 1. Once this property is set, user _MUST_ set a replyTo EPR > > > > > > Ok. > > > > 2. When this property is set and when user sets a replyTo epr, what if > > the reply never comes back to the same Callback? Then we need to handle > > this properly. > > > > When user set this property he explicitly knows that somebody else > > will be managing the delivering of the message to the callback. If > > that mechanism fails it has no difference from a failure of the > > current 'Axis2 Listner' scenario. I.e. the callback will never be > called. > > > > 3. How will RM or anyone who sets the replyTo epr hand over the response > > message to the Callback object? > > > > > > In the polling case, Sandesha2 implementation will be doing an > > axisEngine.reveive () call for the reply message obtained through > > polling, allowing it to be delivered to the users callback. > > > > Chamikara > > > > > Thanks, > > Chinthaka > > > > Chamikara Jayalath wrote: > > > Hi Chinthaka, > > > > > > OK. > > > > > > As u mentioned in ur previous mail currently the semantics of > > > isUseSeperateListner=true has two things. > > > > > > 1. Don't use the back channel of the request message to build the > response. > > > 2. Mr. Axis2, please manage the second channel for me. > > > > > > Now what I want it someway to only give the first semantic. I.e. the > > > second channel will be managed by my own manner (for e.g. RM polling). > > > > > > > I believe this is a general requirement. > > > > > > My sugestion is to introduce a new property to the options object > named > > > DONT_USE_AXIS2_LISTNER (please suggest a different name if this > > sounds bad). > > > > > > If this property is not set execution will be done as it is currently > > > implemented. But if it is set to 'true' Axis2 will not start its > listner > > > and will allow user to set what ever the replyTo value he wants. > > > > > > Hope this clarifies. > > > > > > Chamikara > > > > > > > > > On 9/27/06, *Eran Chinthaka* > > > wrote: > > > > > > Hi Chamikara, > > > > > > Before you do the change, can you please be kind enough to > summarize > > > the > > > change you gonna do? > > > > > > Thanks, > > > Chinthaka > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > > > > > > For additional commands, e-mail: axis-dev-help@ws.apache.org > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > > For additional commands, e-mail: axis-dev-help@ws.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org > For additional commands, e-mail: axis-dev-help@ws.apache.org > > ------=_Part_2083_5234199.1159372924407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Matt,

We will not be asking the user to know anything about polling. They will simply tell Axis2 not to use its internal listner ( may be the environment does not support a listner) and let the message go with what ever the replyTo value user set.

In the polling scenario this will be the anonymous address. Sandesha2 will jump in the middle and use polling to get the reply message.

But doing it the way u segest is also possible, but this will break the current symantics of useSeperateListner being false. Which is that the reply message will come in the back channel.

Chamikara


On 9/27/06, Matthew Lovett <MLOVETT@uk.ibm.com> wrote:
Hi all,

Sorry, but I'm coming into this one a bit late... must read the list more
regularly :)

For the case of WS-RM and polling, I don't think that the user should need
to know about it. I'd assume that the sandesha polling code can jump into
action any time that the user is trying to send a message that has an
anonymous reply to. Here's an attempt to explain further:

isUseSeperateListner=true: RM need not worry about polling, there is a
real replyTo anyway.

isUseSeperateListner=false: The user just wants their reply message, and
they don't want to (or cannot) open up a listener. The RM layer can jump
in here and replace the WS-A anon ReplyTo with the RM polling mechanism,
and so long as the user's message gets pumped back through we should be
ok. I'd hope we can contain that in the RM impl, though I guess it might
need some Axis2 changes to avoid the problem that Chamikara ran into as
well.

I'd hope that the above is the most usable way to do this stuff. I think
this is what David was hinting at earlier - the fact that RM is capable of
polling is really implementation detail. The user just wants to make their
call and get the message back.

Comments?

Matt


"Chamikara Jayalath" <chamikaramj@gmail.com> wrote on 27/09/2006 15:21:22:

> Hi Chinthaka,
>
> Please see below.

> On 9/27/06, Eran Chinthaka <chinthaka@opensource.lk> wrote:
> Hang on a bit.
>
> Ok, I agree to include this property. But we need to do following while
> implementing it.
>
> 1. Once this property is set, user _MUST_ set a replyTo EPR
>
>
> Ok.
>
> 2. When this property is set and when user sets a replyTo epr, what if
> the reply never comes back to the same Callback? Then we need to handle
> this properly.
>
> When user set this property  he  explicitly knows that somebody else
> will be managing the delivering of the message to the callback. If
> that mechanism fails it has no difference from a failure of the
> current 'Axis2 Listner' scenario. I.e. the callback will never be
called.
>
> 3. How will RM or anyone who sets the replyTo epr hand over the response
> message to the Callback object?
>
>
> In the polling case, Sandesha2 implementation will be doing an
> axisEngine.reveive () call for the reply message obtained through
> polling, allowing it to be delivered to the users callback.
>
> Chamikara

>
> Thanks,
> Chinthaka
>
> Chamikara Jayalath wrote:
> > Hi Chinthaka,
> >
> > OK.
> >
> > As u mentioned in ur previous mail currently the semantics of
> > isUseSeperateListner=true has two things.
> >
> > 1. Don't use the back channel of the request message to build the
response.
> > 2. Mr. Axis2,  please manage the second channel for me.
> >
> > Now what I want it someway to only give the first semantic. I.e. the
> > second channel will be managed by my own manner (for e.g. RM polling).

> >
> > I believe this is a general requirement.
> >
> > My sugestion is to introduce a new property to the options object
named
> > DONT_USE_AXIS2_LISTNER (please suggest a different name if this
> sounds bad).
> >
> > If this property is not set execution will be done as it is currently
> > implemented. But if it is set to 'true' Axis2 will not start its
listner
> > and will allow user to set what ever the replyTo value he wants.
> >
> > Hope this clarifies.
> >
> > Chamikara
> >
> >
> > On 9/27/06, *Eran Chinthaka* <chinthaka@opensource.lk
> > <mailto: chinthaka@opensource.lk>> wrote:
> >
> >     Hi Chamikara,
> >
> >     Before you do the change, can you please be kind enough to
summarize
> >     the
> >     change you gonna do?
> >
> >     Thanks,
> >     Chinthaka
> >
> > ---------------------------------------------------------------------
> >     To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> >     <mailto:axis-dev-unsubscribe@ws.apache.org>
> >     For additional commands, e-mail: axis-dev-help@ws.apache.org
> >     <mailto:axis-dev-help@ws.apache.org>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org


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


------=_Part_2083_5234199.1159372924407--