Specifying Real-time Behaviour in Distributed Software ... - CiteSeerX

Download PDF
2 downloads 1822 Views 97KB Size Report
Comment
Software architecture aims at diminishing the overall complexity of software development. In this approach, software design focuses on a higher-level view of a ...
Specifying Real-time Behaviour in Distributed Software Architectures Hector A. Duran-Limon, Gordon S. Blair Computing Department, Lancaster University, Bailrigg, Lancaster LA1 4YR, UK. Tel: +44 1524 593141 Fax: +44 1524 593608 {duranlim, gordon}@comp.lancs.ac.uk

Abstract: Over the last few years, there has been considerable research in the area of Software Architecture. However, relatively little attention has been paid to the specification of real-time properties of such architectures. This paper presents the Xelha architectural description language which is intended to overcome this deficiency. The language offers both a task model and a resource model. The former models component interactions as tasks with associated pools of resources. The latter provides hierarchies of abstract resources. In addition, the use of object-oriented typing allow us to introduce some dynamism to architecture specifications. Finally, Xelha provides support for the specification of both static QoS management (i.e. desired level of QoS) and dynamic QoS mangement (i.e. mechanisms to attain the contracted level of QoS).

1. Introduction Software architecture aims at diminishing the overall complexity of software development. In this approach, software design focuses on a higher-level view of a system, thus abstracting away from implementation details. Architecture description languages (ADLs) represent formal notations for describing software architectures in terms of coarse-grained components and connectors. ADLs also provide architecture configurations which define how component and connectors are interconnected. ADL tools then help to automate the development processes by offering code generation. Importantly, analysis tools allow us to formally verify architecture systems, hence detecting potential problems before starting the fined-grained development process. There has been considerable research in the area. Most research has focused on the specification of static architectures. Furthermore, little attention has been paid to tackle real-time architectural issues, especially, for distributed systems. This paper presents the Xelha notation for the specification of distributed real-time system architectures. Components, connectors and interfaces are explicitly defined within the language. Both components and connectors may be composite. As a consequence, the definition of a system architecture may lead to a component composition hierarchy. Xelha uses object-oriented typing for the purposes of typechecking, architecture reusability and dynamic architecture specifications. The latter allow us to specify a range of architectural types, defined within a type hierarchy, that can be instantiated as a result of accessing a service provided by a component. Real-time specifications are in conformance with both a task model and a resource model. The task model provides a higher-level of resource management by isolating the pool of resources assigned to a task in a unit of resource management. End-to-end component interactions are associated with task graphs. In addition, tasks are associated with both QoS specifications and QoS management structures. The resource model is part of the OpenORB middleware architecture [Costa00a] and provides various levels of abstraction for resources, resource factories and resource managers. Therefore, both fine- and coarse-grained resource management are feasible within this model. Xelha also includes the specification of both static QoS management and dynamic QoS management. The former concerns the definition of the desired QoS properties whereas the latter relates to the mechanisms for maintaining the level of QoS contracted. In our work, we are mainly addressing distributed multimedia systems, however, the ADL can be extended to cover other areas. The paper is structured as follows. Section 2 introduces the OpenORB middleware architecture in conjunction with both the resource model and the task model. Section 3 then introduces the Xelha ADL. An example is presented in section 4. Following this, section 5 describes the implementation of a tool for the ADL and section 6 comments on some related work. Finally, some concluding remarks are presented in section 7.

2. Middleware Architecture 2.1 Overall Approach In our architecture we make use of reflection as a means of achieving a separation of concerns between the functional and non-functional behaviour. Reflection is a means by which a system is able to inspect and change its internals in a principled way [Maes87]. A reflective system is mainly divided into two parts: the base-level and the meta-level. The former deals with the normal aspects of the system whereas the latter regards the system’s representation. The base-level of the middleware platform concerns the programming structures of the

services provided by such a platform. These services are accessed through the base-level interface. In contrast, the meta-level provides the reification of the non-functional properties of this platform, e.g. the resource management of the objects involved in a particular service. The meta-level provides a means to inspect and modify the implementation of the middleware by accessing a well established meta-interface. For instance, the computational resources involved in a service may be reconfigured by manipulating the operations defined at the meta-level. In addition, we adopt the RM-ODP computational model [ISO95] for both the base- and the meta-level. Objects within this model have several interfaces. Not only operational interfaces but also stream and signal interfaces are supported. Moreover, explicit bindings are supported which offer more control over the communication path between object interfaces residing in different capsules (i.e. address spaces). In the architecture, the meta-space is structured, but not restricted, as a set of four orthogonal meta-models (compositional, environmental, encapsulation and resources.) This approach was first introduced by AL-1/D [Okamura92] in order to simplify the meta-interface by maintaining a clear separation of concerns among different system aspects. Each meta-model is introduced in turn below. The compositional meta-model deals with the way a composite object is composed, i.e. how its components are inter-connected, and how these connections are manipulated. There is a compositional meta-model per object. The environmental meta-model is in charge of the environmental computation of an object interface, i.e. how the computation is done. It deals with message arrivals, message selection, dispatching, marshalling, concurrency control, etc. The encapsulation meta-model relates to the set of methods and associated attributes of a particular object interface. Methods scripts can be inspected and changed by accessing this meta-model. Finally, the resource meta-model is concerned with both the resource awareness and resource management of objects in the platform. A more comprehensive description of the resource meta-model is presented below. Further details of the overall architecture can be found in the literature. For example, detailed descriptions of the four meta-models can be found in [Costa00a].

