OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] Proposal for i012


Is there any disagreement that there are uses for the anonymous uri in
the acksTo EPR?

Lei, it sounds like you may have identified a scenario where using the
anonymous uri does not work. Don't use it for that scenario. I also do
not think your proposal below actually addresses i012 as described.

I stick to my original proposal. There is no reason to restrict the use
of the anonymous uri. We don't need to do anything here. I'm copying the
text of my proposal here again.

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.

-----Original Message-----
From: Lei Jin [mailto:ljin@bea.com] 
Sent: Wednesday, August 31, 2005 3:51 PM
To: Christopher B Ferris
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Proposal for i012

I probably should explain this better.  I am proposing that an
AckRequested block can be sent standalone in the message body.  In this
case, it is a request/response message.  And a SequenceAcknowledgement
is sent in response to this message.  If you specify an anonymous URI
for the ReplyTo of the AckRequested message, then the
SequenceAcknowledgement can be sent back on the http response channel.

I guess we could use a different message element than AckRequested, but
I was just trying to reuse an existing construct.

Lei

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Thursday, August 25, 2005 1:59 PM
> To: Lei Jin
> Cc: Anish Karmarkar; Marc Goodner; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] Proposal for i012
> 
> 
> 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
> > > > 
> > > 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]