The ACSI Hub: A Data-centric Environment for Service Interoperation?

Abstract

The business artifact approach to modeling business processes and web service orchestration is gaining wide attention because it enables a holistic marriage of data and process, that in turn supports an intuitive, top-down view of processes, rich flexibility, and verification in the presence of data. The GuardStage-Milestone (GSM) variant of artifacts provides a declarative approach for specifying artifact lifecycles (that is, possible sequencings of activities relevant to an artifact), and provides the foundation for the recent OMG Case Management Model and Notation (CMMN) standard. The ACSI Hub system, open-sourced in 2013 [4], uses the artifact-based approach to support service orchestration, and the demo shows in particular how it works with GSM-based artifacts. The demo shows several capabilities of the ACSI Hub system, including design of the service orchestration schema, configuring of access rights for different participating services, and execution of the overall orchestration as viewed by the participating services. As such, it demonstrates the feasibility and naturalness of using a declarative artifact-based (or case-based) approach for managing flexible service orchestration.

-

The past few years have seen a dramatic upsurge of Software-as-a-Service (SaaS) applications that support business and other services. This highlights the importance of developing intuitive, robust approaches to support service interoperation. Early approaches to service interperation, namely orchestration and choreography, focused primarily on managing the integration of the processing aspects of multiple services. In contrast, [ 10 ] proposes a data-centric approach to orchestration, in which the integrated process is represented using business artifacts [ 14, 11 ]. These correspond to key conceptual entities that are central to guiding the operations of a business (or collection of collaborating businesses). A business artifact type is modeled using (a) an information model, which is intended to hold (physically or logically) all business-relevant data about entities of this type, and (b) a lifecycle model, which is intended to hold the possible ways that an entity of this type might progress through the business. The ? Copyright 2014 for this paper by its authors. Copying permitted for private and academic purposes. demonstration presented here is based on the ACSI Hub system, which enables the creation of service orchestrations using business artifacts with finite state machine based [ 14 ] or Guard-Stage-Milestone (GSM) lifecycles. [ 9, 6 ] In particular, the demonstration shows (i) a GSM business artifact schema that is used to support collaboration between four participating organizations, (ii) how access controls can be specified to permit the organizations to access information and invoke operations, and (iii) how these enforce information privacy and prevent unauthorized actions by the different parties.

The demonstration focuses on business artifacts with Guard-Stage-Milestone (GSM) lifecyles, which [ 9, 6 ]. provide a declarative, modular approach to specify the operations of a business. The GSM paradigm was extended by the ACSI project to incorporate access controls and other functions needed to support the interoperation of multiple services [ 12 ]. GSM is especially well-suited for supporting processes which include a high degree of variability (e.g., by knowledge workers) and/or parallelism of activities. Indeed, the GSM model was used as the basis for the recently released OMG Case Management Model and Notation (CMMN) standard [ 2 ]. This suggests that a variation of the ACSI Hub could be developed, in which CMMN rather than GSM is used.

Due to space limitations, this short paper describes the demo in high-level terms, and with only one screen shot. A demo video available at [ 3 ].

Section 2 briefly highlights key aspects of the demo, including the the authorization mechanism for access rights, and how execution of GSM artifacts is seen by different participants that have differing access rights. Section 3 briefly discusses the maturity of the ACSI Hub tool and its relevance to the BPM (and other) communities. 2

Demo Overview

The demo illustrates the GSM model and ACSI Hub system by showing a sequence of processing steps based on a simplified business process that is performed collaboratively by four kinds of participating organization. More specifically, the OrderToCash example used here focuses on a scenario in which a customer requests a generic product that involves assembly of piece-parts. An order for the product is created by a customer and submitted to a seller, which is responsible for collecting needed components from several suppliers. Once all components are received by the seller, the product is fabricated and then shipped to the customer by a carrier. The actual demo focuses on a subset of the overall process, that illustrates how the rules-based aspect of GSM drives the processing, and also the views that different organizations will see over time. Guard-Stage-Milestone (GSM) model overview. We briefly overview the GSM model in terms of the demo scenario. We assume that the reader has familiarity with the GSM model, and provide only a brief overview here (see, e.g., [ 9 ]).

The OrderToCash schema in the ACSI Hub editor contains a single artifact called “CustomerOrder”. Although there is only one artifact in the demo, in general the ACSI Hub system can support multiple artifact types in one schema. (See [ 9 ] for a more elaborate version of Order to Cash inovlving multiple artifact types.)

The first step of the demo is to show the information model of the CustomerOrder artifact, as supported by the ACSI Hub editor. The information model holds all of the business-relevant data that is read or written during the lifecycle of a customer order. Both scalar and nested attributes are supported.

The demo next shows the lifecycle model of CustomerOrder. GSM lifecycles are built using three kinds of components. First is milestones; these represent businessrelevant operational objectives. For example, milestone “Drafted” is achieved once the order has been drafted by the customer, and milestone “submitted” is achieved once the order has been successfully submitted into the supplier. Milestones are typically associated with the completion of stages, which correspond to one or several activities. Stages can be nested to arbitrary depth. Atomic stages hold a single activity, which will correspond to an external service invocation that could be either manual or automated. These may read or write attributes from the information model. The third kind of component is guard, which are rule-based conditions to decide when to open up stages. Rules are also attached to determine when milestones can be achieved.

GSM lifecycles are basically structured Event-Condition-Action (ECA) rule systems. Each guard and each milestone has one or more sentries, that is, expressions based on (incoming or internal) events and/or conditions written in the Object Constraint Language (OCL). A single incoming event may lead to a chain of sentries being fired, with one or more stages being opened or closed, and one or more external operations being invoked.

Specifying Access Rights. The main feature of the ACSI Hub is to support differentiation of information access and action invocation rights for the different kinds of participants in a collaborative process. The third step of the demo is to show the screen for editing access rights for the different kinds of participants. Figure 1 shows the authorization editor. As illustrated on the left-hand side, the specification activity is currently focused on the Customer role. Using the right-hand side of the screen, the administrator can choose, what attributes of OrderToCash can be viewed by customers (essentially a projection operation). More interestingly, the adminstrator can choose what and how stages/milestones can be viewed by customers, and what sentries can be accessed/triggered by them. The core operators here (see [ 12 ]) include completely hiding a stage, exposing just a stage without its substages, or exposing the stage and its child stages. Similarly, some sentries may be hidden from view, or may be shown but not available for triggering. For example, a customer can see the status of “Processing”, “Preparing”, and “Collecting”, but will not see what is happening inside “Collecting”. Customers will have access only to attributes or stages/milestones that are related to the drafting and submitting stages; all other attributes involved in processing stages are not available. Various consistency conditions are enforced by the authorization editor. Execution. With all of the above specified, the four participant (type)s can now use the ACSI hub engine to collaboratively execute instances of the OrderToCash schema. The remainder of the demo involves illustrations of how one instance of OrderToCash will execute, including what the different participant roles will see at various points in time. These steps are shown using the ACSI Hub administrative console, a richly expressive interface that allows manual step-by-step execution of business process instances. In particular, the administrative console shows the current snapshot of a business artifact instance from the perspective of each role. It also shows the set of event types that would be eligible from a given type of participant for invoking a next step of operation. 3

Maturity and Significance

The ACSI Hub system, and the underyling Barcelona (GSM lifecycles) and Siena (finite state machine based lifecycles) artifact engines, developed over the past several years, are now available opensource [ 4 ]. The development of and research around the ACSI Hub and Barcelona systems was supported in part by the 3-year EU-funded research project on Artifact-Centric Service Interoperation (ACSI).

As part of that project, two in-depth, multi-year pilot investigations were performed [ 15 ]. The Energy Distribution Management for Liquidation use case (“Energy use case” for short), was focused on the Measurement Liquidation procedure that is used in the Spanish Electric Network to calculate the fair remuneration that every agent of the network should receive, as there are numerous companies participating in the energy generation, distribution and commercialization activities. The Flanders Research Information Space Program (FRIS) use case is focused on an initiative of the Flanders Department of Economy, Science and Innovation (EWI) that intends to offer fast access to research information for all the stakeholders, and increase the efficiency and effectiveness of its R&D policy. The use case focuses on the applied biomedical research (TBM) funding programme related artifacts at EWIs funding agency IWT.

More broadly, the Barcelona and ACSI Hub systems have been used for many research investigations, primarily in the areas of process mining, verification, foundations, and systems (e.g., [ 13, 1, 6, 12 ]). Indeed, there have been over 130 publications [ 16 ] stemming from the ACSI project, many of which rely directly on the Barcelona and ACSI Hub prototypes, and all of which are inspired by this line of research. These have been published primarily in the BPM, web services, AI, and database management research communities.

This will be the first public demonstration of the ACSI Hub system. There have been two demos of the underlying Barcelona engine, first at BPM 2011 ([ 8 ], and then an improved version at ICSOC 2013 ([ 7 ]). An early version of Siena (supporting FSM lifecycles) was demo’ed at ICSOC 2008 ([ 5 ]).

References

1. F. Belardinelli , A. Lomuscio , and F. Patrizi . Verification of gsm-based artifact-centric systems through finite abstraction . In Intl. Conf. on Service-Oriented Computing (ICSOC) , pages 17 - 31 , 2012 .

2. BizAgi et. al. Case Management Model and Notation (CMMN) , FTF Beta 1 , Jan . 2013 . OMG Document Number dtc/2013-01-01, Object Management Group.

3. D. Boaz , F. Heath , M. Gupta , L. Limonad , Y. Sun , R. Hull , and R. Vacul ´ın. The ACSI Hub: A Data-centric Environment for Service Interoperation (online demo video ), June 2014 . https://www.youtube.com/watch?v=kXSVJAVEFlY&feature=youtu.be.

4. D. Boaz , L. Limonad , and M. Gupta . BizArtifact: Artifact-centric Business Process Management , June 2013 . http://sourceforge.net/projects/bizartifact/.

5. D. Cohn , P. Dhoolia , T. Heath , F. Pinel , and J. Vergo . Siena: From powerpoint to web app in 5 minutes . In Intl. Conf. on Services Oriented Computing (ICSOC) , 2008 .

6. E. Damaggio , R. Hull , and R. Vacul ´ın. On the equivalence of incremental and fixpoint semantics for business artifacts with guard-stage-milestone lifecycles . Info. Systems , 38 : 561 - 584 , 2013 .

7. T. Heath , D. Boaz , M. Gupta , R. Vacul´ın, Y. Sun, R. Hull , and L. Limonad . Barcelona: A design & runtime environment for declarative artifact-centric business processes . In Proc. Intl. Conf. on Service Oriented Computing (ICSOC) , 2013 .

8. T. Heath , R. Vacul ´ın, and R. Hull . Barcelona: A design and runtime environment for modeling and execution of artifact-centric business processes (demo) . In Proc. Intl. Conf. Business Process Mgmt. (BPM) , 2011 .

9. R. Hull et al. Business artifacts with guard-stage-milestone lifecycles: Managing artifact interactions with conditions and events . In ACM Intl. Conf. on Dist. Event-based Sys. (DEBS) , 2011 .

10. R. Hull , N. Narendra , and A. Nigam . Facilitating workflow interoperation using artifactcentric hubs . In Proc. Intl. Conf. on Service Oriented Computing (ICSOC) , 2009 .

11. S. Kumaran, P. Nandi , T. Heath , K. Bhaskaran , and R. Das . Adoc-oriented programming . In SAINT , pages 334 - 343 , 2003 .

12. L. Limonad , D. Boaz , R. Hull , R. Vacul´ın, and T. Heath . A generic business artifacts based authorization framework for cross-enterprise collaboration . In SRII Global Conference , pages 70 - 79 , 2012 .

13. F. M. Maggi , M. Dumas , L. Garc´ıa-Ban˜uelos, and M. Montali . Discovering data-aware declarative process models from event logs . In Intl. Conf. on Business Process Management (BPM) , pages 81 - 96 , 2013 .

14. A. Nigam and N. S. Caswell. Business Artifacts : An Approach to Operational Specification . IBM Systems Journal , 42 ( 3 ), 2003 .

15. Team ACSI. ACSI - Artifact-Centric Service Interoperation: Deployment and evaluation of pilots using final ACSI Hub System results and evaluation, April 2013 . http://www.acsi-project. eu/deliverables/ACSI-D5 . 5 - V1 .0.pdf.

16. Team ACSI. ACSI - Artifact-Centric Service Interoperation: Publications in Scientific Journals and Publications , April 2013 . http://www.acsi-project. eu/deliverables/ACSI-D6.3 . 3 - V1 .0.pdf.