RE: [ebxml-cppa] RE: [ebxml-msg] A proposal fortheinterpretationofdifferent synchronous reply modes in the CPP/A

[David Fischer <david@drummondgroup.com>]

Thanks Dale,  I am not really worried about a single connection staying open.  I
am more worried about a chain staying open:

	A ==> B ==> C ==> D

All these have to stay open waiting for a response?  Looks like trouble.  The
single-hop case does not cause me any heart-ache.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Tuesday, October 16, 2001 9:01 AM
To: David Fischer; Dan Weinreb; arvola@tibco.com
Cc: ebxml-cppa@lists.oasis-open.org; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-cppa] RE: [ebxml-msg] A proposal for
theinterpretationofdifferent synchronous reply modes in the CPP/A


David Fischer writes:

"I also think the default for syncReply should be true, but for MSH
signals, not
for business replies.  Actually, all that needs to happen is for the MSH
signals
to come back with the HTTP 200 OK.

The need to hold the connection for business signals/response is in the
CPA, not
the value of syncReply. There is only the need for syncReply to match
syncReplyMode.  Some coordination is going to have to be built which
holds MSH
signals while waiting for business replies and then matches them with
business
replies *to the same message*.  This could get complicated.  I think
this means
that the From Party MSH doesn't even get the 200 OK until the business
signals/response are ready.

As I have said before, the thought of a chain of connections, through
multiple
nodes, remaining open waiting for the end to generate a business
response, makes
me *very* uncomfortable.  When I couple that with Dale's response
yesterday on
the call, I think this is disaster.  (Dale said that if the connection
drops for
any reason, the Sender has to start over rather than having the To Party
proceed
non-synchronously -- I think this won't work).

Perhaps we need to promote synchronous MSH signals and asynchronous
business
signals/responses."

David,

I do not think it is our duty to specify
a supposed best current practice
nor try to promote some particular option.
If trading partners do not batch
up orders, then their traffic pattern may
consist of small (1-10-100 KB) messages.
The latency wait for a response may be small
in that situation. Why try
to create a one-size-fits-all protocol
(determined by the worst case you
can dream up)? By the TCP specification,
a TCP connection, once made, is to stay open
until it is closed. People will tend not
to use web server implementations for
b2b messages if those servers arbitrarily
close connections. I think you
are reading in way too much into the HTTP
spec's remarks that clients should
be able to deal with a close from the
server. An overloaded server might be
designed to drop connections, refuse
new ones, or any other blend of behavior.
If using a server for b2b, dropping
connections would not be a good design choice,
and it need not be made. For GETs on
static HTML files, dropping might be
acceptable, though I would prefer throttling
back on connections accepted.

If an asynchronous transfer died in the middle, you
would have to retransmit it. In general, nothing we
adopt at this ebXML protocol level
will prevent a possibility of communications
failure. In practice, a dropped
connection may reflect an underlying disk
full situation on the receiver side.
How would fiddling with synch/asynch help that situation?

As far as holding connections open
while a response is generated, this is
a massively commonplace operation.
If you have done a search, then you
have sent data that needed a backend
database operation of some sort
to obtain the HTTP reply. Is that
something we think is too hard
for b2b implementers? And if the
problem is really that people need to use
800 GB files, and they need to wait
until 3 AM next Saturday until the JCL gets run,
suggest using a protocol with
checkpoint/restart, or some other
chunking mechanism! (Fed Express?)
If the problem is
with N intermediaries along the way,
go direct! And so forth.