[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