[cam] FWD: RE: Use of pre- and postconditions / inconsistencies inspec?

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

Just an FYI here - on some interesting interchange
today on the CEFACT BPSS side.

I had no idea they had backed themselves into a
corner on this one!

I will let every know if they decide to make
an implementation note in V2.0 BPSS on this
approach.

DW.

-------------Forwarded Message-----------------

From:	"UN/CEFACT TMG Business Processes WG", INTERNET:uncefact-tmg-bpwg@listman.disa.org
To:	"UN/CEFACT TMG Business Processes WG", INTERNET:uncefact-tmg-bpwg@listman.disa.org
	
Date:	3/11/2003  3:22 PM

RE:	RE: Use of pre- and postconditions / inconsistencies in spec?

 
JJ,

I did not realize this was an issue - so good this came up!

An alternative here is to push this logic down into the 
business transaction layer.  So that the business transaction 
layer returns a "True / False" response, plus an optional
error status - back up to the BPSS layer.  This certainly
allows the BPSS to continue to operate with that binary logic 
approach - and then the ebMS layer can carry the error
response back to the sender.  

Also - then the overall process status stuff is carried at the 
application layer - on which its going to be highly dependent,
and  where I'd say it makes most sense - instead of the BPSS
having to provide tracking mechanisms.

Better yet - from the CPA / BPSS interface perspective - 
you need only note that the error response mechanism
needs to be supported.

I would also note that the OASIS CAM mechanism already
fully specifies this behaviour - and can access context
variables from the BPSS layer to further facilitate this 
(and those context values can get passed thru from the ebMS
layer - on a URL if necessary).

Also - by inspecting the validation section in the CAM
template that your partner is using - you can see exactly
the end condition checks and business rules.  Part of the
CPA agreement requires alignment on those transaction
business rules anyway - so this IMHO makes an excellent
fit.

Check out the latest draft at:

 http://cam.swiki.net/14

and see the section on transaction validations and the
context variables.

Thanks, DW.
============================================================
Message text written by "UN/CEFACT TMG Business Processes WG"
>
One of the major issues is that there is no official syntax for such
conditions. Another one is that they allow to specify unilateral
specifications, a party could specify that a purchase needs to be
approved before it can be sent out but that "state" is unreachable by
the other party which has no way to know if the order was approved
before it can decide whether it is valid to receive the purchase order.

In the final 2.0 version, the plan (that needs to be discussed) was to
limit the scope of pre/post conditions as annotations (e.g. if I send
you a PO, it means that this PO was improved internally). In particular,
it is forbidden to express choreography constraints based on them. The
only way to specify choreography in 2.0 would then be transitions
between BTAs and condition expressions on the transitions based on the
content of the documents or the type of documents exchanged during the
collaboration.
<