ADAM Seminary

BEHAVIORAL COMPOSITIONS
IN SERVICE
ORIENTED ARCHITECTURE
Sébastien MOSSER,
University of Nice - Sophia Antipolis,
CNRS, I3S Lab, MODALIS Team

ADAM Seminary,
«The North», October 1th, 2010

1

ONCE UPON A TIME ...

a Commercial

an Architect

« Service Oriented Architecture
( S OA ) i s a b u s i n e s s - c e n t ri c I T
architectural approach that supports
integrating your business as linked,
repeatable business tasks, or
services.» (IBM website)

a Commercial

an Architect

« Service Oriented Architecture
( S OA ) i s a b u s i n e s s - c e n t ri c I T
architectural approach that supports
integrating your business as linked,
repeatable business tasks, or
services.» (IBM website)

a Commercial

« Ok, so we will build atomic services and
then implement business processes to
orchestrate them all. It sounds exciting!
Let’s go! »
an Architect

AND THEY ALL LIVED
HAPPILY EVER AFTER ... SURE?
the (same)
Architect

the
(same)Comm

AGENDA
• Context & Problematic

• Contribution:

•a metamodel,

• Several Algorithms

• Validation: Crisis Management Systems

• Perspectives & Conclusions

*
CONTEXT
Business Process Design in Service Oriented Architecture,
towards a Separation of Concerns driven approach.

* : not a state-of-the-art study**

** : but based on the thesis one.

SERVICE ORIENTED
ARCHITECTURES (SOA)
« Service Oriented Architecture is a paradigm for
organizing and utilizing distributed
capabilities that may be under the control of different
ownership domains. It provides a uniform means
to offer, discover, interact with and use
capabilities to produce desired effects
consistent with measurable preconditions and
expectations » [OASIS, 2006]

6

JSEDUITE:
«INFORMATION BROADCAST»

[Brown et al, 98]

7

SERVICE ORIENTED
ARCHITECTURES

Services reﬂect a «service--oriented» approach to
programming, based on the idea of describing
available computational resources, e.g.,
application programs and information system
components, as services that can be delivered
through a standard and well-deﬁned
interface. [Papazoglou, 2008]

8

(WEB) SERVICES
WSDL
XSD

InfoProvider:
getMyInfo: UserId -> Information*

e.g., SOAP UDDI

«standard and well-deﬁned interface»
[Peltz, 03]

9

TECH. VS BUSINESS CONCERNS
• «Technical» concerns integration through WS-*:

• e.g., WS-Security, WS-Authentication, WS-Transactions
[Curbera et al, 03]

• «Business» concerns integration in the composition:

• e.g., promotional offers, new industry partnerships
[Vinosky, 04]

10

BUSINESS PROCESS
user := receive()
Activity Activity
Parallelism
tag := profile::getTag(user)

key:= reg::get(‘twitter’)

tweets:= twitter::read(tag,key)

infos := transform(tweets) Business
Partnership
reply(infos)
11

COMPOSITION OF SERVICES
• «Business Processes» deﬁne the behavior of assemblies

• Activity-based: Invoke a service, assign a value, ...

• Business expressiveness, but still efﬁcient [Glatard, 07]

•

•A real «jungle» of languages:

• Expressiveness benchmarks [van der Aalst, 08]
[Russel et al, 06]

12

*
SO WHAT ?

13 * i.e., «Where is the problem?»

WELCOME TO REALITY !

14 Netbeans 6.5.1 BPEL editor

15
medium business process ...

OPEN ISSUES
Scalability?

Understandability?

Design?

Assessment?
16

TOWARDS A SEPARATION OF
CONCERNS (SOC) APPROACH

• Separation of concerns [Dijkstra, 72]:

• «Build complex things by composing small and simple ones.»

• (Main) existing approaches in the literature:

• Feature - Oriented Programming (FOP) [Batory, 04]

• Aspect - Oriented Programming (AOP) [Kickzales, 01]

17

CONCERNS IN JSEDUITE
• «Essence» of jSeduite:

• Retrieve information to be delivered to a given screen

• Technical concerns:

• e.g., cache, timeout, image compression

• Business concerns:

• e.g., new source of information, cardinality restriction, shufﬂe
towards a Software Product Line ...
18 [Thaker et al, 07]

