[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: minutes 21-Dec-2000 tr&p con-call
Doug,
See my replies embedded 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
*************************************************************************************
Doug Bunting <Doug@ariba.com> on 12/27/2000 06:59:44 PM
To: "'Burdett, David'" <david.burdett@commerceone.com>, "'SHIMAMURA
Masayoshi'" <shima.masa@jp.fujitsu.com>, "ebXML Transport (E-mail)"
<ebxml-transport@lists.ebxml.org>
cc: IWASA Kazunori <iwasa@fs.fujitsu.com>, Jacques Durand
<jacques@savvion.com>
Subject: RE: minutes 21-Dec-2000 tr&p con-call
Since I entered the original comment, it's about time for me to weigh in on
this topic.
We have a well-proven mechanism for duplicate detection (message
identifiers). Providing a second mechanism for the same purpose simply
confuses the specification and will result in solutions that can't
interoperate. We should not mention use of sequence numbers for duplicate
detection except (possibly) in non-normative material. I recommend that we
don't mention this confusion at all.
The history of the sequence number issue seems long and involved. However,
I haven't heard us address one primary underlying issue: In-order delivery
of messages is not a requirement of the TRP. The need to deliver portions
of a transaction in a particular order generally revolves around the
ordering of documents within a specific conversation.
MWS: I agree.
That is, it happens
at a higher level than the point-to-point or end-to-end From / To
relationship (which may include many simultaneous conversations). Ordering
of all messages within those relationships is unnecessary and runs counter
to our stated requirement to keep it simple. If these semantics should be
provided by the TRP framework, we should provide them on a per-conversation
basis.
Assuming we decide to satisfy this new TRP requirement, David's approach
would work as long as messages with sequence numbers do not prevent
delivery
of other reliable messages between the same two parties. I'd recommend
going one step further and scope the sequence number to the conversation
identifier, making the level for its use explicit.
MWS: This makes a lotof sense, but see below.
That is, the sequence
number would be required to be unique within the conversation and each
simultaneous conversation would (implicitly?) have a separate sliding
window
to guarantee in-order delivery to the To party.
MWS: I may have lost track of some of RM discussion lately but the last I
knew, the sliding window related to reliable messaging and I think there
will be objections, on complexity grounds, to having a separate sliding
window for each conversation.
CPA properties such as
maximum number of simultaneous conversations would then be required.
Side question(s): Should the conversation identifier (ConversationId) be
scoped within the CPA identifier (CPAId)? Similarly, should the Action be
scoped to the Service which is (in turn) scoped to the To information?
MWS: Personally, I like this kind of scoping because it allows each party
to define its identifiers locally. However I think that we are reopening
the "locally defined vs URI" issue.
Lower-level issues with the current sequence number semantics: The
wraparound algorithm does not guarantee delivery of the last few messages
before starting at 0. The receiver has no way to learn what the highest
number was prior to wrapping around. And, how do these semantics handle
messages that fail due to an incorrect ebXML Header document? Should a
replacement message that corrects the error reuse the previous sequence
number?
thanx,
doug
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: December 27, 2000 09:26
To: 'SHIMAMURA Masayoshi'; ebXML Transport (E-mail)
Cc: IWASA Kazunori; Jacques Durand
Subject: RE: minutes 21-Dec-2000 tr&p con-call
I think that we should include sequence number in the routing header with
the following semantics:
1. The sequence number MUST be used if delivery of payload data to the end
application by the MSH must be in a specific sequence
2. The sequence number MAY be used to identify missing messages, but does
not remove the need for using MessageIds and RefToMessageId to identify
that
a message has been received and for duplicate filtering.
David
-----Original Message-----
From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
Sent: Wednesday, December 27, 2000 2:42 AM
To: ebXML Transport (E-mail)
Cc: IWASA Kazunori; Jacques Durand
Subject: Re: minutes 21-Dec-2000 tr&p con-call
TRP Members,
Here is my comment on the issue about SequenceNumber in the
previous teleconference minutes.
On Thu, 21 Dec 2000 12:51:13 -0500
Christopher Ferris <chris.ferris@east.sun.com> wrote:
...
> Issue 17
> Title - Sequence number
> Detail - 7.10 SequenceNumber as defined adds little or no value over the
> MessageID element required in MessageData. Recommend removing this
section
> and the corresponding references to SequenceNumber in later examples,
the
> DTD and the schema.
The SequenceNumber has two kind of functions:
(1) Guarantee of Message Order
(2) Effective Duplication Check
The MessageID element in MessageData can not realize the two functions
above. Especially, there is no way to guarantee Message Order except for
using SequenceNumber. Because current MS specification has not the
blocking restriction. The Sender can send some messages without waiting
for acknowledgement message. Thus when a communication error and retry
sequence occurs, sent messages will reach the Receiver in invalid order.
To correct the invalid order in the Receiver, the SequenceNumber must be
included in each message.
> If this section remains, must define the exact content of the
SequenceNumber
> element when the numeric value is greater than 999. Is the next value
> "1000" or "1,000"? Is the text for the maximum value "999999999" or
> "999,999,999" or are both allowed (and equivalent)? Side note: Numeric
> formats vary by locale and a comma is not always the thousands
Good comment. I revise description of the SequenceNumber element to
clear this point.
> If this section remains, "long time" should be defined.
I already removed the term "long time" from the RM spec and added
notification function of reset of SequenceNumber to the RM spec. See
following materials:
- Page 14 in the presentation material
<http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00003.pdf>
- Page 3 and 4 in latest RM spec v0-088
<http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00006.pdf>
Both materials were posted to this mailing list on November and
distributed in previous TRP Meeting in Tokyo.
> At least, refer
to
> a TPA which makes this concrete for a specific trading relationship or
> mention later text on this subject (if any).
>
> Proposal - sequenceNumber element is defined as type int
> in xsd,
Good idea. The MS spec v0.9a defined SequenceNumber element as type int
in xsd in schema. Thank you, David.
> members are in general agreement that should be adequate
> to address the typing issue. As to efficacy of SequenceNumber...
> defer/table discussion/resolution of meaningfulness
> of sequence number element to Jan 4th.
> Resolution - vote Jan 4th, incorporate changes into spec during
> Jan f2f
To realize (1)Guarantee of Message Order and (2)Effective Duplication
Check, the SequenceNumber is obviously needed. For the purpose (2), the
SequenceNumber was approved by the TRP Team and then added to MS spec
v0.8. For the purpose (1), Sliding Window with SequenceNumber in latest
RM spec was approved by the TRP Team in previous TRP meeting in Tokyo
(see the schedule
<http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00005.pdf>
created in the meeting). Thus I believe we does not need more vote.
Please merge latest RM spec (v0-088) into the MS spec v0.9a.
History:
- in September, several TRP members strongly requested to remove the
blocking restriction in mailing list and teleconference so that the
Sender can send some messages without waiting for acknowledgement
message.
- as the result of discussion, the TRP Term decided to remove the
blocking restriction in teleconference on 5th October
See:
<http://lists.ebxml.org/archives/ebxml-transport/200010/msg00036.html>
- however removal of the blocking restriction caused two
problems
(1) Message order is not guaranteed
(2) The Receiver can't know required buffer size previously
- So Fujitsu proposed Sliding Window with SequeceNumber to resolve the
problems in this mailing list and the TRP meeting in Tokyo on November
See:
<http://lists.ebxml.org/archives/ebxml-transport/200010/msg00171.html>
<http://lists.ebxml.org/archives/ebxml-transport/200011/msg00017.html>
- In the TRP meeting in Tokyo, Fujitsu's proposal was approved. The TRP
Team decided to merge latest RM spec (v0-084) including Sliding Window
with SequenceNumber into MS spec
See:
<http://lists.ebxml.org/archives/ebxml-transport/200011/pdf00005.pdf>
- Fujitsu modified and posted revised RM spec (v0-088) including Sliding
Window with SequenceNumber on 14th November to include the result of
the discussion in the TRP meeting in Tokyo for integration with MS
spec.
See:
<http://lists.ebxml.org/archives/ebxml-transport/200011/msg00062.html>
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 Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC