RE: from out of the past...

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

I may be a coelacanth of sorts, but human impatience
is a persistent design constraint! And we should
remember that a user in front of a
web interface may be what is waiting
for the b2b conversations to complete...


> -----Original Message-----
> From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
> Sent: Monday, January 29, 2001 11:08 AM
> To: Moberg, Dale
> Cc: 'christopher ferris'; ebxml-tp@lists.ebxml.org
> Subject: from out of the past...
> 
> 
> 
> 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
> >
> 
> 
>