Re: SequenceNumber [was:minutes 21-Dec-2000 tr&p con-call]

[SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>]

Mr. Christopher Ferris, 

I think that need of guarantee of message order depends on each
application's requirement. An application needs guarantee of message
order, but other application does not need. So I'd like to propose that
MSH provides following three QoS semantics:

(1) OnceAndOnlyOnce with Guarantee of Message Order
        - Both message delivery and message order are guaranteed
(2) OnceAndOnlyOnce without Guarantee of Message Order
        - Message delivery is guaranteed, but message order is not
          guaranteed
(3) BestEffort
        - Both message delivery and message order are not guaranteed

In the QoS semantics, SequenceNumber is used in only (1) to guarantee
message order.

To realize the three QoS above, I'd like to propose to add
MessageOrderSemantics attribute to ReliableMessaingInfo element. It
takes one of the values "Guaranteed" or "NotGuaraneed". Here is
relationship between the QoS semantics above and the attributes in
ReliableMessagingInfo element:

    QoS | DeliverySemantics |  MessageOrder
    ----+-------------------+-----------------
    (1) | OneAndOnlyOnce    |  Guaranteed
    (2) | OneAndOnlyOnce    |  NotGuaranteed
    (3) | BestEffort        |    --------

I believe if there are applications which need guarantee of message
order, MSH should support this function to reduce work of application
developers. Actually existing MOM products, such as MQSeries, support
guarantee of message order.

I think that other issues about SequenceNumber you pointed out can be
resolved by generation of SequenceNumber series for each ConversationId.

Here are my comments on other items:

On Wed, 03 Jan 2001 11:20:53 -0500
Christopher Ferris <chris.ferris@east.sun.com> wrote:
...
> As far as maintaining/preserving order, it is difficult
> at best to do so unless the application itself manages
> the ordering. An ebXML Message Service *may* service

I don't understand why application itself should maintain message order.
It seems lower level function than application layer. Actually existing
MOM products support guarantee of message order independently of
application layer.

> In addition, certain transports such as SMTP cannot
> guarantee order of delivery. Messages *may* get "stuck"
> along the way while others flow before and after. Should
> all message delivery be suspended simply because one
> is delayed? I should think not.

I believe that guarantee of message order in SMTP depends on
implementation. If MSH handles SMTP *directly* and executes retry
sequence in ebXML Message Service layer (not SMTP layer) with
SequenceNumber, message order can be guaranteed.


Regards, 

--
SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED