Towards Automatic Middleware Generation

0 downloads 0 Views 361KB Size Report
“naming/routing table” has to be defined for each node in order for it to fetch the .... transport layer between the nodes is SpaceWire [4]. This allows to “drag” only ...
11th IEEE Symposium on Object Oriented Real-Time Distributed Computing (ISORC)

Towards Automatic Middleware Generation Bechir Z ALILA, Laurent PAUTET, Jérôme H UGUES GET-Télécom Paris – LTCI-UMR 5141 CNRS 46, rue Barrault, F-75634 Paris CEDEX 13, France [email protected], [email protected], [email protected]

Abstract

tion models, concurrency patterns, protocols. This solution extends configurable [16] and generic [2] middleware architectures to ease middleware adaptability. This is an interesting solution, but it focuses more on the middleware implementation point-of-view than the end-user one. Therefore, one needs now to address middleware adaptation and configuration to user-level and not expert. Several works have been carried out. As an example, Zen-Kit [8] allows middleware customization (such as control over memory footprint) by controlling the actual components embedded by the application, while minimizing the difficulty of this custom configuration. However, this approach is focused on RT-CORBA: it does not allow the modification of the middleware architecture by adding new components that would diverge from the standard such as a lightweight invocation protocol. CosMIC [7] tool suite relies on the TAO/CIAO CORBA CCM middleware family to ease the construction of distributed, real-time and embedded (DRE) applications. Yet, these applications are QoS-based, and rely heavily on dynamic semantics for both its configuration and execution, and on CORBA. Still, it shows high-level modeling can help configuring a complete system. Both approaches rely on a highly configurable middleware, built on top of design patterns. While this approach is effective to configure the system, it does not take full advantage of the application architecture. Especially, a lot of useless code is embedded in the application for each configuration option, multiple levels of dispatching occur, etc. This greatly reduces the benefits of a generic middleware. If we target DRE systems, we also want to address HighIntegrity (HI) issues. Thus, we want to perform schedulability analysis and resources dimensioning. However, it is not always easy to do so with the approaches above. We claim that one can take full advantage of building onpurpose middleware from application requirements instead of configuring generic one. By analyzing an architectural description of the system, one can derive more precise middleware components. The immediate benefits would be a complete performance gain, reduced footprint.

Building middleware for distributed applications is a complex task, mixing antagonistic concerns: heterogeneity, performance, reliability, quality of services. Optimization and fine-tuning of middleware for a particular application is even a harder task, usually done manually or through complex design patterns. The advent of “schizophrenic” middleware which separates concerns between distribution model, communication protocols, and their implementation by refining the definition and role of “personalities” brought some elements to solve this problem by enabling full tailoring of the middleware by the developer. In this paper we extend this approach to full automation by generating middleware from an architectural model of the system expressed in a modeling language. This enables precise tuning and configuration of the middleware by generating exactly the required code, prior to runtime. We finally show how this approach fits the requirements of high-integrity or real-time distributed systems.

1

Introduction

Middleware define runtime entities and abstractions for the application developer and their implementations must fulfill application requirements for heterogeneity, performance, reliability or quality of service. Typical solutions are based on standards such as CORBA [11] or DDS [12]. These middleware target an application domain, but can also be adapted to other fields (RT-CORBA [10], CORBA/e [13], etc.). However, adapting or configuring a middleware is still the domain of experts. We need to bring this capability to the end user. We need to contemplate not only the middleware, but also its adaptation and use in a complete process. We showed [9] that separating remote interactions between the logical nodes and their semantics from their implementation is an efficient way to foster extreme genericity of the middleware, e.g. to support multiple distribu-

978-0-7695-3132-8/08 $25.00 © 2008 IEEE DOI 10.1109/ISORC.2008.27

221

In the remainder of this paper, we first present the AADL (Architecture Analysis and Design Language) [15] and the key elements of the schizophrenic architecture. We show how this architecture provides strong guidelines for building middleware components, generated from an AADL model. We then illustrate how the deployment and configuration are performed automatically using AADL and assess our approach.

2

The interface specification of a component is called its type. It provides features (e.g. communication ports). Components communicate one with another by connecting their features. To a given component type correspond zero or more implementations. Each of them describes the internals of the component: subcomponents, connections between these subcomponents, etc. An implementation of a thread or a subprogram can specify call sequences to other subprograms, thus describing the execution flows in the architecture. Since there can be different implementations of a given component type, it is possible to select the actual components to be put into the architecture, without having to change the other components, thus providing a convenient approach to application configuration. The AADL defines the notion of properties that can be attached to most elements (components, connections, features etc.). Properties are name/value pairs that specify constraints or characteristics that apply to the elements of the architecture: frequency of a processor, execution time of a thread, bandwidth of a bus, etc. Some standard properties are defined; but it is possible to define one’s own properties. A detailed introduction to the AADL can be found in [5]. Projects such as OSATE [18] define modeling environments to build AADL models, using the Eclipse platform. We have developed Ocarina, a standalone tool-suite [3] to process AADL models and allow developing, configuring and deploying DRE systems. Ocarina offers scheduling analysis capabilities [19], connection with verification tools, and more notably code generation to Ada 2005. AADL provides two major benefits for building DRE systems. First, compared to other modeling languages, AADL defines low-level abstractions including hardware descriptions. These abstractions are more likely to help design a detailed model close to the final product. Second, the hybrid system components help refine the architecture as they can be detailed later on during the design process. These, among other reasons, are why AADL is a good design vehicle for such systems.

AADL

The AADL [15] is a new architecture description language specifically designed for DRE systems. It is an international standard and is being specified by a community of academic and industrial partners. AADL is a component-centric language which allows the modeling of both software and hardware components. It focuses on the definition of clear block interfaces, and separates the implementations from these interfaces. A graphical as well as a textual representation of the syntax exist. Only non-functional aspects of components can be described with AADL, e.g.: timing properties, memory footprints, interface specifications and how components are interconnected. Functional aspects (algorithmic/behavioral specifications) are attached separately as source code by means of AADL properties (see below). An AADL description is made of components. The AADL standard defines software components (data, thread, thread group, subprogram, process) and execution platform components (memory, bus, processor, device) and hybrid components (system). Components describe well identified elements of the actual architecture. Subprograms model procedures as in C or Ada. Threads model the active part of an application (such as POSIX threads). AADL threads may have multiple operational modes. Each mode may describe a different behaviour and property values for the thread. Processes are memory spaces that contain the threads. Thread groups are used to create a hierarchy among threads. Processors model micro-processors and a minimal operating system (mainly a scheduler). Memories model hard disks, RAMs, buses model all kinds of networks, wires, devices model sensors, etc. Unlike other components, systems do not represent anything concrete; they actually create building blocks to help structure the description. Components may be hierarchical, i.e.: components can contain other components (called subcomponents in this case). In fact, an AADL description is almost always hierarchic, with the topmost component being an AADL system that contains—for example—processes and processors, with the processes containing threads and data, and so on.

3

The Schizophrenic Architecture

To build (automatically or not) a middleware that fulfills the application requirements exactly, one has first to define a highly configurable middleware architecture. In previous projects, we defined the “schizophrenic middleware architecture” [20]. It separates concerns between distribution model, API, communication protocols, and their implementation by refining the definition and role of personalities.

3.1

The Middleware Core Architecture

The schizophrenic architecture consists of 3 layers: application-level and protocol-level personalities built around

222

• typing manages the typing system in the application (sophisticated when it comes to CORBA any mechanism for instance), • transport handles the physical line, • activation ensures that a concrete entity is available to execute requests, • execution assigns resources to process the requests. In [20], we presented PolyORB, our implementation of a schizophrenic middleware. PolyORB is a free software middleware framework. We assessed its suitability to build middleware platforms to support multiple heterogeneous specifications (CORBA, Ada Distributed Systems Annex, Web Applications, Ada Messaging Service close to Sun’s JMS, OMG DDS) and as a COTS for industry projects.

a neutral core. Application interacts with application personalities; protocol personalities operate with the network. Application personalities constitute the adaptation layer between application components and middleware through a dedicated API or code generator. They provide APIs to interface application components with the core middleware; they interact with the core layer in order to allow the exchange of requests between entities. Application personalities can either support specifications such as CORBA, JMS, etc. or dedicated API for specific needs. Protocol personalities handle the mapping of personality-neutral requests (representing interactions between application entities) onto messages exchanged using a chosen communication network and protocol. Protocol personalities can instantiate middleware protocols such as IIOP (for CORBA), SOAP (for Web Services), etc. The neutral core acts as an adaptation layer between application and protocol personalities. It manages execution resources and provides the necessary abstractions to transparently pass requests between protocol and application personalities in a neutral way. It is completely independent from both application and protocol personalities. The neutral core layer enables the selection of any combination of application and/or protocol personalities. Several personalities can be collocated and cooperate in a given middleware instance, leading to its “schizophrenic” nature.

3.2

3.3

Automatic Generation of Services

We focus on the AADL as a modeling language for DRE systems as it allows one to express both the user requirements and the deployment information. Our general approach consists in defining an AADL personality that can be shrank to the language subset effectively used in the application models. But redefining a personality for each application would be a tedious task. Thus, the code production of the services above has to be automatic. We also want to address HI system requirements. The produced middleware has to match a small footprint and to ensure predictability properties. Moreover, we want the produced personality to be Ravenscar compliant [1] in order to perform schedulability analysis on the whole application (middleware included). However, configuring and deploying a general purpose middleware requires an intensive use of design patterns or object-oriented features (dynamic allocation and dynamic binding). This prevents from fulfilling HI requirements. Our approach consists in using AADL to describe the user requirements as well as the deployment information. We reuse the schizophrenic architecture and its canonical functions. We automatically generate most of them in order to implement an AADL distribution model restricted to those features required by the application. We take advantage of the deployment information to statically instantiate the policies needed. To do so, we had to revisit PolyORB implementation as its initial version was based on design patterns. The new schizophrenic middleware, PolyORBHI, is composed of a minimal middleware core and several automatically generated functions.

The Middleware Core Services

The middleware core provides neutral services that correspond to the identification of the key functions involved in request processing. In figure 1, we define the canonical operations performed by any middleware.

Figure 1. The µBroker and its services The µBroker is the core component that provides support for interaction between the canonical services: • addressing manages references of entities connected to the middleware, • binding handles a connection with the remote nodes, • representation takes care of marshaling and unmarshaling when necessary, • interaction manages the liaisons between connected entities in the application, • protocol supports the transmission between two nodes thanks to the network link,

4

Code Generation Strategies

In this section, we describe how we generate code from an AADL model. Unlike the several tools that manipulate AADL and that use model processing techniques to analyze

223

models and (possibly) generate code from them, we used a compilation-like approach to perform this task.

4.1

arborescent view of the modeled system that reflects its hierarchy. Each subclause (subcomponent, subprogram call, etc.) in the original model is instantiated into a “component instance”; the properties and the features of this component instance are deduced from: 1. its (the subclause) own properties or any other contained AADL properties that can be applied to it, or else 2. those of the corresponding component implementation, or else 3. those of the corresponding component type, or else 4. those of its parents if it extends any other component, or else 5. the default value of the property declared in the property set. If the same property is defined on more than one of the levels listed above, the component instance has the closest one to the subclause (e.g: a property declared for a component implementation overrides any same property declared in the component type or in an extended component). During the instantiation step, we may detect inconsistencies in the AADL modeled system (a process does not contain any thread, etc.).

Frontend

In a modern code generator, the frontend parses the AADL model source files and builds an abstract syntax tree (AST). Figure 2 gives an overview of the frontend: a lexer transforms the AADL source into a sequence of tokens, then a parser creates the AST from this sequence performing syntactic checks at the same time and an analyzer does the semantic checks of the model. We adapted this architecture to our code generation requirements by adding to the three steps above an instantiation step to the frontend of our code generator.

4.2

Backend

In a traditional code generator, the backend takes the AST (the AADL instance tree in our case) produced by the frontend, expands it to transform the complex constructions into simpler ones. The expanded tree is traversed to produce the code according to mapping rules. Figure 2. Code Generator Frontend

4.1.1

Lexing, parsing and analysis

