David,
See comments below, MWS:
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/05/2001 03:14:44 PM
To: Martin W Sachs/Watson/IBM@IBMUS
cc: Christopher Ferris <chris.ferris@sun.com>, Dan Weinreb
<dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Marty,
I was suggesting first that we might not need messageOrderSemantics and we
could
do away with this attribute.
I was suggesting second, that it is not particularly useful to tie
MessageOrder
to ConversationId. I did not mean to imply that MessageOrder would be
outside
the confines of a Conversation. We have no means of ending a Conversation
and I
suspect it will be common for Conversations to never end (why should
they?).
MWS: Someone else expressed the view that conversations will always end.
In my mind,
applications that are conversation-based will naturally equate a
conversation with
one unit of business (e.g. one purchase) and so, conversations will always
end. I
suspect that there will be edge cases of legacy software that is not
ebXML-aware that
does its own conversation mangement based on information in the payload
(e.g purchase
order number). The MSH might see that as a single never-ending
conversation.
MWS: You have to have a means of ending a conversation. You don't actually
end it.
The application does that but you have to be notified that the conversation
is ended
precisely so you can purge obsolete stuff from the persistent store. Two
approaches
have already been suggested on this list:
1. Software at each party notifies its MSH
2. Software on the side the sends the last message notifies its MSH and
the
message header contains a flag that notifies the To MSH.
We
do not specify that a ConversationId must be kept in storage anywhere in
the
spec.
MWS: No but since you can (and usually have to) use the convesationId for
routing,
there is an implication that you keep information around that enables that
routing
to be done.
Since there is only a single conversationId, one or both parties has to do
mapping,
which requires some mapping issue to be kept in the persistent store with
the
conversationId.
There is an alternative which the team rejected at least once: The
conversationId
contains a piece that each party supplies (on the first message exchange)
and that
piece is the actual routing information about the conversation. Since the
actual
routing information, rather than a label, is in the message header, the MSH
does
not have to keep the conversationId and mapping information int he
persistent store.
I am looking for another way -- say a new set of ordered messages could
include
the start number so the Receiving MSH does not have to keep messages past
persistDuration?
MWS: I think that it has already been pointed out that the whole
last-ordered message
does not have to be saved in its entirety until the next in-order message
arrives; only the
conversationId, last ordered sequence number, and a few other header things
have to
be saved.
I don't know the solution but I think MessageOrder is broken.
IMO, keeping information in persistent store forever is not the right
answer,
MWS: Again, mostly not forever since most conversations end.
but I will go with that if it will get us past this problem.
David.