Unlike traditional business processes, Collaborative business processes span beyond bor- ders of a single organisation. Due to their nature, Collaborative Business Processes present unique characteristics and verification requirements that cannot be automati- cally met by traditional business processes verification approaches. It necessitates con- sideration of other factors to achieve with their verification;
• Need to express interactivity and communication requirements among the collab- orative business process eco-system. In most cases, dedicated communication and interaction protocols are established for message exchanges between the partners to engage in discussions and iterations before reaching a decision [86]. Due to dif- ferent role interactions from partner organisations, it is important to clearly define organisational units, communication channels and reporting relations during ex- ecutions [171]. The verification of organisational units, communication channels and reporting relations prevents role conflicts and makes work swift. A platform independent model for specifying cooperation among workflows is proposed by [34]. A system implementing the model is as well presented allowing workflows to publish and subscribe to events and, definition of points in execution where to send and receive events. The events are filtered, correlated and dispatched to appropriate target workflow instances. The model however does not guarantee safety of interactions or cooperation among workflow systems since no verifica- tion is conducted. Common forms of interaction adopted in collaborative business processes include [9];
– Capacity sharing; resources are distributed but under one managerial control – Chained execution; the process is broken into sub processes that are executed
by different partners
– Subcontracting; phases of the process are sub contracted to other business partners
– Case transfer; work is balanced between partners
– Loosely coupled; the process is partitioned horizontally and each partner runs one or more parts of the process over a defined protocol
• Dynamism, Flexibility and Complexity: Complexity results from various require- ments from the stakeholders. These usually must be satisfied by the process to achieve compliance on top of other requirements from the external agencies. This requires high flexibility and dynamism of the process. The rate and speed at which changes are verified, integrated and propagated to the necessary components is
important to facilitate decision making. Short of this would be detrimental to the collaboration and entire supply chain.
• Security and privacy requirements: Collaborating organisations do not entirely share their workflows but only necessary data or part of the workflow are made visible. Organisations desire to retain their autonomy [27]. This implies defining the scope of the collaboration sphere and supporting interfaces, and verifying that privacy is not compromised. For example, a Virtual enterprise coordinator ( VEC) is proposed as an approach to control and maintain privacy, flexibility and inde- pendence of an organisation participating in a Cross organisational business pro- cess. VEC supports mapping between interacting workflow management systems by defining interfaces that preserve privacy of shared workflows. The approach however disregards set up and distribution of agreements between collaborators and does not verify the implementation.
• Semantic Notation Requirements: Collaborative business process models are of- ten composed bu merging existing partner models into a single model. This way, model semantic ambiguity arises due to the different ways in which each partner has been designing their models or the supporting modelling languages used at each end. Some modelling tools lack uniform semantics, e.g. BPMN tools. Unify- ing the semantics to avoid misunderstandings is a requirement whose satisfaction is achieved through semantic annotation verification.
CHAPTER 2. RELA TED W ORK
Approach Properties Flexibility Arbitrariness Suitability Complexity Limitations Woflan Soundness and
Liveness
Verifies completed models
Single model verified at a time
Specific to models developed in par- ticular language
Easy to use with graphical interface
Non-collaborative Complex outcomes It is difficult to trace er- rors
YAWL Soundness and Liveness
Design time ex- ception handling model
Each model or sub model is verified inde- pendently Verifies control flow based on Resetnets and transition invari- ants
Not complex to use and supports ex- tension plugins Graphical interface
Non-collaborative
FlowMake Structural conflicts like synchronisa- tion, Deadlocks, consistency, Liveness Exception han- dling. Not scalable as models grow large
Not domain specific Sub models are ver- ified independent of main model
Lack data perspec- tive which is very essential for vF cBP
Graphical interface makes it usable for non-expert users
Non-collaborative Based on control flow and abstracts other perspec- tives
It is difficult to trace er- rors
CHAPTER 2. RELA TED W ORK Petri Nets ysis Coverability and occurrence
handling cation of main and sub models
tems
Non domain spe- cific
less complexity port
SPIN Correctness and logical consistency
On Timeouts it supports exception handling
Wide application not limited to particular domain
The richness of temporal logic can make it viable for vF cBP Its syntactical structure and semantics make it complex. With XSPIN a graphical interface is provided Non-collaborative State explosion
Restricted to smaller sys- tems
UPPAAL Bounded Liveness, deadlock freeness and deadlines
on-the-fly verifica- tion but not scal- able
Verifies concurrent systems but not simultaneously.
No support for data analytics
Supports diagnos- tic trace leading to source of errors
Non-collaborative sup- port
KRONOS Reachability prop- erties (Safety, Non zenoness, Bounded response
Exception han- dling supported
No simultaneous ver- ification models and sub models No known applica- tion to vF domain Graphical interface usability Provides counter examples to aid verification Non-collaborative Limited to smaller models Co consideration for data
CHAPTER 2. RELA TED W ORK
NuSMV safety, and liveli- ness
tion handling taneous models or sub model verification
cific
Scales to other ap- plications interface to ease usability Counter examples provided State explosion HyTECH Reachability, Safety, Liveness, time-bounded, duration No exception handling. Not scalable Specific application for embedded and hybrid systems
Lacks elements like data which a key to vF cBP
Complex tool due to its syntactical and semantic requirements
Non-collaborative State explosion
Supports to smaller sys- tems
Woflan Soundness, Live- ness and Reacha- bility
Lack of flexibility Single model verified at a time
Verifies mod- els from other languages
Graphical interface for usability
Non collaborative. Output not easily under- standable
ADEPT Semantic correct- ness, deadlock and Safety
Handle excep- tions Flexible verification
No support for si- multaneous model and sub models verification
Applicable to other domains other than clinical processes
Use of process tem- plates to easily cre- ate processes.
Lack of proven applica- tion.