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

[Tom Rutt <tom@coastin.com>]

Tom Rutt wrote:

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

from section 8.3 of the january face to face minutes:

Agreed to add the following clarifications to the document:

 - for response reply pattern, the ack cannot be sent back on the 
response to a later request.

-  Multiple acks in same reply to are Allowed for callback reply pattern.

 

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