FOP & AOP IN A FEW WORDS
• Feature - Oriented Programming (focus on «structure»)

• System = Feature 1 ● Feature 2 ● ...

• Based on mathematical ● operator

• Aspect - Oriented Programming (focus on «behavior»)

• System = Base Program + Aspect 1 + Aspect 2 + ...

• Based on a «weave» algorithm, and ordering mechanisms.
19

AOP & FOP FOR SOA ?
Property AOP FOP
P1 Business Expressiveness - +
P2 One cannot ignore reality ~ ~
P3 Concerns reiﬁcation + +
P4 Concerns Behavioral Composition + ~
P5 Activity Parallelism ~ +
P6 Syntax Independence - ~
20

[Charﬁ and Mezzini, 04] [Courbis and Finklestein, 05] [Batory, 07] [Apel et al, 08]

APPLYING SOC TO SOA (1/2)

• Understandability:

•A business expert focuses on his/her own domain.[Stein et al, 08]

• Design:

• Different design strategies may coexists in the company
[Pawlak et al, 05]

21

APPLYING SOC TO SOA (2/2)

• Scalability

• Automatic reasoning leads to optimization [Liu and Batory, 04]

• Assessment

• Composition Conﬂicts may appear (intrinsic to SOC)

[Apel et al, 10]
22

CONTRIBUTION:

an «Activity metamoDel supOrting oRchestration Evolution»

P1 P2 P3
P4 P5 P6
23

REMINDER
SOA Desired Property
P1 Business Expressiveness
P2 One cannot ignore reality
P3 Concerns reiﬁcation
P4 Concerns Behavioral Composition
P5 Activity Parallelism
P6 Syntax Independence

24

RATIONALE

TAMING ORCHESTRATION
DESIGN COMPLEXITY
• Modeler designs incomplete processes (fragments)

• Use case (base process) & extensions, NF properties

• Algorithms build the ﬁnal (complete) process

• Automatic integration & properties preservation (e.g., orders)
25

P1 P2 P3
A (SMALL) METAMODEL
P4 P5 P6

Activities
Processes

Relations

«Concerns «Syntax
reiﬁcation» Independence»

subset of
Variables
«One cannot
ignore reality» BPEL Standard [OASIS, 06] 26

P1 P2 P3
A (SIMPLE) P4 P5 P6
GRAPHICAL SYNTAX
Process Activity

«Business
Relation Expressiveness»

«Activity
Parallelism»

Variable
27

EXECUTION SEMANTICS
• Cutting-Edge approaches:
[Pourraz, 07] [Alloy]
• Process Algebra, Model-Checker

• Executability: Kermeta [Fleurey, 06]

• Logical-based approach

• «Activity-scoped»

• Composition props. deﬁnition

• hard to compute, but simple to check.
example: start(a21) => end(a1) & !val 28

P1 P2 P3
BEHAVIORAL P4 P5 P6
COMPOSITIONS
• An «Action-Based» approach to support compositions
[OMG, 06]
• Elementary actions: add, del [Blanc et al, 08]

• Composite actions: unify, replace, discharge

• Composite actions are «reﬁned» into elementary ones.

• Compositions as «algorithms»

• Algorithms produce «action sets» to be executed.
29

PROCESS NAIVE CORRELATION
A1.
discharge

A2.
a := receive() x:= receive()
unify

b := do(a) y := do(x)

A3.
reply(b) reply(y)
unify
30

ALGORITHM EXECUTION
Naive Correlation Algorithm

+ Action Set

(a,x) := receive()

Execution b := do(a) y := do(x)
Engine
reply(b,y)
31

FORMAL REP. OF ACTIONS
A1
elementary
composite

A2

reﬁnement

A3

32

ACTIONS ADVANTAGES
Input models assumed as «consistent»*

Check Execute Check
Precondition Action Postcondition
Maybe
fail ... Other Actions ... fail Inconsistent

Check Execute Check
Precondition Action Postcondition
... ...
Check Model Invariant «consistent» output
* 21 consistency properties deﬁned in ADORE 33

«ALGORITHM» WRITING

A1 A2 A3
• Many-sorted order logic underlying foundations

• «Logical» expressiveness at the (meta)model level

• Immediate mapping (sort of) into PROLOG
34

