Re: no synch vs asynch indicator in CPP/CPA

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

Hmmm, I have never heard of BEEP.  Is that a stand-in for another
four-letter word?  :-)

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



christopher ferris <chris.ferris@east.sun.com>@volcano.East.Sun.COM on
01/29/2001 04:22:37 PM

Sent by:  cferris@volcano.East.Sun.COM


To:   ebxml-tp@lists.ebxml.org
cc:
Subject:  Re: no synch vs asynch indicator in CPP/CPA



Dale,

I am not disputing that there are circumstances
that may warrant a synchronous exchange (blocking
on a half-duplex communication protocol).

What I was arguing is that synchronous != speed.

Certainly, when a client is either incapable of,
or unwilling to listen on a socket for connections,
it does tend to preclude asynchronous exchanges
where the sender of a response has to initiate the
connection. However, this only serves as a reason
why there is growing interest in protocols such as
BEEP.

HTTP simply wasn't designed for messaging;-)

Cheers,

Chris

"Moberg, Dale" wrote:
>
> Well, if speed is irrelevant, and
> being a user in front of a keyboard
> is irrelevant (and I disagree about
> these relevancy assertions, by the
> way), there remains one factor that
> will be hard to massage away. If the
> originator refuses to listen on a
> TCP port, then using the reply to
> send back data on the open connection
> might be a good way to return data
> and also provide
> a good reason to implement a
> "synchronous" response (reply
> on same connection as request).
>
> Of course, you could have the originator
> poll for a response, as with message
> store solutions (POP3 and IMAP, eg.)
> but that solution space has a number
> of drawbacks so that polling interval
> is increased and that results in slowing
> down when the response is actually
> received...oops I wasn't going to
> mention speed...
>
> Keeping the connection open for a pipeline
> was one main difference between HTTP 1.0
> and HTTP 1.1. BEEP also reduces the
> number of open connections needed
> for traffic between hosts.
> Don't these design changes
> indicate that a number of people consider
> connection overhead a significant
> factor in protocol design and
> are considering ways to reduce it?
>
> > -----Original Message-----
> > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Monday, January 29, 2001 3:12 PM
> > To: ebxml-tp@lists.ebxml.org
> > Subject: Re: no synch vs asynch indicator in CPP/CPA
> >
> >
> > 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
> > > > >
> >