OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [ebxml-cppa] RE: [ebxml-msg] A proposal fortheinterpretationofdifferent 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
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
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
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
non-synchronously -- I think this won't work).

Perhaps we need to promote synchronous MSH signals and asynchronous


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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC