Re: no synch vs asynch indicator in CPP/CPA

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

Chris,

This one is on my list. I had decided to hold off to see what TRP specifies
for sync.

In tpaML, sync/non sync is an attribute of <Action> (meaning it is in the
collaboration protocol) and the words in the spec say that sync means that
the response is returned on the connection created by the request and that
therefore the delivery channel must include HTTP since HTTP is the only
supported protocol that is capable of synchronous as defined above.  Our
assumption was that if you have an HTTP implementation, it can do either
sync or async, so putting the specification in the BP area does not
constrain the implementation except that sync requires HTTP.

We can make it an attribute of the delivery channel, which would mean that
if both sync and non-sync messaging are performed under the same CPA, the
CPA would have to contain a delivery channel for each (perfectly
reasonable).

It seems to me, though, that it is still the collaboration protocol that is
the one that decides whether to use sync or async for a given business
transaction.  The advantage of doing by putting the sync/async attribute in
the delivery channel and binding sync delivery channels to the business
transactions requiring sync is that the chain is explicit in the CPP/CPA
XML document whereas in tpaML, the link is made through specification text
only.

It isn't clear to me where the sync/non-sync indicator belongs.  My first
thought is that it should be an attribute of the Protocol element, valid
only when the protocol is HTTP (not clear a parser can validate this
choice). On the other hand, this attribute really describes how HTTP is to
be used, which argues that it should be higher up in the stack at a point
corresponding to the point in the implementation where the decision is made
to return the response in the response to POST (sync) or as a POST in the
other direction (async).  Is that DocExchange or DeliveryChannel, or in
fact is it an attribute of the business transaction after all?

In any case, let's hold off on this until TRP finishes defining sync.

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>@east.sun.com on 01/23/2001
02:01:16 PM

Sent by:  Chris.Ferris@east.sun.com


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



With the removal of the BusinessProtocol and its children
from the tpaML 1.0.6 in our CPP/CPA DTD, we have lost the
ability to attribute synchronous versus asynchronous characteristics
of a delivery channel.

Presently, the BPM specifies synch versus asynch, but IMHO, this
is the WRONG place to specify such a thing as it imposes a
constraint on an implementation.

Rather, I think that a delivery channel and/or the
transport should be declared as having synch or asynch
characteristics.

This is related to Dale's concerns and (hopefully) investigation
as to the capabilities of the sender which I believe
should also capture some aspect of the synch vs asynch nature
of the initiating (sending) Party's delivery channels.

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?

Cheers,

Chris