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

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

Tom,

I think you're referring to the resolution of issue 030 (use of [reply endpoint] etc), not 052  which is rumbling along?

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