Supporting the Composition of
Distributed Business Processes
Paolo Traverso
ITC-IRST
Trento, Italy
traverso@itc.it
1
Context of the talk
 Service


oriented composition:
business models “from products to services”
software constructed by composition and configuration of
software services that are available by “third parties”
 Services



as distributed business processes:
services that “do” things, beyond information acquisition
services are very rarely “atomic”
services are processes that require a flow of interaction
 The

challenge:
supporting the composition of distributed business processes that
are available as services
2
Focus of the Talk

Automated Composition at Design Time:
automatic generation of compositions of distributed
business processes from their business
requirements

Run-Time Monitoring during Execution:
run-time (or simulation-time) analysis to detect
violations of expected behaviors or to collect
information about service executions
3
Outline





Automated Composition
Run-time Monitoring
Some Applications
Future Research
Conclusions
4
Design Time: Automated Compostion
Composition
requirement
supplier service
supply & pay service
Composed
Service
bank service
5
A Working Hypothesis

Interaction Flows and Executable Composed Services in WSBPEL (Business Process Execution Language)

BPEL offers a set of core process description concepts that
permit to represent the behavioral aspects of business
process interaction at two level of abstractions:


Interaction Flow in Abstract BPEL: defines the
interaction protocol (or Interface) of a service without
exposing the internal behavior

Composed Service in Executable BPEL: defines the
actual code of a service; it can be deployed and executed on
web service execution engines
Embedding in existing business process development
platforms: Active WebFlow platform http://www.activebpel.org
6
Design Time: Automated Compostion
Composition
requirement
supplier service
supply & pay service
Executable
BPEL
bank service
7
The Automated Composition Problem

Inputs:
1.
2.

Interaction Flows (Abstract BPEL) of
a.
available component services
b.
the desired composed service
Composition requirements
Output:
 Executable Composed Service (Executable BPEL) that, by
interacting with available services (described in abstract
BPEL), makes available an interaction flow (in abstract
BPEL) of the composed service and satisfies the composition
requirements
8
Interaction Flows in Abstract BPEL: an Example
9
Interaction Flows in Abstract BPEL (cont.)
10
Interaction Flows as State Transition Systems
request

We translate Abstract BPEL processes into
State Transition Systems

Input actions I (reception of messages)

Output actions O (message sent)

Internal action
t
invalid
Check CC
valid
amount
t (internal evolutions that
tAvailability?
are not visible to external services)
No availability
cancel
Confirm req
confirm
11
The Composition Problem Revisited
Composition
requirements
supplier service
supply & pay service
cancelled ordered
bank service
cancelled
sold
cancelled
paid
12
The Automated Composition Problem

Inputs:
1.
2.

Interaction Flows (Abstract BPEL) of
a.
available component services
b.
the desired composed service
Composition requirements
Output:
 Executable Composed Service (Executable BPEL) that, by
interacting with available services (in abstract BPEL), makes
available an interaction flow (in abstract BPEL) of the
composed service and satisfies the composition
requirements
13
Composition Requirements
Two Aspects of Composition Requirements
1. Control Flow Requirements: Temporal Conditions on the
flow of the execution
2. Data Flow Requirements: requirements on data that are
exchanged among component services
14
Control Flow Requirements
Control Flow
requirements
supplier service
supply & pay service
cancelled ordered
Try sold & ordered & paid
Upon Failure all cancelled
cancelled
bank service
sold
cancelled
paid
15
Data Flow Requirements
Data Flow
requirements
supplier service
supply & pay service
bank service
16
Data Flow Requirements: Example
17
The Automated Composition Problem

Inputs:
1.
2.

Interaction Flows (Abstract BPEL) of
a.
available component services
b.
the desired composed service
Composition requirements
Output:
 Executable Composed Service (Executable BPEL) that, by
interacting with available services (in abstract BPEL), makes
available an interaction flow (in abstract BPEL) of the
composed service and satisfies the composition
requirements
18
The Composition Algorithm: Intuitions

The Parallel Product of the State Transitions Systems (STSs) of
Available Interaction Flows (Components + Composed)

Search the Product STS to satisfy the Composition Requirement

Find a subgraph of the Product STS which satisfies the following
conditions (example with reachability condistion):

