Separating Execution and Data Management: A Key to Business-Process-as-a-Service (BPaaS)

Transcription

1 Separating Execution and Data Management: A Key to Business-Process-as-a-Service (BPaaS) Yutian Sun 1, Jianwen Su 1, and Jian Yang 2 1 Department of Computer Science, UC Santa Barbara, USA 2 Department of Computing, Maquaire University, Australia Abstract. In most business process management (BPM) systems, the interleaving nature of data management and business process (BP) execution makes it hard for providing Business-Process-as-a-Service (BPaaS) due to the enormous effort required on maintaining both the engines as well as the data for the clients. In this paper we formulate a concept of a self-guided artifact, which extends artifactcentric BP models by capturing all needed data for a BP throughout its execution. Taking advantage of self-guided artifacts, the SeGA framework is presented to support the separation of data and BP execution. 1 Introduction The need for business process management (BPM) is ubiquitous as business processes (BPs) or workflows exist in all types of organizations including governments, healthcare, and business. In a traditional setting, to develop a BPM (software) system, required expertise includes application specific knowledge and software development experiences. The development team not only formulates concrete BP models, identify data and other resources including human, but also decides on computing hardware and software. After a BPM system is installed, in addition to routine maintenance, the system is often required to change in order to adapt to the changes in the environment, regulations and policies, market competitions, etc. Changes are hard technically and cost wise to many organizations. For example, soon after installing its BPM system, the Housing Management Bureau in city of Hangzhou, China decided to design another system due to the changed policies, environment, and requirements [9]. Such incidents caused the State Council of China 3 to urge provincial and lower governments to use/purchase more services available in the market to streamline administration, an essential aspect of this call is to shift towards the Business-Process-as-a-Service (BPaaS) paradigm. Cost effective BPaaS is challenging to achieve. Multi-tenancy for BPM systems is an obvious option for effective BPaaS, but is technically hard to realize. A primary reason is that existing BP design methodologies lack coherent plans for data design. BP execution needs at least the following five types of data: (i) business data for the process logic, (ii) BP models, (iii) execution states (and histories), (iv) correlations among BP instances, and (v) resources and their states (e.g, room reserved). Without coherent data design, current BPM systems handle and manage data in ad hoc manners, data for Supported in part by a grant from Bosch. 3

2 BP execution is scattered across databases, auxiliary data stores managed by the BPM systems, and even in files (e.g., BP schemas). It is important to note that artifact-centric BPM systems are similar since their BP models [2,6,9] only focus on data of type (i) but are agnostic of types (ii) to (v). A fundamental principle needed to support BPaaS is the independence of data management and execution management. The principle entails that a BP execution engine should be free of managing any data while the manager of data needed for BP executions should not interfere with decisions on BP execution. A technical challenge here is to develop BPM systems that adhere to this principle. In [1], the authors studied how data auditing can be done for BPaaS, where data and execution management are interleaved. In this paper, we observe that the data auditing problem of [1] can be easily solved if data and execution are independently managed. Rather than developing a new BPM system, in this paper we use self-guided artifacts (sg-artifacts) to show that existing systems can be wrapped and mediated to achieve execution independence. Sg-artifacts extend artifact-centric BP models by capturing all five types of data for a BP throughout its execution. Effectively, sg-artifacts make BP engines free of data management. Technically, we formulate sg-artifacts based on the two artifact systems: Barcelona [5] and EZ-Flow [9]. We not only define sg-artifacts, but also specify correspondence between sg-artifact contents and (effectively) system snapshots in both systems. This paper extends the work in [8], where an earlier SeGA prototype to support process collaboration was reported but the concept of sg-artifact was not clearly formulated. This paper is related to [4] that focuses on how to hide the business logic of outsourced GSM BPs [6] while still providing the BP services to clients. A generic solution for BP execution analysis with a process data warehouse model and ETL generation mechanism was presented in [3]. In paper [7], a mapping language is proposed for connecting the process data with the data in the persistent store. Technical contributions of the paper are: (1) while the concept of sg-artifact was introduced in [8], we formulate sg-artifacts for Barcelona and EZ-Flow that include the mappings to snapshots, i.e., translations between sg-artifacts and Barcelona/EZ- Flow, and (2) a framework called SeGA is developed based on the SeGA tool of [8]. This framework takes advantage of sg-artifacts, supports the separation of data and BP execution for the two targeted systems, and is a sound platform for BPaaS. This paper is organized as follows. Section 2 motivates the need for separating data and execution in order to enable BPaaS. Section 3 reviews Barcelona and EZ-Flow, formulates sg-artifacts including translations from/to Barcelona and EZ-Flow, and outlines the SeGA framework. Section 4 concludes the paper. 2 Motivations The success of cloud computing has fueled the desire to provide BP execution as service or BPaaS. Consider as an example real estate property management in China. There are roughly 10 to 50 Housing Management Bureaus (HMBs) in each of about 30 provinces for managing titles, permits, licenses etc. Each HMB currently runs/maintains its own BPM system. BPaaS could potentially bring huge savings to HMBs in managing and maintaining BPM systems and is a great business opportunity in the software market. 2