The AADL lexer and parser verify that the model is valid according to the AADL grammar given in the standard [15]. Then, a semantic analyzer checks the semantics of the model defined also by the standard. Semantic analyses vary from simple semantic checks (type compatibility, connection orientation, etc.), to more complex analyses (computing constant values, range checks for numeric types, etc.). At the end of these steps we are sure our model is “legal” from the AADL language point of view. However, this model can still contain inconsistencies that would be detected at the instantiation step (section 4.1.2). 4.1.2

Figure 3. Code Generator Backend

4.2.1

Expansion

After the instantiation phase, we have an instance tree that describes the hierarchy of the AADL model. Before going to the code generation, some constructs in this tree need to be simplified and some other constructs need to be added to the tree: this is the expansion phase. After the expansion

Instantiation

As stated by the AADL standard, the model has to be instantiated into a model instance. A model instance is an

224

phase, we have an AADL instance tree that is simpler, richer than the original one and which leads to code generation more easily. For example, some thread dispatch protocols need the thread to be interpreted as if it has one additional in event port. In the expansion phase, this port is added to the thread instance. Also, the expansion phase may detect high level inconsistencies (unsupported data types, unsupported thread dispatch protocols, missing connections, etc.). These errors impede the generation of code; they are reported to the user in order to fix them. 4.2.2

application in question. This allows the implementation of the addressing, binding and execution sevices (defined in section 3), 2. From the data components declarations and the different subprogram signatures, we deduce the communication buffer sizes and allocate them statically. We also generate automatically the data marshalers (resp. unmarshalers) to (resp. from) these buffers. This allows the implementation of the representation and typing services, 3. From the number of threads in the application and their characteristics (periodicity, priority, etc.), we create statically the entire task set of the application1 . This allows the implementation of a part of the activation and interaction sercvices.

Intermediary trees

Two main objectives have to be achieved with the code generator: (1) it must be flexible and easily maintainable and extendable, (2) and the implementation of optimizations within it must be simple. The generator architecture must take in account the differences between a classical programming language and AADL and the fact that a single AADL specification leads to the generation of many source files. To resolve these issues, we introduced a new phase in the compiler backend: the tree conversion phase which consists of transforming the AADL instance tree into a pseudo-AST tree for the appropriate programming language before the code generation. After the build of this tree is complete, it is traversed by a code printer to produce source code. Figure 3 shows the location of the tree conversion step (TC1 ..TCn ) in one of the backends of the generator: For each supported programming language (Ada or C), a set of tree converter is added. They convert the expanded AADL instance tree into a set of programming language trees (one for each source files). The advantage of the tree conversion is that we gain more flexibility: we can add nodes to the created tree in an order that is different from the order of their transformation into source code. We can even override or remove nodes from these trees.

4.3

4.4

Minimal Middleware

The remaining components of the middleware (those who are not automatically generated) constitute the minimal middleware layer. In the following, we give these components and precise which services (see section 3) they correspond to: 1. The task archetypes which are instantiated once per AADL thread. Concretely, these archetypes are Ada generic packages for the Ada middleware and C functions that create threads at initialize time for the C middleware. This completes the implementation of the activation service, 2. Communication protocols; we support a simple adhoc communication protocol as well as a simplified version of CORBA-GIOP [11]. This corresponds to the protocol service, 3. Low level transport layers. We support Ethernet and SpaceWire [4]. This corresponds to the transport service, 4. The archetype of the thread interface queries that allows the user to send or (resp. receive) events manually on (resp. from) thread ports. This completes the implementation of the interaction service.

Result and Benefits

5

Using the code generation strategy described earlier in this section, we have been able to create two code generators: one for Ada and another for C. Our code generators do not produce only applicative part of the code (mapping of data and subprogram components). They also generate an important part of the communication middleware. A large amount of information is extracted from the AADL model and leads to generating several components of the middleware: 1. From the number of nodes in the distributed application and the connections between them, we can deduce the exact number of communication channels that have to be open. The high level transport layer and its initialization are generated automatically and are optimized for the

Automatic Configuration and Deployment

In this section, we show how we can use the information in the AADL model to automatically: • Deploy the HI middleware by exclusively selecting the components that are needed by the application, • Configure the distributed application by parameterizing the components selected during the deployment phase. We explain also how the architecture of the middleware has been inspired from the schizophrenic architecture (section 3) and how the services of the middleware are statically 1 We

mean here the entire user-task set. The entire task set of the application is influenced also by the nature of the transport low level layer and other low level characteristics that may require additional threads to be added to the system. This is also handled statically by our tool.

225

provided. We adapted the definitions of deployment and configuration given by the OMG [14] to enhance the static characteristic in these notions.

5.1

components to be used by the application (deployment) and the exact properties of these components (configuration). The advantage of the dynamic approach is that it makes the application code (the one provided by the user or the one generated automatically) simpler from a middleware designer point of view. However, it has two major drawbacks that impede its use for HI systems: (1) object oriented programming and dynamic binding have several safety problems such as the difficulty to guarantee correct initialization of dispatch tables which are the most classical way to implement dynamic binding in compiled object oriented languages. Some analyses (dead-code detecting) and testing (code coverage) become very hard to perform on object oriented programs [6]. (2) Dynamic memory allocation is not deterministic which may cause a problem during worst case execution time (WCET) analysis for real-time systems. Static deployment and configuration are more suitable for HI distributed systems. They require an analysis phase that statically computes all the resources (memory, bandwidth) and parameters (buffer sizes) needed by the application. It is obvious that this phase is very tedious if performed by the programmer (it has to be redone after any modification of any application parameter). However, if the application is modeled using a well-chosen language such as AADL, this model can be analyzed automatically to compute all resources and a large part of the application code can be generated automatically and contains all the statically computed resources, and their configuration.

Deployment

The deployment of a distributed application is the selection of the middleware components needed to realize a given semantics. The deployment requires also to place some entities that send messages through the network from sender nodes (stubs) and other entities that receive these messages on receiver nodes (skeletons). This task is error prone and should not be done manually by the developer. In most cases, a successful deployment requires that the application nodes know “how” to reach the other nodes they communicate with. In HI systems, this information has to be known at compile time (or at initialization time) so that all the communication channels are created at the very beginning of the distributed application’s life. Therefore a “naming/routing table” has to be defined for each node in order for it to fetch the transport-dependant information of other nodes and be able to communicate with them.

5.2

Configuration

The configuration of a distributed application is the opportunity to parameterize individually each one of the middleware components selected during the deployment phase (section 5.1) and then to assemble them with the generated as well as the user-provided components. For example, binding the size of the incoming requests queue of a given node is a configuration aspect. In embedded systems, the hardware resources are very limited. Therefore, the configuration phase has to optimize the use of these resources by allocating only the necessary amounts of them.

5.3

5.4

Minimal Middleware Architecture

In section 3 we described the “services” provided by a schizophrenic middleware and how they host all undeterministic features of the middleware. In this paragraph, we show how the implementation of these services becomes static and deterministic in our middleware, PolyORB-HI: • addressing: the analysis of the AADL model leads to the generation, on each node N, of a static naming table that contains, for each node connected to N, the transport layer related information that is useful to reach this node. Fetching a node address is therefore done in a constant time, • binding: the topology of the AADL model allows the opening of all necessary communication channels at the very beginning of the application. The endless cyclic nature of the threads in the system (imposed by the Ravenscar profile) implies that there is no new communication channel that are open or closed dynamically at any moment of the application life, • representation: marshalers and unmarshalers are automatically generated for all data types found in the AADL model. The marshaling and unmarshaling of the data is done in a time proportional to the data size. This time can easily bounded by the maximum data size in the model,

Automatic Deployment and Configuration

Since the deployment and configuration of a distributed application are complex tasks, they are usually performed automatically. There are two approaches to deploy and configure automatically a distributed application: • Dynamically: the selected components (deployment) are instantiated dynamically using object factories and the interaction with these components generally uses object oriented programming patterns [17] and dynamic binding. The parameterization of the components (configuration) uses dynamic memory allocation. This approach has been described in details in section 3. • Statically: a deep analysis of the application is performed to determine, at compile time, the exact middleware

226

• interaction: the conformance with the Ravenscar profile implies that all communications are asynchronous. This reduces considerably the waiting time of a node when sending messages to another node. The interaction time is the time a message is passed through the different layers of communication, which is proportional to the message data size and is bounded by the maximum data size in the model, • protocol: similarly to the interaction service, the use of GIOP or the simple ad-hoc communication protocol—in the context of the asynchronous nature of the communications between nodes—makes the building time of a message proportional to the data size. Thus, it can be bounded by the maximum data size in the model, • typing: the analysis of the AADL model before the code generation allows the generation of code corresponding to (and only to) the data types present in the model, all the routines that manipulate these types are also generated automatically and are consequently optimized for the current application. Therefore, there is no need to support sophisticated mechanisms (such as CORBA any mechanism). This increases considerably the performance of the application and removes the type conversions steps that may be a source of undeterminism, • transport: the whole transport layer is configured through the model. A large part of this layer (sending and receiving routine) is generated automatically from the AADL specification of the application. This makes the passing of a message through the transport layer proportional to the data size and is bounded by the maximum data size in the model, • activation: this is ensured by construction since all the threads are activated at the application startup and they remain active during all the application lifetime, • execution: a delivery routine is generated automatically for each node in the distributed application. It is invoked by the communication layers in order to execute the proper code corresponding to the reception of a message. This guarantees a constant time of fetching the behavior.

5.5

Figure 4. Deployment View of the Case Study

crafts2 . From this example, our AADL tool suite Ocarina can deduce that the processors used is LEON and that the transport layer between the nodes is SpaceWire [4]. This allows to “drag” only the middleware low level transport layer that implements SpaceWire communications. This also makes possible the automatic selection of the appropriate compiler when compiling the generated code. To make the application building easier for the user, our tool suite ocarina generates automatically a set of makefiles and project files (for the Ada code) that ensure the proper packages of the middleware are included when compiling the application. We also designed a mechanism of scenario files written also in AADL to describe the code generator needed by the application and other aspects to parameterize our tool suite. All the user has to do is invoking a single command on the scenario file and all the steps described in the sections 4 and 5 (including the compilation of the source code) are performed automatically. Component Application Generated code Middleware Ada Run-Time + drivers

Results and Assessment

Using the approach described in 4, we have been able to perform automatic deployment and configuration of our distributed applications. The AADL properties can enrich the model with deployment and configuration aspects. Figure 4 is an AADL graphical representation of the deployment view of our case study: the model holds three nodes, each is a spacecraft. The first spacecraft is a leader that contains a periodic thread which sends its position to the two other spacecrafts which are followers. They receive the position sent by the leader with a sporadic thread, update their own position and store it in a local protected object in order for it to be used by another thread in these space-

SLOCs 89 961 1068 N/A

.o size (bytes) 8852 66804 32957 ≈ 541Kb

Table 1. Footprint for the partition 2 Several case studies have been carried out2 and show how the big amount of generated code and the customization of the middleware to the application needs reduce considerably the footprint of distributed applications. The total size of the executable (spacecrafts 2 and 3 of figure 4), combining real-time kernel, middleware and the application, is 2 Visit the Ocarina website http://aadl.enst.fr/ocarina and the PolyORB-HI website http://aadl.enst.fr/polyorb-hi for detailed information on the case studies.

227

576kB, using the GNAT for LEON 1.3 compiler. Table 1 gives more detailed measures for these nodes. This footprint fits the requirements from minimal embedded systems, and is clearly under the typical memory range for API-based middleware such as nORB or microORB, which are above 1MB for a complete system, including full OS support.

6

[4] E. ESTEC. ECSS-E-50-12A SpaceWire - Links, nodes, routers and networks. Technical report, European Space Agency, 2003. [5] P. H. Feiler, D. P. Gluch, and J. J. Hudak. The Architecture Analysis & Design Language (AADL): An Introduction. Technical report, 2006. CMU/SEI-2006-TN-011. [6] F. Gasperoni. Safety, security, and object-oriented programming. SIGBED Rev., 3(4):15–26, 2006. [7] A. Gokhale, B. Natarjan, D. C. Schmidt, A. Nechypurenko, N. Wang, J. Gray, S. Neema, T. Bapty, and J. Parsons. CoSMIC: An MDA Generative Tool for Distributed Real-time and Embdedded Component Middleware and Applications. In Proceedings of the OOPSLA 2002 Workshop on Generative Techniques in the Context of Model Driven Architecture, Seattle, WA, Nov. 2002. [8] S. Gorappa, J. A. Colmenares, H. Jafarpour, and R. Klefstad. Tool-based Configuration of Real-time CORBA Middleware for Embedded Systems. In International Symposium on Object-oriented Real-time distributed Computing (ISORC’05), Seattle, USA, May 2005. [9] F. Kordon and L. Pautet. Toward next-generation toward next-generation middleware? IEEE Distributed Systems Online, 5(1), 2005. [10] OMG. Real-Time CORBA Specification, dynamic scheduling, v2.0. OMG, Apr. 2003. OMG Technical Document formal/2003-11-01. [11] OMG. Common Object Request Broker Architecture: Core Specification, Version 3.0.3. OMG, Mar. 2004. OMG Technical Document formal/04-03-12. [12] OMG. Data Distribution Service: Architecture and Specification, revision 1.0. OMG, Mar. 2004. OMG Technical Document. [13] OMG. Common Object Request Broker Architecture - for embedded. OMG, May 2006. OMG Technical Document ptc/06-05-01. [14] OMG. Deployment and Configuration of Component-based Distributed Applications Specification, Version 4.0. OMG, Apr. 2006. OMG Technical Document formal/06-04-02. [15] SAE. Architecture Analysis & Design Language (AS5506), September 2004. available at http://www.sae.org. [16] D. Schmidt, D. Levine, and S. Mungee. The design and performance of real-time object request brokers, 1998. [17] D. Schmidt, M. Stal, H. Rohnert, and F. Buschmann. Pattern-Oriented Software Architecture – Volume 2 – Patterns for Concurrent and Networked Objects. Wiley & Sons, New York, NY, USA, 2000. [18] SEI. Open Source AADL Tool Environment. http://la. sei.cmu.edu/aadl/currentsite/tool/osate.html. [19] F. Singhoff, J. Legrand, L. N. Tchamnda, and L. Marcé. Cheddar : a Flexible Real Time Scheduling Framework. ACM Ada Letters journal, 24(4):1-8, ACM Press. Also published in the proceedings of the ACM SIGADA International Conference, Atlanta, 15-18 November, 2004, Nov. 2004. [20] T. Vergnaud, J. Hugues, L. Pautet, and F. Kordon. PolyORB: a Schizophrenic Middleware to Build Versatile Reliable Distributed Applications. In Proceedings of the 9th International Conference on Reliable Software Techologies Ada-Europe 2004 (RST’04), volume NCS 3063, pages 106– 119, Palma de Mallorca, Spain, June 2004. Springer Verlag.

Conclusions and Future Works

Typical development of DRE systems relies on a complete middleware framework. Such framework should be generic and flexible enough to meet applications requirements. We note such middleware exist, but usually drag a lot of implied complexity to implement such genericity, e.g.: design patterns, dynamic object-orientation. In this paper, we propose not a flexible middleware, but a generative approach to build precisely the middleware required by the application from its architectural description. We proposed to rely on the schizophrenic middleware architecture to describe the core of this middleware. The schizophrenic architecture provides a set of core mechanisms, common to most distribution models. This core defines invariants of the middleware (I/O management, definition of request). Using a description of the application, expressed using the AADL, we showed how code generation completes this core, adding all entities that are specific to application interactions: support for interfaces (types, marshalers), execution (threads) and message exchange (communication channels, protocol). We illustrate this approach is meaningful from a user point-of-view: most of the middleware can be generated out of a complete description. Such approach reduces the need for complex middleware framework, and allows for precise tuning and reduced footprint for embedded systems. Future work will consider extending the range of capabilities provided by the code generator, focusing on dynamic reconfiguration of the system. Acknowledgement: This work has been funded in part by the ANR Flex-eWare project.

References [1] B. Dobbing, A. Burns, and T. Vardanega. Guide for the use of the of the Ravenscar Profile in High Integrity Systems. Technical report, 2003. [2] B. Dumant, F. Horn, F. D. Tran, and J.-B. Stefani. Jonathan: an Open Distributed Processing environment in Java. In IFIP Int’l Conference on Distributed Systems Platforms and Open Distributed Processing, pages 175–190, Londres, 1998. Springer Verlag. [3] ENST. Ocarina: An AADL model processing suite. http://ocarina.enst.fr, 2006.

228