Re: [wsrm] message headers for Ack and Fault ??

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

>
> This is the essence of the resolution to REL 115 and Rel 108.
>
> The concern is the lowered funtionality of polling response.
>
> here is a pseudo exampl
>
> <Faults>
>     <Fault>
>           <FaultType>  processingError </FaultType>
>            <RefToMessageIDs> ... list of message ids which had that
> fault ... </RefToMessageIDs>
>      </Fault>
>     <Fault>
>           <FaultType>  BadHeader </FaultType>
>            <RefToMessageIDs> ... list of message ids which had that
> fault ... </RefToMessageIDs>
>      </Fault>
>  </Faults>
>
> The above xml structure can cary a separate list of messageIDs which
> were not delivered for a specific set of fault codes.
>

 I've few questions:
 1) How does a Poll response with no faults, i,e, a regular poll response look?
 2) If a Callback Response has to be batched (especially want to batch fault responses)
   , how does it do it?
 3) If the Poll with fault is for one msg only, then what is the relationship between
     this header and that Fault header in 1.1 case and 1.2 fault subcode?
  4) What should be the response for Expired messages? In the current proposal,
       they are ignored when responding.

> Its major problem is that it requires keepting fault information in the
> persistence of the receiver.

>
> Here it is again.

 Was it sent before? I don't recollect seeing it before.

>
>
> >
> >
> >
> >>
> >>
> >>>
> >>>
> >>>
> >>>>>>Further, I believe the ReplyPattern element in a request, would be
> >>>>>>more at its
> >>>>>>place in the RM:Request element, as it should be associated with the
> >>>>>>element
> >>>>>>that has "request semantics".
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>+1
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Doing so, the MessageHeader element would only contain ID and general
> >>>>>>message info,
> >>>>>>and would only need be included in "reliable messages", as
> >>>>>>the second sentence in 3.1. clearly suggests already (at odds with
> >>>>>>current usage).
> >>>>>>Later on when we have RM:Response piggybacking on business messages,
> >>>>>>the info in
> >>>>>>messageHeader would be totally orthogonal to the info in RM:Response.
> >>>>>>
> >>>>>>jacques
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>--
> >>>>----------------------------------------------------
> >>>>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> >>>>Tel: +1 732 801 5744          Fax: +1 732 774 5133
> >>>>
> >>>>
> >>>>
> >>>>
> >>>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.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>----------------------------------------------------
> >>Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> >>Tel: +1 732 801 5744          Fax: +1 732 774 5133
> >>
> >>
> >
> >
> >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.
> >
> >
> >
>
> --
> ----------------------------------------------------
> Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133