ALGORITHM EXECUTION
Naive Correlation Algorithm

+ Action Set

(a,x) := receive()

Execution b := do(a) y := do(x)
Engine
reply(b,y)
35

ALGORITHM EXECUTION
Algorithm X

+ Action Set

Resulting Key Point:
Execution
Engine Model Express «actions».
That’s all!
35

CONTRIBUTION ’:

Several composition algorithms

∏1 ∏2

∏3 ∏4
36

REMINDER
SOC Desired Property

Π1 Concurrent experts support

Π2 Support for multiple composition algorithms

Π3 Composition as ﬁrst class entities

Π4 Conﬂict Detection Mechanisms

37

∏1 ∏2
COMPOSITION ∏3 ∏4
COVERAGE
• Weave: • Inline:

• Integrate
fragments into • Absorb a process into
processes another one
• Blocks, Order independence • Composition efﬁciency
• Merge: • Dataﬂow:

• Shared Join Points • Introduce Loops
• Parallel Composition • Non-expert programming
38

WEAVE PRINCIPLES
[Böllert, 99]

ω(before,{a2}) composition ω(after,{rec})
ω(before,{rpl}) directives ω(after,{a1})
39

DIRECTIVES
INDEPENDENCY
ω ω ω ω

actions actions actions actions
#1 #2 #3 #4

Execution
Engine
40

WEAVE PROPERTIES
Property
Order independence
Determinism
Path preservation
Execution order preservation (*)
Condition preservation (*)
Variable initialization
Process always returns a response

(*) can be explicitly bypassed by the designer 41

MERGE PRINCIPLES
{ ω(bef,{X}), ..., ω(par,{X}), ..., ω(aft,{X}) }

Shared Target

42

∏1 ∏2
HANDLING ∏3 ∏4
SHARED TARGETS
{ ω(bef, {X}), ω(par, {X}), ω(aft, {X}) }

Term rewriting (Algorithm scheduler)

( μ({bef, par, aft}, merged), ω(merged, {X}) )

[Hekel, 02] (Critical Pairs)

The directive pool is automatically analyzed and rewrote 43

MERGED ARTIFACT

Parallel
composition

Deterministic

No unexpected
wait introduction

μ({bef, par, aft}, merged)
44

MERGING VS
ORDERING
• Order - Driven (e.g., AspectJ)

• Multiple possible results (n!)

• Explicit, or chosen

• Merge - Driven (ADORE)

• One single result

• Explicitly unordered
(example from Don Batory) 45

RELATION WITH
STEP-WISE DEVELOPMENT
Shared

Target



  

Explicit Ordering 46

∏1 ∏2
INTERFERENCE ∏3 ∏4
AUTOMATIC DETECTION
• Errors: • Strengths

• Concurrent variable access • Strong support to
designers
• Concurrent error
throwing • Automatic identiﬁcation
• Bad-Smells: • Drawbacks

• Introducing equivalent • Syntactic-only detection *
activities
• Costly graph analysis
• Forgotten weave directive (performances)
* «Nemo auditur propriam turpitudinem allegans» 47

CONCURRENT
THROW: «C & !C’»

48

VALIDATION
A Car Crash Management System

49

CASE STUDY: «CAR CRASH
CRISIS MANAGEMENT SYSTEM»
• TAOSD Special Issue on Aspect Oriented Modeling

• Rationale: A common case study to compare AOM approaches

• Context: Crisis Management System (CMS)

• How to handle a «car crash» crisis?

representation
of
50

OUR APPROACH

Given requirements (pdf)

Textual Use Cases System Actors
as as
Business Processes Atomic Services
51

EX: «CAPTURE WITNESS REP.»
Actors

Main
Success
Scenario

Business
Extensions

52

=> REALIZING THE CCCMS ...
•8 Main Success Scenario:

• e.g., «Capture Witness Report»

• 27 Business Extensions:

• e.g., «Fake Witness Information»

•3 Non-Functional Properties:

• i.e., «security», «persistence», «statistical logging»

http://www.adore-design.org/doku/examples/cccms
53

n ts
8 27 e
m
Scenarios Business Extensions i re
q u
Re
Car Crash Crisis
Management System

3
NF Properties

e ss
c
P ro
e ss
s in
B u

