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

[Prasad Yendluri <pyendluri@webmethods.com>]

I agree with this 100% as well. The overhead brought in sequence numbers far
outweighs any benefits it might offer.

Regards, Prasad

Marc Breissinger wrote:

> 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