Service Oriented Architectural Design€¦ · Architectural Design Emilio Tuosto Computer Science...
Transcript of Service Oriented Architectural Design€¦ · Architectural Design Emilio Tuosto Computer Science...
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: [email protected]: [email protected]: [email protected]: [email protected]