n ts
8 27 e
m
q u
Re
Car Crash Crisis
Management System
12
«designing» δ Processes
3
NF Properties

e ss 12
c Partners
P ro
e ss
s in
B u

n ts
8 27 e
m
q u
Re
Car Crash Crisis ~ 13 000
Management System Actions
12
3 «realizing» ρ
NF Properties
1216
e ss 12 Activities 895
c Partners Relations
P ro
e ss ρ
in 76
us Operations
B

n ts
8 27 e
m
q u
Re
Car Crash Crisis ~ 13 000
Management System Actions
12
3 «realizing» ρ
NF Properties
1216
e ss 12 Activities 895
c Partners Relations
P ro
e ss ρ
in 76 Intrinsic
us Operations
B Parallelism

A USE CASE EXAMPLE

composition cms::captureWitnessReport {
apply callDisconnected => a10;
apply requestVideo(user: 'coord') => {a3,a4};
apply fakeWitnessInfo => a2a3
apply ignoreDisconnection => a4;
apply fakeCrisisDetected => a4;
apply fakeCrisisDetected => requestVideo::a3;
}

55

A USE CASE EXAMPLE
Parameters Weave
composition cms::captureWitnessReport {
apply requestVideo(user: 'coord') => {a3,a4};
apply fakeWitnessInfo => a2a3
apply ignoreDisconnection => a4;
apply fakeCrisisDetected => a4; Merge
apply fakeCrisisDetected => requestVideo::a3;
}
Multiple Use Fragment on
of Fragments Fragment
55

OPENING THE BOX

callDisconnected

fakeWitnessInfo

requestVideo

fakeCrisisDetected

ignoreDisconnection

56

OPENING THE BOX
χ

callDisconnected
χ

fakeWitnessInfo χ

requestVideo χ

χ
fakeCrisisDetected
χ

ignoreDisconnection χ

56

OPENING THE BOX
χ

callDisconnected
χ

fakeWitnessInfo χ

requestVideo χ β

χ
fakeCrisisDetected
χ


56

OPENING THE BOX
χ

callDisconnected
χ

fakeWitnessInfo χ

requestVideo χ β
ω
χ
fakeCrisisDetected
χ
μ

56

OPENING THE BOX
χ

callDisconnected
χ

fakeWitnessInfo χ

requestVideo χ β
ω ω
χ
fakeCrisisDetected
χ
μ

captureWitnessReport
56

CCCMS SUMMARY

Main Success Scenario + Business Extensions

Weave Merge Actions Time

23 5 2422 ~ 5s

Previous System + Non Functional Properties

Weave Merge Actions Time

+ 63 + 33 + 8416 + ~60s
57

Business Extensions

Main Success Non Functional
Scenario 58 Properties

PROCESS COGNITIVE LOAD
Parallelism Max. Length
Width x Height | Paths |

| Activities |
• Hypothesis:

59

OBTAINED RESULTS

60

PERSPECTIVES,
implementation and conclusions!

61

«ONGOING»
PERSPECTIVES
Requirement Link with
Engineering «structure»
Univ. of [AOSD’11] Colorado
Ottawa State Univ.

[SC’10]

Composition
Link with Visualization
Univ. of Texas FOP & Order
Univ. of Chile
at Austin 62

IMPLEMENTATION
E -P
R -

DSL

63

IMPLEMENTATION
-P EL
R -E BP G
P N

L
DSL M
X

63
Mondrian

CONTEXT SUMMARY

• Identiﬁcation of a «real» problem:

• How to design complex business processes?

• Proposition:

• Use a dedicated Separation of Concerns technique

• State-of-the-art study:

• No existing solutions to such a problem (but good leads!)
64

CONTRIBUTION SUMMARY

•A kernel:

• Small metamodel, explicit semantics, strong foundations

• Framework to deﬁne algorithms

• Several Algorithms

• Weave, Merge, Inline & Dataflow

• Scheduling, Intrinsic conﬂict detection mechanisms
65

ANY QUESTIONS? REMARKS?

http://www.adore-design.org

66
Illustrations by C.line

ADAM Seminary

More Related Content

Similar to ADAM Seminary (20)

More from Sébastien Mosser (15)

Recently uploaded (20)

ADAM Seminary