from out of the past...

[Martin W Sachs <mwsachs@us.ibm.com>]

Dale,

I haven't hear the words "sub-second response time" in a decade.  I'm
afraid you are dating yourself :-)

The concept of sub-second response time seems to have been lost since the
Web came about.  I am lucky if I get sub-minute response time from most web
sites.

Back in ancient history, people at IBM Yorktown did some very important
studies on why sub-second response time is important to people.  IBM took
them seriously and sub-second response time was a key feature in its
360-370-390 systems. It's a shame that all that has been forgotten.

I do agree that sync is useful for any server that can manage sub-second
response time.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Moberg, Dale" <Dale_Moberg@stercomm.com> on 01/29/2001 10:37:19 AM

To:   "'christopher ferris'" <chris.ferris@east.sun.com>,
      ebxml-tp@lists.ebxml.org
cc:
Subject:  RE: no synch vs asynch indicator in CPP/CPA



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
>