ebxml-tp message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: no synch vs asynch indicator in CPP/CPA


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.



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"
cc:   "christopher ferris" <chris.ferris@east.sun.com>,
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
(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

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


 -----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
 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
    receive capability, meaning that it must receive requests with HTTP
    send the replies synchronously (in the response to the POST). An
    of this case is where the BP that sends requests is a browser and has
    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
 it an implementation matter but it's still the BP characteristics that

 One CPP-structural problem with putting the sync/async choice inside the
 is that it is not clear to me how to convey that information to the rest
 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
 choose the correct delivery channel or is this a case where the CPP
 has to know that certain messages must be synchronous and set the service
 bindings accordingly?


 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?

 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC