[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] message headers for Ack and Fault ??
Sunil Kunisetty wrote: >>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? > I intended the above faults to be added to the exsiting response schema, after the current ref to message IDS delivered. If there are no faults, the structure avove is empty. > 2) If a Callback Response has to be batched (especially want to batch fault responses) > , how does it do it? > Currently the text is unclear on callback response. However, I assumed the batching for callback can only be for acks. Faults would have to be sent each on their own callback request. > 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? > This is an interesting question, I assumed a fault for a poll would be a fault in the data of a poll request. The current syntax (without my suggested addition above) does not allow a poll response to indicate that a message in the list of the poll request was faulted. It just does not appear in the list. With my proposal above, a mesage which was faulted gets indecated in the additional Faults element of the poll response. > 4) What should be the response for Expired messages? In the current proposal, > they are ignored when responding. > continue to ignore them, they did not fault. However you would not put them in the list of messages which were delivered either. > > > >>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 >> >> > > > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]