The document describes a case study on a Car Crash Crisis Management System (CCCMS) to validate an approach for behavioral composition in service-oriented architectures. The CCCMS contains 8 main success scenarios, 27 business extensions, and 3 non-functional properties. The scenarios and extensions were modeled as business processes and atomic services respectively, which were then composed together using the proposed algorithms.

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

2. ONCE UPON A TIME ...
a Commercial
an Architect

3. ONCE UPON A TIME ...
« 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

4. ONCE UPON A TIME ...
« 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

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

6. AGENDA
• Context & Problematic
• Contribution:
•a metamodel,
• Several Algorithms
• Validation: Crisis Management Systems
• Perspectives & Conclusions

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

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

9. JSEDUITE:
«INFORMATION BROADCAST»
[Brown et al, 98]
7

10. SERVICE ORIENTED
ARCHITECTURES
Services reflect 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-defined
interface. [Papazoglou, 2008]
8

11. (WEB) SERVICES
WSDL
XSD
InfoProvider:
getMyInfo: UserId -> Information*
e.g., SOAP UDDI
«standard and well-defined interface»
[Peltz, 03]
9

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

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

14. COMPOSITION OF SERVICES
• «Business Processes» define the behavior of assemblies
• Activity-based: Invoke a service, assign a value, ...
• Business expressiveness, but still efficient [Glatard, 07]
•
•A real «jungle» of languages:
• Expressiveness benchmarks [van der Aalst, 08]
[Russel et al, 06]
12

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

16. WELCOME TO REALITY !
14 Netbeans 6.5.1 BPEL editor

17. WELCOME TO REALITY !
14 Netbeans 6.5.1 BPEL editor

18. 15
medium business process ...

19. OPEN ISSUES
Scalability?
Understandability?
Design?
Assessment?
16

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

21. 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, shuffle
towards a Software Product Line ...
18 [Thaker et al, 07]

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

23. AOP & FOP FOR SOA ?
Property AOP FOP
P1 Business Expressiveness - +
P2 One cannot ignore reality ~ ~
P3 Concerns reification + +
P4 Concerns Behavioral Composition + ~
P5 Activity Parallelism ~ +
P6 Syntax Independence - ~
20
[Charfi and Mezzini, 04] [Courbis and Finklestein, 05] [Batory, 07] [Apel et al, 08]

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

25. APPLYING SOC TO SOA (2/2)
• Scalability
• Automatic reasoning leads to optimization [Liu and Batory, 04]
• Assessment
• Composition Conflicts may appear (intrinsic to SOC)
[Apel et al, 10]
22

26. CONTRIBUTION:
an «Activity metamoDel supOrting oRchestration Evolution»
P1 P2 P3
P4 P5 P6
23

27. REMINDER
SOA Desired Property
P1 Business Expressiveness
P2 One cannot ignore reality
P3 Concerns reification
P4 Concerns Behavioral Composition
P5 Activity Parallelism
P6 Syntax Independence
24

28. RATIONALE
TAMING ORCHESTRATION
DESIGN COMPLEXITY
• Modeler designs incomplete processes (fragments)
• Use case (base process) & extensions, NF properties
• Algorithms build the final (complete) process
• Automatic integration & properties preservation (e.g., orders)
25

29. P1 P2 P3
A (SMALL) METAMODEL
P4 P5 P6
Activities
Processes
Relations
«Concerns «Syntax
reification» Independence»
subset of
Variables
«One cannot
ignore reality» BPEL Standard [OASIS, 06] 26

30. P1 P2 P3
A (SIMPLE) P4 P5 P6
GRAPHICAL SYNTAX
Process Activity
«Business
Relation Expressiveness»
«Activity
Parallelism»
Variable
27

31. EXECUTION SEMANTICS
• Cutting-Edge approaches:
[Pourraz, 07] [Alloy]
• Process Algebra, Model-Checker
• Executability: Kermeta [Fleurey, 06]
• Logical-based approach
• «Activity-scoped»
• Composition props. definition
• hard to compute, but simple to check.
example: start(a21) => end(a1) & !val 28

32. 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 «refined» into elementary ones.
• Compositions as «algorithms»
• Algorithms produce «action sets» to be executed.
29

33. PROCESS NAIVE CORRELATION
A1.
discharge
A2.
a := receive() x:= receive()
unify
b := do(a) y := do(x)
A3.
reply(b) reply(y)
unify
30

34. ALGORITHM EXECUTION
Naive Correlation Algorithm
+ Action Set
(a,x) := receive()
Execution b := do(a) y := do(x)
Engine
reply(b,y)
31

35. FORMAL REP. OF ACTIONS
A1
elementary
composite
A2
refinement
A3
32

36. 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 defined in ADORE 33

37. «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

38. ALGORITHM EXECUTION
Naive Correlation Algorithm
+ Action Set
(a,x) := receive()
Execution b := do(a) y := do(x)
Engine
reply(b,y)
35

39. ALGORITHM EXECUTION
Algorithm X
+ Action Set
Resulting Key Point:
Execution
Engine Model Express «actions».
That’s all!
35

