[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 059 - Protocol event indications are not ws-addressingfaults
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. >>> >>> >>> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]