Re: [ws-tx] Issue 059 - Protocol event indications are not ws-addressingfaults

[Alastair Green <alastair.green@choreology.com>]

Tom,

Further to this exchange, a question.

The latest working draft of WS-RM contains the following:

'The faults defined in this section fall into one of two categories; 
those faults that are the result of
messages or operations within a specific Sequence and those faults that 
are not. By their nature the
CreateSequenceRefused, UnknownSequence, and WSRMRequired faults cannot 
be correlated with a
Sequence. All other faults defined in this section relate to the 
processing of WS-RM protocol messages or
messages containing WS-RM header blocks targeted at a specific Sequence 
and are collectively referred
to as "Sequence faults".

'Faults for the CreateSequence message exchange are treated as defined 
in WS-Addressing.
CreateSequenceRefused is a possible fault reply for this operation. 
UnknownSequence is a fault
generated by endpoints when messages carrying RM header blocks targeted 
at unrecognized or
terminated Sequences are detected, these faults are also treated as 
defined in WS-Addressing. All other
faults in this section relate to the processing of RM header blocks 
targeted at known Sequences and are
collectively referred to as Sequence faults. Entities that generate 
Sequence faults SHOULD send those
faultsbe sent to the same [destination] as 
<wsrm:SequenceAcknowledgement> messages. These
faults are correlated using the Sequence identifier carried in the detail.'

WS-RM is here making a split in terms of faults: those which are 
correlated using [relationship] and those which are correlated by a 
WS-RM-specific identifier (the Sequence identifier). But they are using 
SOAP fault syntax to represent both types of fault.

Do you believe that WS-RM has a similar issue to WS-TX to the one you 
have raised?

The purpose of the question is to understand better where you feel the 
dividing line comes, in terms of using SOAP fault format.

I'm not trying to start a WS-RM discussion on the wrong list, but to 
understand if you feel that WS-RM are doing something right, legal, 
appropriate, and we are not, and if so, what is the criterion that 
distinguishes their approach and ours?

Alastair

Tom Rutt wrote:
> Alastair Green wrote:
>
>> Tom,
>>
>> I think you're referring to the resolution of issue 030 (use of 
>> [reply endpoint] etc), not 052  which is rumbling along?
>
> Yes I did not have access to the issues list when I sent that mail.
>
>>
>> Thoughts on this are contained in a previous post on issue 030:
>>
>>     
>> http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200605/msg00011.html 
>>
>>
>> I do have some sympathy with your view from the standpoint of 
>> clarity, optimal reflection of the layering, etc.
>>
>> Balancing that: this change will affect existing implementations and 
>> therefore interop, and obviously requires changes to the schema/WSDL 
>> as well as to the spec. The change will introduce no functional 
>> improvement in the protocol.
>>
>> The resulting schema will presumably replicate some of the features 
>> of a SOAP 1.2 fault element, which is pre-existing work that is 
>> currently referenced.
>>
>> Also, I think this raises a design consistency problem. The "protocol 
>> event indications" /are /sent as WS-Addressing faults in 
>> WS-Coordination (i.e. they are sent as responses, using 
>> [relationship] to a [reply endpoint] in accordance with WS-A Core 
>> 3.4), but they are sent as plain requests i n WS-AT/BA.
>>
>> Would you propose that we map to SOAP fault in WS-C, but to PEI in 
>> WS-AT/BA? 
>
> Yes, soap fault for ws-c, and PEI for ws-at and ba.
>
> WS addressing reply to and fault to semantics are also for application 
> specific faults.
>
> However, since these PEIs are first class messages, mapped to http 
> request, they do not
> "well fit" the ws addressing fault model.
>
> Tom Rutt
>
>> Or always to PEI? If you view the mode of targetting/delivery as 
>> affecting the type of the element, then this is a pertinent question. 
>> The current spec implicitly considers the mode to be orthogonal to 
>> the type.
>>
>> Alastair
>>
>>
>> Ram Jeyaraman wrote:
>>
>>> This is identified as WS-TX issue 059.
>>>
>>> Please ensure follow-ups have a subject line starting "Issue 059 -
>>> Protocol event indications are not ws-addressing faults".
>>>
>>> -----Original Message-----
>>> From: Tom Rutt [mailto:tom@coastin.com] Sent: Tuesday, May 09, 2006 
>>> 1:23 PM
>>> To: ws-tx
>>> Subject: [ws-tx] NEW ISSUE: Protocol event indications are not
>>> ws-addressing faults
>>>
>>> Nature of Problem:
>>>
>>> With the resolution of Issue 52, the specifications (coord, at, ba) 
>>> have
>>>
>>> two kinds of indicaitons:
>>>
>>> Faults (definined in ws coord) which map to ws-addressing fault model.
>>>
>>> "notifications" (from ws at, ba) which do not map to ws addressing 
>>> faults, and which are treated as
>>> first class "requests" from ws addressiing perspective.
>>>
>>> Mapping the second kind of indication to a soap fault, but not a ws 
>>> addressing fault, will inevitably cause
>>> confustion for implementers of this spec.
>>>
>>> Proposed solution:
>>>
>>> Instead of mapping the "notificaitons" to soap fault syntax, define 
>>> a new schema type
>>> {ProtocolEventIndication) which conveys the proper syntax for the 
>>> contents of these protocol notifications.
>>>
>>> Have each individual protocolEventIndication be mapped to this new 
>>> syntax, as a proper ws addressing request message.
>>>
>>>  
>>>
>
>