RE: RE: [ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

["Gilbert Pilz" <gpilz@bea.com>]

Comments in line . . .

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, January 18, 2007 12:35 PM
To: Gilbert Pilz
Cc: Stefan Batres; ws-rx@lists.oasis-open.org
Subject: RE: RE: [ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

I think there are several different things your hitting here.
1 - what you're describing is not server-side RMS specific.  Handing a normal client/RMS an EPR with the MCanonURI in it could have the same issues your talking about.
2 - any endpoint that accept an EPR, for any purpose, should examine that EPR to make sure it can actually support it.  For example, while WSA doesn't come right out and say it (but perhaps it should), it seems like good practice to make sure that the wsa:ReplyTo actually has an Address value that it can support before it accepts the request message.  IMO, this same rule would apply to any RM EPR as well. And, it doesn't apply to just the anon URI - if the RM endpoint can't support 'ftp' as a transport then it shouldn't accept any EPR with ftp in the address field. 

 

But what does it mean to "support" an EPR? Support it for what purpose? A WS-RM/WS-Addr implementation may be completely capable of "supporting" wsa:anon in the sense that, if you send a request with an anon ReplyTo it will send the response on the back-channel of that request. But there is no way an RMS is ever going to be able to proactively connect to and re-send a message to the wsa:anon EPR. The very definition of wsa:anon precludes such a possibility. Things like 'ftp' are a different thing entirely.

 
3 - re:the Protocol Invariants - again, this is true for any EPR that it can't support - not just non-addressable clients.  
Overall, I think this is a generic EPR issue and not specific to MC nor RM.  I could perhaps adding some guidance text in the RM, along the lines of what we have now about not using the 'none' URI, but I'd prefer if it were done so in a very generic way to cover any problematic EPRs (not just MC ones, or WSA none) - but ideally, that really belongs in WSA  :-)

thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com

"Gilbert Pilz" <gpilz@bea.com>

01/18/2007 03:07 PM

To	"Stefan Batres" <stefanba@microsoft.com>, Doug Davis/Raleigh/IBM@IBMUS
cc	<ws-rx@lists.oasis-open.org>
Subject	RE: RE: [ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

I agree. The point is, unless we specify some mandatory mechanism for a server-side RMS to effectively re-send unacknowledged messages, we have to account for the possibility that there will be no such mechanism. If the RMS can't re-send unacknowledged messages, it can't fulfill the third item of section 2.3 (Protocol Invariants). Therefore, if a server-side WS-RM implementation has no mechanism for re-sending unacked messages to non-addressable clients, it is erroneous for the RMD to accept an offer with a wsa:anonymous endpoint since doing so effectively creates a contract in which the server-side RMS cannot hold up its end of the bargain.
 
- gp

---

From: Stefan Batres [mailto:stefanba@microsoft.com]
Sent: Thursday, January 18, 2007 11:27 AM
To: Gilbert Pilz; Doug Davis
Cc: ws-rx@lists.oasis-open.org
Subject: RE: RE: [ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

But why does the issue have to be around MC? From RM’s point of view, MC can be viewed as just another transport – one that supports reachable clients. The pivot is reachable vs non-reachable clients, not MC per-se.
 
--Stefan
 
From: Gilbert Pilz [mailto:gpilz@bea.com]
Sent: Thursday, January 18, 2007 10:53 AM
To: Doug Davis
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification
 
Whether or not the problem of re-sending responses to non-addressable clients is solved by other specs is not really the issue here. The issue is "how should a WS-RM implementation behave if an MC implementation isn't available?"
 
- gp
 

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, January 18, 2007 8:26 AM
To: Gilbert Pilz
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

Option #3: Say nothing about transport-level issues and assume it will be solved thru composing with other specs (like MC).

thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com

"Gilbert Pilz" <gpilz@bea.com>

01/18/2007 03:25 AM

To	<ws-rx@lists.oasis-open.org>
cc
Subject	[ws-rx] New Issue: Need to clarify relationship between the WS-RM specification and MakeConnection specification

 

We need to clarify the relationship between the base WS-RM specification and the MakeConnection specification. It seems that there are two options:

Option #1: The base specification could explicitly depend upon the MakeConnection specification. For example, by using phrases such as the current (line 238) "Implementations MAY use the WS-MakeConnection anonymous URI template . . .". The problem with this is that it requires the base specification to normatively reference the MC specification. This causes the schedules of WS-RM and WS-MC to be tied together, which runs counter to one of the reasons for splitting them in the first place.

Option #2: The base specification could refer to optional polling mechanisms "such as" WS-MC. A logical consequence of this is that the base spec needs to clearly spell out how the RMS and RMD should behave in the *absence* of any such polling mechanisms (otherwise they are not really optional). Foremost is the expected behavior of the RMD when the RMS sends a CreateSequence message that contains an Offer in which the Endpoint value is wsa:anonymous. It seems that, absent any polling mechanism, there is no way for a server-side RMS to resend unacknowledged response messages* and therefore the RMD SHOULD NOT respond with a CreateSequenceResponse that contains an Accept element (i.e. the RMD SHOULD NOT accept the offer).

- gp

* You could argue that the client can prompt the server to re-send the response by re-sending the request. Without getting into the specifics of this idea, it would still need to be clearly defined in the specification if we expect people to produce solutions that can interoperate around this feature.

smime.p7s