[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
Easy :-)
When the conversation management function above the MSH sets up a new
conversation, it must supply the necessary internal routing information to
the MSH along with the conversationId that goes in the message header. The
MSH has to keep both of them in its persistent store. The internal routing
information would be some kind of class name, applet name, or other
implementation thingie.
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
*************************************************************************************
David Fischer <david@drummondgroup.com> on 12/04/2001 11:45:24 AM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>, Dan Weinreb
<dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Routing on ConversationId? The ConversationId can be anything the sender
chooses. How can you route on ConversationId?
David.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, December 04, 2001 7:53 AM
To: David Fischer
Cc: SHIMAMURA Masayoshi; Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Still not true!
If the MSH bases routing decisions on conversationId, it must hold the
conversationId until it is told by software/middleware that the
conversation is ended; forever if necessary. If it does not hold onto the
conversationId, it will not be able to correctly process messages for the
same conversation that arrive after it purges the conversationId from its
persistent store.
This will really work much better if the MSH gets out of this business and
leaves it to the layer of middleware that manages conversation.
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
********************************************************************************
*****
David Fischer <david@drummondgroup.com> on 12/03/2001 09:47:54 PM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>, Dan Weinreb
<dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
I'm sorry, I think I stirred a hornet's nest.
I do not mean that a Conversation ends with persistDuration. I only meant
the
ConversationID need not be stored (for Message Order) if there are no
persisted
messages for that ConversationId. The Conversation may go on indefinitely.
Sorry for the confusion,
David.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Monday, December 03, 2001 5:25 PM
To: David Fischer
Cc: SHIMAMURA Masayoshi; Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
David,
If things are working right, the end of a conversation should NEVER be
controlled by persistDuration. The end of a conversation is when the
application (or conversation management middleware) says that it's the end.
If persistDuration expires before the software says that the conversation
is ended, it is killing the conversation due to an abnormal condition. I
hope that the MSH would at least have the decency to notify the upper
levels that it has killed a conversation. Once the conversation has been
killed by the MSH, no further messages should be sent with the same
conversation ID since that would confuse the heck out of the upper levels.
The possiblity of that happening means that perhaps there should be a
"start of conversation" indicator in the message header so that a receiving
MSH can distinguish between the start of a new conversation and belated
messages for conversations that it has killed.
Note also that persistDuration may have a very different time scale if we
are going to apply it to the conversationId since a conversation can last
minutes or longer (maybe even weeks), depending on what is going on in the
conversation.
All of this suggests that we would do well to leave all conversation
management, including routing of messages by conversationId, to the upper
levels. That would avoid the need to figure out how long the MSH has to
persist a conversationId.
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
********************************************************************************
*****
David Fischer <david@drummondgroup.com> on 12/03/2001 03:44:24 PM
To: SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>, Dan Weinreb
<dlw@exceloncorp.com>, Martin W Sachs/Watson/IBM@IBMUS
cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
I seem to be missing something. The end of a conversation is controlled by
persistDuration, isn't it? I think the ConversationId is held in
persistent
store with the MessageId (at least in the case of MessageOrdering). Along
with,
or in, the MessageId record, there must be a persistDuration field. When
the
last message in that conversation is deleted from the persistent store
(persistDuration has passed), wouldn't the ConversationId automatically go
with
it? If there are still messages waiting because they are out of order,
would
they not also be deleted when persistDuration expires? If you are
concerned
with messages going away too quickly, then make persistDuration long.
There is nothing forbidding another later message to be sent with the
original
ConversationId but the message order would not be of concern since all the
previous messages have expired anyway.
Or, are you saying ConversationId is held somewhere else?
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
Sent: Monday, December 03, 2001 3:54 AM
To: Dan Weinreb; mwsachs@us.ibm.com
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>
----------------------------------------------------------------
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC