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.