2.2 The Resource Model The most important elements of the resource model are abstract resources, resource factories and resource managers [ReTINA99, Blair99b, Duran00a, Duran00b]. Abstract resources explicitly represent system resources. In addition, there may be various levels of abstractions in which higher level resources are constructed on top of lower level resources. Resource managers are responsible for managing resources, that is, such managers either map or multiplex higher level resources on top of lower level resources. Furthermore, resource schedulers are a specialisation of managers and are in charge of managing processing resources such as threads or virtual processors (or kernel threads). Lastly, the main duty of resource factories is to create abstract resources. For this purpose, higher level factories make use of lower level factories to construct higher level resources. The resource model then consists of three complementary hierarchies corresponding to the main elements of the resource model. Importantly, virtual task machines (VTMs) are top-level resource abstractions and they may encompass several kinds of resources (e.g. CPU, memory and network resources) allocated to a particular task. Further details regarding the resource model can be found in [Blair99b, Duran00a, Duran00b].

2.3 The Task Model The main feature of the task model is that it offers a high-level of resource management by modelling coarse-grained interactions. That is, a task may spawn the boundaries of a component and even those of an address space. We define tasks from two points of view. From the application point of view a task is an activity performed by the system, e.g. transmitting audio over the network or compressing a video image. In contrast, from the programmatic point of view a task is a component operation invocation sequence which has a pool of resources assigned for its execution, i.e. a VTM. A VTM encompasses all the resources that a task uses for executing. There is a one-to-one mapping between tasks and VTMs. The latter may be seen as virtual machines in charge of executing their associated tasks. A distributed task then spawns the boundaries of an address space and is associated with a distributed VTM. Tasks may transverse both components and address spaces boundaries. Therefore, a higher-level of resource management is achieved by both managing coarse-grained tasks and modelling high-level units of resource management. Thus, we take a task-oriented approach for managing resources in which a component hierarchy is associated with a task hierarchy. The top-level task of such a hierarchy is directly associated with the top-level component of the component hierarchy. Lower-levels of a task hierarchy, i.e. sub-tasks, are related to lower-levels in the component hierarchy. As a consequence, a finergrained modelling of the resource management of component configurations can also be achieved. Tasks are not necessarily disjoint and may be interconnected. For instance, a component running one task may invoke another component concerned with a different task. Such an operation invocation is referred to as a task switching point which represents the transition from one task to another.

3. Xelha: a Resource-Aware ADL 3.1 Overview Xelha (pronounced “shelha” with a strong ‘h’ sound) is an ADL for the specification of real-time distributed applications. The language basically encompasses definitions of architectural structures together with their associated QoS management properties. The formers are expressed in terms of components, connectors and interfaces. In contrast, the latter are enunciated within task definitions which include task graphs, QoS specifications and QoS management structures. The language makes use of object-oriented typing in order to increase reusability of architecture definitions, bringing in some mechanisms for type checking and introducing dynamic changes to architectural structures. Thus, component and connector definitions are considered to be type definitions similar to that of a class. Component types may also be generic and, as a consequence, parameterised. The purpose of this is to introduce the ability of defining an architecture of a composite component in which each valid internal component type may be part of a sub-type hierarchy. Such an approach allows us to reuse component configuration definitions. Def component Name( parameters ) extends ComponentType: components: ... connectors: ... interfaces: ... composition graph: ... tasks: ...

Fig. 1. Component Specification

3.2 Components, Connectors and Interfaces Within the language components represent elements possibly residing in different capsules whereas explicit bindings are modelled as connectors. Thus, components residing in different capsules communicate with each other through connectors. Both components and connectors may include other composite and non-composite elements. Hence, a distributed system is represented as a hierarchical composition in terms of both composite components and composite connectors. Such a hierarchical composition is similar to that offered by Darwin [Magee95] for the construction of composite components. The basic structure of a component is shown in figure 1. Primitive components only define the interfaces and tasks sections whereas composite components are concerned with all of them. Connector specifications are similar to component definitions as shown in figure 2. However, connector specifications additionally associate a connector style with the connector definition. There are three connector styles. Operational connections are adequate for (remote) operation invocation whereas signal connections are suitable for one-way notification. Lastly, stream connections provide support for stream communication. Furthermore, connector specifications separate those interfaces that are part of the interaction protocol from the interfaces that provide some control over the connector. The purpose of this is to perform some type-checking to ensure that the style of the interfaces involved in the interaction protocol conform with the style of the connector (see below). Def connector AudioConnector_V1(string srcCapsule, string sinkCapsule) extends AudioConnector: components: srcStub: SrcStub, srcCapsule sinkStub: SinkStub, sinkCapsule connectors: streamConn: StreamConnector(srcCapsule, sinkCapsule) interfaces: interaction: IN: SrcStubIN, ( srcStub, IN ) OUT: SinkStubOUT, ( sinkStub, OUT ) control: CTRL: StreamConnCTRL, (streamConn, CTRL) composition graph: interfaces: OUT: ( srcStub, OUT ) streamConnIN: ( streamConn, IN ) streamConnOUT: ( streamConn, OUT ) IN: ( sinkStub, IN ) edges: ( OUT, streamConnIN ) ( streamConnOUT, IN ) tasks: . . .

Fig. 2. Connector Specification The granularity of a component type may range from a primitive component type to a complex middleware configuration type. In case of a composite element, as depicted in figure 2, the components and connectors section permits us to specify its constituent components by defining both the component type and the capsule where the component is to be created. In case of distributed connectors, the participating capsules are passed as parameters to the connector type. The external interfaces of the component are then defined in the interfaces section. As an example of this consider the interface name IN which is a reference to the interface of the same name belonging to the component srcStub. In addition, the defined interface type

is SrcStubIN. The composition graph section defines how these components are interconnected. For this purpose, in the interface section the involved component interfaces are associated with unique names. Following this, interface attachments are defined in the edges section. Finally, the definition of tasks allow us to specify QoS management as explained below. Interfaces types are specified outside the definition of a component as shown in figure 3. Interfaces are associated with interaction styles which conform with the connection styles delineated above. Furthermore, interfaces are defined in terms of both the operations they provide and the operations they require. We also introduce the optional construct inst within the definition of an operation to denote that the invocation of such an operation will result in the dynamic instantiation of the component type (or any of its sub-types). This approach allows us to define dynamic architectures, i.e. architectures that may experience changes at run-time. For instance, consider an audio connection server implementing the interface depicted in figure 3. Whenever a new connection is requested, a new component of the type or sub-type of AudioConnection is instantiated. An Interface may also be extended by sub-typing an interface type. In addition, the language allows us to extend component types. Hence, when sub-typing a component type, the whole structure of it is inherited (e.g. internal components, interfaces, component graph, etc). As an optional feature, the language allows components residing in the same address space to interact directly without the use of a connector. Thus, when component interactions are rather simple, such interactions may be modelled implicitly. Def Interface AuConnServIN extends AuConnServInterf: provides: boolean new_connection(in string srcInterf, in string sinkInterf, in QoSspec qos): inst AudioConnection requires: . . .

Fig. 3. Interface Specification

3.3 QoS Management 3.3.1 Overview QoS management is concerned with both the QoS properties provided by a service and the actions taken in order to attain the contracted level of QoS. The former corresponds to static QoS management aspects, which include the initial component configuration and the amount of resources required to provide the stated level of QoS [Blair99c]. The latter, in contrast, relates to dynamic QoS management aspects which involves run-time monitoring and dynamic reconfiguration of both the component configuration and the configuration of resources [Blair99c]. It is worth mentioning that we are dealing with both application level services and middleware level services. Within Xelha static QoS management aspects are specified in terms of task graphs together with their associated QoS specifications. There is a one-to-one relationship between a task graph and a statement of QoS properties. In addition, dynamic QoS management aspects are tackled through the use of a QoS management structure consisting of management components [Blair99c], which are in charge of both monitoring QoS violations and selecting an adequate adaptation strategy. Task graphs, QoS specifications and QoS management structures are introduced in turn below.

3.3.2 Static QoS Management Task graphs are defined in terms of task switching points as shown in figure 4. Such points denote the operation that triggers the task switch and is expressed in conjunction with the interface and the component it belongs to. This approach is enough to specify where tasks start and where they finish. “If” statements are optionally defined to determine whether a task switch should be performed according to the current task. Composite tasks are specified by defining the inclusion of other tasks as their sub-tasks. In addition, sub-tasks inherit the importance metric from their super-tasks. Such a metric is used to define the criticality of a task. Hence, tasks with a high importance value have precedence over lower important tasks in case of resource contention. Def task transmitAu.marshall: swithing points: srcStub:CTRL:start [if taskx] qos specifications: delay(srcStub:IN:read, streamConn:IN:put) = 5 throughput(srcStub:OUT:put) = 64 Def task transmitAu includes transmitAu.marshall, tansmitAu.unmarshall: importance: 5 qos specifications: delay(streamConn:IN:put, streamConn:OUT:put) = 10 packet_loss(streamConn:IN:put, streamConn:OUT:put) = 5 delay(srcStub:IN:read, sinkStub:OUT:write) = 20 jitter(srcStub:IN:read, sinkStub:OUT:write) = 1 qos management structure: ...

Fig. 4. Task Specification

QoS specifications then allow us to define the QoS properties associated with a task graph. These properties are expressed in terms of three main QoS categories for distributed multimedia [Blair97]. Firstly, timeliness properties are concerned with the end-to-end delay of multimedia interactions and delay variations, namely, jitter; both of them are measured in milliseconds. Secondly, volume properties deal with the throughput of data and are measured either in frames delivered per second or in bytes per second. Thirdly, reliability properties refer to the permitted percentage of loss of media frames and bit error rates. As depicted in figure 4, QoS specifications are defined in terms of the task end points for each QoS property. Thus, a task end point is defined as a triplet including a component, an interface and an operation. Finally, reservation of resources is defined within the specification of the top-level composite component as shown in figure 5. Such a component represents the higher-level structure of the system. Def component AudioSystem: components: ... connectors: ... composition graph: ... tasks: transmitAu.marshall, 20, “capsule 1” transmitAu.unmarshall, 3, “capsule 2”

Fig. 5. Top-level Component Specification Resources are reserved according to the specifications defined in the tasks section in terms of task name, the maximum number of instances for the task and the capsule where the task will run. For this purpose, the specifications are processed by an interpreter, which translates the QoS specifications of the task into specific resources (e.g. amount of memory and percentage of CPU) taking also into account the maximum desired number of task instances. qos management structure: collector: COLLECT: (sinkStub, COLLECT) timed automaton: automaton: Tautomaton_3 strategy activator: activator: Activator_V1 qos management graph: interfaces: automatonIN: ( automaton, IN ) automatonOUT: ( automaton, OUT ) activatorIN: ( activator, IN ) activatorOUT ( activator, OUT ) streamConnCTRL: ( streamConn, CTRL) edges: ( COLLECT, automatonIN ) ( automatonOUT, activatorIN ) ( activatorOUT, streamConnCTRL )

Fig. 6. QoS Management Structure Specification 3.3.3

Dynamic QoS Management

The role of management components basically involves two aspects, namely, monitoring and control [Blair99c]. The former includes event collectors, which interface with the underlying implementation, and monitors which detect QoS violations. Control aspects include then strategy selectors and strategy activators. It is the responsibility of strategy selectors of deciding which strategy to apply upon the occurrence of a QoS violation. Strategy activators are then in charge of realising the adaptation strategy by providing the detailed implementation of this strategy. Monitors and strategy selectors are usually specified by timed automata [Rajeev94], although collectors and strategy activators are not, especially, for example, when adaptation strategies requires significant modification of the component configuration. Timed automata (TA) are finite state-transition graphs which also include timing (and data) constrains. The main feature of TA is that they can be simulated and formally verified for correctness and reachability. In addition, several graphs can be modelled and simulated separately, and afterwards combined to a single graph [BlairL99]. Xelha defines QoS management structures as shown in figure 6. A task may or may not have associated a QoS management structure. That is, when a task hierarchy is defined, a QoS management structure associated with the top-level task might be enough to determine the adaptation process for the whole hierarchy. However, finer-level of QoS management may be introduced by defining such adaptation structures for finer-level tasks. Event collectors are defined by the interface of the component we want to observe. Monitors and strategy selectors are TA that are modelled separately and joined together afterwards in a single automaton whose behaviour is implemented by a pre-built component which can be automatically generated by the use of some tools (see the implementation section). In addition, the strategy activator is concerned with another pre-built component and, finally, the

component configuration of the QoS management structure is defined in the qos management graph section.

capsuleMgr2

operationalConnector IN capsuleProxy

capsuleMgr1

connectionServer

userInterface

AudioConnection AudioConnector_V1

source

The type of this interface is AuConnServIN

sink

Capsule 1

Capsule 2 dynamically created

Fig. 7. Audio System Architecture

4. An Example As an example consider a system architecture which includes a connection server in charge of dynamically establishing audio connections as shown in figure 7. Such a server is located in capsule 2 and is attached to a user interface component whereby a user may ask for an audio connection between the source and the sink components. The connection server is also connected to a capsule manager which is in charge of creating components within capsule 2. In addition, the connection server has access to the capsule manager residing in capsule 1 through a capsule proxy. The proxy and the capsule manager are then bound with an operational connection. Def component AudioSystem: components: connectionServer: ConnectionServer, “capsule 2” source: AudioSrc, “capsule 1” sink: AudioSink, “capsule 2” capsuleProxy: CapsuleProxy, “capsule 2” capsuleMgr2: CapsuleManager, “capsule 2” capsuleMgr1: capsuleManager, “capsule 1” userInterface: UserInterface, “capsule 2” connectors: operationalConnector: OperationalConnector_V1(“capsule 1”, “capsule 2”) composition graph: interfaces: uiOUT: (userInterface, OUT) connectorServIN: ( connectorServer, IN ) connectorServCAP: ( connectorServ, CAP ) capsuleMgr2IN: ( capsuleMgr2, IN ) connectorServOUT: ( connectorServer, OUT ) capsuleProxyIN: ( capsuleProxy, IN ) capsuleProxyOUT: ( capsuleProxy, OUT ) operationalConnectorIN: ( operationalConnector, IN ) operationalConnectorOUT: ( operationalConnector, OUT ) capsuleMgr1IN: ( capsuleMgr1, IN ) edges: ( uiOUT, connectorServIN ) ( connectorServCAP, capsuleMgr2IN ) ( connectorServOUT, capsuleProxyIN ) ( capsuleProxyOUT, operationalConnectorIN ) ( operationalConnectorOUT, capsuleMgr1IN ) tasks: transmitAu.marshall, 20, “capsule 1” transmitAu.unmarshall, 3, “capsule 2”

Fig. 8. Audio System Architecture Specification This system architecture is specified in Xelha as shown in figure 8. Resources reservation is defined in the tasks section whereby enough resources are reserved for establishing twenty connections for sending audio in capsule 1 whereas capsule 2 is provided with support for three connections for receiving audio. The definition of the interface IN of the component connectionServer is defined in figure 3. Therefore, the run-time invocation of the operation new_connection instantiates the structure of the AudioConnection component type, depicted in figure 9, according to the end points and the desired level of QoS. This

specification states that the type of the connector attaching the end points is AudioConnector, and as a consequence any sub-type of it is also a valid type for the connector. The connector type that best matches the required level of QoS is AudioConnector_V1, depicted in figure 2, which is a sub-type of AudioConnector. The AudioConnector_V1 component type encompasses two stubs components bound by a connector, as shown in figure 10, and is associated with task transmitAu. We use the use case maps notation [Buhr96] to denote task paths. Furthermore, such a task includes the sub-tasks transmitAu.marshall and transmitAu.unmarshall. These sub-tasks have associated with them real-time annotations. For instance, the completion time for each of the two local tasks is 5 milliseconds. In addition, the maximum network delay is 10 milliseconds. As a consequence, the end-to-end delay of task transmitAu is 20 milliseconds. Def component AudioConnection(AudioConnector connectorType, string srcCapsule, string sinkCapule, SrcOUT srcInterf, SinkIN sinkInterf): connectors: auConnector: connectorType(srcCapsule,sinkCapsule) composition graph: interfaces: auConnectorIN: ( auConnector, IN ) auConnectorOUT: ( auConnector, OUT ) edges: ( srcInterf, auConnectorIN ) ( auConnectorOUT, sinkInterf )

Fig. 9. Specification of the AudioConnection Component Type The Xelha task specification is shown in figure 4. Note that both the network delay and the packet loss are defined within the specification of the task transmitAu. The reason of this is that these QoS annotations involve both sub-tasks, i.e. sending and receiving packets from the network. Finally, the QoS management structure for the task transmitAu, whose specification is shown in figure 6, involves an automaton component and an activator component. The former is in charge of monitoring delays and packet losses. On the occurrence of a QoS violation, it is responsible for deciding which strategy to apply. Such a strategy is then realised by the activator component. Examples of adaptation strategies are resource reconfiguration, changing the sample rate, introducing filters, etc. Task path Task starting point

AudioConnector_V1 Task end point network delay = 10 ms transmitAu

sinkStub Ta2 = 20 ms

Ta1 = 0 Tb1 = 0 transmitAu.marshall

srcStub

streamConn Tc1 = 0

Tb2 = 5 ms

activator

Tc2 = 5 ms COLLECT transmitAu.unmarshall

automaton

Fig. 10. Structure of the AudioConnector_V1 Component Type

5. Implementation We have implemented a tool in Python that interprets Xelha specifications and generates code in Python. Python is an ideal language for rapid prototyping. Similar to Java, Python modules are translated into byte-codes to speed up the interpretation process. Moreover, since Python can easily be extended with C programs, Python’s applications can dramatically improve their performance by programming the most critical modules in C. The interpretation process of the tool has basically two phases as shown in figure 11. Firstly, it parses Xelha specifications and generates both object classes in Python and lower-level descriptions of the configuration of resources in a resource configuration description language (RCDL) [Duran00c]. For the generation of Python classes, both components and connectors are mapped to object classes. An example of the latter is shown in figure 12. In addition, the RCDL defines mappings of such object classes to tasks in terms of object templates whereas description of the resources allocated to tasks are defined by task templates. Such description of resources is accomplished by both translating QoS specifications into low-level resource parameters and using well-known real-time scheduling algorithms like rate-monotonic analysis. There is a profile (for each node) of

the worse-case execution times which are estimated by a series of pre-runs and used for the scheduling analysis. Currently, we are dealing with memory and CPU resources. Server implementation code

Xelha specifications Component Config. defs.

Functional requirements

ADL Tool Phase 1

Allocation of Pools of resources

Task templates

ADL Tool Phase 2

Object templates

Dynamic QoS Mgnt. defs.

Captures task model

Object classes RCDL specifications

Static QoS Mgnt. defs.

Task defs. Non-functional requirements

Captures resource model

Predefined object classes

Resource translation conforms with charact. platform of deployment

Service templates

Python Interpreter

Method call interception “hooks” Component configuration instantiation

Associate task model with resource model

Fig. 11. Processing Xelha Specifications Within a service template, component services offering QoS are represented as service type definitions in terms of the supported QoS region, the associated task and the object class that implements the service. Type checking and automatic QoS specifications translation concern future work. Hence, task templates are currently being hand-coded. Our assumptions for the underlying operating system is that it provides some support for priority scheduling such as that available in most Unix and Windows NT platforms. For instance, real-time scheduling may be achieved in a Unix platform as described in [Nahrstedt98]. # File generated by the ADL Tool import import import import import

lbind opbind composite component streambind

class AudioConnector_V1(composite.Composite): def __init__(self,lcap,rcap): interfaces = {’IN:("srcStub","IN"),’OUT:("sinkStub","OUT")} componentGraphSpec = { ’comps’:{ ’sinkStub’:{’factory’:component.componentFactory, ’args’:([’IN’,’CTRL’,’OUT’],SinkStub_V1_0), ’capsule’: lcap}, ’srcStub’:{’factory’:component.componentFactory, ’args’:([’IN’,’CTRL’,’OUT’],SrcStub_V1_0), ’capsule’: rcap}, ’streamConn’:{’factory’:StreamConnector_V1_0,’args’:([rcap, lcap, ’IN’,lbind.IRef(None,["put"],[]), ’CTRL1’,lbind.IRef(None,["start_serving"],[]), ’OUT’,lbind.IRef(None,[],["put"])} }, ’ifaces’:{ "OUT":("srcStub","OUT"), "streamConnIN":("streamConn","IN"), "streamConnOUT":("streamConn","OUT"), "IN":("sinkStub","IN") }, ’edges’:[ ("OUT","streamConnIN"), ("streamConnOUT","IN") ] } composite.Composite.__init__(self,interfaces,componentGraphSpec)

Fig. 12. Generated Object Class for the AudioConnector_V1 Component Type The second phase then concerns the interpretation of RCDL descriptions which takes place just before the application starts running. As a result of such interpretation process the three hierarchies of the resource model, described in section 2.2, are instantiated. The instantiation of such hierarchies involve two important issues. Firstly, the pools of resources (i.e. VTMs) for the specified component services are allocated. Secondly, the mechanisms for the wiring of method call interception “hooks” are placed to redirect object invocation calls to the appropriate pool of resources when a service is accessed. These “hooks” are installed, on a per-object basis, at run-time when object classes are instantiated. After the interpretation process the component configuration is

instantiated on top of an implementation of openORB [Andersen00]. In addition, we have implemented an audio application similar to that presented in section 4 to test the tool. Briefly, objects within this ORB may have several interfaces which can be bound to other matching interfaces whereby the exported methods correspond to the imported methods of the adjacent interface. Remote bindings permit us to connect interfaces residing in different capsules. The same three styles of connections introduced above are supported. In addition, capsules represent an address space and allows objects to transparently invoke other objects residing in a different capsule. The name server allows the user to register both interfaces and capsules and, as a consequence, to access them remotely. Finally, the node manager allows several capsules to coexist within the same node. In order to obtain language independence and conformance with other standard ORBs such as CORBA, Xelha interface definitions could be translated into CORBA IDL descriptions. In particular, the CORBA IDL extensions defined in [Blair97] could be used to support the expression of stream and signal interfaces. The TA tool suite described in [BlairL99] is used to model the timed automaton for the elaboration of the QoS management structures. This tool converts automaton graphs into FC2 files and also supports the composition of TA. Therefore, the monitor and the strategy selector are defined separately and later on joined together in a single automaton. Afterwards, the automaton is translated into an FC2 file and an FC2 processor tool [Andersen00] translates this file into Python object classes.

6. Related Work There has been some interest in the development of ADLs for distributed systems such as Darwin [Magee95] and C2 [Medvidovic96]. In addition, the Aster Project has developed an ADL for the systematic synthesis of middleware configuration [Zarras98]. However, none of them covers descriptions for resource management. There is, though, some related work in the area of real-time systems. MetaH [Binns96] is an ADL for the guidance, navigation and control domain, but it is only suitable for multi-processor system architectures. UniCon [Shaw95] is an ADL that offers support for schedulability analysis. Our task model, however, provides a higher-level of resource management. In addition, the previous work does not deal with dynamic QoS management. ObjectTime [Lyons98] is a tool that implements UML for real-time constructs [Selic98]. Specifically, the modelling structure of this tool comprises three elements, namely, capsules, ports and connectors. The former are actors (i.e. active objects) that communicate with each other through ports. Such ports are objects that implement a particular interface. Finally, connectors represent signal-based communication channels. However, no means is provided to model resources. Recently, a generic framework for modelling resources with UML [Selic00] has been developed and a proposal [OMG00] has been submitted for the OMG adoption. Both, physical and logical resources at various levels of abstractions may be represented within this model. QoS management is modelled in terms of QoS contracts, resource managers and resource brokers. There have been some work regarding specification of dynamic architectures. For instance, Darwin [Magee96] provides two main mechanisms for describing dynamic structures, namely, lazy instantiation and direct dynamic instantiation. In the former, a component is not instantiated until the service it provides is accessed. The latter creates a replica of a component every time the service it provides is accessed. Our approach is similar but more flexible than that taken by Darwin. That is, in our work, on accessing the service provided by a component a sub-type of any specified component type is instantiated without constraining this to the instantiation of the accessed component. Wright [Allen97] also offers support for dynamic change using events, e.g. when an event occurs it triggers some actions like unbinding and rebinding components. All these approaches require that architectural changes be expressed at design time. In contrast, the ArchStudio tool [Oreizy98], which is based on the C2-style, supports unplanned run-time modifications. More specifically, this tool supports operations for the addition and removal of components. The tool also provides an architectural constrain mechanism that validates changes to leave the application in a consistent state. However, when analysing the modifications an architecture might experience, it is easier to do so from languages that explicitly express changes. In terms of type checking for software architectures, Medvidovic presents an extensive analysis of the matter [Medvidovic96, Medvidovic98, Medvidovic99]. This approach claims that object-oriented type checking is not enough to fulfil all the needs of software architectures since object-oriented languages usually deal with a single type checking mechanism and are not able to deal with certain kind of mechanisms such as that of implementation conformance. However, the ADL introduced by this work only denote component sub-typing relationships. As a consequence, the developer must make sure that the adequate changes are made to implement the new types. Other efforts in this area include that performed by the OMG which has recently adopted a real-time specification for CORBA [OMG99a]. Similar to our work, real-time CORBA introduces an activity as a design concept rather than as part of the implementation. However, our work additionally provides explicit entities (i.e. VTMs) for the support of the execution of such activities. In addition, real-time CORBA tangles the application code with the scheduling of activities whereas in our work such scheduling remains hidden from the base-level

application code. Finally, the approach followed by the XMI and the MOF [OMG99b] focus on the interchange and management of the meta-information of a system respectively. Complementary to the work presented here, the latter standard has been used in [Costa00b] to define a type system for a repository of middleware configurations.

7. Concluding Remarks We have presented Xelha as an ADL for the specification of real-time distributed applications. A task model was introduced as part of the language whose main function is to provide a higher-level of resource management by encapsulating all the computational resources involved in a task. In addition, this model enforces a clear separation of concerns by defining QoS statements on a per task-basis. Both static and dynamic QoS management properties can be defined within the language. The formers are defined in terms of task graphs and QoS specifications whereas the latter are defined by management components. Importantly, monitors and strategy selectors, which are modelled as TA, can be simulated and formally verified by associated tools. It is not the purpose of this research to provide support for QoS analysis. However, future work concerns the integration of the work defined in [BlairL00], which offers such support, with our approach. The work has mainly been focused on distributed multimedia system. However, the language is not constrained to this field and can be extended to cover other areas. For instance, the QoS specification statement may be accommodated to a particular application domain. Xelha also covers the specification of dynamic architectures. That is, it allows us to define a range of type values, included in a type hierarchy, that may be dynamically instantiated as a result of accessing a service provided by a component. Although the paper is mainly focused on middleware, our approach is equally applicable to the application level. A tool has also been implemented for the interpretation of Xelha specifications, which generates Python object classes and resource descriptions in RCDL. We are using an audio application and an RM-ODP compliant ORB to test the tool, although, a more realistic case study is currently being developed. Future work is concerned with the implementation of type checking mechanisms as well as support for the translation of QoS specification into specific system resources. Although type checking helps to ensure that an architecture maintains consistency after experiencing changes, it is not enough. Further mechanisms have to be developed to ensure valid states when modifications are performed. Finally, we are addressing the issue of broadening the number of computational resources managed by the resource framework.

Acknowledgements Hector A. Duran-Limon would like to thank his sponsor, the Autonomous National University of Mexico (UNAM). Particular thanks are due to Jean-Bernard Stefani and his group at CNET who have provided partial funding for this work. We also thank Nikos Parlavantzas and Rui Moreira for helpful comments on early drafts of the paper.

References [Allen97] R. Allen, R. Douence, and D. Garlan, “Specifying Dynamism in Software Architectures”, Proc. Workshop Foundations of Component-Based Systems, pp. 11-22, Sept, 1997. [Andersen00] Andersen A., Gordon S. Blair, Frank Eliassen. “A Reflective Component-Based Middleware with Quality of Service Management”. Accepted for publication in Conference on Protocols for Multimedia Systems (PROMS2000), Cracow, Poland, October, 2000. [Binns96] P. Binns, M. Engelhart, M. Jackson and S. Vestal “Domain-Specific Software Architectures for Guidance, Navigation, and Control”, Int’l J. Software Eng. And Knowledge Eng., Vol. 6, no. 2, 1996. [Blair97] Blair, G. S., Stefani, J.B., “Open Distributed Processing and Multimedia”, Addison-Wesley, 1997. [Blair99a] Blair, G.S., Andersen, A., Blair, L., Coulson, G., “The Role of Reflection in Supporting Dynamic QoS Management Functions”, Internal Report MPG-99-03, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., 199 January 1999. [Blair99b] Blair, G.S., Costa, F., Coulson, G., Delpiano, F., Duran-Limon, H., Dumant, B., Horn, F., Parlavantzas, N., and Stefani, J-B. “The Design of a Resource-Aware Reflective Middleware Architecture”, In Second International Conference on Reflection and Meta-level architectures (Reflection’99), St. Malo, France, July 1999. [Blair99c] Blair, G.S., Andersen, A., Blair, L., Coulson, G., “The Role of Reflection in Supporting Dynamic QoS Management Functions”, Internal Report MPG-99-03, Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR, U.K., January 1999. [BlairL99] Blair Lynne, T. Jones, G.S. Blair, “A Tool Suite for Multi-paradigm Specification”, Proc. FASE’99, Amsterdam, The Netherlands, Springer, March 1999. [BlairL00] Blair Lynne, Blair G.S., Specifying and Analysing Multimedia Systems, to appear, In Formal Methods for Distributed Processing, Bowman H. & Derrick J. (eds), Cambridge University Press, 2000. [Buhr96] R. Buhr, R. Casselman: Use Case Maps for Object-Oriented Systems. Prentice Hall, UpperSaddle River, 1996. [Costa00a] Fabio M. Costa, Hector Duran-Limon, Nikos Parlavantzas, Katia B. Saikoski, Gordon Blair, and Geoff Coulson. The Role of Reflective Middleware in Supporting the Engineering of Dynamic Applications. Reflection and Software Engineering, Walter Cazzola, Robert J. Stroud and Francesco Tisato, June, 2000. p. 79-99.

[Costa00b] Costa, F., Blair, G.S., “The Role of Meta-Information Management in Reflective Middleware”, Proceedings of the ECOOP’98 Workshop on Reflective Object-Oriented Programming and Systems, ECOOP’00 Workshop Reader, Springer-Verlag, 2000. [Duran00a] Duran-Limon H. and Blair G. A Resource Management Framework for Adaptive Middleware. In 3th IEEE International Symposium on Object-oriented Real-time Distributed Computing (ISORC’2k), Newport Beach, California, USA, March 2000. [Duran00b] H. Duran-Limon and Gordon Blair. Configuring and Reconfiguring Resources in Middleware. In the 1st International Symposium on Advanced Distributed Systems (ISADS’2000), Gdl, Jalisco, Mexico, March, 2000. [Duran00c] H. Duran-Limon and Gordon Blair. The Importance of Resource Management in Engineering Distributed Objects. Accepted for publication in 2th international workshop on Engineering Distributed Objects (EDO2000), California, USA, November, 2000. [ISO95] ISO/ITU-T. Reference Model for Open Dist. Processing. International Standard ISO/IEC 10746, 1995. [Lyons98] Lyons A., “Developing and debugging Real-Time Software with ObjecTime Developer. Available at http://www.objectime.com [Maes87] Maes, P., “Concepts and Experiments in Computational Reflection”, In Proceedings of OOPSLA’87, Vol 22 of ACM SIGPLAN Notices, pp 147-155, ACM Press, 1987. [Magee95] J. Magee, N, Dulay, S. Eisenbach, and J. Kramer, “Specifying Distributed Software Architectures”, Proc. Fifth European Software Eng. Conf. (ESEC’95), Sept. 1995. [Magee96] J. Magee, and J. Krammer, “Dynamic Structure in Software Architectures”, Proc. ACM SIGSOGT’96: Fourth Symp. Foundations of Software Eng. (EFSE4), pp. 3-14, Oct. 1996. [Medvidovic96] N. Medvidovic, P. Oreizy, J.E. Robbins, and R.N. Taylor, “Using Object-Oriented Typing to Support Architectural Design in the C2 Style”, Proc. ACM SIGSOFT’96: Fourth Symp. Foundations Software of Eng. (FSE4) pp. 24-32, Oct. 1996. [Medvidovic98] N. Medvidovic, D.S. Rosenblum, and R.N. Taylor. “A Type Theory for Software Architectures”. Technical Report, UCI-ICS-98-14, Department of Information and Computer Science, University of California, Irvine, April 1998. [Medvidovic99] N. Medvidovic, D.S. Rosenblum, and R.N. Taylor, “A Language and Environment for Architecture-Based Software Development and Evolution”, Proc. 21th Int’l Conf. Software Eng. (ICSE’99), pp. 44-53, May 1999. [Nahrstedt98] Klara Nahrstedt. Hao hua Chu, and Srinivas Narayan. QoS-aware Resource Management for Distributed Multimedia Applications. Journal of High-Speed Networking, Special Issue on Multimedia Networking, 7:227-255, 1998. [Okamura92] Okamura, H., Ishikawa, Y., Tokoro, M., “AL-1/d: A Distributed Programming System with Multi-Model Reflection Framework”, Proceedings of the Workshop on New Models for Software Architecture, November 1992. [OMG99a] Real-Time CORBA 1.0 Specification, http://www.omg.org/, 1999, Object Management Group. [OMG99b] Meta Object Facility Specification. http://www.omg.org/, 1999, Object Management Group. [OMG00] Joint Initial Proposal for a UML Profile for Schedulability, Performance, and Time. http://www.omg.org/, 1999, Object Management Group. [Oreizy98] P. Oreizy, N. Medvidovic, and R.N. Taylor, “Architecture-Based Runtime Software Evolution”, Proc. 20th Int’l Conf. Software Eng. (ICSE’98), pp. 177-186, Apr. 1998. [ReTINA99] ReTINA, “Extended DPE Resource Control Framework Specifications”, ReTINA Deliverable AC048/D1.01xtn, ACTS Project AC048, January 1999. [Rajeev94] Rajeev A. Dill D., “A Theory of Timed Automata”, Theoretical Computer Science 126:183-235, 1994. [Selic98] Selic B., Rumbaugh J., “Using UML for Modeling Complex Real-Time Systems”, available at http://www.objectime.com [Selic00] Selic B., “A Generic Framework for Modeling Resources with UML”, IEEE Computer, Special Issue on ObjectOriented Real-time Distributed Computing, edited by Eltefaat Shokri and Philip Sheu, June 2000. [Shaw95] M. Shaw, R. DeLine, D.V. Klein, T.L. Ross, D. M. Young, and G. Zelesnik, “Abstractions for Software Architecture and Tools to Support Them”, IEEE Trans. Software Eng., vol. 21, no. 4, pp.314-335, Apr. 1995. [Zarras98] Zarras, A., V. Issarny, “A Framework for Systematic Synthesis of Transactional Middleware”, Proc. IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware’98), pp 257272, Springer, September 1998.