automated performance analysis of business processes

Automated Performance Analysis of Business Processes

Paolo Bocciarelli, Andrea D'Ambrogio

Dept. of Enterprise Engineering University of Roma “Tor Vergata”

Roma (Italy)

Mod4Sim 2012 2nd Workshop on Model-driven Approaches for Simulation Engineering

March 27-28, 2012 Orlando, FL, USA

• Motivations and Objectives

• Background concepts:

MDA principles and standards

BP, Service-oriented Architectures (SOAs) and PyBPMN

jEQN language

• Model-driven QoS analysis of BPs

• Detailed view inside the performance prediction step

UML to EQN model-to-model transformation

EQN to jEQN model-to-text transformation

• Example application and validation issues

Agenda

TMS'12

Andrea D’Ambrogio 3

Motivations and Objectives

• Limitations

The use of simulation-based approaches for the BP analysis is

limited in practice. This is mainly due to the required effort and

skills

• Addressed needs

Close the semantic gap between modeling languages for

specifying BPs (e.g., UML or BPMN) and modeling languages for

analyzing the performance of BPs (e.g., Petri Nets, Extended

Queueing Networks, etc.)

Automate the existing approaches to BP simulations that are

mostly manual or show a limited degree of automation

• Proposed contribution

A model-driven method that exploits PyBPMN and jEQN for

integrating performance prediction activities into the BP

development cycle

TMS'12

• MDA Motivation: transfer the focus of work from coding (“everything is an object”) to modeling (“everything is a model”)

• MDA provides a set of guidelines for structuring specifications expressed as models and transformations between such models

• A transformation maps the elements of a source model that conforms to a specific metamodel to elements of another model, the target model, that conforms to the same or to a different metamodel

• MDA provides the following standards:

Meta Object Facility (MOF): for specifying technology neutral metamodels (i.e., models used to describe other models)

XML Metadata Interchange (XMI): provides a set of rules for serializing MOF metamodels

Query/View/Transformation (QVT): language for specifying model transformations

OMG’s MDA principles and standards

TMS'12

• The term Business Process (BP) refers to the set of activities that companies and organizations carry out to provide services or produce goods

• A BP can be seen as a an orchestration of tasks, each one related to the automated or human resources in charge of its execution


Business process and SOA

• The automated execution of tasks within a BP can be based on SOA standards:

SOA standards define a framework that allows the composition of atomic services to define and execute higher level business processes

Web services represent a set of technologies needed to define and invoke remote software services

TMS'12

• This work exploits Performability-enabled Business Process Modeling Notation (PyBPMN), a language to specify QoS properties of BPs

• PyBPMN has been designed as an extension of the Business Process Modeling Notation (BPMN), the standard language for business process modeling promoted by OMG

• According to MDA the extension process:

leverages on MOF (Meta Object Facility) and XMI (XML Metadata Interchange)

is based on a metamodel extension

• The extension specifically addresses:

Performance modeling: UML Profile for Modeling and Analysis of Real-Time Embedded systems (MARTE)

Reliability modeling: research contributions that add the description of reliability properties to MARTE [Petriu, Bernardi and Merseguer, 2008]


Modeling QoS properties of a BP: PyBPMN

TMS'12

• The proposed model-driven method exploits PyBPMN to carry out the automated QoS analysis of a business process and is integrated into a complete model-driven service composition process


Model-driven QoS analysis of BPs: overview

TMS'12

• The performance prediction activity includes the following steps


Model-driven QoS analysis of BPs: performance prediction

the generation of the

EQN model describing

the orchestration of concrete services

the transformation of EQN

model into the jEQN code

the jEQN execution to

derive the performance indices of interest

TMS'12


Metamodel for Extended Queueing Network models

TMS'12

• The UML-to-EQN model transformation has been specified in the QVT language

• The UML model used as input is obtained from the PyBPMN specification

• The mapping of PyBPMN flow elements to UML AD elements, and AD elements to EQN elements are summarized as follows



PyBPMN Element UML Element EQN Element

Closed Workload (associated to Orchestrator)

MARTE annotation (associated to swimlane)

Users/thinkTime parameters (for Closed EQN)

Open Workload (associated to Orchestrator)

MARTE annotation (associated to swimlane)

Distribution of interarrival time (for Open EQN)

Start/End Event Start/Final Node Terminal node (for closed EQN)

