OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[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"


Title: Message

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]