ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: RE: [ws-rx] New Issue: Need to clarify relationship between the WS-RMspecification and MakeConnection specification
- From: Doug Davis <dug@us.ibm.com>
- To: "Gilbert Pilz" <gpilz@bea.com>
- Date: Thu, 18 Jan 2007 15:35:18 -0500
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.
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]