OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



 Hi Tony,

Tony Graham wrote:

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

 Checking itself is not the only problem, the problem is the dependency.
 I've sent a more detailed response today morning. Let me know if
 you see any problems with my reasoning.

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

 That would have been one option. However, currently for SOAP 1.1 case
 we send the Fault using a Header and for SOAP 1.2 case we use the
 SOAP 1.2 Fault/subcode mechanism. Because of the latter we couldn't
 embed the Fault inside the Response.

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

 At the time we don't support set-of-faults case. What we have currently
 is the all or none approach.

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

 If the request itself is wrong, such as, wrong range or wrong group id. no., then
 we send either the InvalidPollRequest or InvalidMessageId, or InvalidMessageParameters
 depending upon the cause.

 If the request information is correct or valid, then the Response contain message ids
 that are delivered. Response doesn't contain message ids that resulted in
 faults.

 If the processing of the Poll request caused some fault, then either MessageProcessingFailure
 or PermanentProcessingFailure is fault.

 So essentially current Poll proposal doesn't send Faults per individual message. This is
 what we have decided for simplicity sake. We could have done otherwise, but we haven't.


>
>  | >
>  | >         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
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]