RE: no synch vs asynch indicator in CPP/CPA

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

Well, if speed is irrelevant, and
being a user in front of a keyboard
is irrelevant (and I disagree about
these relevancy assertions, by the 
way), there remains one factor that
will be hard to massage away. If the
originator refuses to listen on a
TCP port, then using the reply to
send back data on the open connection
might be a good way to return data 
and also provide 
a good reason to implement a
"synchronous" response (reply
on same connection as request).

Of course, you could have the originator
poll for a response, as with message
store solutions (POP3 and IMAP, eg.)
but that solution space has a number 
of drawbacks so that polling interval
is increased and that results in slowing
down when the response is actually
received...oops I wasn't going to 
mention speed...

Keeping the connection open for a pipeline
was one main difference between HTTP 1.0
and HTTP 1.1. BEEP also reduces the
number of open connections needed
for traffic between hosts. 
Don't these design changes
indicate that a number of people consider 
connection overhead a significant
factor in protocol design and
are considering ways to reduce it?



> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Monday, January 29, 2001 3:12 PM
> To: ebxml-tp@lists.ebxml.org
> Subject: Re: no synch vs asynch indicator in CPP/CPA
> 
> 
> Dick,
> 
> I think that this use case calls out why the characterization
> of synchronous versus asynchronous exchange belongs OUTSIDE
> of the BPM specification and IN the CPA.
> 
> Of course, I also think that again, that all the wrong
> reasons are being used to establish the requirements
> that the communications be synchronous versus asynchronous.
> 
> Speed of execution should never be a factor IMHO. Nor
> should the fact that I might have a user sitting in front
> of a browser/application necessarily imply a requirement
> for a synchronous message exchange.
> 
> My $0.02,
> 
> Chris
> 
> Dick Brooks wrote:
> > 
> > I agree with Dale's position regarding sync/async. In fact 
> the Energy
> > industry has a requirement for both sync and async 
> responses for the exact
> > same business process (purchase order/nomination), depending on the
> > interface used by a trading partner to launch a 
> transaction. For example, a
> > large Energy company may use EDI (X12) to send a bulk 
> upload of purchase
> > orders whereas a small trading partner would use an online, 
> interactive
> > approach to submit one or two purchase orders. The 
> interactive user expects
> > a response in seconds whereas the bulk user expects a 
> response within 15
> > minutes. The exact same business process is being invoked 
> within the backend
> > application system regardless of whether the data arrived 
> via EDI or an
> > interactive session using web forms.
> > 
> > Of course it's not always a black/white decision. 
> Occasionally a company
> > that normally submits transactions using EDI will use an 
> online/interactive
> > session to submit purchase orders. A case in point is when 
> someone needs to
> > order more energy
> > on a weekend, frequently the transaction is performed using 
> an interactive
> > approach from a home computer.
> > 
> > ebXML must allow trading partners to utilize both modes of 
> operation. It is
> > the trading partner's decision as to which method to use and when.
> > 
> > Dick Brooks
> > Group 8760
> > 110 12th Street North
> > Birmingham, AL 35203
> > dick@8760.com
> > 205-250-8053
> > Fax: 205-250-8057
> > http://www.8760.com/
> > 
> > InsideAgent - Empowering e-commerce solutions
> > 
> > > -----Original Message-----
> > > From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com]
> > > Sent: Monday, January 29, 2001 9:37 AM
> > > To: 'christopher ferris'; ebxml-tp@lists.ebxml.org
> > > Subject: RE: no synch vs asynch indicator in CPP/CPA
> > >
> > >
> > > Message-id:
> > >
> > > <5FD6397E455FD4118BAE000629383540D39288@scidubmsg02.isg.stercomm.c
> > > om.148.168.192.in-addr.arpa>
> > > MIME-version: 1.0
> > > X-Mailer: Internet Mail Service (5.5.2650.21)
> > > Content-type: text/plain
> > > List-Owner: <mailto:ebxml-tp-help@lists.ebxml.org>
> > > List-Post: <mailto:ebxml-tp@lists.ebxml.org>
> > > List-Subscribe: 
> <mailto:ebxml-tp-request@lists.ebxml.org?body=subscribe>
> > > List-Unsubscribe:
> > > <mailto:ebxml-tp-request@lists.ebxml.org?body=unsubscribe>
> > > List-Archive: <http://lists.ebxml.org/archives/ebxml-tp>
> > > List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
> > >  <mailto:ebxml-tp-request@lists.ebxml.org?body=help>
> > >
> > > Though I agree with most of what has been said
> > > about synch, RPC-ike TCP transports, there is a
> > > reason behind people talking about real-time and
> > > fast that is worth mentioning. I agree that "real"
> > > real-time has to do with hard deadlines for completion
> > > and has more to do with OS scheduling than transports.
> > > And perfomance evaluation always has the phrase
> > > "all other things being equal" hanging in the background.
> > > But suppose that servicing a request is on the order
> > > of 1 millisecond average response and we are comparing
> > > a synchronous with an asynchronous transport in the
> > > sense of one using one as opposed to more than one
> > > TCP connection. And finally suppose that the
> > > request setup time is equal in both cases (no good
> > > reason why it would not be). Then synchronous will
> > > be faster because the RTTs (round trip transits)
> > > needed for connection setup (maybe 2 or 3 times
> > > approx 100 to 200 milliseconds) will make a difference.
> > > In other words, when we are looking at subsecond
> > > response issues and examining the components
> > > of latency, then the TCP connection overhead
> > > becomes a relevant factor.
> > >
> > > Normally this factor is totally dominated by
> > > backend latency of response (multisecond to hours)
> > > and so it becomse silly to worry about it for
> > > many b2b integration environments. However,
> > > if humans are waiting for confirmation before
> > > moving on, then subsecond latency issues may
> > > become relevant. My $.02.
> > >
> > >
> > > > -----Original Message-----
> > > > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > > > Sent: Monday, January 29, 2001 10:08 AM
> > > > To: ebxml-tp@lists.ebxml.org
> > > > Subject: Re: no synch vs asynch indicator in CPP/CPA
> > > >
> > > >
> > > > Stefano,
> > > >
> > > > I think you've captured this issue quite well below
> > > > when you say:
> > > > > I am not sure completely, but I am tempted to think that
> > > > the issue of
> > > > > sync/async is just an "accident" of implementation, i.e. it
> > > > is something
> > > > > that gets into the picture at the time the CPP is 
> actually created.
> > > > > Something like:
> > > > >         - do you have a browser? Well, you should use this
> > > > and that...
> > > > >         - do you have something different? Well, in this
> > > > case you can use something
> > > > > else.
> > > > > But always to carry out the same business exchanges.
> > > >
> > > > Of course, it is rarely an "accident" as typically, someone
> > > > asks for the synchronicity inj the application, but usually
> > > > for all the wrong reasons;-)
> > > >
> > > > As Marty points out in his response to this issue, synchronous
> > > > exchanges are neither "real-time" nor are they necessarily fast.
> > > >
> > > > In the B2B space, synchronous exchanges can actually lead to
> > > > significant problems due to the uncertain nature of the
> > > > Internet and distributed network computing in general.
> > > >
> > > > As for a Business Process description/model incorporating
> > > > a notion of synchronous vs asynchronous in the MODEL, I think
> > > > that clearly this is a mistake. What is synchronous or 
> asynchronous
> > > > is an implementation detail that should be described
> > > > at the level of the CPP/CPA in describing the technical
> > > > details of how the messages can be exchanged for a 
> given business
> > > > process that is based on the implementation capabilities
> > > > of the partners, NOT on the description of the business
> > > > process model.
> > > >
> > > > To Marty's point that it is the BP that cares, in truth,
> > > > it is the implementation of the software that effects the
> > > > business process that cares. The BP itself is just a desription
> > > > of the messages that are exchanged, and the constraints
> > > > that are enforced as regards to ordering, pre and post
> > > > conditions, etc.
> > > >
> > > > Cheers,
> > > >
> > > > Chris
> > > >
>