3 Hangzhou HMB Enterprise Data Store 1 Yiwu HMB Service Provider BP Engine 1 BP Engine 2 Local 1 Local 2 Enterprise Data Store 2 Fig. 1. Running Clients BP Engines Hangzhou HMB Ent. DS 1 & Local 1 Yiwu HMB Service Provider BP Virtual Engine Fig. 2. Shared BP Virtual Engine Ent. DS 2 & Local 2 Virtualization (i.e., VMs) is a key technology for cloud computing that frees clients from owning and maintaining computing hardware and operating systems. In Fig. 1, a service provider uses VMs to run BPM systems for many HMBs as services. For the large city Hangzhou, its HMB manages its business data in the enterprise database. the service provider can then run and manage the BPM system, including the data store Local 1 containing data specific to Hangzhou HMB s BP execution. Almost all current BPM systems also manage data related to the processes running in the systems locally within the systems. For the small city Yiwu, the situation is similar except that the provider also manages Yiwu s enterprise data. BPM systems are semantically rich, each BP engine only suits in its local context, its local data store is a main part of the reason. As a result, one BP engine cannot be used to serve multiple HMBs. Thus each HMB s BP engine needs to be managed individually, the total effort of maintenance of all BPM systems for HMB clients is not reduced much excepted that it is simply shifted to the service provider. For example, when the core execution engine is to be upgraded, each installation must be upgraded individually in a seemingly repetitive manner. Fig. 2 shows a much improved situation. In this case, only one BP virtual engine is running, each HMB s enterprise business data and engine-specific local data are packaged and stored in an extended data store and maintained either by the client (e.g., Hangzhou) or by the service provider (e.g., Yiwu). Both the data and process definition are provided to the virtual engine when it needs to schedule tasks; upon completion, all data is again packaged and stored accordingly for the client. This is far more efficient and scalable as the number of clients grows. Achieving Fig. 2 turns out to be technically challenging. In order to understand how to separate data from BP execution, we present a concrete example below. Example 1 Consider a BP model in Hangzhou HMB (HHMB). This BP concerns approval for Early-sell permits submitted by developers to allow some apartments in the buildings under construction to be put on the market. Permit approval involves two collaborating BPs carried out by different departments. The primary BP Early-sell Approval Flow (EAF) accepts applications from developers, performs reviews in several aspects, processes fee payment, and issues approval certificates. One aspect of the review concerns reserved space for building maintenance functions (total area, accessibility, etc.) and is done by the other BP Maintenance Space Check (MSC). An EAF instance launches a MSC instance for all apartments in the EAF instance and located in the same building. If multiple buildings are involved in the EAF instance, one MSC instance for each building will be launched. During the execution of an EAF instance, there are at least five types of data involved: (i) the data about the applicant, the apartments, etc., (ii) the EAF model itself, 3

4 (iii) the current execution status, e.g., the initial review of the applicant is completed and two MSC instances have been spawned, (iv) correlation information of the EAF and two MSC instances, and (v) the building records (owned by Hangzhou s Land Management Bureau) have been checked out for possible update by the EAF instance (an approved apartment will be marked on the building records). Among the above types of data, only business data of type (i) is managed in the HHMB enterprise database, while all others are stored within the HHMB s BPM system. If this BPM system is also to manage executions of BPs from other HMBs, problems will rise since data of types (ii) to (v) from all HMBs are mixed together. HHMB uses a proprietary BPM software but the situation is similar for YAWL and jbpm; the conclusion easily applies to YAWL and jbpm. A major overhaul of storage and management of data of types (ii) through (v) seems necessary in order to support multi-tenancy. In this paper, we formulate a technique sgartifact to cleanly separate all types of data from the execution management of a BPM system. Based on sg-artifacts, a framework called SeGA was developed, SeGA easily allows a single BPM system to serve BP executions from multiple clients. 3 Self-Guided Artifacts Our goal is to develop techniques for separating data from execution in order to support multi-tenancy and BPaaS. We start with introduction of wrappers for data used in BPs called self-guided artifacts (or sg-artifacts ) to contain all needed data for execution. We focus on two artifact models, Barcelona [5] (i.e., the execution engine name for GSM [6]) and EZ-Flow [9]. Then we introduce sg-artifacts and how to wrap Barcelona/EZ-Flow into sg-artifacts. Finally, a framework to support sg-artifacts, called SeGA, is presented. Note that activity-centric BPs and artifact-centric BPs only different in modeling data of type (i) (see Section 2), this technique can be easily extended to other BP models/systems. GSM and EZ-Flow Artifacts An artifact stores all business information related to the BP using pairs of attributes and values. An event type is with an event name and a sequence of distinct attributes as payload. Each event type also contains the special attribute ID to hold an artifact identifier (that uniquely identifies each artifact instance). An event is an instance of an event type that can be either incoming or outgoing to denote it is to be sent or received. We now briefly review GSM [5] with an example. Continue with Example 1; Fig. 3 shows the lifecycle of a GSM process for MSC that prescribes how the process should be executed. The lifecycle starts from stage Requirements Check. It is opened once the condition in the diamond-shaped guard is satisfied. The guard tests if a Request Maintenance Check event arrives. Once the stage is activated, some sub-stages can open. For example, if HHMB decides to revise the maintenance apartments plan, substage Partial Apts Check can be activated. During the execution, outgoing events can be sent out to request execution of actual tasks outside environment (e.g., humanperformed). Once the requirement is checked, the circle-shaped milestone with name Details Checked will automatically close the associated stage. The instance finishes when milestone Docs Archived is achieved. The formal models of GSM artifact schemas and lifecycles are given in [6]. A GSM schema always contains an attribute ID to hold the identifier of an artifact instance. 4

5 Requirements Check Partial Part Info Apts Check Collected Report Result Generate Report Report Written All Apts Check Send Report to Office All Info Collected Report Sent Developer Negotiation Result Reported Agmnt Reached Terms Disagreed Archive Docs Details Checked Docs Archived MSC ID = 101 Corr. Info.: EAF_ID = A1 Apt_List No = 1; checkpassed = T No = 2; checkpassed = F Milestone Terms Disagreed = T Docs Archived = F Fig. 3. A GSM Artifact Lifecycle Model of MSC Fig. 4. A MSC Instance A GSM artifact instance records the status of a single run of a GSM artifact at some time point. Fig. 4 shows a MSC artifact instance for the BP described in Fig. 3. Consider the instance with ID = 101. It has two maintenance apartments, in which the one labeled No. 2 failed to pass the maintenance check. The milestone Term Disagreed is achieved to denote that the negotiation with the developer fails at the current moment. There is an attribute called EAF ID in MSC to denote the correlated EAF business processes mentioned in Example 1. An artifact instance represents a running BP instance (with all data values). Artifact instances can depend on each other through the IDs of instances stored as attribute values of other instances. Quite often, if some attributes of an instance change during execution, other instances referencing this instance may possibly change as well. The BP engine should keep track of all dependency relationships. Based on GSM semantics [6], the Barcelona engine [5] was developed. The communication between the environment and Barcelona is done through events. The incoming events (sent by a task or a user) are handled sequentially. For each event, a B-step will be performed to update the correlated artifact instance stored in a DB2 database according to the schema. Some depending artifacts may also change during the same B-step. Once it is done, the engine will process the next event. The EZ-Flow model is similar to GSM, details can be found in [9]. Self-Guided Artifacts A self-guided artifact captures a complete set of data for a BP model so that its instances are independent from execution engine; this is a key enabler for multi-tenancy and BPaaS. In particular, each self-guided artifact instance incorporates both artifact instance (including its snapshot) and its process model that this instance will follow. Conventional BP modeling languages allow specification of tasks and control flow (BPMN, Activity Diagrams, YAWL, etc.), leaving data modeling to some later stage and/or at a lower conceptual level. Artifact-centric models [2,6] integrate logical data models for business data (i.e., type (i)) and activity/task models. Even current artifact systems still capture context, status, and resource data in an ad hoc manner. For example, Barcelona [5] stores artifact dependency and the execution state directly in its local database. In this paper, we advocate a fundamental principle for BPM systems: Execution independence refers to the freedom of making changes to the process execution engine while leaving conceptual BP models unchanged. A necessary ingredient to support execution independence is the ability to capture all five types of data in conceptual BP models, including (i) business data for BP execution, (ii) BP schemas, (iii) current execution states (and histories), (iv) correlations among BP instances, and (v) resources and their states. 5

