RE: no synch vs asynch indicator in CPP/CPA

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

Stefano

I agree that the whole sync/async question is a very grey area.  In tpaML,
we provided for both sync and async business transactions in the same TPA.
For such cases, the infrastructure can do either one, so it must be
something up in the business process that cares. However your points about
it being a technology issue are also valid.

I am concerned about references to "almost real time".  Use of "real time"
to mean "fast" is a serious corruption of its meaning.  "Real time" relates
specifically to meeting real-world deadlines.  It is not necessarily fast
or slow.  Also multiple real time processes may have to work together and
to ensure that all meet their deadlines, some may have to deliberately not
run too fast or they may cause other processes to miss their deadlines.
So, "real time" in general is not an issue for B2B or ebXML.

As to "fast", a sync business transaction is not necessarily fast.  Whether
the or not the communications is fast, the server processing the request
message may still be slow.  That of course reinforces the question of why
the BP should care about sync/async.

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



"Stefano POGLIANI" <stefano.pogliani@sun.com> on 01/29/2001 08:17:27 AM

To:   Martin W Sachs/Watson/IBM@IBMUS, "Duane Nickull"
      <duane@xmlglobal.com>
cc:   "christopher ferris" <chris.ferris@east.sun.com>,
      <ebxml-tp@lists.ebxml.org>
Subject:  RE: no synch vs asynch indicator in CPP/CPA



There is something that plays (in my mind) against the idea that sync/async
would be a BP matter.

Perhaps I am wrong, but if by "BP" we mean the modelling of a given
exchange
(business process), I would be surprised that business analysts (which, in
my mind, are the ones who actually define business processes) would really
care about sync or async. Furthermore, seems to me that the discussion that
went on in this thread assumes that the BP modeller would actually know the
implementation technology. Wouldn't this be "against" the rules of
reusability?

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.

If the BP "assumes" (could it prescribe something like this??) that the
exchange is "almosty real time, then it will be up to the parties to try to
use the best technology to fit this requirement, it cannot be imposed by
the
BP. So, if I only have SMTP, I could try to arrive as close as I can to the
"real time" but I know that I will never arrive; nonetheless, if I find a
partner who is happy with that, I am ok.

This mirrors in some way a similar thread on multi-hop from the TRP. If the
only mean I have is HTTP and a Browser, I would never be able to receive
multiple acks for the same request, unless I find an escape somewhere. But
if the two partners agree on "cutting" some part, why not?

Does this make sense? As said, it is more a brainstorm rather than a final
opinion.

/stefano

» -----Original Message-----
» From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
» Sent: 23 January 2001 21:30
» To: Duane Nickull
» Cc: christopher ferris; ebxml-tp@lists.ebxml.org
» Subject: Re: no synch vs asynch indicator in CPP/CPA
»
»
»
» I may be repeating what I just said in my response to Chris but let me
try
» it again.
»
» The question is, why would Sync ever be used?  Possibilities:
»
»    1.  For whatever reason, the business process decides that it must
»    receive a sync reply to a request, so it specifies sync in one way or
»    another and the result is that the other party is forced provide a
sync
»    receive capability, meaning that it must receive requests with HTTP
and
»    send the replies synchronously (in the response to the POST). An
example
»    of this case is where the BP that sends requests is a browser and has
no
»    async receive capability.
»
»    2. The BP that receives requests has no capability for sending
»    asynchronous replies. But this is backwards.  If it is receiving
»    requests, it has server-type function and surely is capable of sending
»    asynchronous responses.
»
» Notice also that the delivery channel defines receive capabilities.
» However for such a delivery channel a sync/async attribute is really
» describing response-sending capabilities, not receive capabilities.  I'm
» not sure this matters but there may be a comprehensibility issue for the
» standard here.
»
» My conclusion is that it is the BP which cares whether the response is
» synchronous or asynchronous although the only obvious example I can think
» of is where the BP is actually a browser.  I'm not sure whether that
makes
» it an implementation matter but it's still the BP characteristics that
» count.
»
» One CPP-structural problem with putting the sync/async choice inside the
BP
» is that it is not clear to me how to convey that information to the rest
of
» the CPP or CPA, which is  a separate document.  Can the value of an
» attribute in the BP document be conveyed back to the CPP or CPA and used
to
» choose the correct delivery channel or is this a case where the CPP
writer
» has to know that certain messages must be synchronous and set the service
» bindings accordingly?
»
» 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
» ******************************************************************
» *******************
»
»
»
» Duane Nickull <duane@xmlglobal.com> on 01/23/2001 02:46:41 PM
»
» To:   christopher ferris <chris.ferris@east.sun.com>
» cc:   "ebxml-tp@lists.ebxml.org" <ebxml-tp@lists.ebxml.org>
» Subject:  Re: no synch vs asynch indicator in CPP/CPA
»
»
»
»
»
» christopher ferris wrote:
»
» > The distinction as I see it is that the BP should be
» > independent of an implementation, but an implementation
» > that supports a BP would be engineered so as to provide for
» > either response pattern according to its needs.
» >
» > Comments?
» >>>>>>
» Chris:
»
» YOu make some very good points and I fully concur that the synch/asynch
» details belong in the CP*
»
» The BP should remain agnostic to certain delivery details.
»
» Duane Nickull
»
»
»
»