Int. J. Business Process Integration and Management, Vol. 6, No. 1, 2012
29
A component abstraction for business processes Souvik Barat* and Vinay Kulkarni Tata Consultancy Services, 54 B Hadapsar Industrial Estate, Pune, Maharashtra, 411013, India Fax: 91-20-6608-6399 E-mail:
[email protected] E-mail:
[email protected] *Corresponding author Abstract: With continued increase in business dynamics, it is becoming increasingly harder to deliver purpose-specific business system in the ever-shrinking window of opportunity. As business systems for the same intent tend to be similar but never the same, they have considerable overlap with well-defined differences. Software product line engineering techniques attempt to address this problem for software artefacts. Separation of business process concerns from application functionality, as advocated in process centric application development, demands solution on similar lines for business processes too. To this effect, we propose an abstraction for business processes that addresses composition, variability and resolution in a unified manner. We present the abstraction, its model-based realisation, and illustration with an example. Keywords: business process component; business process family; business process reuse. Reference to this paper should be made as follows: Barat, S. and Kulkarni, V. (2012) ‘A component abstraction for business processes’, Int. J. Business Process Integration and Management, Vol. 6, No. 1, pp.29–40. Biographical notes: Souvik Barat is a Scientist at Tata Consultancy Services. He received his MS from Indian Institute of Technology, Madras, India. His research interests include business process management, model-driven software engineering, and software product lines. Vinay Kulkarni is the Chief Scientist at Tata Consultancy Services. His research interests include model-driven software engineering, software product lines, business process management, and enterprise transformation. His work in model-driven software engineering has led to a toolset that has been used to deliver several large business-critical systems over the past 15 years. This paper is a revised and expanded version of a paper entitled ‘A component abstraction for business processes’ presented at the 2nd International Workshop on Reuse in Business Process Management (rBPM 2011), Clermont-Ferrand, France, 29 August 2011.
1
Introduction
We are in the business of developing business-critical software systems, typically for large enterprises. Our experience is that no two systems, even for the same business intent such as straight-through-processing of trade orders, back-office automation of a bank, or automation of insurance policies administration are identical. Though there exists a significant overlap across functional requirements for a given business intent, the variations are manifold too. We have witnessed that such systems tend to vary along three dimensions, namely, business process, functionality, and solution architecture (Kulkarni and Reddy, 2003). Service orientation enables separation of business process concerns from application services. The concerns along functionality and solution architecture dimension get addressed through application service implementation. Similar business applications tend to have considerable overlap of application services. To leverage this
Copyright © 2012 Inderscience Enterprises Ltd.
commonality, we have developed a component abstraction that enables decomposition of application services into common and variable parts, identification of places where variations occur, a type-safe mechanism for plugging in variable parts at these placeholders, and a resolution mechanism to ensure that appropriate variable parts get plugged into the appropriate placeholders. Thus, the component abstraction addresses composition, variability and resolution in a unified manner with locality. We have realised this abstraction using model-based techniques to support a family of business applications (Kulkarni, 2010). In this paper, we build upon the same principles to address composition, variability and resolution of business processes. We propose a model-based realisation of the abstraction and illustrate the key concepts with the help of a non-trivial example. The paper is organised as follows – Section 2 describes the process component abstraction, Section 3 presents an illustrative example, and
30
S. Barat and V. Kulkarni
the process component metamodel is presented in Section 4. A realisation of business process component infrastructure to support business process component abstraction with required context specific adaptability is highlighted in Section 5. We discuss the related work in Section 6 and conclude with a short summary.
ranging from zero visibility (i.e., black box component) to partial introspection (i.e., grey-box component) with contentSpec and variabilitySpec being visible. We introduce the concept of interface port, iPort, and a basic form of interface, task interface, to formalise a process component interface. Formally, an interface port is defined as a tuple iPort = where •
portType describes the interaction role, i.e., input or output
We propose process component abstraction to specify a behavioural unit for representing a business process or its parts in a modular, hierarchically composable, extensible and configurable manner. The abstraction enables:
•
DT is a set of data types from a type system T.
1
composition to realise larger process components from existing process components ad infinitum
•
2
configuration to adapt a process component for predefined situations
enP: An input interaction point of a process component, which describes the entry point of a behavioural unit, i.e., either task or process component. It is similar to start event of a traditional business process model.
3
extension to adapt a process component for a priori unknowable situations.
•
exPs: Set of output interaction points that specify exit points of a behavioural unit, for instance, successful completion, process abandoned, and process cancelled. It is similar to the end event of traditional business process model.
•
lPs: Set of input interaction points for sensing environmental events of interest. IPs are relevant for a process component representing long running and context (environment) aware business process.
•
nPs: Set of output interaction points for notifying significant intermediate milestones to the environment. nPs are similar to the intermediate events of long running business processes.
2
Process component abstraction
In addition, the abstraction makes clear separation of interface from implementation with compIntf, describing the interface of a process component, and compImpl describing the implementation in terms of three parts namely controlSpec, contentSpec and variabilitySpec as shown in Figure 1. The parts are fairly independent from each other thus supporting independent evolution and have predetermined correlations that ensure overall consistency.
2.1 Component interface It specifies an external view of the process component by describing explicit interaction points with the environment. It provides restricted visibility to its internal structure Figure 1
Visualisation of process component abstraction
A task interface is defined as tuple Intf = where
A component abstraction for business processes Component interface, compIntf, is a refinement of the task interface abstraction and is formally defined as compIntf = , where •
visibility is a Boolean flag, e.g., black-box or grey-box.
•
rTs is the set of required tasks of a process component. A process component expects these set of tasks to be performed by external components to achieve the overall objective of a process component. Each of these required tasks is specified using task interface abstraction, i.e., Intf.
•
vConf is the set of configurations where each configuration identifies consistent resolution of process component variability.
2.2 Control specification The control specification specifies the flow definition of a process component. We decouple the control aspect of the process component from other aspects by representing the set of process steps of a process component as task interfaces, i.e., Intf. Formally, a controlSpec is defined as a three-tuples where
31 We assume one-to-one mapping between elements of compIntf.nPs and Event, but one could notify a meaningful event by inferring occurrences of several basic events using existing CEP-based approaches such as Barros el al. (2007). Similar mechanism can be used for listening events of interest. We consider the integration of existing CEP approaches to produce or consume meaningful event as our future work.
2.3 Content specification Content specification describes the possible realisation(s) of the process steps by defining the bindings between task interface and behavioural unit. This behavioural unit could be one of the following elements – (sub) process component with smaller objective (SC), atomic task like service (S) exposed by enterprise application and human task (H), or required task (RT) of a process component, i.e., compIntf.rTs. Formally, a contentSpec of a process component PC is defined as three-tuples where: •
PSIntf is a set of task interfaces defined in controlSpec, i.e., controlSpec.PSIntf.
•
PSIntf is the set of interfaces, intf, representing the process steps
•
BU is the set of behavioural units, i.e., collection of SC, S, H and RT.
•
Events are the set of events used in flow definitions
•
•
cSpecSet is a set of control definitions, where each control definition, cSpec ∈ cSpecSet, is the flow definition defined using (subset of) PSIntf and Events.
BS is a set of bindings. A binding, bind (srcIntf, destIntf) is between two interfaces, i.e., source interface and destination interface. We term a binding as internal binding when srcIntf ∈ PSIntf and destIntf is the interface of one of the elements from BU. We verify the consistency of a binding by validating the conformance between srcIntf and destIntf, where interface conformance is defined with respect to entry point, exit points, listening ports and notification ports.
The formalism supports multiple control definitions of a process component to allow variability in control flow, i.e., a same set of process steps can be performed in a slightly different order to achieve the same mission objective. We mandate that each cSpec of cSpecSet must have distinguished start node and set of end nodes. The conformance criteria of a controlSpec = with respect to compIntf = are defined as follows: •
The entry point of component interface must be compatible with the entry port of start node of all cSpec ∈ cSpecSet. The compatibility criterion is defined in terms of interaction role (i.e., input and output port type) and data types of consumed and produced data.
•
All exit points of the component interface must be compatible with the exit points of end nodes of cSepcSet.
•
All notification ports must be either triggered by an event ∈ Events or produced from any of the process steps, i.e., task interface.
•
All listening ports should be either mapped to intermediate event ∈ Events or mapped to listening port of a process step, i.e., task interface.
Content specification allows more than one binding for a task interface. This opens up the scope for defining variability and configuring them to serve purpose specific behaviours.
2.4 Variability specification The variability specification of a process component specifies the existence of behavioural variability and its resolution in a declarative form. Formally, a variability specification is a six-tuple , where •
FT is a feature tree of a set of features, where each feature (F) describes the variability of a process component in an abstract manner. An FT is similar to the feature tree described in Czarnecki et al. (2004). Primarily, we categorise a feature into two kinds – leaf feature and group feature. Leaf feature is a label that describes a possible choice, and group feature is a label for organising feature structure and representing choice point.
32
S. Barat and V. Kulkarni
•
Const is a set of constraints defined with respect to F to describe inclusion and exclusion relationships of features.
binds a required task of a process component with a compIntf of outer process component
•
VP is the set of variation points, where each variation point represents the location where the behavioural variation exists of a process component. Typically, process component and task interface are the candidate variation points as a process component can expose several valid configurations through component interface and it can contain different control definitions in controlSpec; similarly, a task interface can associate with more than one binding in contentSpec.
2.6 Process component operators
•
Var is the set of variants where each variant represents a fragment of process component. Typically, bindings and control specifications can be seen as candidates for variants, i.e., element of Var.
•
FBind is the feature binding. A feature binding is a binding of a group feature and variation point or a leaf feature and element of Var.
•
Conf is the set of configurations, where each configuration selects a valid and consistent (with respect to Const) set of leaf features. We define a configuration as consistent if the configuration, conf ∈ Conf, selects a set of leaf features such that one and only one element of var ∈ Var exists for each variation point, vp ∈ VP. The (sub) set of configurations, Conf, are exposed though component interface as compIntf.vConf.
We propose a set of operators to assemble, integrate, configure and extend a process component. Assembly operator assembles a set of process components together to form a larger process unit, i.e., a composite process component. A composite process component, compProc = , can be defined by assembling a set of process components PC, where compControlSpec captures the glue specification of the assembly, compContentSpec specifies the internal bindings between task interface used in glue specification and elements of PCs, and compVSpec describes variability of compProc in terms of the variability of PCs. Integrate operator integrates a set of process components using external bindings. Configure operator resolves behavioural variability of a process component, i.e., selects appropriate choice for each variation point such that no constraint is violated. Extension operator extends the behaviour of a process component by: 1
Adding new binding for an Intf. We term this kind of extension as content extension. The content extension leads to adding new behavioural variability of a process component, i.e., either new variation point (element of VP) along with choices (element of Var) or new choice (element of Var) in existing variation point.
2
Adding new control specification, i.e., cSpec in cSpecSet, we term this kind of extension as control extension. The control extension leads to adding new behavioural variability of a process component, i.e., new choice (element of Var).
3
Adding new configuration by selecting new set of choices. We term this as configurability extension, which may leads to a new entry in vConf of a process component interface.
3
Illustrative example
2.5 Process component classifications A process component that cannot be decomposed into smaller process components is termed as elementary process component. An elementary process component does not bind to any other process components and instead binds to atomic task(s), i.e., services (S) human tasks (H). In the similar run, we term a process component as composite process component if it contains at least one process component through internal binding. A composite process component can introspect the contentSpec and variabilitySpec of a sub process component if visibility flag of sub process component interface is true. Thus, it can use the variabilitySpec of sub process components while defining the variability, otherwise composite process component can only use the vConf of the sub process components to define its variability. We term a process component as configurable process component if more than one bindings exist for at least one task interface of a process component or more than one control definitions exist for a process component. Otherwise, it is termed as non-configurable process component. A process component is defined as integrable process component if it has at least one required task. A process component integrates with other process component through a binding, we term as external binding. An external binding
We consider a simplified version of a loan origination process as an illustrative example for demonstrating the concepts presented so far. A loan origination process, typically, is about providing loan to the eligible applicant(s) after validating them for credit worthiness. The process starts with a request from applicant(s) containing specific loan product, reasons for requesting the loan and the desired amount as input data, and ends either by rejecting the request or by dispatching the approved loan amount (may not be same as the requested amount) to the applicant. The various process steps of loan origination process are shown in Figure 2. Each process step has its mission objectives. The mission objectives of each of these process steps are as follows: collect requester details (CRD) collects information from the applicant, preprocessing (PreP) process step
A component abstraction for business processes validates the collected information and orders credit reports, appraisal reports, etc. for checking credit worthiness. Check credit worthiness (CCW) is an underwriting process step which analyses collected data and reports, assigns conditions, and determines the sanctioned amount against applied loan amount. Terms and condition negotiation (TCN) process step is for discussing the terms and conditions with the applicant(s) and prepares the loan agreement if applicant agrees to defined terms and conditions. Rest of the process steps, namely scrutiny of agreement and collateral (SAC), create loan account (CLA) and fund disbursement (FD) are respectively for scrutinising signed agreement and submitted collateral documents, creating loan account in the enterprise system, and finally closing and disbursing the loan amount to applicant. For illustration purpose, we consider the process step CRD is outsourced to external agency with the remaining process steps being managed internally by the loan origination department (LOD). Underwriting department, a sub-unit of LOD, manages CCW process step by decomposing into finer process steps such as credit risk (CR) analysis, operational risk (OR) analysis, market risk (MR) analysis and supervisory review (SR). We consider this process as being used in two contexts having somewhat different behavioural requirements. In one context, the enterprise would like to support partial pre-approval facility for a loan application along with Basel II compliance for CCW process step, and risk-based negotiation in TCN process step. In other context, the organisation would like to support simple process without any pre-approval facility, Basel I compliance for CCW process step, and informal relationship-based negotiation for TCN process step. We term the former as advanced loan origination process and the latter as simple loan origination process. The process component model of loan origination business process is depicted in Figure 3. Component interface (compIntf) of the loan origination process component specifies the interaction points as described in Figure 3(a): a
Request – an entry point for initiating process component when any applicant submits a request; it consumes applicant’s primary contact details, desired loan product and loan amount as input data.
Figure 2 A sample loan origination business process
33 b
Complete – an exit point for successful completion; it produces financial instrument like pay order and copy of the agreement.
c
Reject – an exit point for rejection notification; it produces rejection notification.
d
External fraud – a listening port to consume the news about external fraud happening in the environment (this information is an additional factor while negotiating with applicant in TCN process step).
e
Approved – a notification port for notifying the approval notification once CCW process step is completed.
The component interface also describes two valid configurations, simple and advanced, of the loan origination process. Figure 3(b) describes the control flow specification of the loan origination process component. It describes the flow of process steps using interface (Intf) abstractions. Figure 3(c) describes the content specification in terms of bindings between task interfaces and component interface of process component. CRD interface binds with required task, i.e., rTs::CRD, of component interface, which is not shown in the figure. Multiple bindings for a single process step denote variability. PreP1 process component supports PreP with pre-approval facility and PreP2 without it. Thus, variations in PreP process step are achieved by mapping two non-configurable process components whereas the variability of CCW and TCN process steps are achieved by binding with configurable process components. Figure 3(d) describes the variability specification of the loan origination process component in terms of: a
Abstract representation of variability as a feature tree.
b
Mappings between group feature to variation points, e.g., {Pre-processing → PreP Component Interface}, and leaf features to process component interface, e.g., {With PreApproval → PreP1}, and leaf feature to the configuration of lower level process component, i.e., {Compliant with Basel 1 → Basel 1}.
c
Set of configurations describing the selections, e.g., Advanced = {With PreApproval, Compliant with Based 2, risk-based negotiation}.
34 Figure 3
S. Barat and V. Kulkarni Loan origination process component, (a) process component interface of loan origination process component (b) control specification of loan origination process component (c) content specification of loan origination process component (d) variability specification of loan origination process component (see online version for colours)
(a)
(b)
(c)
(d)
A component abstraction for business processes Figure 4
35
Credit worthiness check process component, (a) control specification of credit worthiness check process component (b) variability specification of credit worthiness check process component (see online version for colours)
(a)
(b)
In this example, available configurations, i.e., the configuration exposed by compIntf.vConf, of CCW and TCN are used to describe the variability of loan origination process component. We consider that CCW process component is a grey-box process component in this example, thus one can use (introspect) the feature model of CCW process component described in Figure 4(b) to describe the variability of loan origination process component. The controlSpec, and variabilitySpec of CCW process component is described in Figure 4. CCW process component supports two flow specifications – cSpec1 and cSpec2 as depicted in Figure 4(a). CSpec2 supports Basel II compliance process flow, which mandates CR analysis, OR analysis, MR analysis with SR process steps whereas cSpec1 supports Basel I, which mandates only CR analysis process as part of credit worthiness check. In our example, we demonstrated the flow using BPMN (OMG, 2010) kinds of specification considering task interface as activity but one can use other kinds of specification for defining task flow. A representation of flow specification, cSpec 3, for CCW process step using declarative language similar to ConDec (Pesic and van der Aalst, 2006) is depicted in Figure 4(a).
4
Process component metamodel
We propose process component metamodel supporting the abstractions presented in Section 2. The metamodel is, essentially, a unification of component interface specification, control specification, content specification
and variability specification describing their interrelationships. The control specification is further unification of imperative languages such as BPMN, EPC (van der Aalst, 1999), and declarative specifications such as ConDec, and the variability specification metamodel is similar to the feature model described in Czarnecki et al. (2004). The key elements and their interrelationships of the process component metamodel are depicted in Figure 5. ComponentInterface, representing compIntf abstraction, specialises interface which represents Intf abstraction. An Interface has one entry point, at least one exit point, and optional listening and notification ports. In addition, ComponentInterface may have a set of required tasks and may expose a set of internally consistent configurations. An interface has bindings of two kinds, namely, internal and external. Internal binding is the binding between a task interface and one of the three options: 1
component interface of a process component
2
an interface that represents a service or human task
3
interface which is exposed through component interface as required task that describes contentSpec.
External binding is the binding between required task and component interface of outer process component that describes integration specification of process components. A process component can contain many ControlDefinitions as controlSpec. ControlDefinition is essentially flow description defined using activity elements (and its sub elements). We use a generalised metamodel, combining the
36
S. Barat and V. Kulkarni
constructs of imperative and declarative specifications. However, one can use a BPMN compliant metamodel, such as Kulkarni and Barat (2010), by constraining a task interface into single entry and single exit point to visualise it as an activity. Alternatively, a set of interaction ports can be used along with events to describe control specification, or one can map all interaction ports to events and specify the control flow in terms Events and Gateways. The variability specification is described using feature hierarchy, featureAssoc and mappings from feature to variation points or variations. Feature hierarchy structure depicted in figure extend feature tree described in abstraction section, where RootFeature, derives from group feature, represents the root of a feature tree, and external feature, kind of leaf feature, Figure 5
Business process component metamodel
represents the configuration of lower level process component. FeatureAssoc is used for describing feature relationships, i.e., dependency, inclusion, exclusion. One can define complex constraints using FeatureConstrains. We use external feature and PH4NLTop to address the composability of variability specification of (sub) process components in a composite process component. We use PH4NLTop to map a feature model of sub process component to support the introspection of feature tree of grey box sub process component. On the other hand, all valid configurations of black-box sub process components can be mapped though external features to represent choices of group features of process component
A component abstraction for business processes
5
Process infrastructure realisation
Business processes come into existence to achieve well-defined business objectives by performing a set of tasks in a systematic manner. Organisations need to stay compliant with new regulations coming up, take innovative offerings quickly to its customers, and stay in step with technology advance. This calls for intuitive, adaptable, and comprehensive business process infrastructure so that existing business systems can support the increased dynamism needs with certainty. Available business process tools are: a
not flexible enough to capture new concerns that may arise due to increased dynamics of business processes
b
not capable of interpreting same concepts differently based on changing business semantics
c
not amenable to different analyses based on the operational contexts.
We are in the process of developing such infrastructure that also supports the proposed process component abstraction. We chose a model driven approach as it enables supporting two fundamental properties of the desired business process infrastructure: flexibility and extensibility of business process specification, and flexibility in model interpretation. MOF (OMG, 2006) is a complete language for describing any metamodel of interest with set of desired constructs (i.e., metamodel elements and their properties). Decoupling of model constructs and their interpretations provides high-degree of flexibility in context specific interpretation of process model. These capabilities can help to support a comprehensive dynamic business process modelling, simulation and execution environment.
5.1 Realisation of metamodelling infrastructure All models are purposive and typically involve multiple stakeholders leading to multiple viewpoints. Specification of each viewpoint is expected to be as intuitive and close to the problem as possible leading to viewpointspecific modelling language and diagramming notation. Theoretically, there can be infinitely many viewpoints – each possibly having a limited and specific view of the entire process. Thus, there could be an expectation to have as many specification languages and diagramming notations as there are stakeholders. Moreover, viewpoints could be related to each other thus leading to a need to be able to transform views from one viewpoint to another. Thus, the following emerge as necessary and sufficient capabilities to comprehensively address this specification problem in practice: 1
A language to define all possible modelling languages such that different modelling languages can be visualised as views of a unified language where the unified language is an adaptive and extensible language.
37 2
A language to define all possible visualisations of a model so that different diagramming notations can be provided to different stakeholders.
3
A language to specify transformation of one model into another
A MOF-based business process metamodelling infrastructure, based on our homegrown metamodelling and model processing infrastructure, is used for developing business process modelling framework. The modelling framework supports the constructs described in the abstraction section. We use BPMN-based notations for specifying flow-constructs and FODA-like notations (Kang et al., 1990) for variability specifications. For a model of a process, it is possible to switch from one diagramming notation to another. It is also possible to extend the process model for greater expressiveness. For example, one can specify relationship between process model and service model conforming to service metamodel (i.e., binding a service task to a service) and organisational model conforming to organisation metamodel (i.e., binding a human task with human agent).
5.2 Realisation of interpretation infrastructure We are using statechart as underlying formalism for developing business process component interpretation environment. Essentially, Statecharts is an extension of conventional state-diagram enabling orthogonality, communication, clustering, and refinement (Harel, 1987). Conventional state-diagram supports basic process flow constructs, i.e., transitions, orthogonality supports concurrency, clustering supports abstraction and modularity, communication supports integration between modules, and refinement supports ‘zoom’ capabilities for moving back and forth between levels of abstraction with depth and hierarchy. However, there is a fundamental difference between the formalism used for defining flow logic (controlSpec) and statechart formalism. BPMN compliant control flow is essentially a flowchart – i.e., task (processing) is associated with vertices whereas the task (processing) is associated with arc in a statechart. In other words, a flowchart executes task in a node whereas a state machine is idle when it is residing in a node (state) and waiting for an event/activity, which typically emits from task, to occur. We overcome this semantic mismatch by considering each state of translated statechart model as a special super-state, where each such special super-state (of the outer statechart) encapsulates a specific statechart (let us term as inner statechart) with task invocation semantic, and the invoked task (within inner statechart) is responsible for emitting one of the possible events/activity. The emitted event/activity triggers the state transition of its outer statechart. Thus, one can visualise a process component as a superstate having statechart specification, where: 1
state can be further refined with invocation semantic in case of service or human task; or pure refinement
38
S. Barat and V. Kulkarni semantic with zoom-in capability in case of sub-process component
2
state changes are triggered by events – emitted internally from invoked task or external events.
It uses event communication capability to interact with other process components for required tasks (rTs) and other interactions, i.e., lPs and nPs. It uses conditional transition capability of statechart to realise variability specification; i.e., when an event e occurs in a state A the system transfers to state B only if condition C is true at that time, here B is a super-state with specification of specific configuration (conf) and there could be several such conditions representing contextual conditions. As a prototype implementation of proposed business process component interpreter, we extended Java-based open source Apache SCXML execution engine (Apache Commons, 2010). SCXML execution engine is a statechart execution environment based on Harel statecharts. It uses State Chart XML (SCXML) specification (W3C, 2007) recommended by World Wide Web Consortium (W3C) as input specification language. We translate process component models to SCXML specifications, using model-to-text transformation technique, which are then input to use SCXMLExecutor. The Invoke specification of SCXML Execution engine is extended with two additional targettypes to specify invocation of service tasks and human tasks. The semantic of invoke of ‘scxml’ targettype is also extended to support late binding of SCXML modules based on metadata table to support variability requirements at execution time. The extended SCXMLEngine supports component abstraction with hierarchical composition and bindings, integration, and variability management. The declarative style of specification of activities is also supported by using the concepts of super-state and orthogonality of the statechart formalism. Moreover, the desired dynamism of the interpretation environment is achieved by exploiting the concepts of clustering and refinement and supporting late-binding of state and state refinement of SCXMLEngine. We extended SCXMLEngine implementation to provide a hook to plug-in user-specific implementation of service task and human task – this helps to plug-in an implementation of simulation function for each tasks. We extended this environment to persist the current status of the process component instances in order to support long-running execution to use this environment as process component execution environment.
6
Related work
Several approaches presented in Eberle et al. (2009), Polyvyanyy et al. (2009) and Schumm et al. (2011) allow visualisation of a business process as a set of process fragments or building blocks. The key motivation here is to improve the flexibility and reuse [of parts] in an effective manner. A component abstraction, Eva component, to visualise business process as encapsulated behavioural unit is presented in Sünbül et al. (2001). An Eva component
consists of an exporter interface describing the provided part, an importer interface describing the required part, and a body containing the realisation expressed in terms of Feva-nets. These approaches support adaptation and evolution of business process by providing different implementations for a process fragment/component. Though identical in philosophy, our approach is based on the concept of fractal (Bruneton et al., 2006). It is a richer component abstraction that supports multi-dimensional separation of concerns such as interface, content and control, and enables independent adaptation and evolution of each of these concerns. van der Aalst et al. (2009) also argued that the need for flexibility and adaptability along multiple dimensions; and proposed an approach supporting hierarchical decomposition and behavioural variability by combining YAWL (van der Aalst and Ter Hofstede, 2005), Worklets (Adams et al., 2006) and Declare (Pesic et al., 2007). The approach achieves the behavioural variability by enabling the selection of appropriate worklets for a process step at runtime (similar to selecting appropriate internal binding in our approach). In contrast, we support design time variability along content and control specifications, and provide an intuitive feature model-based mechanism to select appropriate and consistent set of variants. The approaches presented in Schnieders and Puhlmann (2006), Rosemann and van der Aalst (2007), Gottschalk et al. (2007), Fantinato et al. (2008), Hallerbach et al. (2008), and La Rosa et al. (2011) support behaviour variability of a flattened out business process, whereas we support variability for business processes that can be specified as hierarchical composition of process components. In addition to the novel abstraction presented in this paper, its proposed realisation is also a contribution towards adaptive business process environment. Industry practice uses business process modelling tools that encode fixed interpretation of a fixed metamodel. We use MOF-based extensible metamodel for specifying business processes (so that varying requirements can be captured by an evolving metamodel), and a flexible SCXML-based interpretation environment where new semantic can be provided for existing or new constructs (i.e., metamodel elements). Model-driven approach is fairly well-accepted by business process community (Kindler et al., 2006). Use of state-based formalism, such as statechart, for interpretation purposes is also a well-studied area. However, use of refinement and conditional state transition of statechart formalism for realising adaptive and context-specific specific business process is not reported earlier. Moreover, the adaptation of statechart-based SCXML engine through execution time refinement is another novelty, we think.
7
Conclusions
We proposed a process component abstraction to represent business process fragments with a richer component abstraction such that each unit is encapsulated with well-defined interface and amenable for composition, extension and configuration. The proposed approach
A component abstraction for business processes supports clear separation of control, content and variation concerns while specifying a process component and enables independent evolution along each of these dimensions with assured consistency as a whole. We also illustrated how different paradigms, like event-based or activity-based paradigm, and different types of specification languages, i.e., imperative or declarative, can be used to specify control flow of process component. Testing large monolithic business processes is hard. Specifying variability on a flattened out process flow structure (Kulkarni and Barat, 2010) is hard to use in practice. To overcome these problems, we proposed an abstraction that addresses composition, variability and resolution in a unified manner with locality. We demonstrated how variability management can be handled in localised context and propagated to the larger unit in a systematic manner. Use of the proposed abstraction to address testing and richer analyses is left for future work. We believe model-based nature of our approach will help target multiple process execution platforms, lead to use of richer analyses techniques and testing mechanisms by applying suitable model-to-model transformations. Finally, we presented a technique for implementing a practical adaptive business process interpretation environment. The current implementation is still in experimentation stage and several challenges such as performance, robustness, scalability, etc. are yet to be addressed. Initial experience with the process interpretation environment is positive and has opened up several interesting exploration opportunities such as plan partly and executes in a loop instead of plan once and executes the fixed plan, on a multimodal system.
References Adams, M., Hofstede, A.H.M., Edmond, D. and van der Aalst, W.M.P. (2006) ‘Worklets – a service-oriented implementation of dynamic flexibility in workflows’, OTM Conferences, No. 1, pp.291–308. Apache Commons (2010) ‘Commons SCXML resources’, available at http://commons.apache.org/scxml/ (accessed on 17 April 2012). Barros, A.P., Decker, G. and Großkopf, A. (2007) ‘Complex events in business processes’, BIS, pp.29–40. Bruneton, E., Coupaye, T., Leclercq, M., Quéma, V. and Stefani, J. (2006) ‘The FRACTAL component model and its support in Java’, Software Practice Experience, Vol. 36, Nos. 11–12, pp.1257–1284. Czarnecki, K., Helsen, S. and Eisenecker, U. (2004) ‘Staged configuration using feature models’, Software Product Lines: Third International Conference, SPLC 2004. Eberle, H., Unger, T. and Leymann, F. (2009) ‘Process fragments’, OTM Conferences, No. 1, pp.398–405. Fantinato, M., Toledo, M.B.F. and Gimenes, I.M.S. (2008) ‘Ws-contract establishment with QoS: an approach based on feature modelling’, Int. J. Cooperative Inf. Syst., Vol. 17, No. 3, pp.373–407.
39 Gottschalk, F., van der Aalst, W.M.P., Jansen-Vullers, M.H. and La Rosa, M. (2007) ‘Configurable workflow models’, in Int’l. J. of Coop. Inf. Systems (IJCIS), Vol. 17, No. 2, pp.177–221. Hallerbach, A., Bauer, T. and Reichert, M. (2008) ‘Managing process variants in the process lifecycle’, in 10th Int’l. Conf. on Enterprise Information Systems (ICEIS’08), pp.154–161. Harel, D. (1987) ‘Statecharts: a visual formalism for complex systems’, Sci. Comput. Programming, 1 June, Vol. 8, No. 3, pp.231–274. Kang, K., Cohen, S., Hess, J., Nowak, W. and Peterson, S. (1990) ‘Feature-oriented domain analysis (FODA) feasibility study’, Software Engineering Institute, Carnegie Mellon University. CMU/SEI-90-TR-21. Kindler, E., Axenath, B. and Rubin, V. (2007) ‘AMFIBIA: a meta-model for the integration of business process modelling aspects’, International Journal of Business Process Integration and Management, Vol. 2, No. 2, pp.120–131. Kulkarni, V. (2010) ‘Raising family is a good practice’, FOSD 2010, pp.72–79. Kulkarni, V. and Barat, S. (2010) ‘Business process families using model-driven techniques’, 1st International Workshop on Reuse in Business Process Management (rBPM 2010). Kulkarni, V. and Reddy, S. (2003) ‘Separation of concerns in model-driven development’, IEEE Software, Vol. 20, No. 5, pp.64–69. La Rosa, M., Dumas, M., Ter Hofstede, A.H.M. and Mendling, J. (2011) ‘Configurable multi-perspective business process models’, Inf. Syst., Vol. 36, No. 2, pp.313–340. OMG (2006) ‘Meta-object facility (MOF) 2.0, OMG document – formal/2006-01-01’, available at http://www.omg.org/spec/MOF/2.0/ (accessed on 17 April 2012). OMG (2010) ‘BPMN 2.0, OMG document – dtc/10-06-04’, available at http://www.bpmn.org (accessed on 17 April 2012). Pesic, M. and van der Aalst, W.M.P. (2006) ‘A declarative approach for flexible business processes management’, Business Process Management Workshops 2006, pp.169–180. Pesic, M., Schonenberg, H. and Aalst, W.M.P. (2007) ‘DECLARE: full support for loosely-structured processes’, EDOC 2007, pp.287–300. Polyvyanyy, A., Smirnov, S. and Weske, M. (2009) ‘The triconnected abstraction of process models’, in Proceedings of BPM, 2009, pp.229–244. Rosemann, M. and van der Aalst, W.M.P. (2007) ‘A configurable reference modelling language’, Inf. Syst., Vol. 32, No. 1, pp.1–23. Schnieders, A. and Puhlmann, F. (2006) ‘Variability mechanisms in e-business process families’, in Abramowicz, W. and Mayr, H. (Eds.): 9th International Conference on Business Information Systems (BIS 2006), LNI, Vol. P-85, pp.583–601. Schumm, D., Karastoyanova, D., Kopp, O., Leymann, F., Sonntag, M. and Strauch, S. (2011) ‘Process fragment libraries for easier and faster development of process-based applications’, Journal of Systems Integration, Vol. 2, No. 1, pp.39–55. Sünbül, A., Weber, H. and Padberg, J. (2001) ‘Evolutionary development of business process centered architectures using component technologies’, Journal of Integrated Design & Process Science, Vol. 5, No. 3, pp.13–24.
40
S. Barat and V. Kulkarni
van der Aalst, W.M.P. (1999) ‘Formalization and verification of event-driven process chains’, Information & Software Technology, Vol. 41, No. 10, pp.639–650. van der Aalst, W.M.P. and Ter Hofstede, A.H.M. (2005) ‘YAWL: yet another workflow language’, Inf. Syst., Vol. 30, No. 4, pp.245–275.
van der Aalst, W.M.P., Adams, M., Ter Hofstede, A.H.M., Pesic, M. and Schonenberg, H. (2009) ‘Flexibility as a service’, DASFAA Workshops 2009, pp.319–333. W3C (2007) ‘State machine notation for control abstraction’, W3C Working Draft 21 February 2007, available at http://www.w3.org/TR/scxml/ (accessed on 17 April 2012).
