Re: no synch vs asynch indicator in CPP/CPA

[christopher ferris <chris.ferris@east.sun.com>]

Dale,

While it is quite true that in some cases, a synchronous
request/response can be faster because the overhead
of establishing new TCP connections. One must also
factor in the uncertain nature of the Internet
and distributed network computing into the equation. 

The fact is that a LOT can happen in that millisecond
and this then has implications on how each endpoint
needs to be prepared to deal with the inevitable
failure of a request or response to be received by
either endpoint.

Since the network can fail at any point, from the
sender's perspective, not receiving a response could
mean:
	- the request never made it to the requestee
	and was not processed
	- the request DID make it to the requestee 
	but due to a failure, was not processed
	- the request DID make it to the requestee
	and was processed, but the response was lost
	or never sent

The sender CANNOT know the nature of the
failure, as they are all perceived identically from the
sender's perspective. 

Thus, from either perspective, the request needs to
be treated as if it never happened. This is quite 
difficult when dealing with resources that are
outside of the control of a single authority. Even
two and three phase commit falls apart in this regard.

In the context of a synchronous exchange, the request
needs to have the property of idempotence. The same
request results in the same response with no side-effects
that are different than those which would have ensued
had there been only one request processed.

Of course, your point of "all things being equal"
needs to come into play as well. The fact is that 
very rarely are "all things equal". Efficiency is 
may be predicated on how many messages can be processed
in a given period rather than on how quickly
ONE message can be processed. Some messages may take 
far longer than others. Allowing for aynchronous messaging 
can provide for the possiblity that MORE messages can be 
processed over time by multithreading the processing
of the messages.

Note also that asynchronous does not necessarily
imply connection overhead. Certainly, some protocols
would suffer from overhead of establishing a response
session. However, a connection can be made to
support full-duplex asynchronous exchanges just 
about as easily as it is to make it half-duplex.

Cheers,

Chris

"Moberg, Dale" wrote:
> 
> 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
> >
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard