RE: [ebxml-bp] Linking to end states, in particular from within Decision elements

["Moberg Dale" <dmoberg@axway.com>]

 

[Editorial note: Topic concerns the rigor of our classification of states. Both “gateways” and completion states (and start states) were regarded as “pseudo states” The attempt was made to make BTAs or CAs or CBTAs the “real” states between links. So a decision is not really needed for a BTA that simply “goes to” success or failure; condition expressions on the FromLinks for the completion states can indicate the BTA and expression under which the transition is taken. Yet we left an example in that exhibits the early, less strict semantics of allowing transitions to pseudo states.]

 

[Andreas Schonberger issue on

Linking to end states, in particular from within Decision elements]

Decision element and ToLink, in particular link to end state

[ example omitted; see original for full text]

IMHO:
According to the standard the only way to reach Success/Failure seems to be a FromLink in Success/Failure
that references a TransactionActivity.

 

Comment: While it is possible to restrict states to just BTAs, CBTAs, and CAs (thus treating the Start, Success and Failure objects as auxiliary), in practice it is often convenient to regard them as pseudo states and so use them as an object of a Link. In fact, common practice is to allow this “abuse” of notation. Somehow, we never firmly came down on the model of what the States are. Many of the business oriented participants, interested in issues of state alignment, primarily thought of the BTA etc as the real “units of collaborative business work.” but were happy enough to call the Start or Completion states, “pseudo-states”  The WF restriction we now have is, therefore, probably overly restrictive, because it rules out common, and for the most part harmless, usage of the notation.

 

The only problem with allowing both a linkage from a connection (Transition, Decision, Fork, Join) to a pseudo state, is that it tends to be conducive to documenting the link to an end state twice. I know because I have accidentally done that myself. Then during automatic processing, for example, two edges can show up in the underlying graph.

 

Many of the “tensions” that you have quite astutely pointed out in the Andreas comment series do reflect tensions between technical considerations and the UN/CEFACT metamodel whose concepts were to be partially captured in the XSD. In certain aspects the metamodel was not entirely clear, and we probably could benefit some day from revisiting a more precisely formulated model, and realigning and fixing the XSD in accordance with that model. OMG is still producing models in this area (the one(s) that are to straighten out and clarify the semantics of BPMN 1.1 and 2.0 are ones ebBP has watched with great interest, as well as the continuing work on the UN/CEFACT metamodels). UML 2.0 has a much richer approach to Sequence diagrams that incorporates a lot of the attempts to combine sequence diagram information with QOS, but embed it in a flexible framework for reuse of the “sequence diagram atoms” which are the BTs referenced by BTAs. For example, UML 2.1 has conditional structures for sequence diagrams and so forth.

 

Unfortunately none of these approaches  blend all of the features that ebXML architectural ideas put into the ebBP specification. Some have the process structuring and logic, but lack QOS annotations. Others have good ways of representing activities, especially flows of internal activities, but do not tie them with choreographies or represent them very well.

 

My hypothesis is that standardization in this area will remain iterative for a number of  years, until all the things really useful to capture and model about collaborative business processes, business work flows, services, events, rules and QOS get appropriately represented and interrelated.

 

For the moment, I will add the topic of an errata that supplements the current states that can be referenced in a connection to include the pseudo states. IMO it is relatively harmless to add these states if it seems more natural to you in building process descriptions. But the TC (or its successor maintenance group, really) will have to decide on whether and what errata to issue on the point you raise here.

EndComment

            - A <Transition> from an Activity to Success/Failure does not seem to be possible because of [ToLink/@toBusinessStateRef].
            - A <ToLink> from within Decision/JOIN further does not seem to be possible because of the xsd-documentation of CompletionType:
<xsd:documentation>The type related to the Success for Failure completion of a Business
Collaboration as a transition from an activity.</xsd:documentation>

IMHO:
The standard seems to be somehow contradictory at this point. I think a CompletionState should not only be reachable directly from a TransactionActivity but also from a decision, because depending on the TransactionActivity the result of a collaboration may be a Success or a Failure.
Also, there are examples in the standard that directly switch from a decision to a Success/Failure state

 

Comment: it seems to me that the TC needs to issue an errata that explains the situation about official states and the larger set of nodes in the underlying graph and how it leads to the tensions you have pointed out in the written documentation. Most likely the change, which I hope is agreeable to you, will allow you to link to end states.

EndComment