This document describes process performance monitoring in service compositions. It discusses monitoring a single BPEL process using a resource event model and complex event definitions to calculate performance metrics. It also covers monitoring across partner processes by specifying a monitoring agreement based on a BPEL4Chor choreography model. Key events are correlated using identifiers. A prototype implements monitoring using an Apache ODE BPEL engine and ESPER CEP engine.

1. S-Cube Learning Package
Process Performance Monitoring in
Service Compositions
University of Stuttgart (USTUTT), TU Wien (TUW)
Branimir Wetzstein, USTUTT
www.s-cube-network.eu

2. Learning Package Categorization
S-Cube
Adaptable Coordinated
Service Compositions
Adaptable and QoS-aware
Service Compositions
Process Performance Monitoring in
Service Compositions

3. Learning Package Overview
 Problem Description
 Process Performance Monitoring in Service Compositions
 Discussion
 Conclusions

4. 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

5. 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

6. 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

7. 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

8. Learning Package Overview
 Problem Description
 Process Performance Monitoring in Service
Compositions
 Discussion
 Conclusions

9. Event-Based Monitoring of BPEL
Service 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

10. 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!

11. 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.

12. Background:
Example: BPEL Activity State Model

13. 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

14. 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

15. Monitoring of Process Performance
Metrics (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

16. 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>

17. 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>

18. 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>

19. 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

20. 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

21. Cross-Process Monitoring in Service
Choreographies (1)
© Branimir Wetzstein

22. Cross-Process Monitoring in Service
Choreographies (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

23. 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

24. 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

25. 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

26. Learning Package Overview
 Problem Description
 Process Performance Monitoring in Service Compositions
 Discussion
 Conclusions
© Philipp Leitner

27. 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

28. 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

29. Learning Package Overview
 Problem Description
 Process Performance Monitoring in Service Compositions
 Discussion
 Conclusions
© Philipp Leitner

30. 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

31. Further S-Cube Reading
Wetzstein, Branimir; Leitner, Philipp; Rosenberg, Florian; Dustdar, Schahram; Leymann, Frank: Identifying
Influential Factors of Business Process Performance Using Dependency Analysis. In: Enterprise Information
Systems. 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 Annual
ACM 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 Report
No. 2011/07, University of Stuttgart.
Wetzstein, Leitner, Rosenberg, Brandic, Dustdar, and Leymann. Monitoring and Analyzing Influential Factors
of Business Process Performance. In Proceedings of the 13th IEEE international conference on Enterprise
Distributed Object Computing (EDOC'09). IEEE Press, Piscataway, NJ, USA, 118-127.
Wetzstein, Branimir; Strauch, Steve; Leymann, Frank: Measuring Performance Metrics of WS-BPEL Service
Compositions. In: Proceedings of the Fifth International Conference on Networking and Services (ICNS 2009),
Valencia, Spain, April 20-25, 2009.

32. 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