RE: no synch vs asynch indicator in CPP/CPA

[Dick Brooks <dick@8760.com>]

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