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 proposalfortheinterpretationofdifferent synchronous reply modes in the CPP/A

David and Dale:

How MSH level signals are returned when the HTTP binding for SOAP is used
for sending ebXML messages is still an interlocked ebxml-msg and ebxml-cppa

Either the messaging spec has to state that MSH level signals are always
returned in the same HTTP connection that is used to carry the incoming
message and optionally batched with business level signals/response as
called for in the CPA, or the CPP/A spec needs to introduce an additional
syncReplyMode to cause MSH level signals to be returned synchronously.


-----Original Message-----
From: David Fischer <david@drummondgroup.com>
To: Dale Moberg <dmoberg@cyclonecommerce.com>; Dan Weinreb
<dlw@exceloncorp.com>; arvola@tibco.com <arvola@tibco.com>
Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org>;
ebxml-msg@lists.oasis-open.org <ebxml-msg@lists.oasis-open.org>
Date: Tuesday, October 16, 2001 7:22 AM
Subject: RE: [ebxml-cppa] RE: [ebxml-msg] A proposal
fortheinterpretationofdifferent synchronous reply modes in the CPP/A

>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.
>single-hop case does not cause me any heart-ache.
>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
>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