RE: Syntax options for Async

The fact that a fault may be sent on the backchannel in a number of cases (you identified one not previously discussed - the idea of an intermediate non-WSA node) was one of the more hotly discussed topics on the async task force. It was not agreed that a fault on the backchannel could be ignored, however. Indeed, it was agreed that the sender should be prepared to accept a fault on the backchannel for some period. Ideally this period would be until the 202 was received (sending a fault on the backchannel after that is, um, problematic!). Should the implementation close the connection early, however, the fault would get dropped on the floor (I don't like this - I think closing the connection before receiving the response is just asking for trouble, but there are timeout questions here).
 
I don't believe there was overall agreement on how to describe this. Some believe this belongs to the protocol binding, because it's talking of HTTP 202s. Others believe it can be discussed at a more abstract level, in terms of whether the underlying protocol supports a backchannel (without a backchannel the discussion becomes moot). I'd like to think that it can be described in general terms at a more abstract level, with the specifics (eg: returning a 202) left to the binding.
 
-----Original Message----- 
From: public-ws-addressing-request@w3.org on behalf of Neil Hudson 
Sent: Thu 17-Nov-05 15:30 
To: public-ws-addressing@w3.org 
Cc: 
Subject: Re: Syntax options for Async




	I would like to raise an observation on the proposal : Async Extension for
	SOAP1.1/HTTP
	http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/att-0116/Pr
	oposalTake3.htm
	
	The observation relates to how the rules for routing messages when a
	separate HTTP return connection is being specified for example with:
	    <wsaw:Async wsdl:required="true"/>full<wsaw:Async>
	or possibly:
	    <wsaw:Async wsdl:required="true"/>always<wsaw:Async>
	apply to Fault messages.
	
	In the first case "full" section 3.1.1 states that the consumer can cause a
	separate connection to be used by specifying an explicit reply EPR rather
	than using the anonymous URI.  When this is done the specification states
	that the initial consumer connection receives a Null 202 response without a
	SOAP body and that replies are sent to the EPR on another connection
	initiated by the provider.
	
	
	
	[1] Question on the Null 202 Response?
	
	Does the reply have to have an empty HTTP body or is it just that there is
	no Soap Body inside the reply?  What meaningful information could be
	contained in a non empty HTTP body?  The BP 1.1 states that for one-way
	operation there is no Soap Envelope in the response, should these two
	patterns be consistent?
	
	
	
	[2] Exceptional Cases - Sending Faults to the 'Wrong' Place
	
	The text as currently written could be interpreted as stating that if "full"
	operation is an option and the consumer specifies an EPR for Faults then the
	initial connection, if successful, would never get a Fault Message back but
	would always get the Null 202 response.  I believe there could be
	exceptional cases where the node that receives the initial request could not
	guarantee that a Fault reply will not be sent back on the initial
	connection.  Some possible cases where this could occur are:
	(a) The SOAP envelope has become so corrupted that it can not be parsed and
	a Fault is generated in response.  The parser has two alternatives, don't
	send any Fault information or send  a Fault back on the open connection.
	The later is the general case.
	(b) The Reply EPR and Fault EPR attributes have been lost from the message.
	A Fault is generated.  It could be argued that the sensible thing is to send
	it back over the initial connection.
	(c) The initial connection is to an intermediate node that is not WS-A aware
	and a Fault is generated / returned from this node.
	(d) The message does not map to a recognised operation and the lower level
	dispatcher implementation is not WS-A aware.
	
	The examples above illustrate three basic types of issue:
	(a) Corruption of messages that prevent the use of the Fault EPR even if the
	layer of the service stack is fully capable of dealing with a Fault EPR were
	the information present.
	(b) Lower level protocols within the stack, that are not necessarily WS-A
	aware, and that generate Faults and return them immediately whilst aborting
	the higher level processing.
	(c) Connection through intermediate nodes which may not be WS-A aware and
	may view WS-A data as payload.
	
	Note that on point (b) it could be argued that a compliant implementation
	needs to address the WS-A Fault EPR at all levels.  So for example if the
	SOAP protocol layer detects a Fault it should check for the Fault EPR in the
	message it has received and if so send the Fault to this EPR.  However this
	would increase coupling between layers and goes against the implementation
	of stacks in layers.  Implementation could be easier / cleaner if a
	'generic' SOAP implementation is used and WS-A protocols are implemented as
	a higher layer in the stack.  The present wording would mean a well behaved
	implementation would have to implement Fault EPR routing in the SOAP layer
	and even this would not guarantee that the Fault EPR would always be used
	and that no Fault message would ever come back on the initial channel (due
	to
	message corruption).
	
	In theory a compliant consumer could ( should? ) simply ignore Faults it
	received back instead of a Null 202 reply and carry on, however:
	(a) Consumer implemented based on this assumption could be vulnerable.
	Software that gets something it is not expecting has a long track record of
	malfunctioning badly.  It would be better to spell out what could happen so
	that consumer developers know it is coming - eventually.
	(b) Lower level, 'middleware' faults could be lost because they are not sent
	to the Fault EPR.  If the service is a Robust-In-Only, "You will be told if
	something has gone wrong.", this increases the risk of the request failing
	without the consumer being informed.
	(c) Application monitoring systems / event logs may miss faults resulting in
	a lower quality of service.
	
	Maybe one approach worth considering  is that the provider will be making
	best efforts to send Faults to the EPR specified by the consumer but that
	this will not always be the case and the consumer needs to be aware of this.
	Putting this into concrete requirements is messy but one stab is illustrated
	below:
	
	[1] The consumer MUST be able to receive a Fault reply on the initial
	connection in the response to the initial HTTP request without malfunction.
	[2] The consumer MUST be able to receive Fault replies at the Fault EPR
	without malfunction.
	[3] The consumer MUST be able to receive Fault replies at the Reply EPR
	without malfunction.
	[4] The provider MAY send Generic SOAP and WS-A faults on either the initial
	connection or to the Fault EPR( or to the Reply EPR if no Fault EPR is
	present.).
	[5] The provider SHOULD send WS-A faults to the Fault EPR where this can be
	identified as the consumers selection( or to the Reply EPR if no Fault EPR
	is present.).
	[6] The provider MUST send Faults for protocols that sit above the WS-A
	level to the Fault EPR( or to the Reply EPR if no Fault EPR is present.)
	[7] The provider MUST send explicitly declared Operation Faults to the Fault
	EPR( or to the Reply EPR if no Fault EPR is present.)
	
	I am less clear about suggesting the following:
	
	[8]  The consumer MUST respond identically to Generic SOAP and WS-A faults
	received in either the response to the initial HTTP request or on the
	specified Fault EPR ( which could be the Reply EPR if no Fault EPR was
	specified in the request).
	[9] When the consumer specified a separate Fault EPR it SHOULD respond to
	Faults received on the Reply EPR in a way identical to Faults Received on
	the Fault EPR. - deals with lost Fault EPR
	
	I don't think these state the obvious - for example that a Fault EPR needs
	to deal with Faults that are sent to it.
	
	Explicitly stating that the consumer needs to expect the
	unexpected, particularly for lower level Faults will make for more robust
	less tightly coupled systems.
	
	Best regards
	
	Neil
	
	--
	------------------------------------------------------------
	Neil Hudson CEng MBCS MIEEE
	------------------------------------------------------------
	SQC Technology Limited
	Phone : +44(0)1283 763632
	Fax   : +44(0)1283 763631
	Email : nahudson@sqc.co.uk
	Web   : http://www.sqc.co.uk
	------------------------------------------------------------