Patterns for Architectural Analysis and Systems Integration

(1)

Patterns for Architectural Analysis and

Systems Integration

Nuno Oliveira 1st_{CROSS Workshop} Braga, Portugal July 2, 2011

(2)

Introduction Outline Coordination Pattern CoordL CoordInspector Integration Pattern Repository Systems Integration Conclusion

Context

In the context of Cloud Computing...

I Software deployed somewhere with illusion of infinite resources

I Elasticity – dynamic (on-demand) allocation of resources I Centralisation – data + computation in the same cloud

I Software as a Service (SaaS) available anywhere

I Software is available as services (e.g. Google Apps) I Services provide computation, data, etc.

I Services may be composed with other services (from other providers)

I Service Composition enforces Service-Oriented Architectures (SOA)

Nuno Oliveira CROSS Workshop

(3)

Context

In the context of SOA...

I Service-oriented Computing is the focus

I Services may be seen as traditional Software Components

I Input and Output ports for communication (API of the Service) I Provide results on demand (Web-services (WS) calls)

I Open Source Services as Open Source Components

Reutilisation and Integration of Components are crucial topics in Service Oriented Computing

(4)

Context

I Software (Services) Integration/Composition

I Follows business process patterns (e.g. van der Aalst)

I Based on coordination methodologies (for WS)

I Orchestration – central controller where WS are oblivion about business process or other WS in the application

I Choreography – no central controller and WS know other WS they are communicating with

Composition of components requires good architectural design phase

(5)

Motivation

From the legacy code analysis/understanding stand point...

I Architectural decisions end up hard-wired in the application code

I Leads to analysis and maintenance problems

I Raise the need of separating the coordination from the main business code

I Tool support for architectural decisions discovery is becoming

(6)

Motivation

I CoordInspector is a tool for architectural decisions recovery by

coordination layer extraction

I Processes CIL code (potentially able to analyze systems developed in more than 40 languages compliant with the .NET plataform)

I CIL code of a system is transformed into a System Dependence Graph (SDG)

I SDG is sliced into a Coordination Dependence Graph (CDG)

I CDG holds information about coordination code

I Coordination code is extracted from the CDG, by using graph algorithms to search for non formalised definitions of coordination code patterns

(7)

Objectives

A formalisation of coordination patterns is needed

I Define a robust pattern language to drive the coordination layer

extraction

I Integrate the language in CoordInspector providing:

I Pattern Editor I Pattern Visualization I Extraction Algorithm

I Ready-to-use Patterns (by creation of a Pattern Repository)

(8)

Outline

Coordination Pattern Definition

Formal Model

Transition & Nodes Semantics Operations

CoordL: Coordination Pattern Language Formal Specification

Textual Notation Visual Representation CoordInspector Integration

CoordInspector Architecture The Pattern Editor

The Visualization Pattern Repository

On Line Pattern Repository Local Pattern Repository Systems Integration Conclusion

(9)

Definition

Coordination Pattern - Definition

A Coordination Pattern is an equivalence class, a shape or

sub-graph of a Coordination Dependence Graph, G, corresponding to a trace of coordination policies left in the system code

(10)

Definition

Coordination Dependence Graphs (CDGs)

(11)

Definition

(12)

Definition

Coordination Pattern

(13)

Formal Model

Coordination Pattern - Formal Model

Pattern := hN, in ⊆ N, out ⊆ N, T ⊆ N × ThreadRef × Ni

where:

N – is the set of pattern nodes;

in – is a set of input nodes of the pattern; out – is a set of output nodes of the pattern;

T – is the set of transition relations: n−→ nx 0 ≡ hn0, x , ni ∈ T

(14)

Transition & Nodes Semantics

Transition [[n−→ nx 0 ]]_G = ∃j0,··· ,jn∈Nodes(G). n x −→ j0 x −→ · · ·−→ jx n x −→ n0_{∈ Paths(G)} Fork Nodes f / a,x

b,y(p) = hN ∪ {hf , x i}, {f } ∪ in \ {a, b}, out, T ∪ {f x

−→ a, f −→ b}iy

Join Nodes

(p)a,x_b,y &

j = hN ∪ {hj , x i}, in, {j } ∪ out \ {a, b}, T ∪ {a−→ j, bx −→ j}iy

Thread Trigger Nodes

(p)a,x_b,y & / i ,x j ,x =

hN ∪{hi , xi, hj, xi}, in, {i , j}∪out\{a, b}, T ∪{a−→ i , bx −→ i , ay −→ j, bx −→ j}iy

(15)

Operations

Operations - Aggregations

Let p1= hN1, in1, out1, T1i and p2= hN2, in2, out2, T2i. The aggregated

pattern p1 p2is given by

(16)

Operations

Operations - Connections

Let p = hN, in, out, T i. A connection is established between two nodes in a pattern interface through the link operator:

(p) ij =  



hN, in \ {i }, out \ {j}, T ∪ {j−→ i }ix

⇐ i ∈ in ∧ j ∈ out ∧ x = thread(i ) t thread(j) is defined p ⇐ otherwise

(17)

Operations

Operations - @live

Let p = hN, in, out, T i. The alive operator re-opens closed interface nodes in the following way:

(p)@[i1. . . in|o1. . . om] = hN, in ∪ {i1, . . . , in}, out ∪ {o1, . . . , om}, T i iff

