[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 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC