OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


I will be content however this comes out.

I want to point out, however, even with SMTP, while messages *can* get out of
order, this is highly unusual.  We are once again worrying about a very small
scenario.  Messages out of order *can* occur when sending eMail through
intermediary MTAs.  Most eMail systems today, work through a hole in the
firewall rather than using an eMail forwarder.  My MTA talks across the Internet
directly to your MTA, typically with no intermediaries.  Even when an enterprise
uses a forwarder at the firewall, the transfer is near instant and the chance of
out-of-order messages is remote.

Even if messages do get out of order, the sending TimeStamp makes this obvious
if the application is watching.

How much is this really worth worrying about?  I will be content however this
comes out but I am inclined to leave MessageOrder as an optional, rather than
Core, module.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Sunday, December 02, 2001 8:01 PM
To: Dan Weinreb
Cc: shima.masa@jp.fujitsu.com; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId



A few rejoinders below (MWS:)

********************************************************************************
*****

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
********************************************************************************
*****



Dan Weinreb <dlw@exceloncorp.com> on 12/02/2001 08:17:36 AM

Please respond to Dan Weinreb <dlw@exceloncorp.com>

To:    Martin W Sachs/Watson/IBM@IBMUS
cc:    shima.masa@jp.fujitsu.com, ebxml-msg@lists.oasis-open.org
Subject:    Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId



   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.

MWS:  I agree.

   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.

MWS:  So today (pre-ebXML), it is not clear that you can rely on messages
without acknowledgements back to the sending application (or at least to
the
conversation management function) to stay in order.

   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.

MWS:  I totally agree.

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.

MWS:  Again, I totally agree, which is why my comfort level prefers
acknowledgments going back to the application to ensure order
independent of the transport level.

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.

MWS: I continue to agree.

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.

MWS:  Again, how do your applications deal with this today, without
ebXML?  According to Arvola's posting, the RosettaNet spec warns
receiving applications not to assume anything about message ordering
when there are no acknowledgments. Your answer is in the next paragraph.

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.

MWS:  Yes, this is my thinking also.  So it seems that you want to
depend on MSH ordering to enable your applications to assume that
the unacknowledged messages stay in order.

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.

MWS:  In the MSH, the cost of ordering the messages can't differ much
between whether they are already in order or aren't.  The MSH must
execute the ordering code even if it finds that it doesn't have to
rearrange anything.

MWS:  By pushing the reordering down to the MSH, you are allowing
the reordering to be done in an application-dependent manner, which
will be an advantage for some applications while other applications
effectively pay the system level cost even when ordering isn't needed.
For example, in the case of invoice and the
advance shipping  notification,
it is probably pretty insignificant whether one comes before the other.
You post a "received" to the database for each one when it comes in
and when it is time to pay, you make sure that you received both the
invoice and the goods. (You are probably not going to pay just on the
basis of the advance shipping notification.) Another way of looking
at this is that you are trading off the added complexity in the MSH
to do ordering
for whatever added complexity there is in having the application
manage the ordering by using acknowlegdments to all messages whose
order matters to the receiving application.

MWS:  And there is still the other issue:  whether the ordering should
be done by the MSH or by the conversation management layer of the
middleware.

-- Dan

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC