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