axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <jnekanay...@gmail.com>
Subject Re: [Axis2] Allowing users to set their own replyTo value
Date Wed, 27 Sep 2006 03:04:59 GMT
Cool, +1 from me.
-Jaliya
  ----- Original Message ----- 
  From: Chamikara Jayalath 
  To: axis-dev@ws.apache.org 
  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 <jnekanayake@gmail.com> 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" <davidillsley@gmail.com>
    To: < axis-dev@ws.apache.org>; "Jaliya Ekanayake" <jaliya@apache.org>
    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 <jnekanayake@gmail.com> 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: axis-dev@ws.apache.org 
    >>
    >> 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 <davidillsley@gmail.com> 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 <chamikaramj@gmail.com> 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 < jnekanayake@gmail.com> wrote:
    >> > > > Cool. Thanks for the info.
    >> > > > -Jaliya
    >> > > > ----- Original Message -----
    >> > > > From: "Eran Chinthaka" <chinthaka@opensource.lk>
    >> > > > To: < axis-dev@ws.apache.org >
    >> > > > 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:
    >> > > 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
    >> > > >
    >> > > > 
    >> > >
    >> > >
    >> >
    >> >
    >> > --
    >> > David Illsley - IBM Web Services Development
    >> >
    >> >
    >> --------------------------------------------------------------------- 
    >> > To unsubscribe, e-mail:
    >> axis-dev-unsubscribe@ws.apache.org
    >> > For additional commands, e-mail: axis-dev-help@ws.apache.org
    >> >
    >> >
    >>
    >>
    >
    >
    > --
    > David Illsley - IBM Web Services Development
    >
    > --------------------------------------------------------------------- 
    > 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




Mime
View raw message