Carnets de bord

 

BPML business process definition is an ordered collection of activities: simple, complex, and process activities, as shown in this diagram:

A complex activity is a collection of simple activities and complex activities. A process activity is an activity performed in the BPMS itself, such as a simple calculation.

There are four types of simple activities: operation, produce, consume, and exceptions. These types match precisely the classification of operations in WSDL since a BPML:operation can either be a WSDL request/response or solicit response operation, BPML:produce is equivalent to WSDL:one way and BPML:consume equivalent to WSDL:notification. BPML:exceptions are associated with WSDL:faults.  

Simple activities are made of messages (incoming and outgoing), they constitute the message and data flow of a business process:

 

In BPML, messages are defined from the point of view of the BPMS and not necessarily from the point of view of the business partner which sends or receives the message. Messages are abstract, just like in WSDL: nothing specifies their origin or destination.

Complex and process activities represent the control flow of the business process definition:

Complex activities provide facilities to model (In parentheses, I have indicated the corresponding BPML tag names):

• Sequences of activities (Sequence). 
• Activities happening in parallel (All). 
• Conditional process branching (Switch). 
• Conditional participant branching (Choice). 
• Repeat of activities over a set of entities (ForEach).

An activity can either be a complex, process, or simple activity. A conditional process branching is based on the information contained in the business process instance context.. For instance, "if a shipment amount is greater than $10,000, it requires a manual approval process for the insurance contract". A conditional participant branching is a decision taken by a participant and communicated to the process instance as a message. For instance, an insure shipment request order may be accepted or rejected by the insurer. This decision is communicated as part of a message to the buyer business process instance.

Time constrains may be associated to any activity as part of the control flow of the business process definition.

BPML, like XLANG, and WSFL supports transactional semantics. In the business world, transactions are significantly different from database transactions. The traditional ACID (atomic, consistent, durable, isolated) properties of a database transaction are difficult to implement in real world business transactions. The major issue is the isolation of a database transaction. This property requires resource locking which is impractical in the business world. It would also preclude users from participating in a business process.

BPML supports two transaction models: coordinated and extended. They both provide an "all-or-nothing" guarantee for complex interactions between multiple participants. In a coordinated transaction, all participants agree to either complete the transaction or abort it. This model relies on a two phase commit protocol and is also known as a closed, flat transaction due to its ability to support isolation. The extended transaction model relaxes the isolation requirement. There are two possible modes of recovery for such a transaction: backward recovery, where the transaction initiates some compensating activities that will cancel the effects of the failed transaction, and forward recovery, where the business process instance is allowed to continue its execution taking into account that the transaction failed. Compensating activities are used wherever the execution of an activity cannot be rolled back (such as when an order is shipped). These transactions are also known as open nested transactions or Sagas. This model supports transaction interleaving with arbitrary nesting, in other words, transaction may be composed of other transactions.

BPML transactions operate with users, partners, and systems without discrimination. They do not impose limits on duration and survive hardware or software failures.

BPML provides the concept of an abstract to group a series of activities in a single entity. Abstracts are used to model views of processes supported by participants (e.g ebXML Business Collaborations), or to define reusable views of a process with regards to one or more participants.

An abstract need not be complete and may omit information that is not relevant outside the context of interaction with its participants.

A process can declare it supports one or more abstracts. This is actually the essence of a business process definition: a business process is a collection of collaborations between a role represented by the BPMS and any number of participants, which can be users, systems, or business partners. All simple activities can always be associated with a given collaboration.

 

Assaf Arkin discusses the relationship between Pi-Calculus and BPML.