Evolution of structure and behaviour of components in mobile architecture

Faculty of Information Technology, Brno University of Technology, Abstract. This paper deals with formal description of structure andbehaviour of component based systems with particular features such asdynamic reconfiguration and component mobility. Those features allowsparts of the component based systems to change their structure andbehaviour at run-time. It can be done by means of creating new compo-nents and connections, removing existing components and connection, aswell as moving individual components or groups of interconnected com-ponents into a new context. To support description of initial state andstructural and behavioural evolution of the component based systems, aformal approach has been developed. This approach uses the π-calculus,a well-established process calculus enabling to describe concurrent com-putations with variable configuration.
Key words: Component-based systems, Formal description, π-calculus.
Design of current information systems has to respect many functional andnon-functional requirements, which have significant impact on software archi-tectures of these systems. Those requirements may include geographical andorganisational limitations, support of distributed activities, integration of well-established (third party) software products, connection to a variable set ofexternal systems, etc. The systems need to be realised not as monoliths butas component based systems (CBS), which are systems composed of individualcooperating components – self contained entities accessible and interconnectedthrough well-defined interfaces. Moreover, exact specification of componentsand their interfaces is necessary, as well as description of their communicationbehaviour, the structure of a system and its initial state and evolution duringrun-time.
This paper deals with formal description of structure and behaviour of com- ponents in CBS with particular features such as dynamic reconfiguration andcomponent mobility (i.e. “mobile architecture”). The dynamic reconfigurationrepresents creation, destruction and updating of components and connectionsduring the systems’ run-time, while the component mobility allows creation ofcopies of the components and changes of their context in a system.
The remainder of this paper is organised as follows. In next part of Section 1, we briefly introduce the process algebra π-calculus as a formal basis for ourapproach. In Section 2, we propose set of rules for formal description of structureand behaviour of components in CBS with dynamic reconfiguration and compo-nent mobility. Section 3 deals with an example, on which the formal descriptionof a simple system with component mobility is demonstrated including evolutionof components’ structure and behaviour during the system’s run-time. In Section4, we review main approaches that are relevant to our subject and discuss theiradvantages and disadvantages in comparison with our approach. To conclude, inSection 5, we summarise current results and outline the future work.
To describe component based systems’ structure and behaviour of their enti-ties, we use the process algebra π-calculus, known also as a calculus of mobileprocesses [1]. The π-calculus allows to model systems with dynamic communica-tion structures (i.e. mobile processes) by means of two concepts: processes andnames. The processes are active communicating entities, primitive or expressedin π-calculus (denoted by uppercase letters in expressions), while the names areanything else, e.g. communication links (known as “ports”), variables, constants(data), etc. (denoted by lowercase letters in expressions). Processes use names(as communication links) to interact, and pass names (as variables, constants,and communication links) to another processes by mentioning them in inter-actions. The names received by a process can be used and mentioned by it infurther interactions (as communication links). This paper suppose knowledge offundamentals of the π-calculus, a theory of mobile processes, according to [2]: – x y .P is an output prefix that can send name y via name x (i.e. via the communication link x) and continue1 as process P , – x(z).P is an input prefix that can receive any name via name x and continue as process P with the received name substituted for every free occurrence ofname z in the process, – P + P is a sum of capabilities of P together with capabilities of P processes, it proceeds as either process P or process P , i.e. when a sum exercises oneof its capabilities, the others are rendered void, – P | P is a composition of processes P and P , which can proceed indepen- dently and can interact via shared names, i = P1 | P2 | . . . | Pm is a multi-composition of processes P1, . . . , Pm, which can proceed independently and can interact via shared names, – (z)P is a restriction of the scope2 of name z in process P ,– (x1)(x2) . . . (xm)P = (x1, x2, . . . , xm)P = (˜ scope of names x1, . . . , xm to process P .
1 the prefix ensures that process P can not proceed until a capability of the prefix has 2 the scope of a restriction may change as a result of interaction between processes – !P is a replication that means an infinite composition of processes P or, equivalently, a process satisfying the equation !P = P | !P .
The π-calculus processes can be parametrised. A parametrised process, an abstraction, is an expression of the form (x).P . We may also regard abstractionsas components of input-prefixed processes, viewing a(x).P as an abstractionlocated at name a. In (x).P as in a(x).P , the displayed occurrence of x is bindingwith scope P .
Definition 1 (Abstraction). An abstraction of arity n ≥ 0 is an expressionof the form (x1, . . . , xn).P , where the xi are distinct. For n = 1, the abstractionis a monoadic abstraction, otherwise it is a polyadic abstraction.
When an abstraction (x).P is applied to an argument y it yields process P {y/x}. Application is the destructor of abstractions. We can define two types ofapplication: pseudo-application and constant application. The pseudo-applicationis defined as follows.
Definition 2 (Pseudo-application). If F = (˜ x} is an instance of F . We abbreviate P {˜ refer to this instance operation as pseudo-application of an abstraction.
In contract to the pseudo-application that is only abbreviation of a substitu- tion, the constant application is a real syntactic construct. It allows to describea recursively defined process.
Definition 3 (Constant application). A recursive definition of a process constant K is an expression of the form K = (˜ constant application, sometimes referred as an instance of the process constantK, is a form of process K ˜ In component based systems, a component can be described by means of itsprovided and required interfaces and its communication behaviour. We candistinguish the following types of interfaces functional interfaces for business-oriented services required or provided by a component with input and output parameters, respectively, control interfaces for obtaining references to a component’s provided func- tional interfaces, binding a component’s required functional interfaces toreferenced provided functional interfaces of another component, and chang-ing of behaviour and structure (obtaining references to a fresh copy of acomponent, registration of a new component as a subcomponent and unreg-istration of an old subcomponent of a composite component), reference interface for passing of references to components or references to interfaces, which is required to support component mobility.
A primitive component is realised as “a black-box”, which behaviour has to be formally defined by its developer as a π-calculus process where names representthe component’s interfaces. The process also implements specific control actionsprovided by the component (e.g. requests to start or stop the component).
On the contrary, a composite component is decomposable at the lower levelof hierarchy into a system of subcomponents communicating via their interfacesand their bindings (the component is “a grey-box”). Formal description of thecomposite component’s behaviour and structure is a π-calculus process, whichis composition of – processes representing behaviour of the component’s subcomponents,– processes implementing communication between interconnected interfaces of the subcomponents and internal interfaces of the component, – and processes realising specific control actions (e.g. the requests to start or stop the composite component including their distribution to the compo-nent’s subcomponents, etc.).
A whole component based system can be described as one component withprovided and required interfaces, which represent the system’s input and outputactions, respectively.
Creation of a new connection between two compatible functional interfaces can be done by means of passing of functional interfaces (i.e. component mo-bility). At first, a reference to provided functional interface (a target interface)is obtained from a component via its control interface. This reference is sentvia outgoing connections into different location (via reference interfaces), butonly in the same parent component and at the same level of hierarchy of com-ponents (i.e. crossing the boundary of a composite component is not allowed).
The reference is received by a component with a compatible required functionalinterface (a source interface) and a connection (a binding) of this interface toreferenced interface is created by means of a specific control interface for bindingof the required functional interface. Destruction of a connection can be done byrebinding of a required interface participating in this connection to reference toother provided functional interface.
Connections can interconnect only interfaces of the same types and dynamic creation of new connections and destruction of existing connection are permittedonly for functional interfaces. Combining of actions of functional interfaces withactions of control interfaces is permitted only inside primitive components. Thisallows to build a system where functional (business) requirements imply changesof the system’s architectures.
Notation of Names and Definition of Component Behaviour Before we define and describe π-calculus processes implementing behaviour of acomponent and its individual parts, we need to define the component’s interfaceswithin the terms of the π-calculus, i.e. as names used by the processes. Thefollowing names can be used in external or internal view of a component, i.e.
for the component’s neighbours or the composite component’s subcomponents,respectively.
– external: s0, s1, c, rs, . . . , rs , pg, . . . , pg of any component, – internal: a, r s, . . . , r s , p g, . . . , p g of a composite component only.
where n is a number of the component’s required functional interfaces, m isa number of the component’s provided functional interfaces (both from theexternal view) and the names have the following semantics: via s0 – a running component accepts a request for its stopping, which a com- posite component distributes also to all its subcomponents, via s1 – a stopped component accepts a request for its starting, which a com- posite component distributes also to all its subcomponents, via c – a component accepts a request for its cloning and returns a new stopped via rs – a component accepts a request for binding given provided functional interface (included in the request as the interface’s reference) to requiredfunctional interface ri, via pg – a component accepts a request for referencing to provided functional interface pj that is returned as a reply, via a – a composite component accepts a request for attaching its new subcom- ponent, i.e. for attaching the subcomponent’s s0 and s1 names (stop andstart interfaces), which can be called when the composite component will bestopped or started, respectively, and as a reply, it returns a name acceptingthe request to detach the subcomponent.
Definition 4 (Component Behaviour). A component behaviour of a prim-itive component CompP is a π-calculus abstraction CompP of the form (s0, s1, c, rs, . . . , rs , pg, . . . , pg ).P where process P describes behaviour of the primitive component’s core (as it isdefined by the component’s developer) and processing of control actions.
A component behaviour of a composite component CompQ is a π-calculus (s0, s1, c, rs, . . . , rs , pg, . . . , pg ).Q where process Q describes processing of control actions, communication withsubcomponents connected into composite component CompQ by means of theirinterfaces3, mutual communication of the subcomponents, and contains a com-position of processes describing behaviour of the individual subcomponents.
The following sections describe construction of the processes P and Q, which describe control actions and communication with a primitive component’s coreor with a system of a composite component’s subcomponents.
3 Inside composite component CompQ, in the process Q, there are available names a, At first, we define the auxiliary process W ire, which can receive a message vianame x (i.e. input) and send it to name y (i.e. output) repeatedly till the processreceives a message via name d (i.e. disable processing).
W ire = (x, y, d).(x(m).y m .W ire x, y, d Passing of messages from x to y by process W ire is synchronous, which meansthat a message can not be received on x until a previously received message wassuccessfully sent via y. To allow asynchronous communication, we need to useprocess W ireasync, which is a “buffered” version of process W ire.
W ireasync = (x, y, d).(p)(P ush p, x, d | P op p, y ) P ush = (t, x, d).(x(m).(t )(P ush t , x, d | t t , m ) + d) Binding of a component’s functional interfaces is done via control interfaces.
These control interfaces provide references to a component’s functional providedinterfaces and allow to bind a component’s functional required interfaces toreferenced funcional provided interfaces of another local components. ProcessCtrlIfs implementing the control interfaces can be defined as follows SetIf = (r, s, d).s(p).(d.W ire r, p, d | SetIf r, s, d ) CtrlIfs = (r1, . . . , rn, rs, . . . , rs , p where names r1, . . . , rn, rs, . . . , rs , p the beginning of Section 2.1, processes SetIf and GetIf allow to bind requiredinterfaces and to get references to provided interfaces, respectively, and processP lug is an auxiliary process.
In a composite component, the names representing external functional in- terfaces r1, . . . , rn, p1, . . . , pm are connected to the names representing internalfunctional interfaces p , . . . , p , r , . . . , r . Requests received via external func- tional provided interface pj are forwarded to the interface, which is bound tointernal functional required interface r (and analogously for interfaces p and ri). This is described in process CtrlEI .
CtrlEI = (r1, . . . , rn, p1, . . . , pm, r , . . . , r , p , . . . , p ).
Control of a composite component’s life-cycle4 can be described as processCtrlSS.
Lif e = (sx, sy, px, py).sx(m).(r)(Dist px, m, r | r.Lif e sy, sx, py, px ) (cd(m).d m .d m | W ire p0, c0, d | W ire p1, c1, d ) CtrlSS = (s0, s1, a).(p0, p1)(Lif e s1, s0, p1, p0 | !Attach a, p0, p1 ) where names s0 and s1 represent the component’s interfaces that accept stop andstart requests, respectively. The requests for stopping and starting the compo-nent are distributed to its subcomponents via names p0 and p1, respectively, as itis described in processes Lif e and Dist5. Name a of process CtrlSS can be usedto attach a new subcomponent’s stop and start interfaces (at one step), i.e. toconnect them to the relevant composite component’s stop and start interfaces vianames p0 and p1 and via processes W ire, as it is described in process Attach.
Third name, which is received via name a, can be used later to detach thesubcomponent’s previously attached stop and start interfaces.
Cloning of Components and Updating of Subcomponents Cloning of a component allows to transport the component’s fresh copy intodifferent location, i.e. its subsequent attaching as a subcomponent of othercomponent. The processes of the cloning can be described as follows Ctrlclone = (x).x(k).(s0, s1, c, rs, . . . , rs , pg, . . . , pg , r, p) (k s0, s1, c, r, p | r rs, . . . , rs | p pg, . . . , pg | Component s0, s1, c, rs, . . . , rs , pg, . . . , pg ) where process Component with well-defined parameters s0, s1, c, rs, . . . , rs , pg, . . . , pg describes behaviour of a component, which is cloned when process Ctrlclone receives a request via name x. Then, process Ctrlclone returns namesrepresenting all functional and control interfaces in a process describing be-haviour of the component’s copy.
The fresh copy of a component can be used to replace a compatible subcom- ponent of a composite component. The process of update, which describes thereplacing of an old subcomponent with a new one, is not mandatory part of thecomposite component’s behaviour and its implementation depends on particularconfiguration of the component (e.g. if the component allows updating of itssubcomponents, a context of the replaced subcomponent, which parts of the 4 a primitive component handles stop and start interfaces directly5 in the initial state, the component and its subcomponents are stopped component have to be stopped during the updating, etc.). As an illustrativecase, we can describe process U pdate as follows U pdate = (u, a, s0, sd, rs, . . . , rs , pg, . . . , pg ).(k, s ) .r (r s, . . . , r s).(x)(pg x .x(p).r s p . . . pg .p (p g, . . . , p g ).(x)(p g x .x(p).rs p . . . p g .s .U pdate u, a, s , s , rs, . . . , rs , pg, . . . , pg ) Process U pdate sends via name u a request for a fresh copy of a cloned component. As a return value, it receives a vector of names representing allfunctional interfaces in a process describing behaviour of the new component,which will replace an old subcomponent in its parent component implementingthe update process. Name a provides the parent component’s internal controlinterface to attach the new subcomponent’s stop and start interfaces (the s and s names) and an interface later used to detach the subcomponent (name s ).
Name s0 is used to stop the replaced subcomponent and name sd is neededto detach the old subcomponent’s stop and start interfaces. Finally, namesrs, . . . , rs , pg, . . . , pg represent a context of the updated subcomponent, i.e.
connected interfaces of neighbouring subcomponents.
Component Behaviour of Primitive and Composite Components In conclusion, we can describe the complete behaviour of primitive and compositecomponents. Let’s assume that process abstraction Compimpl with parameterss0, s1, r1, . . . , rn, p1, . . . , pm describes behaviour of the core of a primitive compo-nent (i.e. excluding processing of control actions), as it is defined by the compo-nent’s developer. Further, let’s assume that process abstraction Compsubcompswith parameters a, r s, . . . , r s , p g, . . . , p g describes behaviour of a system of subcomponents interconnected by means of their interfaces into a compositecomponent (see Section 2.2). Names s0, s1, r1, . . . , rn, p1, . . . , pm and names a,rs, . . . , rs , pg, . . . , pg are defined at the beginning of Section 2.1.
Processes Compprim and Compcomp representing behaviour of the mentioned primitive and composite components can be described as follows Compprim = (s0, s1, c, rs, . . . , rs , pg, . . . , pg ).(r (CtrlIfs r1, . . . , rn, rs, . . . , rs , p | Compimpl s0, s1, r1, . . . , rn, p1, . . . , pm ) Compcomp = (s0, s1, c, rs, . . . , rs , pg, . . . , pg ).
(a, r1, . . . , rn, p1, . . . , pm, r , . . . , r , p , . . . , p ) (CtrlIfs r1, . . . , rn, rs, . . . , rs , p | CtrlIfs r , . . . , r , r s, . . . , r s , p , . . . , p , p g, . . . , p g | CtrlEI r1, . . . , rn, p1, . . . , pm, r , . . . , r , p , . . . , p | CtrlSS s0, s1, a | Compsubcomps a, r s, . . . , r s , p g, . . . , p g ) where processes CtrlIfs represent behaviour of control parts of components re-lated to their interfaces (see Section 2.2), processes Ctrlclone describe behaviourof a control part of components related to cloning of these components (seeSection 2.4), process CtrlSS represents behaviour of a component’s control parthandling its stop and start requests (see Section 2.3), and process CtrlEI de-scribes behaviour of communication between internal and external functionalinterfaces of a component (see Section 2.2).
An Example on Evolution of Structure and Behaviour As an example, we describe a component based system for user authenticationand access control. At first the system receives an input from an user in form(username, password) and verifies the user’s password in order to check theuser’s identity. If the user’s password passes the verification, the system createsa new session handle reserved for the user. The session handle is connected tothe system’s core. It enables the user to access the system’s core functionalityperforms access control according to the user’s authorisation. Finally, the sessionhandle is passed back to the user as a return value of the whole process.
– Login component, which verifies the user’s authentication and initiates the – Core component, which provides the system’s core functionality,– and Session component, which enables the user to access the Core com- ponent according to the user’s authorisation.
For simplicity, let’s assume that component Session has only one input in- terface for the user’s calls of the system’s core without any explicit authorisationchecks and component Core implements simple shared memory—one storagefor all users with two interfaces: for saving and loading a value to and from thememory, respectively.
Definition of the Components’ Implementations At first, we define behaviour of the components’ cores, i.e. the components’ im-plementations, which have to be defined by developer of the system. Descriptionof behaviour of the Core component’s implementation is: Coreimpl = (s0, s1, psave, pload).(val)Coreimpl undef, psave, pload where process Coreimpl can save a message received via name psave and loadthe saved message and send it as a reply on a request received via name pload.
Description of behaviour of the Session component’s implementation is the Sessionimpl = (s0, s1, rsave, rload, phandle).Session save, rload, phandle).(save, load)(phandle(ret) where process Sessionimpl can receive via name phandle an user’s request spec-ified subsequently by inputs via names save or load and pass it to processCoreimpl via names rsave or rload (the required interfaces), respectively.
Finally, behaviour of the Login component’s implementation can be defined Loginimpl = (s0, s1, pinit, sysattach, sessionclone, coreg (Loginverify username, password, ok, f ail | Loginimpl s0, s1, pinit, sysattach, sessionclone, coreg + ok.sessionclone new .new(s , s , clone , r , p ) where process Loginimpl can receive an user’s initial request via name pinit asa triple of names (username, password, ret) and after successful verificationof the user’s name and password, the process returns a new session’s handlevia name ret. Name sysattach has to provide an interface to attach new sub-components into the system (see Section 2.3), name sessionclone is connectedto a provided interface for cloning of Session component (see Section 2.4),and coreg names are connected to provided control interfaces for getting references to interfaces save or load of component Core (see Section2.2), respectively. The definition contains pseudo-application of process abstrac-tion Loginverify username, password, ok, f ail , which represents description of behaviour of user’s authentication process (e.g. Loginverify = (. . .).ok for au-thorising of all users).
Description of the Component Based System Now, we can describe behaviour of individual components including their controlparts, as well as behaviour and structure of a composite component, which rep-resents the whole component based system. According to Section 2.5, behaviourof components Core and Session can be described as follows: | Sessionimpl s0, s1, rsave, rload, phandle ) Behaviour of component Login has to be described differently from the oth- ers, because it uses control interfaces sysattach, sessionclone, coreg which can not be referenced (contrary to functional interfaces, see Section 2).
This case can be compared with the description of U pdate process in Section2.4. The behaviour of component Login can be described as follows: | Loginimpl s0, s1, pinit, sysattach, sessionclone, coreg Behaviour and structure of a composite component, which represents the whole component based system, can be described as follows: | Ctrlclone c | CtrlSS s0, s1, a | System a, r s (sessclone, slogin, slogin, dlogin, score, score, dcore, ssess, ssess, dsess) The initial structure and behaviour of the component based system is describedby means of π-calculus process abstraction System. The system consists of com- ponents Core, Session and Login. Structure and behaviour of each componentis described by means of process abstraction Core, Session and Login, respec-tively. When process Login receives a vector of names from process System vianame pinit (a user’s name and a password for authentication of the user anda name for the system’s response), it initiates a composition with new processSession via name sessclone (the composition represents cloning of componentSession for the user), connects names used in the new process to names coresaveand coreload used in process Core, and sends name sesshandle used in the newprocess back via one of names in the vector previously received via pinit (thisrepresents connection of cloned component Session into the system’s contextand passing of its handle reserved for the user).
After those actions, the resulting π-calculus process describes a new state of the system (different from the initial state) where the user has been authenticatedand is authorised to access the system’s core functionality. It is evident thatstructure and behaviour of the system in this state has been changed. Thereis new process Session in composition with original processes and there arenew connections via names shared between the new process and the originalprocesses.
Such evolution of structure and behaviour of component based systems can lead, if uncontrolled, to architectural erosion and architectural drift [3] resultinginto degradation of components’ dependencies over time. In our approach, thisfailing is prevented by 1. limitation of dynamic creation of new connections and destruction of existing connection only to functional interfaces (i.e. architecture of control interfacesand their interconnections is static, contrary to evolving architecture offunctional interfaces’ interconnections), 2. restriction of passing of interfaces only to the parent component of compo- nents owning the interfaces and at the same level of hierarchy of components(i.e. a reference to an interface is not allowed to cross a composite compo-nent’s boundary; see Section 2).
In this way, the evolution of structure and behaviour of component based There have been proposed several component models [4], i.e. meta-models ofcomponent based architecture including systems of architectural entities, theirproperties, styles of their interconnections, and rules of evolution of the ar-chitecture. In this section, we focus on two contemporary component modelssupporting some features of dynamic architectures and formal descriptions.
The component model Fractal [5] is a general component composition framework with support for dynamic architectures. A Fractal component isformed 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. Those subcomponents are controlled by the controller (“a membrane”) of the enclosingcomponent. A component can be shared as a subcomponent by several distinctcomponents. A component with empty content is called a primitive component.
Every component can interact with its environment via operations at externalinterfaces of the component’s controller, while internal interfaces are accessibleonly from the component’s subcomponents. The interfaces can be of two sorts:client (required) and server (provided). Besides, a functional interface requiresor provides functionalities of a component, while a control interface is a serverinterface with operations for introspection of the component and to control itsconfiguration. There are two types of directed connections between compatibleinterfaces of components: primitive bindings between a pair of components andcomposite bindings, which can interconnect several components via a connector.
Behaviour of Fractal components can be formally described by means of parametrised networks of communicating automata language [6]. Behaviour ofeach primitive component is modelled as a finite state parametrised labelled tran-sition system (pLTS) – a labelled transition system with parametrised actions,a set of parameters of the system and variables for each state. Behaviour ofa composed Fractal component is defined using a parametrised synchronisationnetwork (pNet). It is a pLTS computed as a product of subcomponents’ pLTSsand a transducer. The transducer is a pLTS, which synchronises actions of thecorresponding LTSs of the subcomponents. When synchronisation of the actionsoccurs, the transducer changes its state, which means reconfiguration of thecomponent’s architecture. Also behaviour of a Fractal component’s controllercan be formally described by means of pLTS/pNet. The result is composition ofpLTSs for binding and unbinding of each of the component’s functional interfaces(one pLTS per one interface) and pLTS for starting and stopping the component.
In the component model SOFA [7], a part of SOFA project (SOFtware Appliances), a software system is described as a hierarchical composition ofprimitive and composite components. A component is an instance of a template,which is described by its frame and architecture. The frame is a “black-box”specification view of the component defining its provided and required interfaces.
Primitive components are directly implemented by described software system –they have a primitive architecture. The architecture of a composed componentis a “grey-box” implementation view, which defines first level of nesting in thecomponent. It describes direct subcomponents and their interconnections viainterfaces. The connections of the interfaces can be realised via connectors,implicitly for simple connections or explicitly. Explicit connectors are describedin a similar way as the components, by a frame and architecture. The connectorframe is a set of roles, i.e. interfaces, which are compatible with interfaces of com-ponents. The connector architecture can be simple (for primitive connectors), i.e.
directly implemented by described software system, or compound (for compositeconnectors), which contains instances of other connectors and components.
The SOFA uses a component definition language (CDL) for specification of components and behaviour protocols (BPs) for formal description of their be-haviours. The BPs are regular-like expressions on the alphabet of event tokens representing emitting and accepting method calls. Behaviour of a component (itsinterface, frame and architecture) can be described by a BP (interface, frameand architecture protocol, respectively) as the set of all traces of event tokensgenerated by the BP. The architecture protocols can be generated automati-cally from architecture description by a CDL compiler. A protocol conformancerelation ensures the architecture protocol generates only traces allowed by theframe protocol. From dynamic architectures, the SOFA allows only a dynamicupdate of components during a system’s runtime. The update consists in changeof implementation (i.e. an architecture) of the component by a new one. Com-patibility of the implementations is guaranteed by the conformance relation ofa protocol of the new architecture and the component’s frame protocol.
Recently, the SOFA team is working on a new version of the component model. The component model SOFA 2.0 [8] aims at removing several limi-tations of the original version of SOFA – mainly the lack of support of dynamicreconfigurations of an architecture, well-structured and extensible control partsof components, and multiple communication styles among components.
In comparison of our approach with the reviewed approaches, we can find many similar features, which are typical for description of component based sys-tems’ behaviour and structure (a classification of components into primitive andcomposite, focusing on communication between required and provided interfaces,a basic support of dynamic architecture, etc.). Contrary to Fractal or SOFA,our approach allows to describe behaviour and structure of component basedsystems with support of mobile architecture with prevention of the architecturalerosion or drift, i.e. evolving of the system’s behaviour and structure by means ofcomponent and interface mobility with soft restrictions (see Section 2). Moreover,we do not introduce a new formalism to describe the system’s behaviour andstructure, but use well-established π-calculus for definition of individual primi-tive components’ behaviour and their composition into hierarchically structuredcomponent based systems. This approach allows to utilise existing tool for model-checking of π-calculus processes and formal verification of their properties (e.g.
Advanced/Another Bisimulation Checker [9] or tools from ArchWare Project[10]). However, our approach can have also drawbacks, e.g. complex descriptionof primitive components’ behaviour combining actions of functional interfaceswith actions of control interfaces (for example see component Login in Section3.2) or insufficient visibility of a component based system’s structure during itsevolution. The evolution of the system means evolution (reduction) of π-calculusprocess representing too much tightly bound behaviour and structure.
In this paper, we have presented an approach to formal description of behaviourand structure of component based systems with features of dynamic and mobilearchitectures. We use calculus of mobile processes, the π-calculus, for definitionof individual primitive components’ behaviour and their composition into a hier-archically structured component based system. Assets of the approach is support of mobile architecture with prevention of the architectural erosion. Drawbackscan be complex description of primitive components’ behaviour and insufficientvisibility of a system’s structure independently of its behaviour during theirevolution.
Future work is mainly related to integration of the approach into visual UML modeling and CASE tools and automatic “bottom-up” generation of formal de-scription of a component based system’s behaviour and structure from definitionof its primitive components and their composition. We are also experimentingwith description of service-oriented architectures as component based systemswith component mobility.
Acknowledgement. This research has been supported by the Research PlanNo. MSM 0021630528 “Security-Oriented Research in Information Technology”.
1. Milner, R., Parrow, J., Walker, D.: A calculus of mobile processes, parts I and II.
Journal of Information and Computation 100 (September 1992) 41–77 2. Sangiorgi, D., Walker, D.: The π-Calculus: A Theory of Mobile Processes. New Ed edn. Cambridge University Press (October 2003) 3. Perry, D.E., Wolf, A.L.: Foundations for the study of software architecture. SIG- SOFT Software Engineering Notes 17(4) (October 1992) 40–52 4. Lau, K.K., Wang, Z.: A survey of software component models (second edition).
Pre-print CSPP-38, School of Computer Science, The University of Manchester,Manchester M13 9PL, UK (May 2006) 5. Bruneton, E., Coupaye, T., Stefani, J.B.: The Fractal component model. Draft of specification, version 2.0-3, The ObjectWeb Consortium (February 2004) 6. Barros, T.: Formal specification and verification of distributed component systems.
e de Nice – INRIA Sophia Antipolis (November 2005) trading and dynamic updating. In: 4th International Conference on ConfigurableDistributed Systems, Los Alamitos, CA, USA, IEEE Computer Society (May 1998)43–51 sil, F.: SOFA 2.0: Balancing advanced features in a hierarchical component model. In: Proceedings of SERA 2006, Seattle, USA, IEEEComputer Society (August 2006) 40–48 9. Briais, S.: Abc – the Advanced Bisimulation Checker. http://lamp.epfl.ch/ sbri-

Source: http://www.fit.vutbr.cz/~rychly/public/docs/evol-of-struct-and-behav-of-comps-in-mob-arch/evol-of-struct-and-behav-of-comps-in-mob-arch.pdf