service oriented architectural designservice oriented architectural design emilio tuosto computer...

Service Oriented Architectural Design

Emilio TuostoComputer Science Department

University of Leicester

withR. Bruni, A. Lluch Lafuente, and U. Montanari

Dipartimento di InformaticaUniversita’ di Pisa

Web Engineering DayAthens, Sept. 3 2007

Motivations

Key issues of service-based architectures: design reconfiguration

Styles for reusing existing design patternsRun-time changes (e.g., dynamic binding)

require reconfigurations of architecturescomplement their static reconfigurationsdriven by architectural information specified during design

Often, architectural styles must be preserved or consistently changed

SEnSOria aims to develop an approach for engineering SOCs

ADR principlesArchitectures are modelled as suitable graphsHierarchical architectural designs

style preserving rules (not original)algebraic presentation (original)

Reconfigurations defined over style proofs instead of actual architectures

exploits the algebraic presentationstraightforward definition of hierarchical and inductive reconfigurations (ordinary term rewriting and SOS)only valid contexts considered (not all concrete designs)matching is simpler during reconfigurations (design driven)

Overview

Architectural Design Rewriting (ADR)Development/reconfiguration of software architecturesTaking into accounts styles for “well-formed” reconfigurationsApplying ADR to SRML so that SRML is respected by construction (i.e., style preserving rewritings)Concluding remarks

ADR ingredients

Hypergraphsedges model components: can beterminal and non-terminal edgesnodes model connecting ports

Type-(hyper)graphsProductions

rules like L ::= Rspecify how non-terminalsshould be replaced

!

p

!!

i""

##

r

$$

! i%% && ! i%% && " W%%

c

##

ADR by example

A local networking architecture2 styles where each network hub has degree of connectivity 2 or 3Connections between hubs are also driven by the style

•

!"!"

NET

•

• 3hub!! ""

##

•

3hub

$$

""

##

• 3hub!!

%%

##

•

!"!"

NET

•

• 2hub!! "" •

2hub

$$

&&

2hub

''

%%

Designs and productions

Designs and productions• 2hub!! "" •

•

• 3hub!! ""

##

•

• 2N!! "" •

•

• 3N!! ""

##

•

•

NET

##Edges for the network example

Designs and productions

A design consists ofa lhs L which is a graph made of a single non-terminal edgea rhs R graph possibly containing non-terminal edgesa map from the nodes of L to the nodes of R

A production is a design where the occurrences of non-terminal are distinguished

represents the abstract class of the component

type o

f the

produc

tion

• 2hub!! "" •

•

• 3hub!! ""

##

•

• 2N!! "" •

•

• 3N!! ""

##

•

•

NET

##

•

!"!"!"

3N

•

• 3N!! ""

##

•

• #$ • 3N!! ""

##

• 3N!! ""

##

• •$#

3N ::= link3(3N, 3N, 3N)

link3 : 3N× 3N× 3N→ 3N

Edges for the network example

ADR methaphor

A term of a grammar is an instance of a designTerms with variables are partial designsReplacing variables corresponds to refinementReplacing subterms with variables corresponds to abstractionReplacements are driven by term rewriting rules, namely reconfiguration rules t -> t’

style is preserved if t and t’ have the same abstract classotherwise styles change...in a consistent way

Design rewritings

link3to2 : x13to2!" x!

1 x23to2!" x!

2 x33to2!" x!

3

link3(x1, x2, x3)3to2!" link2(link2(x!

2, x!1), x!

3)

Design rewritings

link2 : 2N! 2N" 2N

2N

• !" • 2N!! "" • 2N!! "" • •"!

link3 : 3N× 3N× 3N→ 3N•

!"!"!"

3N

•

• 3N!! ""

##

•

• #$ • 3N!! ""

##

• 3N!! ""

##

• •$#

link3to2 : x13to2!" x!

1 x23to2!" x!

2 x33to2!" x!

3

link3(x1, x2, x3)3to2!" link2(link2(x!

2, x!1), x!

3)

Design rewritings

link2 : 2N! 2N" 2N

2N

• !" • 2N!! "" • 2N!! "" • •"!

link3 : 3N× 3N× 3N→ 3N•

!"!"!"

3N

•

• 3N!! ""

##

•

• #$ • 3N!! ""

##

• 3N!! ""

##

• •$#

link3to2 : x13to2!" x!

1 x23to2!" x!

2 x33to2!" x!

3

link3(x1, x2, x3)3to2!" link2(link2(x!

2, x!1), x!

3)•

!"!"

NET

•

• 3hub!! ""

##

•

3hub

$$

""

##

• 3hub!!

%%

##

•

!"!"

NET

•

• 2hub!! "" •

2hub

$$

&&

2hub

''

%%

SRML architectural elements

borrowed from [FLB06]

service module

componentrequire interface

provide interface

wire

Terminals for SRMLSRML components, wires and interfaces are modelled as terminal arcs

