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

Hi all,

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

	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
		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

	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$

cheers & have a nice weekend

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

Powered by eList eXpress LLC