• Save

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Behavioral Compositions in Service-Oriented Architecture

on

  • 812 views

Presentation used to defend my PhD.

Presentation used to defend my PhD.

Statistics

Views

Total Views
812
Views on SlideShare
523
Embed Views
289

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 289

http://www.i3s.unice.fr 160
http://sm.ace-design.eu 67
http://sm.gcoke.org 62

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

Behavioral Compositions in Service-Oriented Architecture Behavioral Compositions in Service-Oriented Architecture Presentation Transcript

  • BEHAVIORAL COMPOSITIONS IN SERVICE ORIENTED ARCHITECTURE Sébastien MOSSER, University of Nice - Sophia Antipolis, CNRS, I3S Lab, MODALIS Team directed by Mireille Blay-Fornarino & Michel Riveill PhD Thesis Defense October 27th, 2010 1
  • 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 2 an Architect
  • 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! » 2 an Architect
  • AND THEY ALL LIVED HAPPILY EVER AFTER ... SURE? the (same) Architect the (same)Comm 3
  • Google: «SOA failure» graphics by sxc.hu
  • PROBLEMATIC OVERVIEW • Focus on one of the «real» SOA problems: • How to tame complex business processes design? • Proposition: • A dedicated Separation of Concerns (SOC) technique • State-of-the-art study: • No existing solutions to such a problem • Junction of 3 domains: SOA, SOC, Business Process design 5
  • CONTRIBUTION: •A kernel: • Small metamodel, explicit semantics, logical foundations • Action-based framework to define algorithms • Several composition algorithms • Weave, Merge, Inline & Dataflow • Algorithm Scheduling, Interference detection mechanisms http://www.adore-design.org 6
  • Context Kernel Algorithms Conclusions • Context Overview • SOA & Business Processes properties • Separation of concerns mechanisms • Thesis Contribution: •A dedicated metamodel (kernel), • Composition algorithms defined to support Business Process designers • In action: designing a Car Crash Crisis Management System • Conclusions & Perspectives
  • Context Kernel Algorithms Conclusions CONTEXT OVERVIEW Objectives: Identify state-of-the-art SOA properties, Analyse their coverage in Sep. of Concerns approaches P1 P2 P3 P4 P5 P6 8
  • ILLUSTRATION: «INFORMATION BROADCAST» P1: Business Expressiveness [Brown, 98] 9
  • ILLUSTRATION: «INFORMATION BROADCAST» Business Process P1: Business Expressiveness [Brown, 98] keystone 9
  • TECHNOLOGICAL ECOSYSTEM WSDL UDDI XSD Business Web e.g., Process Services BPEL e.g., Standards SOAP P2: One cannot ignore reality [Peltz, 03] 10
  • INTRODUCING TECHNICAL «CONCERNS» (WS-) Authentication Business (WS-) Security Process (WS-) Transactions (WS-)* (49 standards) P3: Concerns reification [Curbera et al, 03] 11
  • INTRODUCING BUSINESS «CONCERNS» Broadcast policies Partners evolution Information Filter Business Usage Statistics Process User profile handling .... P4: Concerns behavioral composition [Vinosky, 04] 12
  • BUSINESS PROCESS Activity user := receive() Parallelism tag := profile::getTag(user) key:= reg::get(‘twitter’) tweets:= twitter::read(tag,key) Business infos := transform(tweets) Partnership Activity reply(infos) P5: Activity Parallelism [Glatard, 07] 13
  • WRITING BUSINESS PROCESS Literature Vocabulary: «zoo» «jungle» ... Expressiveness benchmark (courtesy of Johan Montagnat) [van der Aalst, 08] P6: Syntax Independency [Russel et al, 06], [GWENDIA,07] 14
  • SO WHAT ? 15
  • (simplified & small) 16 real business process ...
  • Business-driven Authentication logic External Partership Persistence Error case User Interaction Fault handlers 17
  • Authentication Interaction: Authentication failure Versus Data storage Persistence Equivalent activities 18
  • Impact of evolution? Reusability? Path preservation? Conditions? Execution trace conservation ? 19
  • TOWARDS A SEPARATION OF CONCERNS (SOC) APPROACH «Build complex things by composing small and simple ones.» [Dijkstra, 72] concern System = + factorization composition + ( +Cache ) algorithm + ( + Threshold ) +( + + Timeout + Cache ) + ... 20
  • FEATURE - ORIENTED PROG. Features as functions [Batory, 04] System = Timeout ( ( Cache ( ))) f●g≠g●f Programs as constants • Composition «assimilated» to function composition (f●g) • Composition as first class entities: equations [Liu and Batory, 04] • Conflict identifications [Apel et al, 10] 21
  • ASPECT - ORIENTED PROG. ASPECT Weave «joinpoint» [Kickzales, 01] TIMEOUT BASE ASPECT PROGRAM ASPECT CACHE «pointcuts» «advice» & Quantifiers • Focuses on non-functional concerns [Stein et al, 08] [SPRING Framework] [Pessemier et al, 08] • Often used to support «integration strategies» 22
  • USING FOP & AOP IN 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 - ~ 23 [Charfi and Mezzini, 04] [Courbis and Finklestein, 05] [Batory, 07] [Apel et al, 08]
  • CONTRIBUTION TAMING BUSINESS PROCESS DESIGN COMPLEXITY •A dedicated metamodel to support process design • Designers write incomplete processes (aka fragments) • Algorithms build the final (complete) process • Automatic integration & properties preservation (e.g., trace) 24
  • Context Kernel Algorithms Conclusions CONTRIBUTION: A metamodel to design business processes, its associated execution semantics, a composition framework to implement algorithms 25
  • LET US TAKE AN EXAMPLE Incomplete processes (aka «fragments») Composition directive ➔ ( Timeout ) ➔ 26
  • EXPECTED RESULT & REQUIREMENTS • Business expressiveness (P1) • Activity parallelism (P5) • Bound to existing standards (P2) • But «syntax-independent» (P6) • Concerns reified as first class entities (P3) • Support for compositions reasoning (P4) 27
  • A MODEL-DRIVEN APPROACH Business P1 « We build models to better understand expressiveness the system we are building » [Booch et al, 05] P2 Concerns reification P3 Need for Need for problem abstraction specialization P4 « a purpose, a model » P5 Syntax Independency P6 28 [Muller et al, 09] «We are using models, as Molière’s Monsieur Jourdain was using prose, without knowing it»
  • EXISTING BEHAVIORAL MODELING APPROACHES , 78] Native composition support Protocol [Hoare Model [Roubstova and McNeil, 1 «Formal»-driven 0] [OMG, 06] Business-oriented BPMN [Klop pman n et a l, 09] No «accepted» [Esh uis , 02] execution semantics UML Activity Diagrams [OMG, 0 5] Simple notation 29
  • ➙ A (SMALL) METAMODEL inspired by the BPEL standard [OASIS, 06] One cannot Activities ignore reality P2 P4 Activity Parallelism P5 Relations 30
  • EXECUTION SEMANTICS • Mandatory to: ☑ Express compositional properties (e.g., path preservation) ☑ And properly execute a process defined with ADORE • Reaching the execution level: (using KERMETA) ☐ Weave executability at the metamodel level [Fleurey, 06] ☑ or Transform an ADORE model into an executable program • Mechanisms sketched in [FAROS,09] (to the BPEL) 31
  • IN A NUTSHELL • Activity model relies on BPEL kernel Activity • Message reception & response sending • Service Invocation, Assignment & Nop • Different relations available: a • Wait, Weak Wait, Guards, Catch b • Computed execution semantics c Relation • («simply») as boolean formulas start( c ) end( a ) & end ( b ) 32
  • BEHAVIORAL COMPOSITIONS • An «Action-Based» approach to support compositions [OMG, 06] • Elementary actions: add, del [Blanc et al, 08] • Composite actions: unify, replace, discharge P4 • Composite actions are «refined» into elementary ones. • Compositions as «algorithms» • Algorithms produce «action sets» to be executed. 33
  • EXAMPLE: PROCESS NAIVE CORRELATION a := receive() x := receive() (a,x) := receive() b := do(a) + y := do(x) = b := do(a) y := do(x) reply(b,y) reply(b) reply(y) Semantic Orchestration Merging 34 [Nemo, Blay, Kniesel, Riveill, ICEIS’07]
  • EXAMPLE: PROCESS NAIVE CORRELATION A1. discharge a := receive() A2. x := receive() unify (a,x) := receive() b := do(a) + y := do(x) = b := do(a) y := do(x) A3. reply(b,y) reply(b) reply(y) unify Semantic Orchestration Merging 34 [Nemo, Blay, Kniesel, Riveill, ICEIS’07]
  • «ALGORITHM» WRITING A1 A2 A3 • Many-sorted order logic (underlying foundations) • «Logical» expressiveness at the (meta)model level • Immediate mapping (sort of) into PROLOG 35
  • FORMAL REP. OF ACTIONS A1 elementary composite A2 refinement A3 36
  • ALGORITHM EXECUTION Naive Correlation Algorithm χ + Action Set do (a,x) := receive() Execution b := do(a) y := do(x) Engine reply(b,y) 37
  • ALGORITHM EXECUTION Algorithm X & Associated properties χ + Action Set do condition preservation, Execution Resulting trace conservation, Engine Model ... Key Point: Express «actions». That’s all! 37
  • WELL-FORMED MODELS Input models assumed as «well-formed» Check Execute Check Precondition Action Postcondition Maybe Inconsistent fail fail [Balzer, 91] ... Other Actions ... Check Model Invariant «well-formed» output fail Well-formed: entry to exit path, no cycle, ... 38
  • Context Kernel Algorithms Conclusions COMPOSITION ALGORITHMS DEFINED IN Weave, Merge, Inline & Dataflow 39
  • ALGORITHMS OVERVIEW ICIW’09  ECSA’08       Step-wise development 40
  • ALGORITHMS OVERVIEW ICIW’09  ECSA’08 Fragment integration       Step-wise development 40
  • ALGORITHMS OVERVIEW ICIW’09  Shared targets ECSA’08 Fragment integration       Step-wise development 40
  • ALGORITHMS OVERVIEW ICIW’09  Shared targets ECSA’08 Fragment integration       efficiency data parallelism Step-wise development 40
  • WEAVE: INTEGRATE FRAGMENTS INTO PROCESSES      41
  • WEAVE PRINCIPLES ω(after,{rec}) ω(after,{a1}) ω(before,{a2}) ω(before,{rpl}) System’ = execute({ω,ω,ω,ω}, System) 42
  • DIRECTIVES INDEPENDENCY χ(ω) χ(ω) χ(ω) χ(ω) actions actions actions actions #1 #2 #3 #4 ∪ ∪ ∪ Execution Engine = do(χ(ω)∪χ(ω)∪χ(ω)∪χ(ω), System) 43
  • IMMEDIATE ADVANTAGES Algorithm Level «Compositional properties» Order independence ensured by construction (details in the thesis) Determinism Process level Opt. preservation Path preservation Execution order Variable initialization Condition Always return a response (can be bypassed by the designer) 44
  • STEP-WISE APPROACH Timeout ω ➠ Step #1: + Timeout Endogenous 45
  • STEP-WISE APPROACH Step #1 result ω ➠ Explicit ordering, when needed Step #2: Step #1 + 46
  • INTERFERENCE AUTOMATIC DETECTION • Errors: • Strengths • Concurrent variable access • Strong support to designers • Concurrent throwing error ✘ • Automatic identification • Bad-Smells: • Drawbacks • Introducing equivalent • Syntactic-only detection* activities • Forgotten ☹ weave directive • Costly graph analysis (performances) * «Nemo auditur propriam turpitudinem allegans» 47
  • ILLUSTRATION ω send(pict) A A ➟ ✘ ω’ B B pict := resize(pict) 48
  • ILLUSTRATION ω ✔ send(pict) A A ω’ B ➟ B pict := resize(pict) 48
  • MERGE: HANDLING SHARED TARGETS      49
  • MERGE PRINCIPLES { ω(bef,{X}), ..., ω(par,{X}), ..., ω(aft,{X}) } Shared Target bef par aft 50
  • MERGE PRINCIPLES { ω(bef, {X}), ω(par, {X}), ω(aft, {X}) } Term rewriting (Algorithm scheduler) [Hekel, 02] (Critical Pairs) ( μ({bef, par, aft}, merged), ω(merged,{X})) merged Fragment «union» 51
  • INTERFERENCES DETECTION MECHANISMS 52
  • INTERFERENCES DETECTION MECHANISMS ✘ μ 52
  • INTERFERENCES DETECTION MECHANISMS ✔ μ 52
  • INTERFERENCES DETECTION MECHANISMS ✔ μ ω 52
  • MERGING VS ORDERING Example: (courtesy of Don Batory) Single No unexpected result wait introduction 53
  • VALIDATION ELEMENTS A Car Crash Crisis Management System 54
  • IMPLEMENTATION E -P R - DSL 55
  • IMPLEMENTATION L G N -P P E P R-E B L DSL M X 55
  • IMPLEMENTATION L G N -P P E P R-E B L DSL M X Mondrian 55
  • CASE STUDY: «CAR CRASH CRISIS MANAGEMENT SYSTEM» • TAOSD Special Issue on Aspect Oriented Modeling • Rationale: A common case study to compare AOM approaches • Different software engineering domains: Req., Design, V&V, ... • Unfortunately alone at the design level ☹ • Context: Crisis Management System (CMS) • Instantiated context: How to handle a «car crash» crisis? 56 TAOSD’10
  • ➟ 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 57
  • Car Crash Crisis Management System 8 Scenarios 27 Business 12 Extensions Processes 3 29 NF Properties fragments 124 χ compositions ts ~ One-to-one ~ 900 en irem mapping! relations u eq R Interference detection identifies > 1200 requirements weaknesses! activities 58
  • 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 59
  • PROCESS METRICS • Activity provenance: • «Point of origin» associated to an activity in a given process • up to 80% of a process may be added by new concerns! • Cognitive load: [Cardoso et al, 03] • Measure the process «understandability» for a designer • Σ(load(fragments)) + load(initial) < load(composed) e.g., 6 < 247 !! Graphic by Clémentine 60
  • Context Kernel Algorithms Conclusions CONCLUSIONS, and perspectives 61
  • CONTRIBUTION: •A kernel: • Small metamodel, explicit semantics, logical foundations • Action-based framework to define algorithms • Several composition algorithms • Weave, Merge, Inline & Dataflow • Algorithm Scheduling, Interference detection mechanisms http://www.adore-design.org 62
  • «ONGOING» PERSPECTIVES Requirements Link with Engineering «structure» AOSD’11 Univ. of Ottawa Colorado State Univ. SC’10 Link with Composition & FOP & Order Visualization Univ. of Texas at Austin 63 Univ. of Chile
  • OPEN PERSPECTIVES • Short term: • Definition of a bi-directional SOA design tool chain, from requirements to code. • Mid term: • Introduce «dynamic» capabilities to address context-aware systems & SPLs • Long term: • Factorization of composition mechanisms from different domains 64
  • ANY QUESTIONS? REMARKS? http://www.adore-design.org 65 Illustrations by C.line
  • MAIN PUBLICATIONS Algorithms Tool Chain ECSA’08 SC’10 MDE & SOA ICIW’09 AOSD’11 CAL’08 IAWTIC’08 Case studies Tech. Reports LMO’09 RSTI’07 ANR FAROS (7) MODSE’09 Lab Interns (3) TAOSD’10 special issue on AOM 66
  • ATTIC
  • Non Functional Properties Main Success Business Extensions Scenario 68
  • PROCESS COGNITIVE LOAD Parallelism Max. Length Width x Height | Paths | [Cardoso et al, 03] | Activities | • Hypothesis: 69
  • OBTAINED RESULTS 70
  • OBTAINED RESULTS 70
  • OBTAINED RESULTS 70
  • EXAMPLE: CONCURRENT THROW 71
  • EXAMPLE: CONCURRENT THROW 71
  • COMPOSITION COVERAGE • Weave: • Inline: • Integrates fragments into • Absorbs a process into processes another one • Blocks, Order independence • Composition efficiency • Merge: • Dataflow: • Shared targets • Introduces Loops • Parallel Composition • Non-expert programming ECSA’08 72 ICIW’09
  • IDEA: APPLYING SOC CONCEPTS TO SOA Scalability? ✘ Understandability? ✘ Design? ✘ Assessment? ✘ 73
  • IDEA: APPLYING SOC CONCEPTS TO SOA Automated reasoning on Scalability? concerns leads to optimization ✔ A business expert focuses Understandability? on his/her own domain ✔ Different design strategies Design? may coexist in the company ✔ Composition conflicts Assessment? can be identified ✔ 73