Cavendish School of Computer Science Technical Reports Series
Middleware Models for Dynamic Software Architectures G. R. Ribeiro Justo Cavendish School of Computer Science, University of Westminster, London, UK E-mail:
[email protected]
Technical Report: CSCS-TR-1-99
Abstract
Component technology is a new promising approach to the development of complex, reusable distributed systems in that it separates the application concerns into components that can be programmed separately and assembled together through processes of composition. Architecture description languages provide suitable notations to describe the systems architecture in terms of components, with well-de ned interfaces, connectors and the architectural con guration, where components and instances are created and glued. The middleware provides the infra-structure in which components can be executed and interact in a transparent manner. A limitation of existing (algebraic) formal component models is that they are static, which means that the architectural con guration cannot be recon gured during execution. This problem can be the result of existing algebraic formalisms (process algebras) applied to communicating systems, which usually only support static networks of processes. This paper examines the formal modelling of dynamic recon guration and presents results that demonstrate that realistic recon guration models can be formulated using static formal models. This is illustrated with examples of two recon guration models speci ed in CSPM , a dialect of CSP used by the FDR2 model checker.
1 Introduction Although distributed (communicating) systems are inherently dynamic, as they have to provide availability and handle faults, they have mainly been regarded as static, where both the number of communicating processes and their interconnections are xed. The current trend, however, indicates that not only specialised applications in banking and telecommunications but also future software systems will be built from a collection of existing components, which are con gured or may even have to be dynamically recon gured (changed) at run time to satisfy eciency or fault-tolerance requirements. Models of recon gurations have been studied for some time [7, 6, 3] but they have focussed mainly on specialised applications, which means that strong assumptions are usually made with respect to the execution and communication. For example, the model proposed in [7] assumes that the communications are transactions, where the initiator always receives a con rmation at the end of the transaction. Another problem results from the formal models used to model communicating systems, especially applying algebraic approaches. Process algebras and the theories behind them have been studied over the last two decades and their results are well established. For example, CSP [5] and LOTOS [4] have been applied in various industrial projects. Most of these process algebras, however, are based on static models. For example, in CSP channel names are constants and are not rst class objects, which means that they cannot be passed as values between communicating processes. A few solutions do exist such as that proposed by the -calculus [9]. In the -calculus, a channel is regarded just as a value and therefore can be sent between processes. A second important property of the -calculus is to allow new (fresh) names to be de ned. These two properties support the dynamic variations of a con guration, where processes can create new channels and pass their values to other processes to enable them to com1
municate. Observe that the -calculus represents a very severe change of the earlier CCS [8], which was much simpler, as the new constructs are not derived from the existing ones. Another solution is to formulate dynamic models using the existing constructs. An example is the model proposed for Wright [1], an architecture description language (ADL) based on CSP. The key concepts of an architecture description are the components, connectors and the (architectural) con guration, where the instances and interconnections of the components and connectors are de ned. In Wright, each component contains ports (and each connector contains roles), which de ne their behaviour and are speci ed in CSP. In a con guration, compatible ports are attached to compatible roles. The proposed dynamic model is simple [2] and consists rstly of identifying all the possible con gurations of an architecture and secondly introducing new control channels, which indicate when a recon guration is permitted. The rst problem with the solution presented by [2] is that the planned recon gurations must be listed. Secondly, the behaviour of the ports may become too complex because of the control channels. Also, their model appears to be purely for speci cation purposes, and gives no indication as to how it might be realised. In this paper, a recon guration model based on an existing recon guration middleware is proposed. The proposed model attempts to deal with channel names in a manner similar to that used by -calculus. But processes do not interact directly so the con guration can be easily changed \on-the- y". The solution was to introduce a naming server (a middleware server), which maintains a mapping table of channels and can forward the messages between the processes. The paper is structured as follows. In the next section, a simple recon guration model is presented. The model does not assume the existence of a \con guration" process, so any process can change the con guration. Section 3 presents another model based on the idea of an architecture description where the con guration and recon guration are speci ed. Finally in Section 5, we present the main conclusions about and further directions of the work described in the paper.
2 A Simple Model In certain types of recon gurable systems, the con guration is de ned implicitly by the topology of channels amongst the processes. In this case, a process must know the identities of the processes it can communicate with or it can be informed by other processes about the identity of the those unknown processes. To illustrate this situation, assume the example similar to the mobile telephone network presented in [9]. Figure 1 shows a Car (telephone) process with channels, one to talk and another one to switch from the current station to another station. The Station process switches the Car connection when requested by the Central process. Observe that both the Station and Central are involved in the recon guration of the Car process.
2.1 The Middleware Model
A key concept in many current distributed system models is a distributed object computing (DOC) middleware [13, 12]. A DOC middleware facilitates the collaboration of local and remote application components. The model formalised in this paper is a simpli ed version 2
. talk
switch
Station 1
...
Station 2
Station n
Central
Figure 1: A mobile telephone network.
configuration messages
Task
Interface
Configuration
Interface
Interface
Task
Task
Link Server
Communication
C++CL Middleware
1
Figure 2: C++CL Middleware. of the C++CL DOC middleware presented in [10] and illustrated in Figure 2. C++CL has been designed to support the development of recon gurable distributed systems. For simplicity, the paper will not cover the details of C++CL. The reader can refer to [10] for more details. Observe that all processes (tasks) do not interact directly but must use the middleware. The middleware keeps a con guration mapping table, which associates pairs of connected channels. A recon guration consists of modifying that mapping. In this rst simpli ed version of the model, not all channels must be connected via the middleware but only those channels, which may be recon gured. Assuming the mobile network example, the channels correspond to those between the Car process and the Station processes, as illustrated in Figure 3a). The middleware process contains a nite (but large) number of channels. This assumption does not make the solution less generic. Each application process is connected to a particular channel of the middleware. The application speci c processes do not have to use the same name, as a simple renaming procedure can be applied. As illustrated in Figure 3a), channels ctr.0 and ctr.1 are not recon gurable as they are not connected via the middleware. The idea of the example is 3
c.0 Car
Car
Middleware c.1 c.1.4
c.2
c.4
c.3
c.0.4
c.0.2
c.5 Station 1
Station 1
Station 2
Station 2
ctr.0
Central
ctr.1 Central
Subnetwork Abstract Model
Mobile Network Middleware
Figure 3: The Mobile Network Middleware Model. a) Complete Model b) Abstract Model to illustrate that not all connections must be done via the middleware.
2.2 Formalising the Model in CSPM
A formalised version of the mobile network middleware is presented in Figure 4. The machine-readable dialect of CSP (CSPM ) is used [11]. CSPM is the language used by the model checking tool FDR2 [11]. It combines the CSP process algebra with an expression language. The fundamentals of CSP are maintained; that is; the pre x operator ! is denoted by -> (e.g a->P), the external choice is denoted by [] (e.g P[]Q) and guards are denoted by & (e.g b0 & c0 [] b1 & c1). The parallel operator PX kY is written as P[X||Y]Q and the interleave operator P jjj Q is written as P|||Q. The notation used for the concealment operator P nX is P\X, where X is a set of events. The only way of writing the renaming operator is by using substitution. For example, in process P[[ b CarAbst [] c.1.4 -> CarAbst1 CarAbst1 = c.0.4 -> CarAbst1
As expected, process Network is trace equivalent to process CarAbst and in addition the re nement check Network v CarAbst is satis ed.
3 An ADL-Based Model In the previous middleware model, there is no separation of computation and con guration. A key aspect of an ADL is the separation of the computation (programming-inthe-small) from the system structure (programming-in-the-large). The system structure is that part of the design where the components and their relationships are speci ed. The architectural con guration is that part of the de nition where the instances and interconnections of the components and connectors are de ned. The advantage of this approach is the development of components, which are independent of any particular con guration and, therefore, more reusable. In this section, an ADL-based middleware model is presented, where the main idea is to introduce the notion of a \con guration" process, the role of which is to set up the connections between the processes' channels. A further aspect of the model is to illustrate how the communication between processes can be managed by the middleware. Each channel is associated with a bu er, where the sending process can put a message if the bu er is empty and similarly a receiving process can get a message out of the bu er if it is not empty. Extra conditional guards have been speci ed in the middleware to guarantee this property. Observe that this protocol allows the middleware to simulate a kind of \synchronous" communication, where the sender only continues after the receiver reads the message. To illustrate the formalisation of this model, assume a simple send/receive con guration presented in Figure 5. 5
-- Process Car Car ( t ) = c.0 ! t -> Car ( t ) [] c.1 ? s: Integer -> Car ( s ) -- Process Central Central = ctr.0 ! 0 -> ctr.1 ! 0 -> SKIP Station(i) = c.(2 * (i+1)) ? t:Integer -> Station(i) [] ctr.i ? s:Integer -> c.((2 * (i+1)) + 1) ! s -> SKIP -- The Subnetwork (Control and Stations) Subnetwork = ( (||| i:stations @ Station(i))
[| {ctr.0.x, ctr.1.x | x Middleware (assignArrayAt(array, x , true),p0,p1,p2,p3,p4,p5) [] -- Process car: switch arrayAt(array, p1) & c.1 ! 4 -> ( let S' = assignArrayAt(array, 1 , false) S'' = assignArrayAt(S', 2 , false) S''' = assignArrayAt(S'', 4 , true) within Middleware ( S''', p0, p1, p2, p3, p4, p5 )) [] -- Process station 0 - talk arrayAt(array, p2) & c.2 ! 0 -> Middleware (assignArrayAt(array, 2, false), p0, p1, p2, p3, p4, p5 ) [] -- Process station 0 - switch c.3 ? x: Integer -> Middleware (assignArrayAt(array, 1, true), p0, p1, p2, p3, p4, p5 ) [] -- Process station 1 - talk arrayAt(array, p4) & c.4 ! 0 -> Middleware ( assignArrayAt(array, 4, false), p0, p1, p2, p3, p4, p5 ) [] -- Process station 1 - switch c.5 ? x: Integer -> SKIP -- Initial State Space S_Initial = Network = ((Subnetwork) \ {ctr.0.x, ctr.1.x | x config!Output -> config!1 -> config!1 -> config!Input -> SKIP -- Guard Definition guardServer((B, P, C, N, A, I), pos) = if arrayAt(A, pos) then let test1 = arrayAt(P, pos) test2 = arrayAt(C, pos) test3 = arrayAt(N, pos) within ((test1 == Input and not arrayAt(I, pos)) or ((test1 == Output) and arrayAt(I, arrayAt(test2, test3)))) else false -- Server Definition SERVER(S)
= CONFIGURATION(S) [] WAITING(S)
CONFIGURATION(S)
= config?proc1 ->config?port1 -> config?type1 -> config?proc2 -> config?port2 -> config?type2 -> ((proc1==0 and proc2==1) & (let S1 = getPCNA(S) S2 = getBI(S) S' = configureServer(S1, proc1, port1, type1, proc2, port2, type2) S'' = putBI(S', S2) within SERVER(S'')))
WAITING(S)
= [] i: Clients @ S!=S_Initial & (guardServer(S, i) & c.i?msg -> OUT_REPLY(S, i, msg))
OUT_REPLY(S, i, msg) = if arrayAt(getPort(S), i) == Output then (let S1 = getBCI(S) S2 = getPNA(S) S'' = BIupdate(S1, i, msg, false) S''' = putBCI(S2, S'') within SERVER(S''')) else reply.i.arrayAt(getBuffer(S), i) -> (let S3 = getI(S) S4 = getBPCNA(S) S'''' = Iupdate(S3, i, true) S''''' = putI(S4, S'''') within SERVER(S''''')) -- Top Level Process ServerConfig = SERVER(S_Initial) [|{|config|}|] CONFIG_PROC ClientProcs
= SENDER ||| RECEIVER
MiddlewareServer2 = ServerConfig [|{|c, reply|}|] ClientProcs
Figure 6: Formal speci cation of the ADL-based middleware.
8
SENDREC
v (MiddlewareServer2\{|config,c|})[[reply.1.0
