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] Issue 28: MakeConnection preconditions are unclear


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
 



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