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

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

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

Regards,


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