This week the BCS SPA group held a fascinating session titled “Modelling Choreography” by requirements analyst Ashley McNeile.

Ashley described some of the past efforts to model and implement choreographies, using types of process algebra such as  Robert Millner’s Calculus of Communicating Systems (CCS) and its derivative Pi-Calculus. However, Ashley used sequences of events and states (i.e. a state diagram) which he also compared to Michael Jackson’s formalised object lifecycles (e.g. JSD  / Jackson Diagrams). Various W3C efforts have described choreographies too - e.g. WS-CDL. Of course the latest modelling construct for choreography is BPMN2!

As an example of his practice, Ashley described an example - modelling bank account transactions via Protocol Modelling (using simple state diagrams):

• state model 1: defined the close and withdraw events on an active account
• state model 2: defined the freeze and release account events
• state model 3: this had no state transitions, but defined the state by the associated constraints (or business rules)
  • if balance < 0 then account state is overdrawn
  • one cannot close an account if it is overdrawn
• all 3 state models operate in parallel.

To analyse these state models they can be combined into a single state models (with all combinations of states, and all events), and then the unreachable states can be filtered out. The interesting thing here is (1) the analysis of state models for completeness and (2) the use of incomplete state diagrams as a business notation for textual (policy or constraint) business rules.

Other observations:

1. These types of business rule apply to states and data; they can be extracted and modified (by a developer, or state modeller) into event rules or guards in a state transition diagram. Is it interesting to specify these business rules up front before mapping to events and processes? Yes from a business perspective, as new events or states might affect or be affected by existing business rules.
2. Using a state to specify a business rule (in terms of the state and output) is an interesting notation that lends itself well to mapping to appropriate events (or indeed processes). Could it catch on in the business rule community?
3. The use of an explicit choreography language has not had  much success it seems. Google WS-CDL and most entries are dated 2009 or earlier. BPMN2’s choreography may yet prove useful but possibly the concepts are too difficult for business modellers yet imply a co-operative design process for developers that rarely occurs in practice (beyond “this is the interface”!).
4. At the end of the day, the sequence of events in a business system is just a complex event - which maybe can tell you if the choreography is valid or not.

I’ll add a link to the slides to help explain all the above when they become available…

Annex: a Distributed System Choreography Development Process:

This process describes a development process of state diagrams for choreography purposes:

1. Define participants and messages (/events) that interact between them
2. Define states with events as messages from and to, with only 1 sender per state
3. Project the states out to individual participants - i.e the parts of the state model for each participant - allowing ambiguous states but ensuring these have no sends
4. Merge the states for each participant
5. Enact - check each event at a time to prove feasibility of the interacting state models

Very impressive work, by a team led by Mark Linehan of IBM Research, on Date Time was presented by NIST’s Ed Barkmeyer at OMG this week. This is a “work in progress” for likely completion later this year but clearly could play an important role in temporal operations in event processing.

To quote from the latest draft, the objectives of this work are:

1. Provide a Standard Business Vocabulary for Date and Time Concepts. Provide a vocabulary of date and time concepts that business users can share and exploit in their business domain vocabularies and rules…
2. Support Machine Reasoning about Time. Provide a formal ontology that enables machine interpretation and reasoning…
3. Enable implementation…

It covers a time infrastructure (intervals, Allen Relations, durations and SBVR “states of affairs” such as events and situations), organizing time in calendars, “indexical time concepts” such as the meaning of “now” etc in a business context, and so forth. Indeed it seems the only thing NOT covered are the ad hoc adjustments of “leap seconds” to a “year” that are made every now again. And there are versions for UML, SBVR and CLIF, and plans an ODM / OWL version.

One of the drivers of success in the BPM world has been BPMN - the Business Process Modelling Notation - developed under BPMI before it got absorbed into OMG, and probably a bigger success than any other modelling standard - and now as BPMN 2.o (beta, at this time) slightly reconfigured in name as the Business Process Model And Notation. BPMN is used to provide a “process” perspective (versus, say, a data or an event perspective) of a system and shows the flow or orchestration of process tasks and activities. It is made up of (per the excellent bpme.de BPMN2 summary poster):

• 2 flow subtypes: sequence is the normal flow, with default and conditional conditional subtypes
• 7 task types: send, receive, user, manual, “business rule” (really decision), service, and script
• 6 activity markers: sub-process, loop, parallel, sequential, ad-hoc and compensation
• 7 gateways: exclusive, event-based, parallel, inclusive, exclusive event-based, parallel event-based, and complex
• 6 types of data: input, output, object, collection, store, and message
  and
• 63 types of event…

OK, “63 types of event” needs a bit of explanation (and justification). These consist of:

• 13 main event types: untyped, message, timer, escalation, conditional, link, error, cancel, compensation, signal, multiple, parallel multiple, and terminate

… across 8 situations classified by location in a process:

• Start: top-level, event sub-process interrupting, and event sub-process non-interrupting
• Intermediate: catching, boundary interrupting, boundary non-interrupting, and throwing
• End

… but with some situations not requiring certain types of event (e.g. there is no “start cancel process” event) leaving 58 63 event types defined [*1].

Presumably BPMN tools will let the user specifiy the main event type and associate the correct symbol from the context in most cases, leaving us to consider just the 13 main event types.

So let us analyse these event types from an event processing perspective:

• Message and timer events: these are probably most familiar with to those with an event processing perspective, with a message relating to what we consider either a source or a derived event.
• Escalation: this is really a deferal to a different process (e.g. a supervisory process), and can be handled by some internal message in event processing.
• Conditional: this is “reacting to conditions becoming true” - in other words equivalent to a rule-firing (or event query) success. In a rule system this might be handled just by setting some fact or data, which in an inferencing rule system will use some internal event to signal to the rule engine that other rules may “fire” - however there is no need to explicitly model this behavior. I may also of course create an event (or in a query system, insert / update some event), which is again is not explicitly modelled as “conditional” per se…
• Link: some means of connecting models: this is more a “page break” than a business event!
• Error: I prefer the term “exception” here, which of course is a local context - an error event in one process is a normal event in an error-handling process, etc.
• Cancel: this is more a transaction-specific event: if dealing with transactions then some events may indeed be “cancel transaction X” requests, which may or may not be satisfiable, etc.
• Compensation: this is where some process route may require some compensatory process - for example in relation to a “cancel” event.
• Signal: signalling information across processes: this is might be used as a control event, such as in controlling a choreography.
• Multiple: one of a set of events is “caught” or provides the cue to continue the process.
• Parallel Multiple: all of a set of events is “caught” to continue the process.
• Untyped events are used for start and state changes. Typically, though, a state change is the main event we are interested in (in event processing)!
• Terminate event - process complete! From an event perspective this (process end) might never happen of course…

The extra detail might be explained by the fact that in BPMN you are detailing *how* to implement a process, and the “event symbol” is providing you with some specific context for that event. In event processing languages, you usually describing “what* is to be processed, and where all events contribute to some situation or context. It will be interesting to see how these 58 symbols work out in practice, as a hindrance or a help for process designers…

Note:

*1: the table of events above, from the BPMN2 poster from bpmb.de, has 63 event symbols, and is slightly re-organised from the equivalent table in the BPMN2 beta specification (Table 10.93 pp 269-270, in 10-06-04.pdf). Interestingly the specification document also includes a table to detail the event symbols (Table 12.23 ppp 405-411, in 10-06-04.pdf) but this shows only 58 symbols! Let’s just say “lots of event types” in BPMN2 then…

A customer was asking about methodologies around business rules, which was also the topic of a recent LinkedIn discussion started by Paul Harmon of BPTrends (who is apparently extending his BPM methodology to rules). Some general thoughts on methodologies below:

What am I trying to achieve?

1. For (stateless) business decisions, as usually associated with business rule automation in the literature today, consider that common paradigms like decision tables can be viewed both as specification documents (e.g. in a spreadsheet) as well as executable artifacts. As an example, TIBCO BusinessEvents can import Excel spreadsheets into its Decision Manager.
2. For (stateful) rule-based CEP and event-driven business processes - event-rule processing can involve multiple entities - events being filtered, patterns detected, facts inferred, actions made etc - and ideally the rules will be specified declaratively, guided optionally by state models.

What is the generic approach to identifying / specifying business rules?

The generic approach is:

(a) Identify the business entities being processed

• E.g. use cases and actors

(b) Identify associated states

• E.g. entity states and what decisions need to be applied in these states

(c) Identify the associated events

• E.g. business changes like new customer, new agent, removed order, etc
• E.g. occasions when we need to make a decision in a process

(d) Identify business rules against entity / state / event

• Conditions that apply
• Reactions or results
• Inferrences to be made
• Patterns to be identified
• Rulesheets / decision tables

What about “business rules” in the widest sense: rules about the business for the business?

The above comments apply to the common-use of  “business rule” relating to rules and decisions in processes, possibly automated (e.g. in rule engines, with the relevant OMG standard being PRR), and possibly as a part of complex event processing.

For the wider definition of business rules, defining business rules as constraints against the business and documented as a business asset (relevant OMG standard being BMM and SBVR) there are additional steps, usually via some controlled business ontology or vocabulary:

(a2) Identify declarative business rule statements that associate entities with each other

• Eg statements of constraints between the business entities at particular times or on particular business level events

(d) Map business rule statements to associated entity / state / event occurrences to enforce the business rules in particular processes.

What are the  main published methodologies?

There are 2 main providers of methodologies (outside of particular rule vendors’ thoughts … ):

i. Barbara von Halle @ KPI: the main reference remains Business Rules Applied and associated methodology although unfortunately this has not been updated (for example, it predates the concept of CEP and indeed TIBCO as the ~3rd largest rule engine vendor). KPI also have a new book about to be released covering more of a decision model approach.

ii. Ron Ross @ BRSolutions: business rule documentation focus - the main book is Business Rule Concepts which is uptodate and covers mostly the wider definition of business rules, but does relate how these map to automatable rules (and events).

iii. For simpler requirements gathering, the (very) basic separation of business rules from use cases is often covered in Use Case books.

How do these apply to CEP?

Part (d) of the generic approach is obviously far more important in pure event processing. The identification of what filters (to events, payloads etc), what patterns (including patterns on streams as well as individual events, and across data combined with events), and combinations thereof are required to identify a complex event effectively requires its own methodology, which we can cover separately.

Dr Terry Halpin (of ORM fame) has published on BRCommunity.com a series of articles on temporal modeling. In his latest article he mentions the use of state models, as used in the TIBCO BusinessEvents CEP tool, but concentrates on some disjoint subclasses to describe role types of entities over time. Nonetheless, its an interesting series relevant to time-based event processing.

PS: Shame that BRCommunity is free-registration-required, but some good content on there…