Guide to Embedded Systems Architecture - Part 1: Defining middleware

Other reasons to remove it from the application layer are: to allow reusability with other applications, to decrease development costs or time by purchasing it off-the-shelf-through a third party vendor, or to simplify application code. The remaining sections of this chapter define what middleware and application software is or isn't, and provide real-world pseudocode examples of middleware and application software.

10.1 What Is Middleware?
In the most general terms, middleware software is any system software that is not the OS kernel, device drivers, or application software. Note that some OSes may integrate middleware into the OS executable (see Chapter 9). In short, in an embedded system middleware is system software that typically sits on either the device drivers or on top of the OS, and can sometimes be incorporated within the OS itself.

Figure 10-1: Middleware within the Embedded Systems Model

Middleware is usually the software that mediates between application software and the kernel or device driver software. Middleware is also software that mediates and serves different application software. Specifically, middleware is an abstraction layer generally used on embedded devices with two or more applications in order to provide flexibility, security, portability, connectivity, intercommunication, and/or interoperability mechanisms between applications.

One of the main strengths in using middleware is that it allows for the reduction of the complexity of the applications by centralizing software infrastructure that would traditionally be redundantly found in the application layer. However, in introducing middleware to a system, one introduces additional overhead, which can greatly impact scalability and performance. In short, middleware impacts the embedded system at all layers.

There are many different types of middleware elements, including message oriented middleware (MOM), object request brokers (ORBs), remote procedure calls (RPCs), database/database access, and networking protocols above the device driver layer and below the application layers of the OSI model. However, most types of middleware commonly fall under one of two general categories:

• general-purpose, meaning they are typically implemented in a variety of devices, such as networking protocols above the device driver layer and below the application layers of the OSI model, file systems, or some virtual machines such as the JVM.

• market-specific, meaning they are unique to a particular family of embedded systems, such as a digital TV standard-based software that sits on an OS or JVM.

Whether general purpose or market-specific, a middleware element can be further categorized as proprietary, meaning it is closed software supported by a company that licenses it to others for use, or open, meaning it is standardized by some industry committee and can be implemented and/or licensed by any interested party.

More complex embedded systems usually have more than one middleware element, since it is unusual to find one technology that supports all specified application requirements. In this case, the individual middleware elements are typically selected based upon their interoperability with each other, so as to avoid later problems in integration.

In some cases, integrated middleware packages of compatible middleware elements are available commercially, off-the-shelf, for use in embedded systems, such as the Sun embedded Java solutions, Microsoft's .NET Compact Framework, and CORBA from the Object Management Group (OMG), to name a few. Many embedded OS vendors also provide integrated middleware packages that run "out-of-the-box" with their respective OS and hardware platforms.

Section 10.3 of this chapter provides specific real-world examples of individual middleware networking elements, as well as integrated middleware Java packages.