This is about the use case for message ordering in the quote from Dan
Weinreb's posting below.
Dan quotes Mike Rowley who said:
> 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.
Someone, please explain why the collaboration will break if I receive the
advance shipment notice before the invoice. If that happens, I will know to
expect the invoice. It seems to me that these two messages are classic
cases for using email, in which case the order of receipt is unpredictable.
The code on the other side could issue a warning to its user if the advance
ship notice comes first but it shouldn't crash the collaboration. If the
collaboration protocol design really requires that the invoice be RECEIVED
before the advance shipment notice, then the collaboration protocol should
specify an acknowledgment to the invoice.
Maybe I am missing an important point in this use case but if I am right,
then I have to ask: why must we design for a broken use case?
Regards,
Marty
*************************************************************************************
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/30/2001 03:12:25 AM
To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-msg@lists.oasis-open.org
cc:
Subject: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
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>
>
>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>