Automated Performance Analysis of Business Processes


Published on

Presentation at the 2nd International Workshop on Model-driven Approaches for Simulation Engineering

(held within the SCS/IEEE Symposium on Theory of Modeling and Simulation part of SpringSim 2012)

Please see: for further details

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Automated Performance Analysis of Business Processes

  1. 1. Mod4Sim 20122nd Workshop on Model-driven Approaches for Simulation Engineering March 27-28, 2012 Orlando, FL, USA Automated Performance Analysis of Business Processes Paolo Bocciarelli, Andrea DAmbrogio Dept. of Enterprise Engineering University of Roma “Tor Vergata” Roma (Italy)
  2. 2. Agenda • 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 issuesTMS12
  3. 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 cycleTMS12 Andrea D’Ambrogio 3
  4. 4. OMG’s MDA principles and standards • 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 transformationsTMS12
  5. 5. Business process and SOA• 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• 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 servicesTMS12 Andrea D’Ambrogio 5
  6. 6. Modeling QoS properties of a BP: PyBPMN • 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]TMS12 Andrea D’Ambrogio 6
  7. 7. Model-driven QoS analysis of BPs: overview • 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 processTMS12 Andrea D’Ambrogio 7
  8. 8. Model-driven QoS analysis of BPs: performance prediction • The performance prediction activity includes the following steps  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 interestTMS12 Andrea D’Ambrogio 8
  9. 9. Metamodel for Extended Queueing Network modelsTMS12 Andrea D’Ambrogio 9
  10. 10. UML to EQN model-to-model transformation • 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 MARTE annotation Users/thinkTime 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 Open EQN) Start/End Event Start/Final Node Terminal node (for closed EQN) Task Source/Sink node Opaque Action Node (associated to Orchestrator (for open EQN) Inclusive Diverging Gateway Fork Node Fork Node Inclusive Converging Gateway Join Node Join Node Exclusive Diverging/Converging Decision Node Router Node Gateway Message Flow/ Sequence Flow Clontrol Flow routing within the EQNTMS12 Andrea D’Ambrogio 10
  11. 11. UML to EQN model-to-model transformation • 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 participantTMS12 Andrea D’Ambrogio 11
  12. 12. ged to " Ser ved" , P UML to EQN model-to-model transformation ce Center, to model A request to the next service center is structured as follows: ce provider sends to EQN Model 1. job passes through the WAN release Service Center, to model the set C1 request message that the r at or Ser vi ce to the orchestrator sends Token Poolhe router R forwards service provider from Orchestrator o 2. job passes through the the Set C0 node ServiceCenter R [C0] Participant Service Center, to center. WAN [C1] allocate Particpant ServiceCenter model the service execution to Orchestrator ServiceCenter performed by the participant set C0N model has been 3. jobClass is updated as Served thm 1 based on the 4. job passes through the Figur e 4. Mapping of SendTask/ReceiveTask p WAN on Service Center, to model the describes someN- t response message o- j EQN model- jobclass is updated to toServe (C1) jobclass is updated (C0) toServe to Served (C0) 5. job returns to the Orchestrator Service Center mapped to jEQN classes, except for Terminal and that, due to design choices of jEQN, are to ext tr ansfor ma- TMS12 Andrea D’Ambrogio differently. 12
  13. 13. jEQN Overview • 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
  14. 14. jEQN Architecture Layer 4 jEQN Simulation Language Layer Layer 3 Implementation of the jEQN Simulation Language Layer 2 Execution Container LocalEngine DistributedEngine Layer 1 Distributed DES Abstraction Layer 0 Any other Distributed (Distributed Simulation HLA DIS Simulation Infrastructure Infrastructure)TMS12 Andrea D’Ambrogio 14
  15. 15. EQN to jEQN model-to-text transformation • 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)TMS12 Andrea D’Ambrogio 15
  16. 16. EQN to jEQN model-to-text transformation • 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 TERMINAL NODE EQN FINITE NETWORK … SOURCE (N users) INFINITE SERVER (serviceTime = thinkTime)TMS12 Andrea D’Ambrogio 16
  17. 17. 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)TMS12 Andrea D’Ambrogio 17
  18. 18. Example application: BP specification • 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 servicesTMS12 Andrea D’Ambrogio 18
  19. 19. Example application: generation of the UML design model • 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 PurchaseService: PM: PaymentManager BM: BillingManager SM: StockManager Orchestrator <<PaStep>> {hostDemand = (est, mean, (2.5,ms)) <<PaStep>> <<PaCommStep>> checkOut {hostDemand = (msr, mean, (200,ms)) msgSize = (250,KB),(50,KB)} PaymentService <<PaStep>> <<PaCommStep>> {hostDemand = (msr, mean, (250,ms)) msgSize = (2,KB),(120,KB)} <<PaStep>> [prob=0.9] <<PaCommStep>> {hostDemand = (msr, mean, (300,ms)) msgSize = (50,KB),(100,KB)} [prob=0.3] Shipping Billing Service ServiceTMS12 Andrea D’Ambrogio 19
  20. 20. Example application: generation of the peformance model The performance prediction is carried out by first generating a set of EQN performance model that corresponds to the UML model representing the candidate configurationsTMS12 Andrea D’Ambrogio 20
  21. 21. Example application • The performance prediction is concluded by executing the jEQN code in order to obtain the performance indices of interest To validate the results, a LQN model has been generated for the example case study.TMS12 Andrea D’Ambrogio 21
  22. 22. 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 approachTMS12
  23. 23. Backup SlidesTMS12
  24. 24. BPMN extension processTMS12
  25. 25. BPMN: Business Process Modeling Notation The Business Process Modeling Notation (BPMN) is a standard for the high-level specification of business processesTMS12
  26. 26. PyBPMN extension details Workload characterization Performance/reliability characterizationTMS12