RE: TPA and ebXML Header question

[Henry Lowe <hlowe@omg.org>]

Dale,

See comments embedded below:

At 07:53 AM 10/18/2000 -0400, Moberg, Dale wrote:
>
>>Before we go too far in considering what is in scope for MS and 
>>what is out of scope (someone else's problem), I believe we got 
>>into message sequencing because the RM potentially destroys the 
>>sequencing that comes as part of the underlying transport (all 
>>connection oriented transports I can think of give you sequencing 
>>and we haven't seriously consider connectionless, e.g., UDP).  
>
>I do not see that TRP RM in any way "destroys" the sequencing

Correct me if I'm wrong, but I believe we got into this as, if RM 
sends a message and it doesn't arrive, it sends the message again.
Up to this point, all messages sent are in the sequence they were 
send by the originator of the sequence of messages (thanks to TCP/IP 
or some other transport as you point out below).  However, when 
something goes wrong and a message doesn't arrive, RM detects this 
and sends the message again.  This time, however, the message is 
out of sequence.  This is the problem and what I meant by the 
phrase '"destroys" the sequencing' -- I probably should have choosen 
a less blunt way of phrasing this.

Assuming this is correct (as I said, correct me if I'm wrong), in 
giving us a reliable service, RM has also introduced a problem 
which is the subject of this thread.  All I'm saying is that the 
problem should be fixed in the RM spec as it wasn't there before.

I would suggest that what the RM spec does is point out this problem 
and say that the RM Service (which unfortunately doesn't exist as 
we don't have any service specs) fixes this problem -- it is up to 
the implementation to find the best way of fixing it (David Burdett 
mentioned one way of fixing it in the implementation, i.e., buffering, 
but there may be better or at least alternatives). 

>of the underling transport. The TCP sequencing is, sorry,
>about this-- at the network/transport layer, and RM pertains
>to the whole ebXML protocol data unit, offered by the MSH layer,
>that is well above IP and TCP. We don't even "see" TCP sequencing
>at this level and certainly don't alter anything in that layer.

Very true, but we certainly enjoy the benefits of TCP/IP sequencing :-)

Best regards,
Henry

>The sequencing is not sequencing of IP packets
>(TCP does that, end of story)  but of the ebXML messages.
>Mixing apples and kumquats here.
>
>
>
>>If the MS layer has caused the problem, shouldn't we fix it?
>
>You must explain here clearly which problem it is alleged to 
>have caused. 
>
>>(providing a service whose QoS is lower than that of the underlying 
>>service on which it is built, doesn't seem too helpful -- though 
>>there are precedents, e.g., OSI Session [however, OSI is a beer 
>>driven discussion -- not for this list]).
>
>I agree that OSI specifics are history, but what is it that they say
>about people who ignore history? IETF mainly ignores the higher layers
>because those layers were not "bits on the wire" layers. They were
>layers involved in getting the bits off and back on the wires :-)
>These middleware layers just 
>might be relevant to business 
>uses of messaging even
>though they are not "strictly" network layers.
>
>
>