Conrmon features of current information systems have significant 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.
Increasing globalisation of information society and its progression creatc nceds for extensivc and reliable information technology solutions. Common requirements 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 specification 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 updating of components and connections during the systems' runtimc (i.e. dgnami,c reconfigurat'ion), maintaining components' compatibility, etc. [4] 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'itectures (i.e. architectrtres with dynamic reconfigurations) and mobi,le arch'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 processing bounded to one component without advanced featurcs such as dynamic reconfiguration.
The component-based deuelopment (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 accessible t,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,ntics and 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 reconfigurations and component mobility, strict isolation of control and business logic 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 disadvantages compared with the rcviewed approaches. To conclude, in Section 5, we summarise our approach, current results and briefly outline the future work.
In this scction, wc describe our approach to the componcnt model with support of mobile architectures. The Figure 1 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'ite i,mplementati,on (conpositecomprnpl) is decomposable on 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 (descendants of 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-Interface) are required or provided (attribute type of the entity) by u component to its neighbouring componcnts at the samc level of the architccture description (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 services for components' introspection (e.g. getFunclnterfacesO) and changes of an architecture and behaviour (startO and stopO). The services for changes of an architecturc are, for example, packComponentO and 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 implcmentation. The connector abstract'ion (ConnAbstraction) represents an abstract connection of a pair of compatiblc interfaces. The connectorimplementation (Connlmprementation) represents specific 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).
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, cortrtectiotr to inter:connect subcomponents 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 intcrconnect required functional interfaces with (providcd2) control interfaces. This allows to build systems where functional (business) requirements imply changes of the systems' architectures.
The componcnt model's formal description can be realised by means of the process algebra n-calculus, known as thc calculus of mobi,Ie processes [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 process C : (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 dcnoted as a paramctric proccss C(p1 ,. ..,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 "f packConponentO and unpackConponento 2 in ou. approach, the control interfaces are only provided (they provide a control) Component Model 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 providcd interfaces reprcsented by names pr ,. . . ,pu and required interfaccs represented by namcs Qt,...,eu of the subcomponents, we can define parametric n-calculus process for binding the interfaces B(pr,...,pu,Q,,...,e,) :ii qi@).pr(r).B(pr,...,pu,et,...,Qu) (
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--calculus processcs: directly by mcans of higher ordcr z--calculus or indirectly by means of passing of names ("an executor example" in [6]). The indirect mcthod in terms of systcms of asynchronous concurrent processes has been described in [9]. We can define processes that 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,metric process Ps to send (export) all interfaces pr,...,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 The proccss [/6: is used by a componcnt, which is a destination of passing of the c's interfaces.
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 composite 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.
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 labelled transi,t'ion sgstem (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 systemthcy 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 componcnts. 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,our protocols (BPs) for formal description of their behaviours. 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
Component Model with Support of Mobile Architectures 6l generatcd by the BP. The architccture protocols can be generated automatically 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. Compatibility 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 limitations of the original version of SOFAmainly thc lack of support of dynamic reconfigurations of an architecture, well-structured and extensible control parts of components, and multiplc communication styles among components.
Thc componcnt model proposed in this paper is able to handle mobile architcctures, 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 separation 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 controlfunctional bindings by special z--calculus constructions (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'eature is 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 components 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.
This paper dcscribes thc componcnt modcl with support of mobilc architectures.
The component model splits a distributed information system into primitive and 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 the components. 'I'he components and the connectors are described at different levcls, as their specificatiorrs and 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 componcnt 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 implementation support.
Th'i,s research 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 0 0 2 1 6 3 0 5 2 8 " 5 ecuritg-Ori,ented Res earch i,n Information Technology " .