?z
All terminal states satisfy the condition
t
2. If a state belongs to the subgraph, then
?w
?x
a.
all outgoing taus
t
b.
all outgoing outputs
!d
!a
?y
!c
c.
one outgoing inputs
!b
belong to the subgraph
3. remove non deadlock-free components
Product STSs can be extremely large: we use BDD-based exploration
primitives from the “Planning as Model Checking” framework
1.
19
Composition Results: Example
20
Composition Results: Example (cont.)
21
Focus of the Talk

Automated Composition at Design Time:
automatic generation of compositionsof distributed
business processes from their business
requirements

Run-Time Monitoring during Execution:
run-time (or simulation-time) analysis to detect
violations of expected behaviors or to collect
information about service executions
22
Run-Time Monitoring: Motivations
 Need to check the behavior of the partners of a composition,
in order to:
 detect unexpected changes in the behavior
 detect violations to service-level agreements
 Need to monitor performance & quality of the composition:
 react to business problems and opportunities at real time
23
Run-Time Monitoring of Compositions
Inputs:
 A set of component services (defined as Abstract BPEL
interfaces)…
 A composed service (defined as Executable BPEL) …
 A monitoring specification
Output:
 Notification of violation of expected behavior …
 Notification of situations of interest …
 Aggregated/statistical information on process(es) behaviours
24
Examples of Properties to be Monitored

Check if the partners respect the expected behaviors:
 The Bank does not refuse the credentials of the Store

Statistical and performance information:
 Count the number of times a given event occurs
 Count the number of items offered to the Client before
the Client accepts to buy
 Measure durations and time intervals
 Measure the time requested to finalize the payment
with the Bank
Properties Related to Single Process Instance
25
Examples of Properties to be Monitored (cont.)

Aggregated information on correct behavior
 The Bank never refuses the credentials of the Store

Aggregated performance measurement
 Average duration of the interactions with the Bank for
the payment procedure

QOS

The average time required by the Bank to complete the
payment procedure should be less than 1500 ms
Properties Related to Process Classes
26
Run-Time Monitoring of Compositions

Monitors are programs executed in parallel to BPEL processes
 They intercept messages from/to these processes
 They report boolean or statistical information

Instance monitor: associated to a specific instance of a BPEL process
 Violation of interaction protocols
 Violation of functional requirements
 Performance analysis

Class monitor: associated to all instances of a BPEL process
 Aggregated information on protocol/requirements violations
 Statistical information on process behavior
 QoS

Monitors can be:
 written by hand, or
 generated from a high-level description of the condition to be detected
27
Architecture for Run-time Monitoring
28
Process Monitoring Console
29
Monitor Specification Language

The language is defined in 3 steps:
 events specification
 allows to specify the events that are relevant for the monitor
evolution
 instance level formulas
 specifies boolean/numerical formulas on process instances
corresponding to suitable patterns of events
 class level formulas
 specifies boolean/numerical formulas on process classes by
aggregating instance level formulas
30
Instance Level Properties: Examples

The Bank does not refuse the credentials (account no) of the Store
! O (msg(Bank.output = invalid_target_account))

Count the number of items offered to the Client before the Client
accepts to buy
O (msg(Client.output = buy)) ?
count(msg(Client.output = refuse_offer)) : 0

Measure the time requested to finalize the payment with the Bank
time((msg(Bank.output = ok) | msg(Bank.output = error))
S msg(Bank.input = start_payment))
31
Class Level Properties: Examples

The Bank never refuses the credentials of the Store
AND (! O (msg(Bank.output = invalid_target_account)))