Task (associated to Orchestrator

Opaque Action Node Source/Sink node (for open EQN)

Inclusive Diverging Gateway Fork Node Fork Node

Inclusive Converging Gateway Join Node Join Node

Exclusive Diverging/Converging Gateway

Decision Node Router Node

Message Flow/ Sequence Flow Clontrol Flow routing within the EQN

TMS'12

• The mapping of each pair SendTask/ReceiveTask in the PyBPMN model to UML AD and EQN is non-trivial

• To this respect, the proposed EQN model includes two classes of jobs: toServe, to represent jobs which have to be served by a participant, and Served, to model a job just served by a participant



TMS'12

Table 1. Mapping of AD elements to EQN elements

PyBPMN Element UML Element EQN element

Closed Workload MARTE annotation Users and think time parameters

(associated to Orchestrator) (associated to swimlane) (for closed EQN)

Open Workload MARTE annotation Distribution of interarrival time

(associated to Orchestrator) (associated to swimlane) (for ppen EQN)

Start/End Event Start/Final NodeTerminal node (for closed EQN)

Source/Sink node (for open EQN)

Task (associated to Orchestrator) Opaque Action Node request to Orchestrator Service Center

Send Task (associated to Orchestrator)Call Operation Node see Figure 4

Receive Task (associated to Participant

Inclusive Diverging Gateway Fork Node Fork Node

Inclusive Converging Gateway Join Node Join Node

ExclusiveDiverging Gateway Decision NodeRouter Node

ExclusiveConverging Gateway Decision Node

Message FlowControl Flow used for defining the routing within the EQN

Sequence Flow

participant. It should benoted that the router Rforwards

jobs of class " C0" to the Participant Service Center .

Moreover, the access to the Participant Service Center

is controlled by nodes Al l ocat e/Rel ease, in order

to model the capacity of the server which provides

the requested service. Finally, as the job leaves the

Rel ease node, its class is changed to " Ser ved" ,

briefly denoted as " C1" ;

• job passes through the WAN Service Center , to model

the response message that the service provider sends to

the orchestrator;

• job returns to the Or chest r at or Ser vi ce

Cent er ; it should be noted that the router R forwards

all jobs belonging to class " C1" to the Set C0 node

and then to the orchestrator service center .

The parameterization of the EQN model has been

carried out by implementing an algorithm 1 based on the

one specified in [3]. The next Section describes some

implementation issues regarding the EQN- t o- j EQN model-

to-text transformation.

5.2. EQN to jEQN model-to-text transforma-tion

The jEQN code that implements the EQN model is

obtained by use of a model-to-text transformation, which is

specified and implemented by use of standard XML-based

languages and tools, such as XSLT [29].

All elements in the XML document obtained by the

PyBPMN- t o- EQN model transformation can be directly

1The algorithm, that in its original form uses the Extended Execution

Graph formalism to model the process behavior, has been adapted in this

work in order to accept as input an UML AD extended with MARTE

annotations.

ParticipantOrchestrator

Orc

he

str

ato

rP

art

icip

an

t

Attività

ParticpantServiceCenter

TokenPool

allocate

release

WAN

sendTask

receiveTask

set C0

set C1

R

from Orchestrator ServiceCenter

to Orchestrator ServiceCenter

[C1]

[C0]

PyBPMM Model

EQN Model

CallOperationto ParticipantService

PreviousNode

NextNode

PreviousTask

NextTask

AD Model

Figure4. Mapping of SendTask/ReceiveTask pair to EQN

mapped to jEQN classes, except for Terminal and Fork nodes

that, due to design choices of jEQN, are to be managed

differently.

The EQN Terminal node does not have any corresponding

element in jEQN. Terminal nodescan be implemented by use

of the following jEQN classes:

• a Sour ce class, where the

sour ceTer mi nat i onPol i cy attribute value

is equal to N, being N the number of users of the closed

workload;

• an I nf i ni t eSer ver class, whose ser vi ceTi me

corresponds to the thinkTime.

1. job passes through the WAN Service Center, to model the request message that the orchestrator sends to the service provider

2. job passes through the Participant Service Center, to model the service execution performed by the participant

3. jobClass is updated as Served

4. job passes through the WAN Service Center, to model the response message

5. job returns to the Orchestrator Service Center



A request to the next service center is structured as follows:

jobclass is toServe (C0) jobclass is updated to Served (C1) jobclass is updated to toServe (C0)

TMS'12

• jEQN is a Java-based Domain Specific Language (DSL) for the Extended Queueing Network (EQN) domain

• jEQN founds on software engineering best practices, so that it overcomes the limitations of currently available EQN languages (i.e., lack of abstraction, semantic gap between EQN

conceptual model and the simulation language conceptual model, low degree of customizability)

• jEQN is built on top of a software architecture that allows to decouple the simulation logic of each component from the coordination and communication logic of the simulation container

• As a consequence, jEQN supports local or distributed simulation by the transparent use of DS standards

• jEQN source code is available under Open Source GPL v3.0 license

jEQN Overview

http://sites.google.com/site/simulationarchitecture/jeqn

TMS'12


jEQN Architecture

Implementation of the jEQN

Simulation Language

Execution Container

Distributed DES Abstraction

HLA DISAny other Distributed

Simulation Infrastructure

jEQN Simulation

Language Layer

Layer 0(Distributed Simulation

Infrastructure)

Layer 1

Layer 2

Layer 3

Layer 4

LocalEngine DistributedEngine

TMS'12

• The jEQN code that implements the EQN model is obtained by

use of a model-to-text transformation, which is specified and

implemented by use of XSLT

• All elements in the EQN model can be directly mapped to jEQN

classes, except for Terminal and Fork nodes that are to be

managed differently

• The jEQN Fork class has been implemented regardless of any

consideration of routing policy of outcoming jobs: a routing

policy has to be specified by use of a specific Router class

• An EQN Fork node is implemented using the following jEQN

classes

a Fork class

a Router class, whose routingPolicy is set according to specific

needs (the present version adopts a round robin policy)



TMS'12

• The EQN Terminal node does not have any corresponding element in jEQN, so that it has been implemented by use of the following jEQN classes and links:

A Source class, where the sourceTerminationPolicy attribute value is equal to N, being N the number of users of the closed workload

an InfiniteServer class, whose serviceTime corresponds to the thinkTime

All the incoming edges of a Terminal node in the EQN model are mapped to the incoming link of the InfiniteServer



FINITE SOURCE …

INFINITE SERVER

EQN NETWORK

(N users)

(serviceTime = thinkTime)

TERMINAL NODE

TMS'12


Example application:overview

• Let us consider an example application dealing with a business process for checking out orders

• It is supposed that users purchase goods through the following main steps

1. the user navigates in the provider’s catalog and adds the desired items to the basket

2. the user clicks the checkout button to complete the order and pay;

3. the user specifies the information needed to pay (i.e., the credit card number) and to receive the parcel (i.e., address, email contact, etc.)

4. the system computes the total cost, including shipment fares, and prepares the bill

5. the process in charge of providing, preparing and shipping the purchased item is activated

• As regards step 3, it is assumed that payment fails with a probability equal to 10% (in this case the process terminates)

TMS'12

• PyBPMN is used to specify the functional and non-functional requirements of the BP

• BP is designed as an orchestration of the following services:

Payment Manager (PM) service, to provide payment services

Stock Manager (SM) service, to manage the stock and the shipping of the ordered items

BillingManager (BM) service, to provide billing services


Example application: BP specification

TMS'12

• At the second step, the PyBPMN-to-UML model transformation is executed to generate the UML design model

• At the third step, a service discovery is carried out to find a set of concrete services that match the abstract service interfaces specified in the PyBPMN

• As a result, the performance characteristics of the candidate service are available, thus can be included in the UML model by use of SoaML and MARTE profiles


Example application: generation of the UML design model

SM: StockManagerPM: PaymentManagerPurchaseService:

Orchestrator

BM: BillingManager

checkOut

PaymentService

Shipping

Service

[prob=0.9]

[prob=0.3]

<<PaStep>>

<<PaCommStep>>

{hostDemand = ('msr', 'mean', (200,'ms))

msgSize = (250,'KB'),(50,'KB')}

<<PaStep>>

{hostDemand = ('est', 'mean', (2.5,'ms))

<<PaStep>>

<<PaCommStep>>


msgSize = (2,'KB'),(120,'KB')}

Billing

Service

<<PaStep>>

<<PaCommStep>>


msgSize = (50,'KB'),(100,'KB')}

TMS'12

Andrea D’Ambrogio

The performance

prediction is carried

out by first generating

a set of EQN

performance model

that corresponds to

the UML model

representing the

candidate

configurations

20

Example application: generation of the peformance model

TMS'12

• The performance prediction is concluded by executing the jEQN code in order to obtain the performance indices of interest


Example application

To validate the results, a LQN model has been generated for the example case study.

TMS'12

Conclusions

• This paper has introduced a model-driven method to

automate the performance prediction of BPs

• The method makes use of:

PyBPMN, to specify the functional/non functional BP

requirements

UML (with MARTE/SoaML annotations) to specify the design

model

EQN formalism, to specify the BP performance model

jEQN language, to implement/execute the performance model

and yields the performance indices of interest

• The method founds on model-driven standards to automate

model building

• The proposed contribution has been integrated into an

already available method for the QoS prediction of BPs,

which has been used to validate the approach TMS'12

Backup Slides

TMS'12

BPMN extension process

TMS'12

The Business Process Modeling Notation (BPMN) is a standard for the high-level specification of business processes

BPMN: Business Process Modeling Notation

TMS'12

Workload

characterization

Performance/reliability

characterization

PyBPMN extension details

TMS'12

automated performance analysis of business processes

Technology

uml model

jeqn model

model transformation

transformation of eqn

eqn model transformation

source model

model transformationstms12

target model