[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
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.
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]
|
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.)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]