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

[David Fischer <david@drummondgroup.com>]

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.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Monday, October 15, 2001 10:14 PM
To: arvola@tibco.com
Cc: david@drummondgroup.com; ebxml-cppa@lists.oasis-open.org;
ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-cppa] RE: [ebxml-msg] A proposal for the
interpretationofdifferent synchronous reply modes in the CPP/A


   Date: Fri, 12 Oct 2001 10:43:30 -0700
   From: Arvola Chan <arvola@tibco.com>

   I suppose you are saying that the default for syncReply should be True. If
   the transport is SMTP, syncReply is not applicable. If the transport is
   HTTP, then by default the business response should be returned
   synchronously.

(By "returned synchronously" here we mean "returned within the HTTP reply".)

Really?  I thought that some business responses often take so long
that you really would not want to hold an HTTP TCP connection open for
that long.  For example, what about a business request that can only
be satisfied when some human being performs some interaction: the
business reply might not be ready for a long time.  (Or am I
misunderstanding and business replies never take that long?)

Of course, it's not that important which value is the default value,
if you can always set the vale explicitly when you want to...