A Middleware-centric design methodology for networked embedded systems

ion levels Hardware Operating System Host insfrastructure Middleware Fig. 2.2. A level-based middleware classification. host infrastructure middleware include the following: the Adaptive Communication Environment (ACE) [22] is a portable and efficient toolkit that encapsulates native operating system network programming capabilities such as inter-process communication, static and dynamic configuration of application components, and synchronization. Real-Time Java Virtual Machines implement the Real-Time Specification for Java (RTSJ) [23]. The RTSJ is a set of extensions to Java that provide a largely platform-independent way of executing code by encapsulating the differences between real-time operating systems and CPU architectures.. Distribution middleware uses and extends host infrastructure middleware in order to automate common network programming tasks, such as connection and memory management, marshaling and demarshaling, endpoint and request demultiplexing, synchronization, and multithreading. Developers who use distribution middleware can program distributed applications much like stand-alone applications, that is, by invoking operations on target objects without concern for their location, language, OS, or hardware. At the heart of distribution middleware are Object Request Brokers (ORBs), such as Java RMI [24], and CORBA [25]. Common middleware services augment distribution middleware by defining higher-level domain-independent services, such as event notification, logging, persistence, security, and recoverable transactions. Whereas distribution middleware focuses largely on managing end-system resources in support of an object-oriented distributed programming model, common middleware services focus on allocating, scheduling, and coordinating various resources throughout a distributed system. Without common middleware services, these end-to-end capabilities would have to be implemented ad hoc by each networked application. Examples of common middleware services include the OMG’s CORBAServices [26] and the CORBA 2.3 Middleware classification 11 Component Model (CCM) [27], which provide domain-independent interfaces and distribution capabilities that can be used by many distributed applications. The OMG CORBAServices and CCM specifications define a wide variety of these services, including event notification, naming, security, and fault tolerance. Domain-specific middleware services satisfy specific requirements of particular domains, such as telecommunications, e-commerce, health care, process automation, or avionics. Whereas the other object-oriented middleware layers provide broadly reusable ”horizontal” mechanisms and services, domain-specific services target vertical markets. From a ”commercial off-the-shelf” (COTS) perspective, domain-specific services are the least mature of the middleware layers today. This is due in part to the historical lack of middleware standards needed to provide a stable base upon which to create domain-specific services. 2.3 Middleware classification The layer decomposition of the whole middleware architecture is a typical modeldriven approach to simplify the design tasks, and classify the functionalities provided by the middleware. Moreover, almost all actual middleware are cross layer, providing a set of services at each layer. Some research efforts have been directed to the development of new middleware based on different programming paradigms [28]. A programming paradigm allows to program the NES as a standalone application it should hide hardware and distribution issues from the programmer as far as possible. We propose to classify them in following four main classes as reported in Figure 2.3 Middleware classification Database Tuplespace OOM MOM TinyDB T-Spaces TAO Mires Cougar ICE TinyLime ... ... ... ... Fig. 2.3. A programming paradigm-based middleware classification.