(18)

Definition Formal Model

CoordL: Coordination Pattern Language Formal Specification

Textual Notation Visual Representation CoordInspector Integration

The Visualization

Pattern Repository

On Line Pattern Repository Local Pattern Repository

Systems Integration Conclusion

(19)

Formal Specification

CoordL - Formal Specification

1 l a n g → p a t t e r n+ 2 p a t t e r n → ID ‘ ( ’ p o r t s ‘ | ’ p o r t s ‘ ) ’ ‘ { ’ d e c l s g r a p h ‘ } ’ 3 p o r t s → l s t I D 4 d e c l s → d e c l ‘ ; ’ ( d e c l ‘ ; ’ ) ∗ 5 d e c l → ‘ node ’ l s t I D ‘= ’ n o d e R u l e s | ‘ f o r k ’ l s t I D | ‘ j o i n ’ l s t I D | 6 ‘ t t r i g g e r ’ l s t I D | ID i n s t a n c e s 7 i n s t a n c e s → i n s t a n c e ( ‘ , ’ i n s t a n c e ) ∗ 8 i n s t a n c e → ID ‘ ( ’ p o r t s ‘ | ’ p o r t s ‘ ) ’ 9 . . . 10 g r a p h → a g g r e g a t i o n | c o n n e c t i o n s 11 a g g r e g a t i o n → p a t t r e f ( ‘ + ’ p a t t r e f ) ∗ 12 p a t t r e f → c n o d e | ‘ ( ’ a g g r e g a t i o n n ‘ ) ’ c o n n e c t i o n 13 . . . 14 c n o d e → n o d e | ID ‘ . ’ propTT 15 . . . 16 c o n n e c t i o n → ‘ { ’ o p e r a t i o n s ‘ } ’ ‘ @ ’ ‘ [ ’ p o r t s a l i v e ‘ | ’ p o r t s a l i v e ‘ ] ’ 17 . . . 18 o p e r a t i o n → c n o d e l i n k c n o d e | f o r k | j o i n | t t r i g g e r 19 . . . 20 f o r k → n o d e s p l i n k ‘ { ’ c n o d e ‘ , ’ c n o d e ‘ } ’ 21 . . . 22 l i n k → ‘ − ’ ID ‘ − ’ ‘ > ’ 23 . . .

(20)

Textual Notation

CoordL - Textual Notation

1p a t t e r n 1 ( p1 | p4 ) { 2 n o d e p1 , p2 , p3 , p4 = { 3 s t == ”∗” && 4 c t == w e b s e r v i c e && 5 cm == s y n c && 6 c r == c o n s u m e r && 7 } ; 8 f o r k f ; 9 j o i n j ; 10 11 { f − ( x , y ) −> ( p2 , p3 ) } 12 {p1 −x−> f , ( p2 , p3 ) − ( x , y ) −> j } 13 { j −x−> p4} 14} 1 p a t t e r n 2 ( p1 | p2 ) { 2 n o d e p1 , p2 , p3 = { s t == ” ∗ ” } ; 3 p a t t e r n 1 p a t t ( i 1 | o1 ) ; 4 5 ( 6 ( p1 + p a t t + p2 ) 7 {p1 −x−> p a t t ( i 1 ) , 8 p a t t ( o1 ) −x−> p2 , 9 p2 −x−> p3 } @ [ p2 | ] 10 ) { p3 −x−> p2 } 11 }

(21)

Visual Representation

CoordL - Visual Representation

pattern 1 pattern 2 Node Fork Join Ttrigger Instance Edge Op.Edge

(22)

CoordL: Coordination Pattern Language

Formal Specification Textual Notation Visual Representation

CoordInspector Integration CoordInspector Architecture The Pattern Editor

The Visualization Pattern Repository

(23)

CoordInspector Architecture

(24)

The Pattern Editor

CoordInspector - The CoordL IDE

(25)

The Visualization

(26)

CoordInspector Integration

The Visualization

Pattern Repository

On Line Pattern Repository Local Pattern Repository Systems Integration Conclusion

(27)

On Line Pattern Repository

I Coordiantion Pattern is the basic piece

I Pattern Information is stored in an XML structure

I Name I Abstract I Motivation I Applicability

I Implementation in real code I CoordL definition

I Examples I Known-uses I Contributors

I Related Patterns (relations like use, simulation, bisimulation) I Kewywords Classification

(28)

Local Pattern Repository

I Synchronized with the online repository via Webservice

I Integrated in the CoordL IDE

I Pattern Details visualization and use provided

(29)

The Visualization

Pattern Repository

(30)

Systems Integration with CoordInspector

Overall strategy:

(31)

The Visualization

Pattern Repository

(32)

Conclusion

I A language to define coordination patterns, CoordL, was defined

with

I a precise semantics I a visual notation and

I a processor for syntactic/semantic check and transformations

I CoordL specifications formally drive the extraction of the

coordination layer of software systems.

I The extraction is done resorting to a graph-based search algorithm

I The CoordInspector tool was enriched with an Integrated

Development Environment for CoordL

I A repository was created to support the reuse of patterns

(33)

Conclusion – Further Thoughts

I Integration strategy based on coordination patterns analysis

I pattern calculus

I pattern analysis based on properties/invariants

I Possible integration of CoordInspector into CROSS portal as a

plug-in

(34)