OASIS ebXML Messaging Services TC

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

  • 1.  [ebxml-msg] Re: Comments on the 1.09 about ConversationId

    Posted 11-30-2001 08:16
    Martin, Thank you for sending your comments. However I don't understand why From Party's internal ConversationId *value* should be propagated to To Party. My proposal means that From Party's internal ConversationId value is converted to MSH's ConversationId value through the indications of start and end timing of the conversation, and then the MSH's ConversationId value is propagated to To Party. Is there any problem? > MWS: It is not at all clear to me that message order is a > responsibility of > the MSH. I understand that the MS architecture has the MSH > guaranteeing order. However in every conversation use case I have > seen, there is only one message outstanding in the conversation at > any time. Hence the conversation semantics guarantee ordering without > assistance from the MSH. Please remember Dan Weinreb's comments below. BPSS needs guarantee of message order in messaging layer. > Date: Tue, 16 Oct 2001 09:04:28 -0400 (EDT) > From: Dan Weinreb <dlw@exceloncorp.com> > Subject: Re: [ebxml-msg] Comments on ebMS_v1.04c > > Date: Sun, 14 Oct 2001 22:37:02 -0400 > From: Martin W Sachs <mwsachs@us.ibm.com> > > New MWS comment: I have never understood the value of > messageOrderSemantics, especially since ordering is performed separately > for each conversation. > > I understand what you're saying here and you have an interesting point. > I checked this out with my colleague Mike Rowley, who says: > > Not quite. Within a single collaboration, it is sometimes important that the > messaging system not reverse the order of messages. The BPSS may require, for > example, that an Invoice be sent and then an Advanced Shipment Notice (ASN), > in that order. Neither of these have response messages so they may be sent > one right after the other. The code on the other side will be written on the > assumption that the ASN will never arrive before the Invoice, so if the > messaging system gets them out of order, it will break the collaboration. > > That is, the BPSS can specify a BinaryCollaboration that has two > BusinessTransactionActivities, one after the other in a particular > order, each one of them a BusinessTransaction specifying a document > flow consisting only of a request . In addition, existing B2B applications also need guarantee of message order in lower layer. Please remember Colleen Evans's comments: < http://lists.oasis-open.org/archives/ebxml-msg/200110/msg00102.html > I think there is no such rule that only one message outstanding in the conversation at any time in the ebXML architecture and general business process. By the way, I don't understand ConversationId enough. Because ConversationId does not appear in ebXML's higher level specifications such as BPSS or Core component at all. The ConversationId somehow appears in only CPPA and Message Service. I'd like to understand details of ConversationId. Can I have your answers to following questions? - Why ConversationId is needed? - What kind of good effect is there in B2B? - What layer does use ConversationId? Business application? Or any middleware? What kind of middleware? - Why does ConversationId not appear in ebXML specifications except for CPPA and Message Service? - Would you show use case of ConversationId? Regards, -- SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> TEL:+81-45-476-4590(ext.7128-4241) FAX:+81-45-476-4726(ext.7128-6783) Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED > Date: Thu, 29 Nov 2001 09:43:14 -0500 > From: Martin W Sachs <mwsachs@us.ibm.com> > Subject: Re: [ebxml-msg] Comments on the 1.09 about ConversationId > To: SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> > Message-id: <OF77C7AA5A.6C5D2F36-ON85256B13.004FA39D@pok.ibm.com> > > > Shimamura-san, > > Please see below for some responses (MWS:) > > Regards, > Martin Sachs > > ************************************************************************************* > > 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 > ************************************************************************************* > > > > SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> on 11/29/2001 05:39:33 AM > > To: ebxml-msg@lists.oasis-open.org > cc: > Subject: [ebxml-msg] Comments on the 1.09 about ConversationId > > > > The specification of ConversationId element on page 20 has two problems: > > 1) The value of the ConversationId element is determined by the Party. > > ConversationId is very important for guarantee of message order. > Because message order is guaranteed per each conversation. Thus MSH > instead of Party should determines and manages the value of the > ConversationId to prevent invalid ConversationId value. I propose > following change: > > MWS: I disagree. The MSH is a messaging agent. Management of the > conversation > is at a higher level, either in other middleware or in the application > or both. > The conversationId has to be supplied to the MSH by the higher levels > when the > higher levels request that a message be sent. I understand that the MS > specification provides for ordering the messages in a conversation but > that > is function which is not needed. See comments below. > > Line 823-825 > ... The Party initiating a conversation determines the value of the > ConversationId element that SHALL be reflected in all messages > pertaining to that conversation. > > V > ... The Party indicates start and end of conversation to MSH. The > value of the ConversationId element is generated and managed by the > MSH. > > MWS: I agree that the Party (i.e. the application or appropriate > middleware) > has to indicate start and end of a conversation to the MSH. I do not > agree that the MSH should generate the conversationId or otherwise > manage it. The conversationId is passed between Parties in the > message > header. The party sending the first message of theconversation > generates > the conversationId. The other party may map that conversationId to > its own > internal conversation identifier. > > 2) Receiving MSH can't know the end of conversation. > > Receiving MSH holds received conversation's ConversationId in its > persistent storage for guarantee of message order. > > MWS: It is not at all clear to me that message order is a > responsibility of > the MSH. I understand that the MS architecture has the MSH > guaranteeing order. However in every conversation use case I have > seen, there is only one message outstanding in the conversation at > any time. Hence the conversation semantics guarantee ordering without > assistance from the MSH. > > However receiving > MSH has not any way to know the end of conversation. Thus receiving > MSH don't know when ConversationId's information can be removed from > its persistent storage. > > To resolve the problem, I propose to add status attribute to > ConversationId element. The status attribute takes one of following > three values: > Start: First message in messages belong with the conversation. > Middle: A message except for first and last message in messages > belong with the conversation. > End: Last message in messages belong with the conversation. > Alone: First and last message in the conversation which consist > of only one message. It MUST be specified when the > conversation have only one message. > > MWS: If it is agreed that conversations are really managed at a higher > level in the middleware, then this attribute is not needed at all. > At each Party, the middleware component that manages the conversation > must notify the MSH when that conversation has ended. > > MWS (soapbox here): This discussion is another example of how the > MSG team has done itself a great disservice by not defining the > functions that an API to the MSH must provide. > > > > > Regards, > > -- > SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> > TEL:+81-45-476-4590(ext.7128-4241) FAX:+81-45-476-4726(ext.7128-6783) > Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: < http://lists.oasis-open.org/ob/adm.pl > > > >