[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
Ralph,
I hope you are right. I can offer one edge case, however, but it is only a
Research prototype.
When we did our BPF prototype (runtime for B2B using tpaML), we did an
exercise with OBI. We created a tpaML instance for OBI. However, OBI does
not (or at least did not) have the concept of a conversationId in the
header. So, we used the purchase order number to represent the unit of
business. The PO number is in payload as far as our middleware prototype
was concerned, so at the middleware level, there appeared to be a single
endless conversation. Granted, we might have found a way to do this by
introducing a concept of "no conversation". In any case, that was what led
me to suggest that there might be edge cases of legacy software that behave
like a single never-ending conversation. I hope that those edge cases
never turn up but from the viewpoint of conversationId, it doesn't matter
because a conversation can run longer than persistDuration and I am not
sure that "infinitely long" would have to be handled any differently from
"very long".
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
*************************************************************************************
Ralph Berwanger <rberwanger@bTrade.com> on 12/06/2001 10:12:32 AM
To: ebxml-msg@lists.oasis-open.org
cc:
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Marty,
Speaking from the legacy community point-of-view, we have been
discussing the fact that each EDI interchange (set of purchase orders)
would be a unique conversation. I cannot recall a single discussion
where the concept of a never-ending conversation came up (except for a
couple standards bodies but that is a different subject all together).
That does not mean that you are not correct in the assumption, only that
it appears contrary to my experience. Also, I said that I do not
'recall' and that can provide some hints to my baseline.
Ralph
ASC X12, Vice Chair
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Thursday, December 06, 2001 9:05 AM
To: David Fischer
Cc: Christopher Ferris; Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
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.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, December 05, 2001 10:21 AM
To: David Fischer
Cc: Christopher Ferris; Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Some 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 09:59:17 AM
To: Martin W Sachs/Watson/IBM@IBMUS, Christopher Ferris
<chris.ferris@sun.com>
cc: Dan Weinreb <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about
ConversationId
Shimamura-san's modification of Marty's words (edited version):
When messageOrderSemantics is set to "Guaranteed", the Receiving MSH
shall preserve in persistent storage all required SOAP Header
information, including SequenceNumber, needed to keep the
Message Order semantics of the last message in the conversation
sent in order to the application until either a subsequent
in-order message arrives or until the conversation ends
(no matter how long the conversation exists).
The Receiving MSH shall preserve in persistent storage the
ConversationId of an in-progress conversation until that conversation
ends (no matter how long the conversation exists).
MWS: I still think that a non-normative reminder is needed that these
holding
times might exceed the value of persistDuration
Does this meet everyone's requirements? I think we will get some flack
since
this guarantees slow accumulation of old ConversationIds in persistent
Storage.
MWS: You can't avoid accumulating old conversationIds since a
conversation
can last a long time. The conversationIds will eventually be purged as
each
conversation ends. A never-ending conversation will only contribute one
conversationId, so it shouldn't be a big deal.
In the second paragraph, do we need to say Conversations with
messageOrderSemantics set to "Guaranteed"?
Do we need messageOrderSemantics? If MessageOrder is present, why would
messageOrderSemantics ever be "NotGuaranteed"? The problem is
MessageOrder
tied
to ConversationId. MessageOrder is a very time limited situation while
ConversationId can be unlimited -- not a good match.
MWS: As long as the sequencing is within a conversation, that's the way
it
is.
If you try to do message ordering over the entire stream, you need
sequence
numbers across the entire stream and you are spinning your wheels
ordering
message that have no functional time relationship to each other.
Regards,
David.
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Wednesday, December 05, 2001 8:08 AM
To: Christopher Ferris
Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
You need to say enough in the MSG spec to inform an implementer that
persistDuration follows different rules for conversationId and
last-ordered-message than for reliable messaging. Considering the
amount
of discussion we have had on this point, we cannot assume that a
"reasonable implementer" will know what to do. There are plenty of
examples
in the newspapers about deadly mistakes made by reasonable implementers.
The Risks Forum mut be full of them.
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
************************************************************************
********
*****
Christopher Ferris <chris.ferris@sun.com> on 12/04/2001 09:39:42 PM
To: David Fischer <david@drummondgroup.com>
cc: Martin W Sachs/Watson/IBM@IBMUS, Dan Weinreb
<dlw@exceloncorp.com>,
ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about
ConversationId
The thing I have trouble with here is why we have to say anything
in the spec. This is too suggestive of implementation detail
IMO (although probably accurate). Why do we need to say anything
about this at all?
Cheers,
Chris
David Fischer wrote:
> OK, I think that will work, but it is not the whole message which
needs
to be
> saved. Once the message is delivered to the application, just the
MessageId,
> CPAId, persistDuration, ConversationId, SequenceNumber (did I get
everything?)
> need to be saved. The spec says now only the MessageId needs to be
saved
but
> that's not enough for MessageOrder.
>
> David.
>
> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, December 04, 2001 5:01 PM
> To: Christopher Ferris
> Cc: David Fischer; Dan Weinreb; ebxml-msg@lists.oasis-open.org;
> ebxml-cppa@lists.oasis-open.org
> Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
>
> Then it should only be necessary to add to the MSG spec words that
say:
>
> The MSH shall preserve in persistent storage the last message in
the
> conversation that was sent in order to the application until either
a
> subseqent in-order message arrives or until the conversation ends
> (regardless of how long that takes). These words probably should be
> modified if preserving some header information is all that is
needed.
>
> The MSH shall preserve in persistent storage the conversationId of
an
> in-progress conversation until that conversation ends (no matter
how
> long that takes).
>
>
> No change is needed to the CPPA spec unless it now does not say that
> persistDuration is the mininum length of time... (see Chris' words
below).
>
> 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
>
************************************************************************
********
> *****
>
>
>
> Christopher Ferris <chris.ferris@sun.com> on 12/04/2001 05:46:11 PM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: David Fischer <david@drummondgroup.com>, Dan Weinreb
> <dlw@exceloncorp.com>, ebxml-msg@lists.oasis-open.org
> Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about
ConversationId
>
>
>
> right now, the spec suggests #1 which is that pd is the
> minimum length of time that a party will commit to
> preserving a message (or its relevant artifacts) in
> persistent store for purposes of filtering duplicate
> messages.
>
> Cheers,
>
> Chris
>
> Martin W Sachs wrote:
>
>
>>One of these possibilities:
>>
>>1. If the MSG spec states that persistDuration is a minimum length of
>>
> time,
>
>>then all you need is to add words to the MSG spec conveying additional
>>rules when message ordering is in effect.
>>
>>2. If the MSG spec states that messages that live until
persistDuration
>>MUST be discarded right away, then we probably need additional text in
>>
> both
>
>>the MSG and the CPA spec.
>>
>>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 02:39:43 PM
>>
>>To: Martin W Sachs/Watson/IBM@IBMUS
>>cc: Dan Weinreb <dlw@exceloncorp.com>,
ebxml-msg@lists.oasis-open.org
>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about
ConversationId
>>
>>
>>
>>Yes Marty, absolutely. I think there are potential problems
(discussed
>>below)
>>which make MessageOrder quite fragile. I am shuddering over the
thought
>>
> of
>
>>changing the persistDuration rules depending upon whether or not
>>MessageOrder is
>>present (wouldn't this constitute a CPA override!).
>>
>>I still like your other solution.
>>
>>Regards,
>>
>>David Fischer
>>Drummond Group.
>>
>>-----Original Message-----
>>From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
>>Sent: Tuesday, December 04, 2001 10:50 AM
>>To: David Fischer
>>Cc: Dan Weinreb; ebxml-msg@lists.oasis-open.org
>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>
>>
>>
>>Some comments below.
>>
>>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:16:21 AM
>>
>>To: Dan Weinreb <dlw@exceloncorp.com>
>>cc: ebxml-msg@lists.oasis-open.org
>>Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about
ConversationId
>>
>>
>>
>>Dan, did you mean to imply that messages are no longer stored once
they
>>
> are
>
>>acknowledged? This is not the case. Messages must be stored longer
than
>>persistDuration. In your scenario, when 12 got to the Receiving MSH,
>>
> 1-10
>
>>are
>>still in the store. If you wait so long that 1-10 have passed
>>persistDuration,
>>then I think you have waited so long that it does not matter any more.
>>
>>I see your point about what happens if there is nothing in the store
and
>>the
>>Receiving MSH gets a message with a number larger than 1. However,
this
>>implies
>>the last ordered message/MessageId (which has been delivered in order)
>>
> must
>
>>be
>>stored indefinitely (forever?) which is probably not acceptable.
>>
>>MWS: For most conversations, there will be an indication of an end,
at
>>which time
>>the last ordered message can be discarded. I guess if storage is
tight,
>>you
>>only need to keep the sequence number and conversationId of the last
>>ordered message
>>
>>
>>This also
>>points out the conflict between Message Order and persistDuration.
What
>>
> if
>
>>messages 1,2,3,4 have persistDuration of 2 days. Messages 1,2,4 are
>>delivered.
>>The MSH hands 1,2 to the application but holds 4. For some reason, 3
is
>>not
>>delivered for 3 days. In this case 3,4 have already passed
>>
> persistDuration
>
>>so
>>they are not delivered. The next day, 5 is delivered. Since 3,4 were
>>
> not
>
>>delivered, then 5 cannot be delivered (nor any subsequent messages)
even
>>though
>>it is still within TTL, and the ordering is forever broken for this
>>ConversationId. We may have to say Message Ordering does not work if
any
>>message in the order fails to be delivered within its persistDuration
(or
>>maybe
>>TTL)? Of course, all this can be adjusted at run time by increasing
the
>>value
>>of persistDuration in the CPA. Once again, MessageOrdering is based
on
>>persistDuration.
>>
>>MWS: All of which says that some additional rules are needed on
>>
> discarding
>
>>messages
>>in the presence of ordering. The last ordered message cannot be
>>
> discarded
>
>>until
>>either the next message in the sequence arrives or the application
ends
>>
> the
>
>>conversation,
>>regardless of its persist duration. Similary, if there is a gap in
the
>>sequence numbers,
>>all the out of sequence messages must be preserved, regardless of
>>persistDuration,
>>until they can be delivered. The MSG or CPPA specification must
provide
>>advice on
>>how long to set persistDuration depending on what combination of
reliable
>>messaging
>>and ordering is being used.
>>
>>I am wondering why are we messing with all of this? Did I see Marty
>>suggest, if
>>messages are order dependant, just wait for acknowledgment from the
end
>>before
>>sending the next message? Sounds good.
>>
>>MWS: Ahhh... the light begins to dawn.
>>
>>Regards,
>>
>>David.
>>
>>-----Original Message-----
>>From: Dan Weinreb [mailto:dlw@exceloncorp.com]
>>Sent: Monday, December 03, 2001 9:40 PM
>>To: david@drummondgroup.com
>>Cc: rberwanger@btrade.com; ebxml-msg@lists.oasis-open.org
>>Subject: Re: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>>
>>
>> Date: Mon, 03 Dec 2001 20:30:08 -0600
>> From: David Fischer <david@drummondgroup.com>
>>
>> If there
>> are no messages in the persistent store pertaining to a
conversation,
>> then
>>there
>> is no need to store it any longer for the purposes of maintaining
>> message
>>order.
>>
>>I'm not sure that would work. Suppose two parties establish a
>>conversation with ID 5551212. Party A sends messages numbered 1
>>through 10 to Party B, and party B's application reads all the
>>messages and acknowledges them, so that there aren't any messages
>>still waiting to be delivered to B. Now a message arrives at B with
>>conversation ID 5551212 and a sequence number of 12. The MSH at B's
>>end has to realize that is should not deliver this message to the
>>application because message 11 hasn't arrived yet. So the MSH at B's
>>end has to be storing somewhere the fact that the most recent message
>>delivered to the application from conversation 5551212 is 10.
>>
>>-- Dan
>>
>>
>>
>>----------------------------------------------------------------
>>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>
>
>
>
>
> ----------------------------------------------------------------
> 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>
----------------------------------------------------------------
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>
----------------------------------------------------------------
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