Re: no synch vs asynch indicator in CPP/CPA

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

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
> > >
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