Doug:
My 2 cents on your challenges to MSFT
proposal below – which are by the way valid questions, for which I tried
to see how the proposal would work.
Again I think MSFT proposal needs some
tightening - but I believe the out-of-bound communication/configuration needs
you assume, either are not specific to this proposal, or are reasonable (e.g. knowledge
of policy).
-Jacques
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, November 27, 2006
5:17 AM
To: Jonathan Marsh
Cc: 'Gilbert Pilz'; 'Marc
Goodner'; 'Paul Fremantle'; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue 28:
MakeConnection preconditions are unclear
Jonathan,
your observations, in general, sound nice but I think you're a bit mixed up. None
of those claims apply to what's in the spec (at least not to the RManonURI
variant of MC) which is why they're not mentioned in the spec. None of
those server-side preconditions are needed beyond how EPRs are shared today no
matter what the value of the wsa:Address element. I think you're not
understanding how MC is used because passing around an EPR with the RManonURI
in it is no different than passing around an EPR with wsa:Anon in it - and
these claims your making about preconditions don't seem to plague the
WS-Addressing spec. However, your observation about how the MSFT proposal
doesn't have preconditions is quite interesting. Extracting some text
from the latest version (my comments in parens):
The RM Source SHOULD include this element in any
CreateSequence message it sends when it anticipates
MakeConnection will be used to retrieve Sequence Traffic
and Sequence Lifecycle Messages
(this appears twice)
(How does this 'anticipation'
logic work? It sounds to me like it MUST always be sent w/o some out-of-band
talking)
<JD> I guess the wording makes it appear more
complicated than it really is: reception by RMS of an MC unrelated to any
sequence, is the sign that a CS is expected as response, and that future traffic
messages for this sequence will need be pulled, possibly using MC (so inclusion
of MakeConTo should be done in such CS, unless RMS has good reasons to not
initiate a sequence). In case the sequence is offered, inclusion of MakeConTo in
CSR is decided when the RMS on RM server side, knows it will not / wants not /
cannot take initiative to send requests to the offering endpoint – and it
already knows how to deal with this endpoint, as it receives another
sequence from it.
When an unreachable client
requires a new inbound sequence it MAY send the MakeConnection
header independently to RM service endpoint
(How does the client know when a
new sequence is needed by the RMS w/o some out-of-band talking?)
<JD>
that question is valid for the other proposals as well. More generally, 2
cases:
(a) unreachable client is a WS client. In that case it has knowledge of
the policy (e.g. WSDL or other) that tells the response messages must be sent
reliably (also works for out-only ops).
(b) unreachable client is a case of WS service that needs to fetch
its inputs. Then the associated RMD also knows from the policy associated with its
WS endpoint.
Upon receipt of a MakeConnection header block that the RM
Source cannot relate to an existing
sequence it MUST respond with either a CreateSequence
message on the protocol specific back
channel of the request, or with a MakeConnectionRefused
fault
(How does the RMS know when to
fault or create an unneeded Sequence when a late arriving MC arrives?)
<JD> looking at this differently: with
current spec wd-16 or with other proposal, the RMS will anyway have to decide
whether or not to send back a CS, when receiving an MC. In the case of MSFT
proposal, it will just send a fault instead of not sending back a CS, because
this kind of MC was supposed to get a CS as response. So the RMS always knows
when it needs a new sequence or not, and is the one deciding when its “too
late” (or too early?) for a sequence or not.
If
the RMS is given a traffic message that must be sent reliably, and no sequence
exist for it, it sure knows a new sequence is needed, and an invite to create
one should be accepted. If it already has a sequence open so that the new
one would be redundant, it can fault it.
I guess
the main case where it is important to fault, is for resisting attacks with many
such MCs trying to take undesired sequence resources on RMS. Security might
help here.
The MakeConnection header
MUST NOT be included on a message for which there is a defined response.
(When the RM logic is not
co-located with the application logic how is this determination made?)
<JD>
The wording “defined response” in the proposal needs be improved. I
guess the absence of wsa:ReplyTo anon should be a good sign? In the extreme
case where this header is added after RM processing for traffic messages , then
MC should simply never be piggybacked (this is a configuration matter).
There are many potential
mechanisms (e.g. reference parameters in the MakeConnectionTo EPR) that
allow a server to relate a new sequence to a client to one
previously established from the same client.
Mandating a particular mechanism an implementation must
use is out of scope of this specification.
(As you said, not having a clear
understanding of how things will work will lead to interop issues)
<JD>
either needs be specified in MSFT proposal, or at least a solution outlined even
if not in WS-RX, to be convinced that RSP can handle this.
These
are just some of the 'unknowns' I quickly found in the MSFT proposal. You
said you believe that the MSFT proposal doesn't require out-of-band
communications - and yet for just the items listed above I think each one of
those requires quite a bit of it. Since you seem to understand the MSFT
proposal perhaps you could explain to me how the above questions can be
interoperably answered w/o some out-of-band communications that are not
specified in the MSFT's proposal.
thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com
"Jonathan Marsh"
<jonathan@wso2.com>
11/25/2006 10:40 AM
|
To
|
Doug Davis/Raleigh/IBM@IBMUS
|
cc
|
"'Gilbert Pilz'"
<Gilbert.Pilz@bea.com>, "'Marc Goodner'"
<mgoodner@microsoft.com>, "'Paul Fremantle'"
<paul@wso2.com>, <ws-rx@lists.oasis-open.org>
|
Subject
|
RE: [ws-rx] Issue 28: MakeConnection
preconditions are unclear
|
|
So I infer that the complete set of preconditions
are:
Client:
1) An EPR (self-generated), using the RMAnon URI template.
Server:
2) The client’s EPR.
3) An indication from the client that it may use MakeConnection in
future interactions.
The spec does not mandate any particular way that the EPR and
the indication get from client to server.
I have three observations about this:
1) When a spec relies on out-of-band communication to operate, at the
very least the preconditions should be formally enumerated. This issue
asks for such clarification in the spec.
2) Because there is a reliance on preconditions, the behavior when
they haven’t been met should be described in sufficient detail to have
interoperable failures.
3) In the large, interoperability would be better served by reducing
dependence on out-of-band preconditions. I think the Microsoft proposal
has advantages in this regard.
Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com