6 In database management systems, physical data independence was a key enabler for the development of transaction models (concurrency, crash recovery) independently from query optimization. Analogously, execution independence could allow the management/modification of execution and data to be dealt with separately. We now define the central notion of self-guided artifacts. Essentially, a selfguided artifact (instance) is a GSM (EZ-Flow) artifact augmented with state and runtime dependency information, and with the artifact schema. (Resource data is not included since neither models represent resources.) Definition: A self-guided (or sg-) artifact schema is a tuple (A, ID, Att, Sta), where A is a (unique) name, ID is the ID attribute, Att is a set of data attributes, and Sta is a set of state attributes. Given an sg-artifact schema (A, ID, Att, Sta), a self-guided (sg-) artifact instance Σ of A is a tuple (ν, L, M, Dep) where ν assigns values to attributes in {ID} Att Sta such that ν(id) is a unique ID, L is either GSM or EZ representing a modeling language (GSM or EZ-Flow), M is an artifact schema in the language L, and Dep is a set of dependencies whose representation depends on the language L. A sg-artifact schema is an abstraction of running instances of both GSM and EZ- Flow artifacts. Each sg-artifact instance captures data attribute values, status and dependencies, and (its own copy of) schema or BP model. The inclusion of the schema frees the engine from storing BP models. To achieve execution independence for GSM (EZ) artifacts, all data concerning BP including data and states are extracted from Barcelona (EZ-Flow) and stored as sgartifact instances. When Barcelona performs a B-step (EZ-Flow performs a transition), it updates all affected artifact instances. Thus, it is necessary to establish a 1-1 mapping from GSM (EZ) instances to sg-artifact instances so that the fact of sg-artifacts storing the system data/status is transparent to Barcelona (EZ-Flow). We discuss below a few technical notions for the mappings for GSM and EZ-Flow separately. In Barcelona, once an event comes, it will first affect one GSM instance; during the same B-step, the effect may also ripple to the other depending instances. For each GSM instance, a dependency closure can be computed to record all the instances that might be affected during the execution. Given a sg-artifact instance Σ = (ν, L, M, Dep), the key notion relating a GSM instance Σ and sg-artifacts is given by mapping (i) the ID, data, and status attributes/values through ν, (ii) L = GSM, (iii) M to be the schema of Σ, and (iv) Dep the dependency closure of Σ. The mapping not only keeps the original ID, data and status attributes, but also includes the execution language and the schema. For the dependency closure, though it can be derived from the data attribute values, it is necessary to raise it as the first-class citizen in order to explicitly denote the relationship with other instances. Given a sg-artifact instance Σ that is mapped from a GSM instance Σ, it is straightforward to recover Σ by simply mapping each attribute-value pair from Σ to Σ. The mapping from EZ-Flow (schema/instances) to sg-artifact (schema/instances) can be achieved similarly; the logical description of the mapping is omitted. The SeGA Framework A sg-artifact instance captures all necessary data for execution, and allows a BP engine 6

