supporting the composition of distributed business processes paolo traverso itc-irst
DESCRIPTION
Supporting the Composition of Distributed Business Processes Paolo Traverso ITC-IRST Trento, Italy [email protected]. Context of the talk. Service oriented composition: business models “from products to services” - PowerPoint PPT PresentationTRANSCRIPT
1
Supporting the Composition of Distributed Business Processes
Paolo Traverso ITC-IRST Trento, Italy
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!