This document proposes an architecture for enabling reusable and adaptive modeling, provisioning, and execution of BPEL processes. The architecture supports collaborative, dynamic, and complex systems through reusable process fragments and abstract activities that can be flexibly modeled and executed. It consists of a modeling environment to create and manage process models using fragments, and a runtime environment containing an execution engine, integration layer, and persistence layer to instantiate and execute processes by injecting fragments at runtime. The architecture was evaluated through a use case of modeling and executing payment processes across different transportation systems.
3. Introduction
īĸ The service oriented computing paradigm
ī Development & operation of complex distributed systems
īĸ Application in different areas of the system
īĸ Collaborative, Dynamic, and Complex (CDC) systems
was proposed
ī Adapting with respect to different triggers
ī Modeling, Provisioning and Execution aspects
3
5. Motivation
īĸ Collective Adaptive Systems (CAS) as a type of
CDC systems, CAS consists of
ī Heterogeneous entities
īĸ High influence on the behavior of the system
īĸ Modeling, execution, and adaptation of CAS entities
and their interactions
5
11. īĸ Process Modeler
ī Create process models
ī Manage processes
ī Support operations on running process instance
ī Injection of fragments
īĸ Support the reusability
īĸ Fragment Repository
ī Storage of process fragments
ī Retrieval of process fragments
11
13. īĸ The Integration Layer:
ī Exposes the engine-internal functionality
ī Provides the communication features
īĸ The Workflow Engine API: as an intermediate layer
īĸ The Runtime Layer: provides the core functionality
ī Instantiate and execute a process model
ī Re-executing parts of a running process instance
ī Realize the Injection Framework
īĸ The Persistence Layer: provides database
13
16. īĸ Payment Gateway
ī Concrete
ī Different payment methods
īĸ Abstract the definition of the payment process
īĸ Abstract activity
ī conductPayment
16
19. Conclusion (1/2)
īĸ Collaborative, Dynamic, and Complex (CDC)
systems
ī Application based on complex services
īĸ Abstract activities at the design level
âĸ Flexibility at modeling level
âĸ Reusability across designed models
19
20. Conclusion (2/2)
īĸ Modeling and Runtime environments
ī Deployment of reusable and adaptive processes
ī Execution of reusable and adaptive processes
īĸ Abstract constructs in executable process models
ī Specify process fragment
20
So that why there was need for across-domain solution
The top-down approach, this approach starts with creating the model then providing it to the process engine and then executing the complete or partial designed model
The bottom-up approach, this approach derives the complete or partial designed model used
The adaptation can be performed in any of the life cycle phases
The Integration Layer exposes the engine-internal functionality to the outside, and provides the communication features required by deployed BPEL processes.
Â
The Workflow Engine API comprises a set of APIs for engine-internal operations which are used as an intermediate layer between the Integration Layer and the engine-internal functionalities grouped in the Runtime Layer.
The Persistence Layer provides the execution engine with the database to interpret and persist all execution related information such as deployed process models, running instances information, history of the execution.
The evaluation of the presented approach is performed on a case study scoped in the domain of CAS systems of the Urban Mobility System scenario
in this work we focus entirely on the adaptation and reusability of each entitiesâ behavior which is expressed as process
In this scenario, the userâs preferred payment method is the MasterCard credit card.
When the engine execute the conductPayment activity, the payment method chosen by the user is first analyzed and then retrieved from the fragment repository. After that the engine schedules the execution of the fetched fragment within the running process instance.
Modifications in the process model are propagated to the modeling tool, which also indicates in real time the execution state of each process activity.