www.s-cube-network.eu

S-Cube Learning Package

Process Performance Monitoring in Service Compositions

University of Stuttgart (USTUTT), TU Wien (TUW)

Branimir Wetzstein, USTUTT

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, …

Reseller

Lis

tener

Dashboard

QoS Monitor

Monitor

Metric

definitions

Metrics

Database

Service

Event

Event

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

Queues /

Topics

Event Event

Get Order Status

Get Shipment Status

Event Event

Event

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

CEP

Event

Event

Learning Package Overview

Problem Description

Process Performance Monitoring in Service

Compositions

Discussion

Conclusions

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)

Process Engine

Lis

tener

Dashboard

QoS Monitor

Complex Event

Processing

Metric

definitions

Metrics

Database

Service

Event

Event

Other Event

Sources

Event

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

Link, Correlation Set

Instances

• unique instance ID of the process instance

• unique instance ID of the scope where the element is declared

• 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

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, Activity_Completed e2

WHERE e1.pname=„POProcess“ AND

e1.aname=„Receive Order“ AND

e2.aname=„Ship Order“ AND

e1.pid = e2.pid

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

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…

© Branimir Wetzstein

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

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

Process Engine

Lis

tener

Dashboard

QoS Monitor

Complex Event

Processing

Metric

definitions

Metrics

Database

Service

Event

Event

Other Event

Sources

Event

Cross-Process Monitoring in Service Choreographies (1)

© Branimir Wetzstein

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

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)

© Branimir Wetzstein

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

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

© Branimir Wetzstein

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

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

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