40. CONTRIBUTION ’:
Several composition algorithms
∏1 ∏2
∏3 ∏4
36

41. REMINDER
SOC Desired Property
Π1 Concurrent experts support
Π2 Support for multiple composition algorithms
Π3 Composition as first class entities
Π4 Conflict Detection Mechanisms
37

42. ∏1 ∏2
COMPOSITION ∏3 ∏4
COVERAGE
• Weave: • Inline:
• Integrate
fragments into • Absorb a process into
processes another one
• Blocks, Order independence • Composition efficiency
• Merge: • Dataflow:
• Shared Join Points • Introduce Loops
• Parallel Composition • Non-expert programming
38

43. WEAVE PRINCIPLES
[Böllert, 99]
ω(before,{a2}) composition ω(after,{rec})
ω(before,{rpl}) directives ω(after,{a1})
39

44. DIRECTIVES
INDEPENDENCY
ω ω ω ω
actions actions actions actions
#1 #2 #3 #4
Execution
Engine
40

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

46. MERGE PRINCIPLES
{ ω(bef,{X}), ..., ω(par,{X}), ..., ω(aft,{X}) }
Shared Target
42

47. ∏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

48. MERGED ARTIFACT
Parallel
composition
Deterministic
No unexpected
wait introduction
μ({bef, par, aft}, merged)
44

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

50. RELATION WITH
STEP-WISE DEVELOPMENT
Shared

Target

  
Explicit Ordering 46

51. ∏1 ∏2
INTERFERENCE ∏3 ∏4
AUTOMATIC DETECTION
• Errors: • Strengths
• Concurrent variable access • Strong support to
designers
• Concurrent error
throwing • Automatic identification
• Bad-Smells: • Drawbacks
• Introducing equivalent • Syntactic-only detection *
activities
• Costly graph analysis
• Forgotten weave directive (performances)
* «Nemo auditur propriam turpitudinem allegans» 47

52. CONCURRENT
THROW: «C & !C’»
48

53. VALIDATION
A Car Crash Management System
49

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

55. OUR APPROACH
Given requirements (pdf)
Textual Use Cases System Actors
as as
Business Processes Atomic Services
51

56. EX: «CAPTURE WITNESS REP.»
Actors
Main
Success
Scenario
Business
Extensions
52

57. => 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

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

59. n ts
8 27 e
m
Scenarios Business Extensions i re
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

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

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

62. A USE CASE EXAMPLE
composition cms::captureWitnessReport {
apply callDisconnected => a10;
apply callDisconnected => a2;
apply requestVideo(user: 'coord') => {a3,a4};
apply fakeWitnessInfo => a2a3
apply ignoreDisconnection => a4;
apply fakeCrisisDetected => a4;
apply fakeCrisisDetected => requestVideo::a3;
}
55

63. A USE CASE EXAMPLE
Parameters Weave
composition cms::captureWitnessReport {
apply callDisconnected => a10;
apply callDisconnected => a2;
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

64. OPENING THE BOX
callDisconnected
fakeWitnessInfo
requestVideo
fakeCrisisDetected
ignoreDisconnection
56

65. OPENING THE BOX
χ
callDisconnected
χ
fakeWitnessInfo χ
requestVideo χ
χ
fakeCrisisDetected
χ
ignoreDisconnection χ
56

66. OPENING THE BOX
χ
callDisconnected
χ
fakeWitnessInfo χ
requestVideo χ β
χ
fakeCrisisDetected
χ
ignoreDisconnection χ
56

67. OPENING THE BOX
χ
callDisconnected
χ
fakeWitnessInfo χ
requestVideo χ β
ω
χ
fakeCrisisDetected
χ
μ
ignoreDisconnection χ
56

68. OPENING THE BOX
χ
callDisconnected
χ
fakeWitnessInfo χ
requestVideo χ β
ω ω
χ
fakeCrisisDetected
χ
μ
ignoreDisconnection χ
captureWitnessReport
56

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

70. Business Extensions
Main Success Non Functional
Scenario 58 Properties

71. PROCESS COGNITIVE LOAD
Parallelism Max. Length
Width x Height | Paths |
| Activities |
• Hypothesis:
59

72. OBTAINED RESULTS
60

73. OBTAINED RESULTS
60

74. OBTAINED RESULTS
60

75. PERSPECTIVES,
implementation and conclusions!
61

76. «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

77. IMPLEMENTATION
63

78. IMPLEMENTATION
E -P
R -
DSL
63

79. IMPLEMENTATION
-P EL
R -E BP G
P N
L
DSL M
X
63
Mondrian

80. CONTEXT SUMMARY
• Identification 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

81. CONTRIBUTION SUMMARY
•A kernel:
• Small metamodel, explicit semantics, strong foundations
• Framework to define algorithms
• Several Algorithms
• Weave, Merge, Inline & Dataflow
• Scheduling, Intrinsic conflict detection mechanisms
65

82. ANY QUESTIONS? REMARKS?
http://www.adore-design.org
66
Illustrations by C.line