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

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

Tony Graham wrote:

Sunil Kunisetty <Sunil.Kunisetty@oracle.com> wrote at Mon, 09 Feb 2004 17:26:10 -0800:
> 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.

I fear that adding an attribute is a workaround, not a solution, but I
will need to look at your response in more detail.

 Please. Let me know if you still see an issue.

 

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

I figured SOAP 1.2 would figure in it.

A SOAP 1.2 Fault element inside a SOAP header block has no

 In the 1.2 case,  Faults are sent inside the Body/Fault and
not in a Header
 unlike the 1.1 case. That's why we don't want to  intermix
fault codes in
 the Response element.

 
SOAP-defined semantics anyway, which is where you have to put the
Fault element if you were piggybacking the Fault message on a Normal
message (not that we seem to have the term anymore).

In any case, you could put the message id information inside the SOAP
Detail element of a SOAP 1.2 Fault element.

 Yes. That's what we are doing. That's what I meant above by "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.

So the sending RMP never gets a fault for a Reliable Message that was

 Yes and No.
 Yes, you get the Fault if you  use the Callback or Response Reply Pattern.
 No for Poll.  It's a known limitation for Poll  -  a trade off for simplicity.
 That's why it is a more a Poll request rather a Status request.

 
sent containing an error?  What does that say about the "per Reliable
Message" Notify "abstract operation" for the Poll RM-Reply Pattern?

Also, isn't the sending RMP just going to keep resending the same
flawed message since it never receives an Acknowledgment for it?

 You can still get the fault if you use the Callback or Response pattern.
 Only for Poll, you don't get. Poll just sends the list of messages
that
 was delivered to the next layer, unless processing the Poll request
 itself fails.

 We need to clarify this in our specification.

 thx!
 -Sunil