Re: [wsrm] Discussion on Issues Rel 108 and 115

[Tom Rutt <tom@coastin.com>]

Jacques Durand wrote:

> >The major problem with this is the requirmenet for the receiver to 
> remember which fault >codes arose for each non-delivered message.
>
> Yes, I would think twice before making this a REQUIRED feature...
> There is also a limit for how many delivered messages a "poll" can 
> acknowledge:
> Normally, a receiver can rely on the presence of stored message IDs,
> to know which messages have been delivered.
> But when these messages expire, the receiver may get rid of these IDs,
> as no duplicate elimination will be needed anymore.
> (except for groups, where efficient interval representation does not
> require removing expired IDs.)
> So, unless Poll requests can limit their responses to non-expired
> messages, I see more headache in remembering not just the Faulted 
> messages,
> but all the delivered ones as well...
>
It should be clarified that the poll response only includes non expired 
message IDs.

The extra cost to keep the fault structure is not great,  and could be 
part of the requirements for a Receiving RMP
supporting the poll request operation.

I still am not sure whether the callback would benefit from this 
addtional refToFaults element in the response.  It might just be simpler
to require all faults to be sent with their own callback, and just allow 
callbacks to batch acks.

Tom Rutt

> Jacques
>
>
> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Friday, February 13, 2004 5:37 PM
> To: wsrm
> Subject: [wsrm] Discussion on Issues Rel 108 and 115
>
>
> These issues deal with the semantics of poll response for messages which
> were not delivered due to a fault
>
> Current semantics of returning fault are as follows:
>
> For resposne reply pattern a single message fault is returned in the
> response to the reliable request.
>
> For callback reply pattern, a single message fault is returned in the
> callback containing the Fault element.
>
> It is not clearly stated, but the receving RMP could batch a bunch of
> acks in a single callback message, but there is not way to do this
> for faults.
>
> Currently there is not way to indicate in a response to a poll that a
> message was not delivered due to  a fault.  The response to the
> poll merely lists all message IDs in the poll range which were
> delivered.  Messages not in that list may be held, or may have been not
> delivered due to a fault condition.
>
> A fault element in a response to a poll, only indicates a problem wiht
> the poll request itself.  It cannot be used to indicate a fault on a 
> prior
> reliable messasge request.
>
> The current Response syntax is as follows:
>
> <!--
>
>  Response Header Type and it's elements
>
>   -->
> - <#> <xsd:complexType name="*ResponseType*">
> - <#> <xsd:complexContent>
> - <#> <xsd:extension base="*wsrm:RmBaseType*">
> - <#>       <xsd:sequence>
>               <xsd:element name="*RefToGroupId*"
> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
>      </xsd:sequence>
>   </xsd:extension>
>  </xsd:complexContent>
> </xsd:complexType>
>
>
> We could add a new element to the responst type as follows
>
> <xsd:complexType name="*ResponseType*">
> - <#> <xsd:complexContent>
> - <#> <xsd:extension base="*wsrm:RmBaseType*">
> - <#>       <xsd:sequence>
>               <xsd:element name="*RefToGroupId*"
> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
>            <xsd:element name="*RefToFaults*" type="*wsrm:FaultsRefType*"
> maxOccurs="*unbounded*" />
>
>      </xsd:sequence>
>   </xsd:extension>
>  </xsd:complexContent>
> </xsd:complexType>
>
> <xsd:complexType name="*FaultsRefType*">
> - <#> <xsd:complexContent>
> - <#>       <xsd:sequence>      
>                <xsd:element name="*FaultCode*" type="xsd:string"
> maxOccurs="*1*" />
>               <xsd:element name="*RefToGroupId*"
> type="*wsrm:ResponseElementType*" maxOccurs="*unbounded*" />
>     </xsd:sequence>
> </xsd:complexContent>
> </xsd:complexType>           
>
> An example of the structure of the RefToFaults element (repeated here
> twice) would be as follows
>
>
>    <RefToFaults>
>
>          <FaultCode>  processingError </FaultCode>
>
>           <RefToGroupID> ... list of message ids in group a which had 
> processing error fault ... </RefToGroupID>
>            <RefToGroupID> ... list of message ids , in group b which 
> had processing error fault ... </RefToGroupID>
>     </RefToFaults>
>
>    <RefToFaults>
>
>          <FaultCode>  BadHeader </FaultCode>
>
>           <RefToGroupID ... list of message ids  in group a which had 
> Bad header fault ... </RefToGroupID>
>
>     </RefToFaults>
>
> The major problem with this is the requirmenet for the receiver to 
> remember which fault codes arose for each non-delivered message.
>
> However, it would give full functionality to the poll response.
>
> Tom Rutt
>
>
>
>
>
>
>
> -- 
>
> ----------------------------------------------------
> 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