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

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

 Tom,

 Here are the consolidated list of problems with this proposal. Some of them have
 been already mentioned, just listing them again for completeness. Some of them
 are critical and some of them are minor:

 Conceptual changes (major):

1. Changes in persistence model:
1. We now end up persisting  non-expired some faulty messages. Note that messages that caused PermanentProcessingFailures may or not be persisted in the first place.
2. Definition of MessageOrder and DuplicateElimination has to change (slightly) since we persist faulty messages also. So a duplicate message is deleted only if the earlier message was not faulted. Something similar has to be said for Message Ordering.

 Conceptual changes (minor):

1. Poll response will  now be different than Callback and Response reply pattern responses. So implementation logic to handle them will have to be different.
2. Have to be mentioned that only non-expired message faults will be sent back.
3. Have to be mentioned that not all non-expired faulty message's faults can be sent back as some messages can cause fatal errors (those that cause PermanentProcessingFailures faults).

Problems with the proposed schema (minor, can be fixed):

1. Both RefToMessageIds and RefToFaults doesn't have minOccurs=0, so essentially you cannot send either just one fault or one regular RefToMessageId. If you add minOccurs=0 to both the subelements, then a PollResponse could be empty. Schema validation could be difficult in that case.
2. RefToFaults should not extend RmBaseType as only top-level elements (Header elements) should extend it. Sub-elements shouldn't extend it. Because RefToFaults extends RmBaseType, it has soap:mustUnderstand=true on a sub-element, which doesn't make sense.
3. If we have to go this route, it will be much simpler to add an attribute (faultCode) to SequenceNumber rather than add a new RefToFaults element.

 While we can still address all the above either explicitly saying
so in the specification,
 it will have a big impact on the schema and specification and
will delay the public draft
 atleast by a month. What concerns me more is why this issue is
being raised so
 late in the game, when we already decided not to have this fault
sending feature for polls
 long time back. I wish the issue was raised at that time only.

 -Sunil

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.

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.