s-cube lp: process performance monitoring in service compositions
Post on 10-Dec-2014
571 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related