7 Schema Snapshot Incoming events Outgoing events Barcelona Engine SeGA Mediator BP Service Interface Service Provider Fig. 5. The SeGA Framework Client SeGA Dispatcher SG-Artifacts Repository 1 SeGA Dispatcher SG-Artifacts Repository k to operate without knowing the context of instances. The SeGA framework wraps BP engines into stateless services to support BPaaS and how sg-artifacts can interact with the provided services. Based on SeGA, a prototype was developed and reported in [8]. Fig. 5 shows the architecture of the SeGA framework (or simply SeGA), which consists of a SeGA dispatcher and a SeGA mediator. When an external event arrives, the dispatcher fetches the relevant sg-artifact instances from a sg-artifact repository, separates the schema from each sg-artifact instance, maps it back to the original form (GSM or EZ-Flow), and sends the external event, schema, and the original artifact instance to the mediator. When the mediator receives the event, schema, and the instance, it deposits the artifact schema in the appropriate location where the Barcelona/EZ-Flow engine can access, and passes the control over to the Barcelona/EZ-Flow engine by forwarding the event. When the Barcelona/EZ-Flow engine receives the incoming event, it executes the next step and updates the artifact instances according to the schema deposited by the mediator; and outgoing events may also be sent directly from the engine if there exists task invocation during the execution. Once it completes, the mediator fetches the updated artifact instances, together with their schemas and states, and sends them back to the dispatcher. The dispatcher then maps the instances and schemas back to sg-artifacts and stores into the corresponding repository. SeGA can be used to support BPaaS. The dispatcher would reside at the service consumer, where a repository of sg-artifacts is maintained. The mediator is located at the service provider who runs a BP engine (or multiple engines). The dispatcher and mediator communicate through service invocations such as WSDL or REST, and work in pairs so that the service provider can use its BP engines to execute BP received from the service consumer in the form of data. The SeGA framework takes advantage of the execution independence that separate data and execution management. From the engine s perspective, it provides businessprocess-as-a-service but does not maintain any data. This allows the provider to serve a large number of consumers. From the consumer s view, all BP data are maintained at its site; beyond that, there is no need to manage BP execution. SeGA requires the dispatcher/service consumer to have a sg-artifact repository so that the dispatcher can fetch (sg-artifact) instances. In general, an enterprise stores the data in a enterprise persistent data store (e.g., a relational database) rather than storing data for each individual BP model. A general approach of a data mapping to bridge the relationships between sg-artifact instances and databases was developed in [7]. As an advantage of [7], one can design artifact storage and map the artifact data to the existing database(s). The mapping in [7] can propagate updates on artifact instances to the database and vice versa. Together with the mapping framework, the SeGA framework provides an effective way of elevating a BPM system for multi-tenancy and BPaaS. 7

8 Design Methodology to BPM Systems Our study on SeGA leads to two suggestions for the future BPM system development. First, existing BPM systems can be extended so that data in the process manager is extracted and packaged with the business data into sg-artifacts. Although we only explored two systems, the same method is applicable to other systems including jbpm and possibly YAWL. Second, more generally it is most desirable to develop future BPM systems that support the independence principle. In this regard, we envision that a BPM system consists of three layers, a modeling layer to accept/analyze the data and BP design, and map to sg-artifacts; a SeGA layer to manage sg-artifacts and interact with the engine at runtime; an execution layer to manage executions with no local data. Such new style BPM systems will provide a tremendous support for BPaaS and process collaboration. 4 Conclusions The demand for BPaaS is coming. We have seen various vertical BPaaSs in for example HR and procurement. Clearly BPaaS is not just about providing APIs and interfaces for configuration and graphical analysis. The challenges lie in the capability to handle massive scaling, the service must be able to support multiple languages and execution environments, as well as massive customers and processes. We argue that the separation of the data from the execution engine is a good way to achieve this demanded scaling. References 1. R. Accorsi. Business Process as a Service: Chances for remote auditing. In Proc. IEEE 35th Annual COMPSAC Workshops, pages , K. Bhattacharya, C. Gerede, R. Hull, R. Liu, and J. Su. Towards formal analysis of artifactcentric business process models. In Proc. 5th Int. Conf. on Business Process Management (BPM), Brisbane, Australia, September F. Casati, M. Castellanos, U. Dayal, and N. Salazar. A generic solution for warehousing business process data. In Proc. 33rd Int. Conf. on Very Large Data Bases (VLDB), pages , R. Eshuis, R. Hull, Y. Sun, and R. Vaculín. Splitting GSM schemas: A framework for outsourcing of declarative artifact systems. In Proc. 11th Int. Conf. on Business Process Management (BPM), pages , T. Heath, D. Boaz, M. Gupta, R. Vaculín, Y. Sun, R. Hull, and L. Limonad. Barcelona: A design and runtime environment for declarative artifact-centric BPM. In Proc. 11th Int. Conf. on Service-Oriented Computing (ICSOC), pages , R. Hull et al. Business artifacts with guard-stage-milestone lifecycles: Managing artifact interactions with conditions and events. In Proc. 5th ACM Int. Conf. on Distributed Event-Based System (DEBS), pages 51 62, Y. Sun, J. Su, B. Wu, and J. Yang. Modeling data for business processes. In Proc. 30th Int. Conf. on Data Engineering (ICDE), pages , Y. Sun, W. Xu, J. Su, and J. Yang. SeGA: A mediator for artifact-centric business processes. In Proc. 20th Int. Conf. on Cooperative Information Systems (CoopIS), pages , W. Xu, J. Su, Z. Yan, J. Yang, and L. Zhang. An artifact-centric approach to dynamic modification of workflow execution. In Proc. 19th Int. Conf. on Cooperative Information Systems (CoopIS), pages ,