In “challenging” economic times, technology uptake depends more than usual on perceptions of what business value a technology can provide. So for starters, let’s recall that business process standards support technologies that have been argued as providing values in the following ways:

·    documentation of business operations (BPMN), thereby preserving business knowledge capital
·    opportunities to be turned into executable code (BPEL), perhaps improving quality of implementations and portability
·    inputs to tools based on formal methods (WS-CDL) to establish that processes are free from certain defects (livelock, race conditions, starvation)
·    optimizing performance (BPMN using statistics gathered from simulations or  measured through monitoring)
·    and, according to the vision of model-driven architectures (or domain specific languages), presumably there are yet other useful problem-solving tasks that can benefit from applying business process knowledge

The preliminary results suggest that that there may be several payoffs for technologies built upon business process standards, and that the value of these technologies may consist of incremental and increasingly powerful technologies, rather than found in “one killer app.”

The OASIS ebBP 2.0 standard was an early standard in the business process area whose design differs to some extent from others that have emerged more recently (mentioned above). One main design goal for ebBP was to support specifications of collaborative process contracts, especially qualityof-service agreements, but also the basic logic that governs exchanging business data—what response documents can be sent to a request document, what sequences are allowed, when processes can be done concurrently, what yields success, what yields failure, and so on.

So, like other standards, ebBP has value as documentation and could be used as an input to validation tools that check for the presence or absence of desirable or undesirable properties. Unlike some recent standards, however, ebBP models were intended to apply no matter what collaboration or communication protocols or services were used, so long as business data was exchanged. So it deliberately abstracts over business data format and syntax (traditional EDI, XML, etc), and over communication transfer protocol (FTP, HTTP, etc) and over such features as connectionless, synchronous, asynchronous and the like. (An optional construct allows a “mapping” to a WSDL to be indicated, however.)

Also, the purely choreographic aspect of business process (those aspects captured by state transition diagrams), was viewed as only one aspect of the business process description, and the descriptions were kept fairly simple. Equally important was the specification of quality of service levels (such as the time to acknowledge delivery or the overall time to perform a unit of ”business work”) for processes and sub-processes. Intentionally omitted was much of the detail pertaining to the internal business process and workflow; there are only orchestration “stubs” to serve as placeholders for details concerning requesting or responding activities.

Other potential uses for ebBP have begun to emerge over time. As a specification, for example, an ebBP business process description can provide something that an implementation can be checked against. Static checks could reveal that a given implementation (possibly specified by BPEL or Java or maybe SCA) matches the specification.  The check is done by showing that the implementation and specification are “equivalent” with respect to their embedded labeled transition systems (LTS]. Other related tools such as the Eclipse plug-in, LTSA, have emerged that take service specifications, such as those provided by WS-CDL, and provide quality checks (checking for the presence of good qualities, such as fairness, or the absence of bad ones, such as live locks.) Over time, editing tools could be expected to emerge with capabilities for warnings of hazards or providing various design “scorecards.”

The OASIS TaMie TC is investigating ways to monitor or test that event traces of processes conform or violate various test assertions. The major goal of the TC is to define an events scripting language for running against event “boards” to check that events satisfy certain conditions. One subproject in this group has been to explore sources of domain knowledge that can provide inputs that can be compiled into these event testing scripts, creating an automated and standardized way of setting up aspects of Business Activity Monitoring (BAM).

The subproject has defined cases making use of UBL 2.0 messages,

and ebBP 2.0 defined specifications of business collaborations (“choreographies”) that are specified while using these messages. The compilation process begins with deriving an LTS version of the content of the ebBP model. 

The LTS input is then compiled into the event scripting language which can then be interpreted by an events engine that understands the scripting language and contains a data base or stream of events that can serve as the TaMie event “board.”

One hope is that eventually any business process description (such as BPMN 2, WS-BPEL, etc.) can be transformed into a common LTS XML languages that can be compiled into the TaMie scripting language. In this way, common business process description can provide inputs for multiple services of value to companies:

·    For checking implementation correctness within and between enterprises
·    For checking process design with respect to static qualities or defects
·    For generating BAM monitoring tasks in accordance with deployed specifications
·    For classification of event stream simulations with respect to efficiency and time to perform
·    And for the usual cited benefit of model assisted computations, generating code to run execution engines.

At present users of BP technologies may be bewildered by the variety of notations that exist to capture process specifications, and there are certainly considerable variations in approaches with respect to the semantic richness of process descriptions. But there are underlying commonalities emerging that will enable several kinds of useful work to be done, each defined task adding incremental benefits to deployments of increasingly sophisticated forms of automated and semi-automated business collaboration.