1

Supporting the Composition of Distributed Business Processes

Paolo Traverso ITC-IRST Trento, Italy

traverso@itc.it

2

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

Context of the talk

3

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

4

Automated Composition Run-time Monitoring Some Applications Future Research Conclusions

Outline

5

Design Time: Automated Compostion

supplier service

supply & pay service

bank service

Inte

ract

ion

Flow

Inte

ract

ion

Flow

Composed

ServiceInte

ract

ion

Flow

Compositionrequirement

6

Interaction Flows and Executable Composed Services in WS-BPEL (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

A Working Hypothesis

7

Design Time: Automated Compostion

supplier service

supply & pay service

bank service

Abstra

ct

BPEL

Abstra

ct

BPEL

Executable

BPELAbst

ract

BPEL

Compositionrequirement

8

Inputs:

1. Interaction Flows (Abstract BPEL) of

a. available component services

b. the desired composed service

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

The Automated Composition Problem

9

Interaction Flows in Abstract BPEL: an Example

10

Interaction Flows in Abstract BPEL (cont.)

11

Interaction Flows as State Transition Systems

We translate Abstract BPEL processes into State Transition Systems

Input actions I (reception of messages)

Output actions O (message sent)

Internal action (internal evolutions that are not visible to external services)

request

Check CC

invalid valid

amount

Availability?

No availability Confirm req

cancel confirm

12

The Composition Problem Revisited

supplier service

supply & pay service

bank service

Compositionrequirements

orderedcancelled

soldcancelled

paidcancelled

13

Inputs:

1. Interaction Flows (Abstract BPEL) of

a. available component services

b. the desired composed service

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

The Automated Composition Problem

14

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

Composition Requirements

15

Control Flow Requirements

supplier service

supply & pay service

bank service

Control Flowrequirements

orderedcancelled

paidcancelled

soldcancelled

Try sold & ordered & paidUpon Failure all cancelled

16

Data Flow Requirements

supplier service

supply & pay service

bank service

Data Flowrequirements

17

Data Flow Requirements: Example

18

Inputs:

1. Interaction Flows (Abstract BPEL) of

a. available component services

b. the desired composed service

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

The Automated Composition Problem

19

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):1. All terminal states satisfy the condition2. If a state belongs to the subgraph, then

a. all outgoing tausb. all outgoing outputsc. one outgoing inputs

belong to the subgraph3. remove non deadlock-free components

Product STSs can be extremely large: we use BDD-based exploration primitives from the “Planning as Model Checking” framework

The Composition Algorithm: Intuitions

?x

?y !a

!b

?z

?w

!c!d

20

Composition Results: Example

21

Composition Results: Example (cont.)

22

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

23

Run-Time Monitoring: Motivations

Need to check the behavior of the partners of a composition, in order to:

detect unexpected changes in the behaviordetect violations to service-level agreements

Need to monitor performance & quality of the composition:

react to business problems and opportunities at real time

24

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

Run-Time Monitoring of Compositions

25

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

Examples of Properties to be Monitored

26

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

Examples of Properties to be Monitored (cont.)

27

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

Run-Time Monitoring of Compositions

28

Architecture for Run-time Monitoring

29

Process Monitoring Console

30

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

31

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

32

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

33

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

34

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

35

War

eho

use

Man

agem

en

t

Tra

nsp

ort

atio

nM

anag

emen

t

Lo

gis

tic

s

ER P

CR

M

Bu

sin

ess

Inte

llig

enc

e

Info

rmat

ion

S

yste

m

(e.g

. S

AP

)

Objectives: Development of “vertical” services for logistics High degree of customizability at low cost Horizontal interoperability with “generic services”

Some Applications: Logistics

36

Ser

vizi

oT

rib

uti

Ser

vizi

oT

eso

reri

a

Ser

vizi

oR

agio

ner

ia

Objectives: e-Government service interoperability Experimented at the local level Synthesis, Analysis and Monitoring of service composition

Some Applications: e-Government

37

Tributi

Ragioneria

Tesoreria

Some Applications: e-Government

38

Objective:

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

Requirement of minimal change of existing legacy systems

Some Applications: e-Government (II)

Ges

tio

ne

Co

ntr

ibu

ti

Ges

tio

ne

Co

nta

bil

e

39

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

Some Future Research Challenges

40

Design Time: requirements R

eq

uir

em

en

tsPro

cess

Need to model services at the requirements level

41

Design Time: “Aspects” of Requirements

42

Design Time: Aspects Oriented Software Engineering

Separate models of the different “aspects” of each service Business logics (central aspects) Transactions, security, reliability… SLA, rules, policies…

Composition of aspect-oriented services Composition of the business logics Composition of the transactional behavior Negotiation of SLAs

Deployment of the executable services BPEL WS-Transaction Monitors

43

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

44

Run Time: Autonomic Composition

Self-* of a service composition Given some business level requirements for the composition,

automatically build the implementation: 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)

But, how much self-*? 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

45

Overall Model: Run Time

EX

EC

UTIO

N

A

uto

nom

ics

MO

DEL

Synthesis Analysis Monitoring

Aspect Oriented Requirements

Enriched Processes

46

Overall Model: Continuous Design

EX

EC

UTIO

NEX

EC

UTIO

N

Au

ton

om

ics

Au

ton

om

ics

MO

DEL

MO

DEL

SynthesisSynthesis VerificationVerification MonitoringMonitoring

Aspect Oriented Requirements

Aspect Oriented Requirements

Enriched ProcessesEnriched Processes

DESIGN

47

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.

48

Conclusions

Thank you for your attention!