Re: [wsrm] REL-xyz:proposal to add a new attribute (messageType) toResponse element

[Tony Graham <Tony.Graham@sun.com>]

Sunil Kunisetty <Sunil.Kunisetty@oracle.com> wrote at Mon, 09 Feb 2004 11:11:06 -0800:
...
> Sunil Kunisetty wrote:
> 
> >  I like to suggest that we add an attribute by name messageType to the
> >  response Header element to easily distinguish a RM-Fault message with
> >  an RM-Ack. Message. Currently we need to check for the existence of
> >  the Fault Header (for SOAP 1.1_ to distinguish an Ack. To a Fault.
> >  This is some what tedious and instead having a simple attribute with the type
> >  of the message will make it simpler and less error prone.

If checking for the existence of a SOAP Header Element is tedious and
error prone, then setting an attribute under some circumstances is, if
anything, more tedious and error prone.

A better optimisation would be to put the Fault element, if any,
*inside* the Response element or to allow the content of the Response
element inside the Fault element.

Either of those would make the fault processing more useful with the
Poll reply pattern since you could then return a set of faults and
acknowledgments in the response to a PollRequest.

I still suspect that Sunil misunderstood me in his response to my
message of 16th January:

 | > 748     While a PollRequest can request acknowledgment of a messages
 | >         with a range of sequence number values, it is not clear what
 | >         happens when one or more of the messages in that range caused
 | >         faults.
 | >
 | >         Consider, for example, a sequence of messages with the same
 | >         GroupId and sequence numbers 0 to 4 sent using the Poll reply
 | >         pattern.  If message 1 fails with an InvalidMessageHeader
 | >         fault and message 3 fails with an InvalidRequest fault, what
 | >         is the expected response for a PollRequest element containing
 | >         <SequenceNumberRange from="0" to="4"/>?
 | 
 |  Here is what I had in my proposal for Rel 94:
 | 
 |  <rel94-snippet>
 |  1.InvalidGroupId:  Even if one of the GroupIds are wrong or invalid, this
 | fault will be sent.
 |   2.InvalidSequenceNumber: Even if one of the SequenceNumbers is wrong or
 | invalid,
 |      this fault will be generated and sent.
 | 
 | 
 |  Essentially, all or none approach wrt to Faults. We should be able to share
 | the above
 |  Status values with Fault  Codes. Note both  are QNAME types and hence
 | shareable.
 | </rel94-snippet>
 | 
 |  So essentially your example will result in a Fault.

If Response allowed Fault, the response to my example PollRequest
would contain five Response elements, two of which contained Fault
elements.

If Fault contained what Response contains, the response to my example
PollRequest would contain three Response elements and two Fault
elements.

Even if Sunil didn't misunderstand me, it would currently take three
PollRequest messages to get the status of the five messages in my
example: one would get the acknowledgments for sequence numbers 0, 2,
and 4; one would get the fault for 1; and the other would get the
fault for 3.

Alternatively, if I've misunderstood Sunil, you'd only ever get fault
messages when you do a PollRequest for a range of messages that
includes a message with a fault.  I really hope that's not what he's
saying.

Regards,


Tony Graham
------------------------------------------------------------------------
Web Products, Technologies and Standards           Phone: +353 1 8199708
Sun Microsystems                                              x(70)19708
East Point Business Park, Dublin 3, Ireland