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

[Marc Breissinger <marcb@webmethods.com>]

I am in total agreement with Chris on this issue.  I believe sequencing
should be left the application.

marc

-----Original Message-----
From: Chris.Ferris@east.sun.com [mailto:Chris.Ferris@east.sun.com]
Sent: Wednesday, January 03, 2001 11:21 AM
To: ebXML Transport
Subject: Re: SequenceNumber [was:minutes 21-Dec-2000 tr&p con-call]


Shimamura-san,

Why would addendums to the 1st message be
sent as separate messages? It would seem logical
to me that if the message payloads were that closely related,
that they could be sent as a single message with
multiple parts in the payload, the first/primary item containing
references to the other parts.

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
multiple applications, be multi-threaded, etc. It *may*
not get messages from the application in the order in
which they were intended by the application in the event
that there is some internal MOM software employed. The
MSH *may* receive messages from different applications
directed to the same party. Should the message ordering
be preserved by sending application? By party? By message type?
By receiving application?

In a multi-threaded MSH, receiving send requests from
multiple applications, it is non-deterministic as to which
message is processed first when two or more applications
enqueue messages nearly simultaneously for the same party.

It *may* be the case that two different messages travel
distinctly different routes before reaching their final
destination (the To party) when intermediaries are involved,
especially those intermediaries offering value add services
along the way.

In short, I don't believe that this issue is necessarily
solved by sequence numbers. I think that it adds unnecessary
overhead to an MSH to REQUIRE that it somehow preserve
ordering for any set of (possibly, but not necessarily) related
messages between two parties.

Now, this is not to say that sequence numbers don't
add value. They may in fact do so. However, the sequence
number should not be required to be used by an MSH to enforce
that it deliver messages to receiving application(s) in any
particular order. This would, IMHO, be a fundamental mistake
in our design as it might preclude ANY processing of
ANY messages should a receiving application be unavailable
to process messages while others are viable.

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.

My $0.02,

Chris
SHIMAMURA Masayoshi wrote:
>
> Mr. Nikola Stojanovic,
>
> On Fri, 29 Dec 2000 09:23:18 -0500
> Nikola Stojanovic <nhomest1@twcny.rr.com> wrote:
> ...
> > I cannot see why. Also, it seems to me that using the first example one
can
> > have something like this:
> >
> >       1st Message [MessageId = a]
> >       2nd Message [MessageId = b, RefToMessageId = a]
> >       3rd Message [MessageId = c, RefToMessageId = a]
> >       4th Message [MessageId = d, RefToMessageId = b]
> >       5th Message [MessageId = e, RefToMessageId = c]
> >
>
> It seems to me that your example above does not represent the document's
> structure correctly. I considered following case:
>     The 1st Message includes main business payload. Other Messages (2nd
>     to 4th) includes addendum business payload to 1st Message's main
>     business payload. At same time, the order of business payloads has a
>     meaning in business. This is widely used business document structure
>     (ex. license agreement).
> Each Messages 2nd to 5th are individual addendum to 1st Message. Thus
> the Messages 2nd to 5th should make reference to 1st Message (MessageId
> = a) by RefToMessageId.
>
> > and I cannot see how SequenceNumber example can handle that.
> >
>
> I did not say that SequenceNumber alone can handle the business document
> structure. My suggestion is that both MessageId/RefToMessageId and
> SequenceNumber are needed to handle the business document structure
> correctly.
>
> > But, maybe this is just speculating about requirements that don't exist
(it
> > would take me a while to find a Use Case delivery matrix) for Phase 1.
> > AFAIR, SequenceNumber was introduced in order to do Reliable Messaging
and
> > Temporal Ordering of messages wasn't part of it.
>
> Guarantee of message order is one of main requirements in Reliable
> Messaging Phase 2 in the Delivery Matrix. Now we are in Phase 2 (and
> Phase 3), aren't we?
>
> 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