Hi all,
Yep, I also agree on this. As it stands now, conversationID is out of the
MSH's sphere of influence. We had some e-mails during the "old" days about
MSH spec and Application relationships/interfaces.
When we get a chance, I would like to re-visit (or rather visit) this
issue. May be we will keep this for version 1.5 or 2.
cheers
| -----Original Message-----
| From: Dan Weinreb [mailto:dlw@exceloncorp.com]
| Sent: Friday, November 30, 2001 8:00 PM
| To: mwsachs@us.ibm.com
| 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 09:38:24 -0500
| From: Martin W Sachs <mwsachs@us.ibm.com>
|
| MWS: The total of my argument is that there is no reason for
| the MSH to
| manage the conversationId or to create its own internal form of the
| conversationId. The conversation is a construct of the
| application and
| higher level middleware and the MSH only has to place the
| conversationId in
| the header of the outgoing message. See my response below.
|
| I agree with this.
|
| I think this is independent of the issue of message ordering.
|
| (Actually, the MS spec generally has little to say about the interface
| between the Application and the MSH, so I'm not sure why we should
| start worrying about it now. The MS spec really just talks about the
| communication between the two ends. So the question of whether the
| application supplies the conversationId to the MSH, or the MSH
| generates the conversationId itself, may not even be "in scope".
| In light of this, I think we should not say anything about "who"
| picks the conversationId as part of the MS spec.)
|
| ----------------------------------------------------------------
| To subscribe or unsubscribe from this elist use the subscription
| manager: <http://lists.oasis-open.org/ob/adm.pl>
|