• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
S-CUBE LP: Process Performance Monitoring in Service Compositions
 

S-CUBE LP: Process Performance Monitoring in Service Compositions

on

  • 452 views

 

Statistics

Views

Total Views
452
Views on SlideShare
358
Embed Views
94

Actions

Likes
0
Downloads
5
Comments
0

1 Embed 94

http://vc.infosys.tuwien.ac.at 94

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    S-CUBE LP: Process Performance Monitoring in Service Compositions S-CUBE LP: Process Performance Monitoring in Service Compositions Presentation Transcript

    • S-Cube Learning Package Process Performance Monitoring in Service CompositionsUniversity of Stuttgart (USTUTT), TU Wien (TUW) Branimir Wetzstein, USTUTT www.s-cube-network.eu
    • Learning Package Categorization S-Cube Adaptable Coordinated Service Compositions Adaptable and QoS-aware Service Compositions Process Performance Monitoring in Service Compositions
    • Learning Package Overview Problem Description Process Performance Monitoring in Service Compositions Discussion Conclusions
    • Let’s Consider a Scenario (1) Assume a reseller who has implemented a business process as a service composition He interacts with external services of customer, suppliers, shipper, bank, etc. in a service choreography
    • Let’s Consider a Scenario (2) The reseller is interested in measuring the process performance of his own internal business process  Process performance metrics (PPMs) based on time, cost, quality, customer satisfaction dimensions – Order Fulfillment Lead Time, Perfect Order Fulfillment (in time and in full), Customer Complaint Rate, …  QoS metrics, evaluating characteristics of the process execution infrastructure, e.g. availability of the service endpoints, … Listener Service Monitor Dashboard Event Metric definitions Reseller Event Metrics Database QoS Monitor
    • Let’s Consider a Scenario (3) The reseller is also interested monitoring across public partner processes in the choreography Process Tracking: – Partners want to track the state of the choreography beyond their own process – Example: Customer wants to track its shipment (Amazon-DHL Example) - Where is my shipment at the moment? Customer Reseller Shipper Get Order Status Get Shipment Status Event Event Event Event Event Queues / Topics
    • Let’s Consider a Scenario (4) The reseller is also interested monitoring across public partner processes in the choreography Evaluate cross-partner metrics for evaluation of KPIs and SLAs – E.g., order fulfilment lead time –  Gather and correlate events from different processes Customer Reseller Event Event CEP Event
    • Learning Package Overview Problem Description Process Performance Monitoring in Service Compositions Discussion Conclusions
    • Event-Based Monitoring of BPELService Orchestrations Our monitoring approach for service orchestrations supports: – Process Performance Metrics (PPMs) based on process events (BPEL event model) – QoS metrics based on QoS events provided by QoS monitors – Correlation of Process events and QoS events – Metric calculation based on Complex Event Processing (ESPER) Listener Service Event Complex Event Dashboard Processing Process Engine Metric definitions Event Metrics QoS Monitor Database Event Other Event Sources
    • BPEL Monitoring Mechanisms BPEL engines typically support following monitoring mechanisms: – Events are published (asynchronously) to message queues and topics which external monitors can subscribe to – Events are stored persistently in an audit trail (database) – A monitoring interface which enables active querying of information on deployed processes and running process instances Supported events are defined in an Event Model – Unfortunately, however, there is NO standard BPEL event metamodel  Every BPEL engine provides different types of events – Some BPEL engines support also (synchronous) blocking events; the execution of the process instance is halted until it is unblocked by an incoming message – Most BPEL engines enable configuring an event filter for a process model (using a deployment descriptor)  thus only needed events are published at runtime which improves performance!
    • Background:BPEL 2.0 Event Model BPEL 2.0 Event Model contains: – State Models - Separate state models for instances of following elements: Process, Activity, Scope Activity, Loop Activity, Invoke Activity, Link, Variable, Partner Link, Correlation Set - Transitions between States are denoted by different types of Events – Event Contents - Event attributes, in particular the different IDs which identify the corresponding element in the process instance Kopp, Oliver; Henke, Sebastian; Karastoyanova, Dimka; Khalaf, Rania; Leymann, Frank ; Sonntag, Mirko; Steinmetz, Thomas; Unger, Tobias; Wetzstein, Branimir: An Event Model for WS-BPEL 2.0, Technical Report No. 2011/07, University of Stuttgart.
    • Background:Example: BPEL Activity State Model
    • Background:Event Contents An event contains following information: – event name – creation timestamp – IDs which enable assignment of the event to the corresponding BPEL element instance – other information, e.g. variable value BPEL element Needed identifiers Process Model • QName of the process model • version number of the process model Process Instance • globally unique instance ID of the process instance Activity Instance • An XPath expression, which uniquely identifies the construct in the process model • Globally unique instance ID of the process instance • Unique instance ID of the innermost scope instance, where the activity is nested in • unique instance ID of the activity instance Link, Variable, Partner • unique instance ID of the process instance Link, Correlation Set • unique instance ID of the scope where the element is declared Instances • an XPath expression uniquely identifying the construct in the process model
    • Correlation of BPEL Events Calculation of BPEL process instance metrics can be done based on instance IDs set by the BPEL engine SELECT e2.timestamp – e1.timestamp FROM Activity_Executing e1, Activity_Completed e2 WHERE e1.pname=„POProcess“ AND e1.aname=„Receive Order“ AND e2.aname=„Ship Order“ AND e1.pid = e2.pid When, however, the BPEL process is not the only event source, other correlation tokens have to be chosen: SELECT e2.timestamp – e1.timestamp FROM Activity_Executing e1, Variable_Modification e2, Order_Shipped e3 WHERE e1.pname=„POProcess“ AND e1.aname=„Receive Order“ AND e2.vname=„Order“ AND e1.pid = e2.pid AND e2.orderId = e3.orderId
    • Monitoring of Process PerformanceMetrics (PPMs) PPMs are metrics defined based on runtime events of processes – We focus here on runtime events of WS-BPEL service orchestrations, but in general our approach supports arbitrary events of information systems participating in the business process We distinguish between resource events and complex events – Resource event definitions specify (based on the BPEL event model) which raw events we need from the BPEL engine – Complex events are defined (recursively) based on other events and are used for PPM calculation
    • Definition of Resource Events A resource event definition specifies the following three elements: – Monitored resource: concrete BPEL entity instance + which states (as defined in the BPEL event model) – Process data: Optionally, one can specify which process data (defined as WS- BPEL variable) is to be part of the event. The data is read when the event is published. – Target message queue or pub/sub topic <resourceEventDefinition name="OrderReceivedEvent"> <monitoredResource process="reseller:PurchaseOrderProcess" scope="process" activity="reseller:ReceivePO" state="completed"/> <data> <processVariable name="order" variable="purchaseOrder"/> </data> <publish> <queue name="PurchaseOrderProcess.ResourceEvents" /> </publish> </resourceEventDefinition>
    • Definition of Complex Events Complex events are specified by correlating and aggregating existing events (resource and complex events) A complex event definition specifies the following three elements: – Consumed events: source event queue(s) and/or topic(s) – Event aggregation statement: CEP statement which correlates and aggregates the consumed events to a new event – Target message queue or pub/sub topic <complexEventDefinition name="OrderFulfillmentTimeEvent"> <consume><queue name="PurchaseOrderProcess.ResourceEvents" /></consume> <eventAggregation> <statement><![CDATA[ SELECT abs(b.timestamp - a.timestamp) AS metricValue, "ms" AS unit, a.piid AS piid FROM PATTERN [EVERY a = ResourceEvent(name="OrderReceivedEvent") -> b = ResourceEvent(name="ReceivedDeliveryNotificationEvent" AND piid = a.piid) ] ]]><statement> </eventAggregation> <publish> <topic name="PurchaseOrderProcess.metrics" /> </publish> </complexEventDefinition>
    • Monitoring QoS Metrics In our context, QoS can be measured in three different ways: – probing by a separate QoS monitor (e.g., probing whether an endpoint is available, see example below) – instrumentation of the WS-BPEL engine – instrumentation of the WS-BPEL process (evaluating QoS parameters using PPMs, e.g. response times of WS can be estimated through WS-BPEL activity durations) <QoSEventDefinition name="ProcessEndpointAvailableEvent"> <availabilityProbe> <endpoint> http://localhost:8082/.../poProcess?wsdl </endpoint> <testFrequencyPerMinute>20</testFrequencyPerMinute> </availabilityProbe> <publish> <queue name="PurchaseOrderProcess.QoSEvents" /> </publish> </QoSEventDefinition>
    • Correlation of PPMs and QoS Metrics If QoS events do not contain corresponding process instance identifiers, then correlation with process events is typically done based on time periods… <complexEventDefinition name="ProcessInstanceAvailableEvent"> <consume>...</consume> <eventAggregation> <statement><![CDATA[ SELECT begin.piid as piid, q.available as available from PATTERN [ begin=ResourceEvent(name="OrderProcessingStartedEvent") -> q=QoSEvent(name="ProcessEndpointAvailableEvent") UNTIL end=ResourceEvent(name ="OrderProcessingCompletedEvent" AND piid = begin.piid ) ]]><statement> </eventAggregation> <publish> <topic name="PurchaseOrderProcess.metrics" /> </publish> </complexEventDefinition> © Branimir Wetzstein
    • Deployment and Monitoring Deployment of the monitor model:  Resource event definitions are deployed to Event Listener in the BPEL Engine (Apache ODE), QoS Monitor, and other arbitrary event adapters  Complex event definitions are deployed to the ESPER CEP Engine Listener Service Event Complex Event Dashboard Processing Process Engine Metric definitions Event Metrics QoS Monitor Database Event Other Event Sources
    • Cross-Process Monitoring in ServiceChoreographies (1) © Branimir Wetzstein
    • Cross-Process Monitoring in ServiceChoreographies (2) For specification of monitoring solutions across partners, a single BPEL process is no more enough – We now use a service choreography description as basis – A service choreography model is an agreement between partners on their public processes and message exchanges We base our approach on a BPEL4Chor description – Each partner exposes an abstract BPEL process – A topology document specifies how these abstract processes are connected together by message links On top of the BPEL4Chor we specify a monitoring agreement – Similar to the monitor model specified for one BPEL process – An XML-based document specifying which resource events and complex events the partners have to provide © Branimir Wetzstein
    • Monitoring Agreement (MA) An MA consists of : – Resource event definitions based on the BPEL event model and abstract processes of the BPEL4Chor model – Complex event definitions based on other event defining event aggregation statements (in ESPER) <monitoringAgreement xmlns:chor="http://purchaseOrder/choreography" xmlns:reseller="http://purchaseOrder/reseller"> <resorceEventDefinitions> <resourceEventDefinition name="OrderReceivedEvent">… </resourceEventDefinition> ... <resorceEventDefinitions> <complexEventDefinitions> <complexEventDefinition providedBy="reseller“ name="CustomerAOrderReceivedEvent" choreography="chor:orderChoreography">… </complexEventDefinition> ... </complexEventDefinitions> <monitoringAgreement> © Branimir Wetzstein
    • Event Correlation in Choreographies In order to be able to perform event correlation for monitored resources, corresponding resource identifiers have to be included in events – For choreography instances, additional choregraphy model and instance identifier have to be included into events In addition, those two identifiers have to be transported in message interactions, e.g., as part of SOAP Header <soap:header > <chor:choreography xmlns:chor =" http: // iaas / monitoring / choreography "> <chor:cid >{http: //.../ choreography } orderChoreography </ chor:cid > <chor:ciid >{...} orderChoreography /2009 -11 -02 -12 :05:21:005</ chor:ciid > </ chor:choreography > ... </ soap:header > © Branimir Wetzstein
    • Prototype Implementation A prototype has been implemented based on… – Apache ODE BPEL Engine: A new Event Listener is configured based on resource event definitions – ESPER CEP Engine © Branimir Wetzstein
    • Learning Package Overview Problem Description Process Performance Monitoring in Service Compositions Discussion Conclusions © Philipp Leitner
    • Discussion - Advantages The Event-based Monitoring Approach based on a state-of- the-art CEP engine has the following advantages: – Complex Computations– A state-of-the-art CEP language is more powerful than most domain-specific or specialized monitoring languages – High throughput, low latency – provided by the underlying CEP engine implementation – Support for arbitrary events – Process events based on BPEL event model and some QoS events are directly supported
    • Discussion - Disadvantages … but of course the approach also has some disadvantages. – Specification of Monitored Properties – is relatively time-consuming and error-prone because of the relatively low-level language – Transactionality and Persistence – during event processing is not directly supported
    • Learning Package Overview Problem Description Process Performance Monitoring in Service Compositions Discussion Conclusions © Philipp Leitner
    • Summary Event-based Monitoring of processes based on BPEL and BPEL4Chor Models Monitor model specifies: 1. Resource events which should be provided by BPEL engine (based on BPEL event model) or QoS monitor 2. Complex events which specify higher-level monitored properties based on an event processing language (ESPER EPL) Monitoring across processes: – Choreography model with public process descriptions as basis – Extensions for choreography instance identification in message and event exchanges needed
    • Further S-Cube ReadingWetzstein, Branimir; Leitner, Philipp; Rosenberg, Florian; Dustdar, Schahram; Leymann, Frank: IdentifyingInfluential Factors of Business Process Performance Using Dependency Analysis. In: Enterprise InformationSystems. Vol. 5(1), Taylor & Francis, 2010.Wetzstein, Branimir; Karastoyanova, Dimka; Kopp, Oliver; Leymann, Frank; Zwink, Daniel: Cross-Organizational Process Monitoring based on Service Choreographies. In: Proceedings of the 25th AnnualACM Symposium on Applied Computing (SAC 2010); Sierre, Switzerland, 21-26 March, 2010.Kopp, Oliver; Henke, Sebastian; Karastoyanova, Dimka; Khalaf, Rania; Leymann, Frank ; Sonntag, Mirko;Steinmetz, Thomas; Unger, Tobias; Wetzstein, Branimir: An Event Model for WS-BPEL 2.0, Technical ReportNo. 2011/07, University of Stuttgart.Wetzstein, Leitner, Rosenberg, Brandic, Dustdar, and Leymann. Monitoring and Analyzing Influential Factorsof Business Process Performance. In Proceedings of the 13th IEEE international conference on EnterpriseDistributed Object Computing (EDOC09). IEEE Press, Piscataway, NJ, USA, 118-127.Wetzstein, Branimir; Strauch, Steve; Leymann, Frank: Measuring Performance Metrics of WS-BPEL ServiceCompositions. In: Proceedings of the Fifth International Conference on Networking and Services (ICNS 2009),Valencia, Spain, April 20-25, 2009.
    • Acknowledgements The research leading to these results has received funding from the European Community’s Seventh Framework Programme [FP7/2007-2013] under grant agreement 215483 (S-Cube). © Philipp Leitner