Shimamura-san
If the conversation is managed by higher levels of middleware, then the
receivng and sending MSHs still can know when the conversation is ended.
It can find out through its own API from the middleware that manages the
conversation. These things are very hard to discuss and achieve consensus
on because the MSG team has never written down the list of functions that
are performed by the API to the MSH.
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 12/03/2001 04:53:41 AM
To: Dan Weinreb <dlw@exceloncorp.com>, Martin W Sachs/Watson/IBM@IBMUS
cc: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Dan and Martin,
My proposal's purpose is not management of ConversationId by MSH itself.
Its purpose is prevention of invalid ConversationId and acquisition of
timing information of the end of conversation in MSH. Because message
order is guaranteed per conversation. If higher layer (application or
middleware) gives MSH invalid ConversationId, MSH will fail in guarantee
of message order. And also if MSH can't know when the conversation
finishes, MSH can't decide that when the conversation's sequence number
information can be released from MSH's resource.
So I can withdraw (1) in my proposals below, but I'd like to keep (2) as
my proposal. Because if higher layer gives MSH the status information
(Start, Middle, End or Alone), sending MSH and receiving MSH can check
invalid ConversationId and can know when the conversation finishes.
On Thu, 29 Nov 2001 19:39:33 +0900
SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> wrote:
> 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:
>
> 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.
>
> 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. 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.
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>