|
Cool, +1 from me.
-Jaliya
----- Original Message -----
Sent: Tuesday, September 26, 2006 7:53
PM
Subject: Re: [Axis2] Allowing users to
set their own replyTo value
Hi David, Jaliya,
This change will not add anything
specific to RM to the Axis2 engine. Its just a general requirement.
For
the symantics of isUseSeperateListner what was given by David ('dont use the
back channel for the response') applies nicely. Because in the polling
scenario the response really does not come in the back channel of the request
message. (I just tried to mention it in a transport indipendent manner :D
).
Implementing this is not a problem. If everybody agrees I can do
that.
Chamikara
On 9/27/06, Jaliya
Ekanayake <[EMAIL PROTECTED]>
wrote:
Hi
David,
I agree with you that QoSs should be able to handle their task
without intervening with the application. At the same time there is
another requirement that the web service engine should be kept clean from
the specific QoS implementation details.
People express their ideas
infavor of both of these concepts and IMHO there are some QoSs that
require breaking of one of the above "nice" features. The polling
requirement or RM is something like that.
Thanks, -Jaliya
----- Original Message ----- From:
"David Illsley" <[EMAIL PROTECTED]> To:
< [email protected]>;
"Jaliya Ekanayake" <[EMAIL PROTECTED]> Sent: Tuesday,
September 26, 2006 11:52 AM Subject: Re: [Axis2] Allowing users to set
their own replyTo value
> In general I consider RM to be a
QOS and as such should be able to be > applied without modifying the
application. > > I also don't think that the generally
understood semantic for > isUseSeperateListner is what you described.
I'd be really surprised if > any sizeable portion of users thought it
means anything outer than use > a separate connection for the response
(don't use the back channel) as > that's the only way I've seen it
documented. > > My reading of this thread is that
Service/OperationClient isn't > currently implemented in a way that
lets RM be dropped in cleanly. I'd > like to see this resolved in a
clean way which insulates applications > from RM specific info (like
to do polling you need a separate listener > - this really is an
implementation detail) however I don't have the > time to volunteer to
work on this at the moment. > > David > > On
26/09/06, Jaliya Ekanayake <[EMAIL PROTECTED]>
wrote: >> >> >> Hi Chamikara and
All, >> >> I think although the polling comes as a part of
RM it is a general >> scenario >> applied to
request/response messaging. So I also agree that user informs >>
what is happening by setting some option (say POLLING_ENABLED=true)
to >> the >> system so that everybody is clear about the
message exchange. >> >> Thanks, >>
-Jaliya >> >> ----- Original Message ----- >>
From: Chamikara Jayalath >> To: [email protected]
>> >> Sent: Tuesday, September 26, 2006 4:24
AM >> Subject: Re: [Axis2] Allowing users to set their own replyTo
value >> >> Hi David, >> >> Well,
according to the way Axis2 has being implemented I belive >>
isUseSeperateListner has following symantics. >> >> 'The
response will come in some mechanism. Dont look for it in the >>
TransportIn stream just after sending the request out'. >> I
believed this mechanism can be either the listner given by Axis2
or >> some >> other mechanism like WSRM
polling. >> >> Accoding to the way execute method of the
OutInAxisOperation hs being >> implemented. If
useSeperateListner=false it immediately tries to build a >>
response SOAP envelope from the input stream, causing it to fail in
the >> scenario I gave. >> >> Hope this
clarifies. >> >>
Chamikara >> >> >> >> On 9/26/06, David
Illsley <[EMAIL PROTECTED]>
wrote: >> > Hi Chamikara, thanks for the clarification.
>> > >> > I am however, a little
confused... >> > >> > I've always associated the RM
polling with use of the HTTP back >> > channel and yet you're
trying to support RM polling when the user has >> > explicitly
decided to use separate connections: when >> >
options.isUseSeparateListener () returns true. >> > >>
> If RM polling works when this property is not set then it seems pretty
>> > reasonable to me to say that "RM polling only works when
you've >> > configured your ServiceClient to not use separate
connections" >> > >> > How does that sound? Am I
missing something? >> > David >> > >> >
On 26/09/06, Chamikara Jayalath <[EMAIL PROTECTED]>
wrote: >> > > Hi David, All, >> > >
>> > > Thanks for ur points. >> >
> >> > > Let me come to my real requirement. I'm trying to
integrate WSRM >> > > polling >> > >
capabilities into Sandesha2. With polling users get the ability to do
>> > > reliable In-Out invocations without an endpoint at
the client side. >> > > Here >> > > users will
be sending application messages (say 'Echo Messages') with >> >
> replyTo value set to Anonymous. But the HTTP response of that message
>> will >> > > not have the EchoResponse message
(lets stick to the HTTP scenario >> > > for >>
now). >> > > But Sandesha2 underneath will get the response
message by sending a >> > > different message called
MakeConnection which will get the >> > >
'EchoResponse >> > > message' in its HTTP back
channel. >> > > >> > > I asume that for the
client this is still an In-Out invocation so he >>
should >> > > be able to do it with the existing
ServiceClient/OperationClient API. >> > > >> >
> Now what I need from Axis2 is a mechanism to do this in a
manner >> transparent >> > > to the user. But doing
a fireAndForget invocation does not help me. >> Since >>
> > there is no way to give the reply back to the user
transparently.So >> > > if >> > > basically
users can do In-Out callback based invocations with replyTo >>
value >> > > set as Anonymous, Sandesha2 module underneath
can identify this as >> > > the >> > > polling
scenario and do the previously mentioned polling message >>
exchange. >> > > >> > > So I'd like to propose
another aproach. Users can set a special >> > >
property >> in >> > > the options object (say
DONT_USE_AXIS2_LISTNER). So if they hvnt set >> this >>
> > everything will go as current scenario. But if they have Axis2
will >> > > not >> > > start its listners and
will simply let the message go with the >> > >
replyTo >> value >> > > set by the
client. >> > > >> > > How abt that. Or is
there a better approach to do this ? >> > > >> >
> Chamikara >> > > >> > > >> >
> >> > > On 9/25/06, Jaliya Ekanayake < [EMAIL PROTECTED]>
wrote: >> > > > Cool. Thanks for the info. >>
> > > -Jaliya >> > > > ----- Original Message
----- >> > > > From: "Eran Chinthaka" <[EMAIL PROTECTED]> >>
> > > To: < [email protected]
> >> > > > Sent: Monday, September 25, 2006 2:15
PM >> > > > Subject: Re: [Axis2] Allowing users to set
their own replyTo value >> > > > >> > >
> >> > > > > Jaliya Ekanayake wrote: >>
> > > >> Yes, we can do this using one-way
messages. >> > > > >> However, when we use axis2
client inside a container we don't >> > > > >>
need >> to >> > > > >> use the replyTo
generated by axis2, rather we can use the >> > > >
>> endpoint >> that >> > > > >> is
already there. >> > > > >> How can we do
this? >> > > > > >> > > > > You
need to register a new TransportListener from whatever the >>
container >> > > > > you are in. For example, if you
are running Axis2 inside jetty, >> > > > >
then >> you >> > > > > need to register jetty
listener as your http transport listener >> > > > >
(you >> > > > > will have to implement the
TransportListener on that). Axis2 will >> ask >> >
> > > from the transport listener for an EPR, given a service
name. >> > > > > >> > > > > --
Chinthaka >> > > > > >> > > >
> >> > > >>
--------------------------------------------------------------------- >>
> > > > To unsubscribe, e-mail: >> > > [EMAIL PROTECTED] >>
> > > > For additional commands, e-mail: [EMAIL PROTECTED] >>
> > > > >> > > > >> > >
> >> > > >>
--------------------------------------------------------------------- >>
> > > To unsubscribe, e-mail: >> > > [EMAIL PROTECTED] >>
> > > For additional commands, e-mail: [EMAIL PROTECTED] >>
> > > >> > > > >> > > >>
> > >> > >> > >> > -- >>
> David Illsley - IBM Web Services Development >>
> >> > >>
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: >> [EMAIL PROTECTED] >>
> For additional commands, e-mail: [EMAIL PROTECTED] >>
> >> > >> >> > > >
-- > David Illsley - IBM Web Services Development > >
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] >
For additional commands, e-mail: [EMAIL PROTECTED]
>
--------------------------------------------------------------------- To
unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
|