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
------------------------------------------------------------

Received on Thursday, 17 November 2005 13:01:48 UTC