Average duration of the interactions with the Bank for the
payment procedure
AVG (time((msg(Bank.output = ok) | msg(Bank.output = error))
S msg(Bank.input = start_payment))

The average time required by the Bank to complete the
payment procedure should be less than 1500 ms
AVG (time((msg(Bank.output = ok) | msg(Bank.output = error))
S msg(Bank.input = start_payment)) < 1500
32
Monitor Generation

Based on standard techniques for mapping temporal logics into
finite state automata

Necessity to deal with enriched automata:



we have to take into account numerical values, not only booleans
updates of class monitors depend on updates of the associated
instance monitors
These enriched automata are then emitted as Java code
33
Some Industrial Projects and Collaborations

Logistics: Opera 21

e-Banking: Monte dei Paschi, BPVR

Telcos: Telecom Italia, DocomoLab Europe

e-Ambient: Siemens, Heidi

e-Government: Engineering spa, SAP, DeltaDator, Italian and
Regional Government
34
Some Applications: Logistics
Business
Intelligence
CRM
ERP
Information System
(e.g. SAP)
Transportation
Management
Warehouse
Management
Objectives:
 Development of “vertical” services for logistics
 High degree of customizability at low cost
 Horizontal interoperability with “generic services”
Logistics

35
Some Applications: e-Government
Servizio
Ragioneria
Servizio
Tesoreria
Objectives:
 e-Government service interoperability
 Experimented at the local level
 Synthesis, Analysis and Monitoring of service composition
Servizio
Tributi

36
Some Applications: e-Government
Tributi
Tesoreria
Ragioneria
37
Some Applications: e-Government (II)
Objective:

Requirement of minimal change of existing legacy systems
Gestione
Contabile
process monitoring for governance and notification, e.g.,
 Number of instances involved in different processes
 Statistics and timing of different phases of the processes
 Governance and notification of critical situations,
 Notification of the status of the procedures
Gestione
Contributi

38
Some Future Research Challenges

Present: automated tools that perform time consuming and error
prone tasks (e.g., detailed analysis, detect interaction problems,
monitor execution step by step,...)
 Automated Composition
 Automated Analysis
 Run-Time Monitoring

Future: supporting the life-cycle of Web services
 Design-time (off-line):
 Aspect oriented service engineering
 Run-time:
 “Bounded” autonomics
39
Design Time: requirements
Need to model services at the requirements level
Process
Requirements

40
Design Time: “Aspects” of Requirements
41
Design Time: Aspects Oriented Software Engineering

Separate models of the different “aspects” of each service




Composition of aspect-oriented services




Business logics (central aspects)
Transactions, security, reliability…
SLA, rules, policies…
Composition of the business logics
Composition of the transactional behavior
Negotiation of SLAs
Deployment of the executable services



BPEL
WS-Transaction
Monitors
42
Run Time: Autonomics

Autonomic systems: systems able to adapt themselves without the
intervention of humans




self-configuration
self-optimization
self-healing
self-adaptation

Autonomic services: apply this concept to web services

At the moment: focus on the “technical” aspects of service interactions





Detection of failures in external services
Automated optimization of number of trials
Load distribution among different service providers
…
Challenge: move autonomics at the “service” level
43
Run Time: Autonomic Composition

Self-* of a service composition

Given some business level requirements for the composition,
automatically build the implementation:





But, how much self-*?




combine in suitable ways the participating services (self-configuring
composition)
guarantee the maximization of some expected reward (self-optimizing
composition)
detect requirements that are no longer satisfied (self-healing composition)
adapt to unexpected changes in external services (self-adapting composition)
Unbounded autonomics is dangerous
Autonomic compositions should not take strategic decisions
The control should be in the hand of the analysts
Bounded autonomics:


Set clear bounds to the self-* of a systems
Requirements are needed to define these bounds
44
Overall Model: Run Time
MODEL
Synthesis
Analysis
Monitoring
EXECUTION
Autonomics
Aspect Oriented
Requirements
Enriched Processes
45
Overall Model: Continuous Design
DESIGN
MODEL
Synthesis
Verification
Monitoring
EXECUTION
Autonomics
Aspect Oriented
Requirements
Enriched Processes
46
Some References (see also http://astroproject.org)

Automated Composition






P. Traverso and M. Pistore. Automated Composition of Semantic Web
Services into Executable Processes. ISWC 2004
M. Pistore, P. Traverso, P. Bertoli, and A. Marconi. Synthesis of
Composite BPEL4WS Web Services. IEEE ICWS 2005.
M. Pistore, A. Marconi, P. Bertoli, and P. Traverso. Automated
Composition of Web Services by Planning at the Knowledge Level.
IJCAI 2005.
M. Pistore, L. Spalazzi, and P. Traverso. A Minimalist Approach to
Semantic Annotations for Web Processes Compositions. ESWC 2006.
A. Marconi, M. Pistore, P. Traverso. Specifying Data-Flow
Requirements for the Automated Composition of Web Services. IEEE
SEMF’06.
Monitoring


F. Barbon, P. Traverso, M. Pistore, and M. Trainotti. Run-Time
Monitoring of the Execution of Plans for Web Service Compositions.
ICAPS 2006.
F. Barbon, P. Traverso, M. Pistore, and M. Trainotti. Run-Time
Monitoring of Instances and Classes of Web Service Compositions.
IEEE ICWS 2006.
47
Conclusions
Thank you for your
attention!
48