RE: TPA and ebXML Header question

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

We are not talking about TCP or IP.  We are talking about something that is
in between the messaging service and TCP, such as http, IBM MQSeries, SMTP,
or whatever.  In other words, the thing below the messaging service that is
sending multiple protocol data units.  Some instance of that layer will
naturally keep them in the order in which the messaging service presented
them and others won't.

It is within the scope of the messaging service to provide the application
a means of assuring that the protocol data units will not be reordered if
the layer below the messaging service doesn't reorder them and even
enabling compensation for misordering below it. Permitting the application
to block until the messaging service informs it that it has sent the
message is one way.

Regars,
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
*************************************************************************************



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 10/18/2000 07:53:44 AM

To:   "'Henry Lowe'" <hlowe@omg.org>, ebxml-transport@lists.ebxml.org
cc:   Krishna Sankar <ksankar@cisco.com>, mark.hale@ajubasolutions.com,
      Scott Hinkelman/Austin/IBM@IBMUS, Bob Haugen
      <linkage@interaccess.com>, David RR Webber <Gnosis_@compuserve.com>,
      Zvi Bruckner <zvi.b@sapiens.com>
Subject:  RE: TPA and ebXML Header question




>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
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.
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.