RE: [ws-rx] Proposal for i012

[Christopher B Ferris <chrisfer@us.ibm.com>]

Lei,

AckRequested is not request/response. I don't see how this helps at all. 

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Lei Jin" <ljin@bea.com> wrote on 08/25/2005 03:12:13 PM:

> A request-response MEP used reliably is asynchronous and is basically
> composed of two separate one-way MEPs.  Thus, there are really no
> differences to the oneway case. (there is nothing normally flowing back
> on the http response) 
> 
> If there is an AcksTo address on the source side that is reachable from
> the destination, then use that address.   Otherwise, use the not-allowed
> EPR for AcksTo which means you can retrieve the Acks through AcksRequest
> messages.
> 
> Lei
> 
> > -----Original Message-----
> > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> > Sent: Thursday, August 25, 2005 10:24 AM
> > To: Lei Jin
> > Cc: Marc Goodner; ws-rx@lists.oasis-open.org; Christopher B Ferris
> > Subject: Re: [ws-rx] Proposal for i012
> > 
> > 
> > Hi Lei,
> > 
> > How does your proposal address the scenario where:
> > HTTP is being used, there aren't any intermediaries, it is a 
> > request-response WSDL MEP, and the acks are to be sent using the HTTP 
> > response (backchannel).
> > 
> > In such a case, what should the value of the [address] property of 
> > AcksTo EPR be?
> > 
> > -Anish
> > --
> > 
> > Lei Jin wrote:
> > > I disagree.  Here is a use case that shows a problem with 
> > an anonymous
> > > AcksTo.
> > > 
> > > Node A  --->  Intermediary ---> Node B
> > > 
> > > Node A tries to send messages reliably to Node B.  For simplicity, 
> > > let's
> > > assume these are all oneway messages.  Node A establishes a 
> > reliable 
> > > sequence with an anonymous AcksTo and starts to send messages.  The 
> > > messages first go through the Intermediary which has B's WSDL and 
> > > figures out these are oneway messages.  So it decides to 
> > send back a 
> > > http 202 to A and close the connection before forwarding 
> > the message on 
> > > to Node B.  Now Node B gets the message and wants to send 
> > back an Ack 
> > > synchronously (due to the anonymous Ack).  But it can't 
> > send the Ack 
> > > since the connection between Node A and the Intermediary is 
> > already closed.
> > > 
> > > Basically the problem is that the introduction of anonymous AcksTo
> > > converts a oneway MEP into a two-way MEP.  In order for it 
> > to work, all 
> > > intermediaries will need to be WSRM aware and keep 
> > connections open in 
> > > case synchronous acks need to be sent back.
> > > 
> > > Proposal:
> > > 
> > > * Specifically call out that the anonymous IRI is not to be used in 
> > > AcksTo.
> > > * AcksTo may take on the value of the "not allowed" IRI, 
> > >  "_http://www.w3.org/@@@@/@@/addressing/none_";.  When 
> > AcksTo takes on 
> > > this value, acknowledgement will only be sent back in response to 
> > > AckRequest messages.
> > > 
> > > Lei
> > > 
> > > 
> > >     -----Original Message-----
> > >     *From:* Marc Goodner [mailto:mgoodner@microsoft.com]
> > >     *Sent:* Tuesday, August 23, 2005 3:16 PM
> > >     *To:* ws-rx@lists.oasis-open.org; Lei Jin; Christopher B Ferris
> > >     *Subject:* [ws-rx] Proposal for i012
> > > 
> > >     I believe Chris Ferris had made a similar proposal 
> > earlier but in
> > >     the interest of a +1 and trying to move this along I'll 
> > make a more
> > >     formal proposal.
> > > 
> > > 
> > > 
> > >     Proposal:
> > > 
> > >     WS-RM was designed to be used with WS-Addressing in which the
> > >     behavior of the anonymous URI is defined as an address 
> > in an EPR.
> > >     There is no requirement that the anonymous URI must be used and
> > >     there are valid applications of it, therefore this 
> > issue should be
> > >     closed with no action
> > > 
> >