Terminals for SRMLSRML components, wires and interfaces are modelled as terminal arcs

Terminals for SRML

c !! ◦

◦

c!! ◦

◦

! c!!!

r

!! !

p

!!i!! "" i!! ""

!

r

!!i!! ""

e!! ""

i!!

""

SRML components, wires and interfaces are modelled as terminal arcs

Terminals for SRML

c !! ◦

◦

c!! ◦

◦

! c!!!

r

!! !

p

!!i!! "" i!! ""

!

r

!!i!! ""

e!! ""

i!!

""

SRML components, wires and interfaces are modelled as terminal arcs

Restrictions:Typing restrictions not present in the (less-accurate) UML metamodelinternal wire cannot connect ᐊ or ᐅ nodesFurther restrictions enforced by the actual use of wires in a diagramOnly the most abstract structural aspects of SRML are considered

Non-terminals for SRMLNon-terminals used as

the interface of a design (its type) andin the body of a design (as an abstract element)

!/◦ "/◦

I

!!

""

##

$$!/◦ "/◦

C

%% %%◦ ◦

"

! B&&

''

(("

"

AB

''

(("

internal wires service components service module body activity module body

! M&& AM " W&& " E&& )) !

service module activity module wrapped service external wire

ADR4SRML...top down

ADR4SRML...top down

modules

bodies

amod smod wrap

AM

AB !!

""

! W##

! W##

M

B

$$

!!

""

! W##

" !" "

! W##

W

! !" ! E !!## " M##

ewire

E

! !" ! e !!## " ""!

abod sbodAB

C

!!

""

r

##◦ ! !!" !" !"

◦ I$$

%% &&

''

r

##! !!" !" !"

B

p

!!

I

(( ##

))

r

**" "!"!"! " C

!!

""

! !!" !" !"

◦

I

++

&&

,, ◦ I$$

%%

--

,,

! !!" !" !"

r

..

ADR4SRML...top down

ADR4SRML...top down

components

wires

comp compsC

◦ ◦!" !" !"

c

!!

C

C

""

##

C

""

$$◦ ◦!" !" !" !" !"

◦ ◦!" !" !" !" !" !" !" !"

◦ ◦!" !" !" !" !" !" !" !" !" !" !" !" !" !" !"

◦ ◦!" !" !" !" !" !" !" !" !" !" !" !" !" !" !" !" !" !"

I

%%

&&

''

((

wires iwire nowireI

I

!!

"" ##

$$

!/! !" !/! "/! "/!"!

!/! !" !/! "/! "/!"!

I

%%

&&''

((

I

!/! !" !/! "/! "/!"!

!/! !" !/! i)) ** "/! "/!"!

!/! !" !/! "/! "/!"!

I

!/! !" !/! "/! "/!"!

!/! !" !/! "/! "/!"!

ADR4SRML...Break-down SRML’scomposition operation

first wrap modulesthen “internalise” wires

An advantage is to get“consistency” by constructionin SRML reconfigurations

ADR4SRML...Break-down SRML’scomposition operation

first wrap modulesthen “internalise” wires

An advantage is to get“consistency” by constructionin SRML reconfigurations

linkI

◦ !"!"!" ◦ ◦ ◦"! "! "!

I

!!

!!

"" ! e!! "" " I!!

""

""◦ !"!"!" ◦ ◦ ◦"! "! "!

ADR4SRML...Break-down SRML’scomposition operation

first wrap modulesthen “internalise” wires

An advantage is to get“consistency” by constructionin SRML reconfigurations

linkI

◦ !"!"!" ◦ ◦ ◦"! "! "!

I

!!

!!

"" ! e!! "" " I!!

""

""◦ !"!"!" ◦ ◦ ◦"! "! "!

link(iwire, iwire) int−→ iwire.

ADR4SRML...Break-down SRML’scomposition operation

first wrap modulesthen “internalise” wires

An advantage is to get“consistency” by constructionin SRML reconfigurations

linkI

◦ !"!"!" ◦ ◦ ◦"! "! "!

I

!!

!!

"" ! e!! "" " I!!

""

""◦ !"!"!" ◦ ◦ ◦"! "! "!

link(iwire, iwire) int−→ iwire.

I

! !"!"!" ! i!! "" ! e!! "" " i!! "" ! !"! "! "! int"

I

! !"!"!" ! i!! "" ! !"! "! "!

Conclusions

We propose ADR as a framework for style-preserving reconfigurations of software architecturesBased on algebra of typed-graphs with interfacesHierarchical and inductive features for representing complex reconfigurationsFormal model for SRML...reconfigurations of which are compliant with SRML meta-model by constructionFuture work: application of ADR to SOA

Useful pointers

A technical report is available athttp://www.di.unipi.it/TR/(TR-07-17)Emails

Roberto: bruni@di.unipi.itAlberto: llafuente@di.unipi.itUgo: ugo@di.unipi.itEmilio: et52@le.ac.uk