Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Fri, 30 Nov 2001 18:42:50 -0500
   From: "Martin W Sachs" <mwsachs@us.ibm.com>

   Is there any explicit requirement that can be expressed in the BPSS
   instance document to say "these unacknowledged messages must be sent over a
   transport that maintains order"?

Are you asking whether there's one now, or whether (I'm saying that)
there should be one?  I don't think there is one now.  If the question
of whether the MSH's agree to deliver the messages of a given
conversation in order is an option, then certainly something has to
tell us whether to turn that option on or off.  I think Arvola
suggested that this should be in the CPA.

   What happens today (pre-ebXML) if those messages are sent over SMTP which,
   if I understand it correctly, will not maintain order? TCP keeps the bytes
   in each message in order but it can't keep the emails in order. 

Right, if you use email and don't build anything on top of it to deal with
ordering, the email messages can arrive in any order.

								   HTTP will
   itself maintain order if all the messages are sent over the same path.

If it's the same path, yeah, I guess so, although once you have some
of those complicated intermediate-node scenarios that we've discussed,
it's not clear that you'll always know whether messages are all coming
over the same path.  My sense is that it's better not to try to depend
on this.

   Whoever is configuring the systems has to know not to use SMTP with such a
   business process. Is there anything even with ebXML to flag that the CPA
   must be written either to use message ordering or not to use SMTP?

   Maybe I am being extravagent with business process implementation but my
   comfort level is much higher if the business process is written to assure
   ordering rather than having to keep an eye on what is going on across
   multiple layers to assure that ordering is maintained.

I agree that keeping an eye on what is going on across multiple layers
would be a bad thing.  But I had in mind a different approach to
solving this.

I don't think anybody ought to be thinking about the idea that certain
business processes have to use HTTP rather than SMTP.  That really
strikes me as violation of modularity and layering.  The high levels
should not have any knowledge of transport/communication-level
protocols such as HTTP and SMTP.  After all, maybe in a year or two
we'll add a few new ones: we don't want the higher levels to have to
be retroactively modified to know about new protocols.

The higher levels should just deal with the MSH, and let the MSH worry
about knowing about the difference between HTTP and SMTP.  The higher
levels just say whether they need messages to be delivered in order or
not.  It's the job of the MSH to accomplish that.

As an implementor, I would try to keep the
transport/communication-level protocols as low in the layering as
possible.  If message ordering within a conversation needs to be
maintained, I'd just put sequence numbers into every ebXML message,
regardless of how the transport is going to work, and whenever any
message arrives, I'd use the sequence numbers to make sure that the
messages are delivered to the application in order.

In other words, I would not try to take advantage of any special
knowledge about "HTTP over the same path", and just assume that
messages might arrive out of order.  This seems like the robust way to
structure things.

You might argue that in this approach I might be paying the cost of
doing message ordering even in some cases when it's not needed (e.g.
the case where I know somehow that everything is "HTTP over the same
path").  However, the cost of doing message ordering is pretty low
when the messages actually do always arrive in the same order.

-- Dan