Position paper: Separation of concerns due to extensible container support Ansgar Radermacher, Sylvain Robert, Sébastien Gérard, François Terrier CEA-LIST CEA Saclay 91191 Gif sur Yvette Cedex, France {Ansgar.Radermacher, Sylvain.Robert, Sebastien.Gerard, Francois.Terrier}@cea.fr Vincent Seignole, Virginie Watine Thales Thales Communications 91300 Massy, France {vincent.seignole, virginie.watine}@fr.thalesgroup.com Keywords CCM, CORBA, ADL, connectors. 1. INTRODUCTION Framework-based components approaches (e.g. CCM, EJB) have until not achieved a breakthrough in the real-time and embedded community. Yet, the interest in component based paradigms is increasing, along with the need to make sys- tems less dedicated, more flexible, and follow standardized software platforms. The work described here has been done in the context of the European projects COMPARE and MERCED 1 which focus on the development of a flexible component technology for complex embedded real-time systems. A promising ap- proach is the container/component pattern employed by the CORBA Component Model (CCM) [2]. The component is embedded into the container through which all interactions with the external world are managed. Some non-functional concerns, such as transactions and persistency are already supported. However, the standardized CCM container is not flexible enough. Transactions are useful for enterprise applications, but we rarely need these in embedded systems which re- quire different services. An example is a configurable syn- chronization policy enforced by the container, but there is no possibility to add such a service in a consistent way. Since CCM supports only synchronous method invocations and a specific form of event delivery, another motivation for more adaptability is the wish to use additional interac- tion mechanisms, for instance an event delivery mechanism provided by the target RTOS. In order to do this, we could configure a CORBA ORB, e.g. by means of pluggable transport protocols. We consider this inadequate, since an ORB has a higher overhead compared to a native commu- nication layer. We don’t seek a fixed extension of the set of supported interactions: in the embedded and RT domain, we often need to add interaction mechanisms that exactly fit 1 http://www.ist-compare.org http://www.itea-merced.org domain and target – we require a general procedure how to add specific interaction mechanisms. We motivated the need for two kinds of adaptability in a container: the flexible management of services and interac- tion mechanisms. In the next two sections, we deal with these two aspects and present their realization in CCM. 2. Open container This section deals with an open container, i.e. a container tailored by means of plug-ins that support the handling of non functional aspects. We call these plug-ins container services. The following considerations are based on the lightweight variant of CCM [1]. The general approach is the separation of concerns principle: we keep real-time and quality-of-service (QoS) related code as far as possible out of the component code. Instead, we add the real-time aspects by means of declara- tions that are part of the container configuration. This en- hances the reusability: the remaining “business code” is free of specific aspects of a certain target configuration and is therefore reusable. 2.1 Container Services A major feature of the open container is its flexibility. In- stead of providing a predetermined set of container ser- vices, it is possible to register a new service with a con- tainer using a plug-in architecture. Figure 1: Container Services As shown in Figure 1, one or more container services can intercept the call through a receptacle on the client side. In Clock Display Timer Container services client Container Container Container services server