RE: [ebxml-bp] beginsWhen, endsWhen, pre- and postConditions, versions 2 and 3, and "executable"

["Yunker, John" <yunker@amazon.com>]

Title: Message

Being able to shared discrete executable syntax for beginsWhen, endsWhen, preCondition, and postCondition are CRITICAL to handling complex business interactions.

 

For instance, the collaboration requires a legal notification of delivery, so it has a "DeliveryNotification" transaction that adheres to the "Notification" pattern (means a legally enforceable receipt ack signal).  However we only want that notification to take place when the signature is available (might mean that the driver must return his devive, although implementation is "visible" to the BPSS).  Note that the BPSS "transitions" to this transaction as soon as the product is shipped, so the B2B software is then waiting for an "event" that will start this transaction.  So far we have insisted on waving our hands as to how this event is specified, however even more important is how to make sure that if multiple backend events must be received, how to know when to start the transaction.

 

Now the message could make the signature required, (in effect push the problem onto the data "cannot start until all data received"), but this makes tie in to the agreement layer VERY difficult (messages are usually reused over several use cases, and XSD isn't very good a context driven rules :-).

 

So, machine decipherable "beginsWhen" is incredibly useful for process-context driven communication, enforcement, and verification of rules related to content driven process conformance.  (a mouthful).

 

Without the ability to specify these rules, we cannot effectively link business requirements to process execution.  (we just assume the partner has a group of business analysts who are reading the text and figuring out how to drive proper triggering of transactions).

 

I would like to see this in the current release (at least as optional, similar to the syntax on the transition guards), however in interest of getting things done I could see waiting to 3.0.  I cannot in any case see "giving up on this" (sorry Dale, no slight intended, used for emphasis only :-)

 

Thanks,

John

 

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Monday, June 14, 2004 9:45 AM
To: ebxml-bp@lists.oasis-open.org
Subject: [ebxml-bp] beginsWhen, endsWhen, pre- and postConditions, versions 2 and 3, and "executable"

Our working drafts currently contain the following information concerning the topics on the subject line.

 

Please review questions in-line, and then also consider the list of questions at the end.

 

 

7.4.4.1

 

Business Transaction Activity and Collaboration Activity may define business rules with the beginsWhen, endsWhen, preCondition and postCondition attributes. These attributes do not have a specific syntax as part of this specification, so the current type is string.

 

 Because these expressions cannot be generally executed by an ebXML infrastructure, in the current release of the ebXML BPSS technical specification, they are considered to have a “documentation” purpose.

 

 In particular they cannot be used to specify any part of the choreography of the collaboration. In future releases they will play a role along with transitions and pseudo-states.

[Is this version 3.0 or are we giving up on this? How would monitoring have to be extended to know about the external events?]

 

The semantics of beginsWhen and endsWhen indicate that the corresponding business activity needs to be started or ended as soon as the expression in the attribute value is true. 

 

PreConditions and postConditions indicate that the corresponding business activity may start only if the corresponding expressions are true.

[ This reads to me that a business activity may start only if the postCondition is true? Is this what is meant?]

 

7.9

 

We have taken great care in this new version of the specification to distinguish what is executable and computable versus general expressions written in text and associated with model elements. In particular, we exclude, beginsWhen, endsWhen, preCondition and postCondition from the responsibility of a BSI.

 [ Will this be true in versions 2.0 and 3.0 also?]

 

beginsWhen	xsd:string			A description of an event external to the collaboration that normally causes this collaboration to commence
endsWhen	xsd:string			A description of an event external to this collaboration that normally causes this collaboration to conclude
preCondition	xsd:string			A description of a state external to this collaboration that is required before this collaboration can commence
postCondition	xsd:string			A description of a state that does not exist before the execution of this collaboration but will exist as a result of the execution of this collaboration [the text needs to be aligned with this description IMO]

 

=====================

 

More Questions

 

1[Align with ebMS]. I proposed that we support monitoring and verification in the implementation of a BSI, and be able to base those computational tasks on an extension of an ebXML MSH to become an ebXML MSH plus BSI monitor. Along with support of graphical editing tools,  and alignment with CPPA, these are the main sources of constraints on us with respect to implementational concerns. These constraints are not to interfere with the main task of spelling out a business state alignment specification notation.

2[Execution]. We are not chartered to create an execution language under OASIS. Editorially I propose that we either remove or very strictly qualify the use of the term "execution." This term creates confusion for implementers who think of execution as running some process.

Perhaps by "execution," we mean"evaluation" or "interpretation". That is, a BSI monitoring and verification tool will have to check documents and statuses (that is what monitoring involves) and relate these "events" to movement from state to state(s) [plural because of nondeterminism presence.] BPSS implicitly contains a declarative (sub) language, and such a thing needs evaluation/interpretation. Is that what we mean by execution? Or is it something else?.

3[Timers]. A BSI also probably has to run timers as part of its monitoring. Since some signals arise from these timers, perhaps the production and consumption of signals is done by the BSI software tool. But business application systems may also want to know and/or control these events, and the BSI monitoring task would be passive with respect to the production of these events. Implementers now face considerable ambiguity when building tools that can flexibly control signals or just observe them. If they control them, how do the business applications themselves get informed about the result of signal processing? If they don't control them, they still must maintain a monitoring apparatus sufficient to determine state alignment status. So, for example, how do they know their timers line up correctly with the business application timers? This problem gets even worse as we move to allow more dynamic timers set by runtime conditions.

4.[Signals in general] Production of signal messages-- is this to be regarded as something a monitor/verifier has to do? Or can the monitor/verifier be independent of this task? It is part of the BSI interface, but is also something applications may in effect control. How do we allow deployment scenarios consistent with the BSI signal production being performed by the business application, rather than the "middleware"? (This question is implicit in issue 3 also.)