Re: [ws-rx] Issue 30: Facilities to support optionalMakeConnection.underspecified

[Doug Davis <dug@us.ibm.com>]

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