=Paper=
{{Paper
|id=Vol-252/paper-7
|storemode=property
|title=Component Model with Support of Mobile Architectures
|pdfUrl=https://ceur-ws.org/Vol-252/paper07.pdf
|volume=Vol-252
|dblpUrl=https://dblp.org/rec/conf/isim/Rychly07
}}
==Component Model with Support of Mobile Architectures==
https://ceur-ws.org/Vol-252/paper07.pdf
Component Model with Support of Mobile
Architectures
Marek Rychllli
Dcpartment of Information Systcms,
Faculty of Information Technology, Brno University of Tcchnology,
BoZet6chova 2, 612 66 Brno, Czech Republic,
rychly@fit. vutbr. cz
Abstract. Conrmon features of current information systems have sig-
nificant impact on software architectures of the systems. The systems
can not be realised as monoliths, formal speciflcation of behaviour and
interfaces of thc systenrs' parts are neccssary) as well as specification
of their interaction. Moreover, the systems have to deal with many
problems including the ability to clonc components and to move the
copics across a network (componcnt mobility), creation, destruclion and
updating of components and connections during the systems' runtime
(dvnamic reconfiguration), maintaining components' compatibility, etc.
In this paper, wc prcscnt the component modcl with support of mobile
architectures and outlinc its formal basis. We also rcvicw thc rclated
research on the currcnt theory and practicc of formal component-based
dcvclopment of software systcms.
I{eywords: Softwarc Arc}ritecture, Componcnt-Based Developrnent, Com-
porrerrt Modcl, Formal Specificatiorr
Introduction
Increasing globalisation of information society and its progression creatc nceds
for extensivc and reliable information technology solutions. Common require-
ments for current information systcms include adaptability to variable structure
of organisation, support of distributed activities, intcgration of well-establishcd
(third party) softwarc products, conncction to a variable sct of external systems,
etc. Thosc f'catures have significant irnpact on software architectures of the
systems. The systems can not be realised as monoliths, exact specification of
functions and intcrfaces of the systcms' parts are necessary, as well as spec-
ification of their cornrnunication and deployrnent. Therefore, the information
systcms of organisations are realised as networks of quite autonomous, but
cooperative, units communicating asynchronously via messages of appropriate
format. Unfortunately, design and implementation of thc systems have to deal
with many problems including the ability to clone components and to move the
copies across a network (i.e. component mob'il'itg), creation, destruction and up-
dating of components and connections during the systems' runtimc (i.e. dgnami,c
reconfigurat'ion),maintaining components' compatibility, etc. [4]
56 M. Rychly
Moreover, those distributcd information systems are getting involved. Thcir
architecturcs are evolving during runtitne and fbrmal specifications arc necessary,
particularly in critical applications. Design of the systems with dynamic arch'itec-
tures (i.e. architectrtres with dynamic reconfigurations) and mobi,learch'itectures
(i.e. dynamic architectures with component mobility) can not bc done by means
of conventional software design mcthods. In most cases, these methods are able
to dcscribe semi-formally only sequcntial processing or simple concurrcnt pro-
cessing bounded to one component without advanced featurcs such as dynamic
reconfiguration.
The component-baseddeuelopment (CBD, see [10]) is a software developmcnt
methodology, which is strongly oriented to composability and re-usability in a
softwarc system's architccture. In thc CBD, from a structural point of view, a
software system is composed of componenfs, which are self contained entities
accessiblet,hrough well-defined i,nterfaces.Connection of compatible interfaces
of cooperating components is realised via connectors. Actual organisation of
components interconnectcd via connectors is called configurati,on. Component
models arc specific meta-models of software architcctures supporting the CBD,
which define synta,x, sema,nticsand compositiorr of components.
Although the CBD can be the right way to cope with the problems of the
distributcd information systems, it has some limitations in formal description,
which restrict the full support for the mobilc architectures. Those restrictions
can be delimitcd by usage of formal bases that do not consider dynamic recon-
figurations and component mobility, strict isolation of control and businesslogic
of components that does not ailow full integration of dynamic reconfigurations
into the components, etc.
In this paper, we propose the component model with support of mobile
architcctures and review the rclated current formal approaches to the CBD. The
rcmainder of this papcr is organiscd as follows. In Section 2, wc introduce our
proposcd approach in more detail. In Section 3, we review the main approaches
that are relcvant to our subject. In Section 4, we discuss advantages and disad-
vantages compared with the rcviewed approaches. To conclude, in Section 5, we
summarise our approach, current results and briefly outline the future work.
2 Component Model
In this scction, wc describe our approach to the componcnt model with support of
mobile architectures. The Figure 1 describesan outline of the component modcl's
mcta-modcl. Three basic entities rcpresent thc core entitics of a component based
architecture: a component, an interface and a connector.
The component is an active communicating entity in a component based soft-
ware systcm. In our approach, thc componcnt consists of component abstraction
and componcnt implemcntation. The component abstract'ion (ConpAbstraction in
the rneta-model) represents the component's specification and behaviour given
by the component's formal description (scmantics of scrvices providcd by the
component). The component 'implementat'ion (Conpftoplementation)rcpresents
ComponentModel with Support of Mobile Architectures 57
conQtns SuDcomponen{s
Fig. 1. Diagram of thc meta-model (an outlinc).
specific implementation of the component's behaviour (implementation of the
serviccs). The implemcntation can bc primitive or compositc. The primi,tiue
'implementati,on (PrinitiveConplmpl) is realised dircctly, beyond the scope of
architccture description (it is "a black-box"). The compos'itei,mplementati,on
(conpositecomprnpl) is decomposableon a systcm of subcomponents at the lower
level of architecture dcscription (it is "a grey-box"). The subcomponents are
rcpresented by component abstractions (ConpAbstraction).
The interface of a componcnt (descendantsof entity Interf ace) can be sorted
according to its rclative location compared with the component into public and
privatc interfaces. The publi,c i,nterfaces (euuruncrnterface and PubCtrt-Inter-
face) are required or provided (attribute type of the entity) by u component
to its neighbouring componcnts at the samc level of the architccture descrip-
tion (i.e. not to subcomponents of a neighbouring component, for example).
The priuate i,nterfaces(lrivrunclnterface and Privctrtlnterface), which exist
only in composite componcnts, are the components' public interfaces delegated
into thc components' composite implementation where they arc available for
the components' subcomponents. According to functionality of intcrfaces, we
distinguish functional interfaces and control interfaces. The funct'ional,interfaces
(luurunclnterface and PrivFuncfnterface) represent business oricnted services.
The control 'interfaces (euuctrtrnterface and Privctrt-rnterface) providc ser-
vices for components' introspection (e.g. getFunclnterfacesO) and changes of
an architecture and behaviour (startO and stopO). The servicesfor changesof
an architecturc are, for example, packComponentOand unpackCornponentO for a
component's transformation into and from a transmittable mcssage, respectively.
The connector is responsible for a rcliable communication between required
and provided interfaces. It consists of connector abstraction and connector implc-
mentation. The connector abstract'ion (ConnAbstraction) represents an abstract
connection of a pair of compatiblc interfaces. The connectorimplementation
(Connlmprementation)representsspecific implcmentation of thc connector, which
depends e.g. on comrnunication style (buffered and unbuffered connection) or a,
type of synchronisation (blocking and output non-blocking).
58 M. Rychly
2.L Behaviour and Support of Mobile Architectures
We focus on behaviour particularly rclatedto the features of mobile arch'itectures,
i.c. on creation and destruction of components and connections and on passing of
components. Evolution of an architecturc begins in thc state where initialisation
of ttre architccture is finishcd. Then, a new componenl can be creatcd by means of
duplication of an existing componcntl where thc new componcnt can be placed as
a subcomponent of a parent component or sent via its outgoing connections (via
providcd interfaccs) . Destruct'ion of a cornponent canbc done automatically after
releasing of its provided interfaces (the componcnt is forgotten when there arc
no outgoing connections). Creat'ion of new connect'ions between two intcrfaces
can be done also by means of passing of componcnts. A componcnt, which
is creating a new conncction, rcccives a component with a target interface
and obtains the interface via the component's control interface. This enables
a,cortrtectiotrto inter:connectsubcomponents of two different parent components
if one of the subcomponent is accessible via passing of components, i.e. to
sharc one subcomponent between many parent components. Destructi,on of a
connect'ion can be done directly via connected interface (actually, the connection
is forgotten) so no destruction is needed). The pass'ing of a component is realised
by means of its control interface (the component is "packed" into a messagc)
and control interface of target component (the message is "unpacked" and the
component will become a subcomponent of thc target component).
As it follows from the description of behaviour, the connections can intcr-
connect required functional interfaces with (providcd2) control interfaces. This
allows to build systems where functional (business) requirements imply changes
of the systems' architectures.
2.2 Formal Description
The componcnt model's formal description can be realised by means of the
process algebra n-calculus, known as thc calculus of mobi,Ieprocesses[6], which
allows modelling of systems with dynamic communication structures (i.e. mobile
processcs). The dcscription is based on our prcvious research on distributed
information systems as systems of asynchronous concurrcnt processcs [8] and
thc mobile architecturc's features in such systems [9].
Formal description of a C componcnt's behaviour can bc expressed as the
z-calculus processC : (CtlC.) + stop.start.C.h is a non-detcrministic choice
between a parallel composition of processcs, which rcpresent its functional part
C7 and control part C", and the proccss that waits for "start" after it receives
"stop" via names start and stop, respectively. Intcrfaces of the component C
are reprcsented by free namcs in thc process C, by its parameters, if the C is
d c n o t e d a s a p a r a m c t r i c p r o c c s sC ( p 1, . . . , p ^ ) .
For componcnt abstraction C, the definition of the process C y is givcn by
a designcr of a system or a componcnt, which contains the component C as its
t by -"""r packConponentOand unpackConponento
"f
2 in ou. approach, the control interfacesare only provided (they provide a control)
ComponentModel wilh Support of Mobile Architectures 59
subcomponcnt. It represents required functional behaviour of thc system's or
component's part. For componcnt primitive implementation C, the definitiorr
of the process C y is givcn by description of functional behaviour of the C
component's implementation according to its specification (the implementation
is "a blackbox"). For cornponent composite irnplementation, the definition of
theprocessCyisaparallelcompositionof.nprocessesCr(pt,r,,...,pr,^1),...,
Cn(pn,r,,. . . ,p,n,rn,) that represcnt component abstractions of thc C component's
subcomponents, and their interconnections. For each connection between pro-
vidcd interfaces reprcsented by names pr ,. . . ,pu and required interfaccs rep-
resented by namcs Qt,...,eu of the subcomponents,we can define parametric
n-calculus process for binding the interfaces
B ( p r , . . . , p u , Q , , . . . ,:ei i, ) q i @ ) . p r ( r ) . B ( p r , . . . , p u , e t , . . . ,( Q
1 )u )
i:I j:I
As it has been describcd in the previous section, the most of the features
of mobile architectures can bc reduced to the component mobility feature. In
thc n-calculus, this featurc can be dcscribed as passing of z--calculusprocesscs:
directly by mcans of higher ordcr z--calculusor indirectly by means of passing of
names ("an executor example" in [6]). The indirect mcthod in terms of systcms
of asynchronous concurrent processeshas been described in [9]. We can define
processesthat rcalises pack and unpack control intcrfaces. LcI C(p1,. . . ,p,n) be
a n-calculus process representing behaviour of a component C with rn interfaces.
Then, we define para,metricprocessPs to send (export) all interfacespr,...,p,n
of the component C via name p, and proccss U6 to receive (import) thc interfaccs
via name p into a context of another process, as follows
I ' c l p . p r .. . . , p ^ ) : p l r ) ( r \ p t ) . . . r \ p . ) )
n / \ / \ / - / \ _ ,
()\
u c (p ,p t, . . . , p,n) : (" )(p(r).n(pt). . . r(p.))
Those processesimplement interfaces packO and unpackO, respectivcly. The
control part of the component C is defined ffiC.:l.Pc. The proccss [/6: is used
by a componcnt, which is a destination of passing of the c's interfaces.
3 Related Work
There havc been proposcd several component models [5]. In this scction) we focus
on two contemporary component models supporting some features of dynamic
architecturcs and formal descriptions.
Thc component model FYactal [2] is a general component composition
framework with support for dynamic architectures. A Fractal componcnt is
formed out of two parts: a controller and a content. The content of a com-
posite component is composed of a finite number of nested components. 'Ihose
subcomponents arc controlled by the controller ("a membrane" ) of the enclosing
component. A component can bc shared as a subcomponcnt by scveral distinct
componcnts. A component with empty content is callcd a primitive component.
60 M. Rychly
Evcry component can interact with its environment via operations at external
intcrfaces of the component's controller, while internal interfaces arc accessible
only from the component's subcomponcnts. Thc interfaces can be of two sorts:
client (requircd) and scrver (provided). Besidcs, a functional interface requires
or providcs functionalities of a component, whilc a control intcrface is a scrver
interface with opcrations for introspcction of the componcnt and to control its
configuration. There are two hvpes of directed connections between compatible
interfaccs of components: primitive bindings between a pair of components and
composite bindings, which can interconnect several components via a conncctor.
Bchaviour of Fractal components can be formally describcd by means of
parametri'sed networks of commun'icati,ng automata language [1]. Behaviour of
each primitive component is modelled as a finite state parametrised labelledtran-
si,t'ionsgstem (pLTS) - a labellcd transition system with parametrised actions,
a set of parameters of the system and variables for cach state. Behaviour of
a composed FYactal component is defined using a parametrised sgnchronisation
network (pNet). It is a pLTS computed as a product of subcomponcnts' pLTSs
and a transducer. Thc transduccr is a pLTS, which synchronises actions of the
corrcsponding LTSs of the subcomponents. When synchronisation of thc actions
occurs, the transducer changes its state, which mcans reconfiguration of the
component's architecture. Also behaviour of a Fractal component's controller
can bc formally described by means of pLTS/pNet. The rcsult is composition of
pLTSs for binding and unbinding of each of thc component's functional interfaces
(one pLTS per one interface) and pLTS for starting and stopping the component.
In the component model SOFA [7], u part of S)FA project (SoFtware
Appli,ances/, a softwarc system is described as a hierarchical composition of
primitive and composite components. A component is an instance of a template,
which is dcscribed by its frame and architccture. Thc frame is a "black-box"
specification view of the component defining its provided and required interf'aces.
Primitivc componcnts arc directly implemented by described software system -
thcy have a primitivc architccture. The architecture of a composcd component
is a "grey-box" implementation view, which defines first level of nesting in bhe
component. It describes dircct subcomponents and their interconnections via
interfaces. The conncctions of the interfaces can be realised via conncctors,
implicitly for simplc connections or cxplicitly. trxplicit connectors are described
in a similar way as the components, by a frame and architecture. The conncctor
frame is a set of roles, i.e. interfaces, which arc compatible with interfaces of com-
poncnts. The conncctor architecture can be simplc (for primitive connectors), i.e.
directly implcmented by described software system, or compound (for composite
conncctors), which contains instances of other connectors and components.
Thc SOFA uses a componen,t,d,efi,ni,t,i,on,
lan,gu,age(CDL) for specification of
components and behaui,ourprotocols (BPs) for formal description of their be-
haviours. Thc BPs are regular-like cxpressions on the alphabet of event tokens
reprcsenting cmitting and accepting method calls. Behaviour of a component (its
interface, frame and architecture) can be dcscribed by a BP (interface, framc
and architccture protocol, respectively) as the set of all traces of event tokens
ComponentModel with Support of Mobile Architectures 6l
generatcd by the BP. The architccture protocols can be generated automati-
cally from architccture description by a CDL comp'iler. A protocol conformance
relati,on ensures thc architecture protocol generatcs only traces allowed by the
frame protocol. From dynamic architcctures, the SOFA allows only a dynamic
update of componcnts during a system's runtime. The update consists in change
of implemcntation (i.e. an architecturc) of the component by a new one. Com-
patibility of thc implementations is guaranteed by thc conformance rclation of
a protocol of the new architecture and the component's framc protocol.
Recently, the SOFA tcam is working on a new version of the component
modcl. The component model SOFA 2.0 [3] aims at removing sevcral limi-
tations of the original version of SOFA - mainly thc lack of support of dynamic
reconfigurations of an architecture, well-structured and extensible control parts
of components, and multiplc communication styles among components.
4 Discussion
Thc componcnt model proposed in this paper is able to handle mobile architcc-
tures, unlike the SOFA that supports only a subset of dynamic architcctures
or the Fractal/Fractive, which does not support components mobility. As is
described in Section 2.2, the n-calculus provides fitting fbrmalism.
Moreovcr, the proposed semantics permits to combine provided control and
required functional interfaces, e.g. in comparison with the Fractal/Fractive that
also providcs control and functional interfaces. Regardless, in some cases,it sepa-
ration descriptiou and vcrification of control and functional parts is needcd. The
possiblc solution can be an application of typed z-calculus, which distinguishcs a
type of names, and rcplacing of some communication patterns that use control-
functional bindings by special z--calculusconstructions (c.g. a special stop/start
processcs recursivcly controlling also subcomponents of a component, which is
stopped/started). Rcgardless, for mobilc architectures, the ability to combine
control and functional intcrfaces is nccessary.
The ncxt featurc of the component model is partially independencc of a
component's specification from its implementation. This f'eatureis similar to the
SOFA's component-templatc relationship. It allows to control behaviour of a
primary component's implementation, define a composite component's border
that isolatcs its subcomponcnts, which is called "a membranc" in the Fractal,
ctc. Our goal is to expand thc specification-implerncntation rclationship of com-
ponents so it allows runtimc replaccments of the components' implementations
without need to stop a component during replacement, in comparison with the
SOFA. We bclieve it can be achieved by means of component mobility.
Howcvcr, all above mcntioned fcatures will be parts of an ongoing work.
5 Conclusion and F\rture Work
This paper dcscribesthc componcnt modcl with support of mobilc architectures.
The component model splits a distributed information system into primitive and
62 M. Rychly
composite conrponents according of decomposability of the system's parts, the
components' functional and control interfaces according to types of required
or provided serviccs, and conncctors realising a communication layer betwccn
'I'he
the components. components and the connectors are described at different
levcls, as their specificatiorrsand irnplcrnentatious. Scrnantics of thc entities can
be describcd by means of z-calculus processes.
An ongoing work is rclated to completing cxact description of the compo-
ncnt model's formal semantics. Future work is mainly related to realisation of a
supporting environmcnt, which allows intcgration of the model into a software
development process, including integration of verificat,ion tools and implemen-
tation support.
Th'i,sresearch has been supported bg the Grant Agencg of Czech Republi,c grants
No. 102/05/0723 "A Fro,mework for Formal Speci,ficotions o,n,d,PrototEping o,f
Informati,on Sgstem's Network Applicati,ons" and bg the Research Plan No. MSM
002 163052 8 "5 ecuritg- Ori,ented Research i,n Information Technology" .
References
1. T. Barros. Formal specificat'ion and uemfi,cation of distributed contponent systems.
PhD thesis, Universit6 de Nice - INRIA Sophia Antipolis, Nov. 2005.
2. E. Bruneton, T. Coupaye, and J.-B. Stefani. The Fbactal component model. Draft
of speciflcation, version 2.0-3, The ObjectWeb Consortium, Feb. 2004.
3. T. Brrre5, P. Hnet,vnka, and F. Pl6Sil. SOFA 2.0: Balancing advanced feat,rrrcsin a
hierarchical cornponent model. In Proceedings of SERA 2006, pages 40-48, Scattle,
USA, Aug. 2006. IEEE Computer Socicty.
4. .J.I{16l and M. Zemlicka. Autonomous components. In SOFSEM 2000: Theory
and Practtce of Informat'ics, volume 1963 of Lecture Notes zn Cornputer Sciertce,
pagcs 375- 383. Springer, 2000.
5. K.-K. Lau and Z. Wang. A survey of software comporrerrt models (second cdition).
Prc-print CSPP-38, School of Computer Sciencc, The Univcrsity of Manchester,
Manchester M13 gPL, UK, May 2006.
6. R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes) part I/II.
Journal of Inforrnati,on and Com,putati,on,l00:4L,77, Sept. 1992.
7. F. Pl6Sil, D. Bflek, and R. Janedek. SOFA/DCUP: Architecture for component
trading and dynamic updating. ln lth International Conference on Configurable
Di,stributed Systerns, pages 43 51, Los Alamitos, CA, USA, May 1998. IEtrtr Com-
putcr Society.
8. M. Rychl;f. Towards verification of systems of asynchronous concurrent processes.
In Proceedi,ngs of 9th Internati,onal Conference Inforrnation Systems lrnplementa-
tion and Modelling (ISIM'06), pages 123 130. MARQ, Apr. 2006.
9. M. Rychly arrd J. Zendulka. Distributed inforrnation systerrr as a systern of
asynchronous concurrent processes. In MEMICS 2006 Second Doctoral Workshop
on Mathernati,co,l and Engi,'neering Methods i,n Com,puter Sc,ience, pages 206 2r3.
Faculty of Information Technology BUT, Oct. 2006.
10. C. Szyperski. Com,ponent Software: Begond Object-Oriented Programmi,ng. Addi-
son Wesley Professional, second cdition, Nov. 2002.