[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
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC