You seem to have a lot of expectations around establishing preconditions
for use of MakeConnection that place some interesting restrictions on the
message flows you have in mind. I don’t find any of your statements
around “too late” being supported by what is in the spec. I think you
need to be clear in what your expected use of MakeConnection is for what is in
the spec today. It is becoming quite clear that there are some things that just
aren’t present in the spec that one needs to understand if we want to use
it in the way that you intend to.
I don’t find anything confusing about the statement in the
issue around MC+SeqId. There isn’t anything needed to be said about MC
being used or not in that case as the SeqID is the only piece of identifying
information you need for it.
Again, you seem to have a real requirement that the use of MC be
specified over the wire in advance of actually using it somehow. I don’t
understand these requirements as they are not described in the specification.
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Tuesday, November 14, 2006 9:01 AM
To: Marc Goodner
Cc: Jonathan Marsh; Marc Goodner; ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Issue 30: Facilities to support optional
MakeConnection.underspecified
Not true.
As I said in the previous note, sending a MCRefused in response to a MC
is too late - a policy assertion is needed for all variants of MC.
As for
Jonathan's comment about MC+SeqID being clear that MC will be used is very odd
to me since there's nothing in there to indicate that MC will be used.
The use of WSA's anon can't possibly mean anything about MC since it may
be used for the CS even when MC will not be used - like normal async cases.
Meaning, all app messages could use real async EPRs but the CS could use
anonymous - a very common case. The only case that clearly indicates that
MC will be used is the use of the RManonURI - it very clearly indicates that if
the client doesn't get the expected response it will poll for it. None of
the other variants of MC have the client telling the server this information.
thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com
|
Marc
Goodner <mgoodner@microsoft.com>
11/14/2006
11:37 AM
|
|
To
|
Marc
Goodner <mgoodner@microsoft.com>, Jonathan Marsh
<jonathan@wso2.com>, "ws-rx@lists.oasis-open.org"
<ws-rx@lists.oasis-open.org>
|
|
cc
|
|
|
Subject
|
[ws-rx]
Issue 30: Facilities to support optional MakeConnection.underspecified
|
|
In
the proposal we made for PR001 I don’t believe this is an issue as there
is a MakeConnectionRefused fault defined.
If
PR001 is closed with no action I agree that it would be good for such a fault
to be added to the spec.
From: Jonathan Marsh
[mailto:jonathan@wso2.com]
Sent: Monday, November 06, 2006 9:56 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] New issue: Facilities to support optional
MakeConnection.underspecified
The spec
implies that MakeConnection is required of all implementations. Since
there appear to be preconditions to initiating polling, and these preconditions
are outside the scope of the spec, it is entirely possible that a particular
implementation can refuse to accept the preconditions that require polling.
Such a refusal
is reasonable, as polling can be resource intensive (requires a store of
messages waiting to be polled). Buffering messages has inherent limits:
- The
physical machine hosting the buffering service may have less than infinite
capacity. In fact, it may appear to have no capacity to create a new
buffer for a particular user.
- The
buffering service may have policies on when an unpolled buffer can be
discarded.
- The
buffering service may need to reject or destroy to avoid DoS attacks.
Since accepting
the preconditions is not mandatory, effective use of a MakeConnection is also
effectively optional. However the negotiation of this scenario is
currently outside the scope of the spec, and is likely to suffer a loss of
interoperability as a result. The optional nature should be clarified in
the spec, and further infrastructure should be deployed (e.g. a
MakeConnectionRefused error, possibly an rm:MakeConnectionEnabled policy
assertion) to assist in interoperability in determining at run time, possibly
even at design time, whether a MakeConnection attempt has been, or will be,
successful.
With
MakeConnection+SeqID, there is a clear marker that Polling is being
"initiated" - a CreateSequence+Offer+WSA-AnonymousEPR indicates that
two way reliability with Anon is happening. The server can either fault
CreateSeqRefused or can fail to accept the Offered sequence (which is after all
the troublemaker). However, with MakeConnection+RManonURI, the RMAnonURI
can be "slipped" in at some earlier point into messages that do not
have any relationship to the RM agent, for example as a ReplyTo. The RM agent
may not be handling that message, but in this case what does the server do with
this message?
Jonathan
Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com