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

[Krishna Sankar <ksankar@cisco.com>]

Hi all,

 |
 |    It is not reasonable, in my mind, to define a business process that
emits
 |    two messages that have no responses and expect them to be always
received
 |    in the order in which they were issued.

<KS>
	a.	The order is binary - either the messages are ordered or not. (I am
referring to the word "always")

	b.	There are a lot of very straightforward use cases which are order
sensitive.
		Stock quotes (they use the time to maintain the order)
		Price messages (again the apps can maintain order based on time)

	c.	If the application has to account for un-ordered messages, it is more
burdensome. There are all kinds of scenarios which can break the order logic
at the app level, but might be easier at the MSH level.

	d.	We are trying to decouple the transport issues from the application
logic and so this (like reliable messaging etc) falls under the MSH than the
application.

	e.	When we dive deep into more sophisticated collaboration models, it would
be extremely efficient to have the order capability at the message layer.

	f.	As a practical counter point, ordering only would be relevant from a
single server. Maintaining order on a distributed system or different
systems would be difficult-if not impossible. In this scenario, it is better
the apps maintain the logic to handle ordering.

	my 0.01$
</KS>

cheers & have a nice weekend