8.1 Message-oriented Middleware and Distributed Transaction

Message-oriented middleware (MOM) is software that provides message passing capabilities between overlying middleware and/or application software within an embedded system (Figure 8.1). MOM is typically used when some type of point-to-point and/or autonomous publish-subscribe messaging scheme is optimal. The APIs and functionality provided by MOM software allow for simplifying the ability to design overlying software components, because the APIs abstract out underlying networking protocol details and other underlying system components for developers. For overlying middleware and application software that adhere to the supplied APIs, this type of middleware is what allows for the interoperability of the overlying software components that communicate via these messages.

When MOM software also provides message-passing capabilities between overlying software of independent devices connected across a network, MOM middleware is further classified as distributed messaging middleware. In this case, the APIs and functionality provided by this type of more complex MOM software also aid in the portability of overlying middleware and application software to other devices with vastly different underlying system software and hardware components.

MOM middleware is typically based on some hybrid combination of client–server and the peer-to-peer architecture model of message-passing communication. This means an MOM server has control in managing the MOM clients. MOM clients can pass messages peer-to-peer, not requiring the centralized MOM server to manage and control all communication. Depending on the implementation, MOM servers can manage MOM client messages either concurrently (where more than one MOM client request can be handled in parallel) and/or iteratively (a.k.a. one-at-a-time). How MOM servers and clients manage communication is ultimately dependent on whether the messaging scheme is based upon a synchronous message-passing model, an asynchronous message-passing model, or a model based upon some combination of both.

In general, synchronous message passing is based upon a request–response type of handshaking scheme. This type of MOM communication requires that an MOM receiver exists in some form at the time the MOM sender transmits a message, in order to eventually unblock the waiting sender with a response message. For example, an MOM client that transmits a message to another MOM client and/or MOM server will block waiting for some type of response message from the receiver. The advantage of synchronous MOM messaging communication is that it is simpler and straightforward. On the flip-side, if there are hard real-time scheduling requirements for the device, it is risky to use MOM software that blocks the system waiting for a response message.

Disadvantages with an underlying synchronous scheme are highlighted in an embedded device with requirements to support multiple, complex interactions and nested calls between MOM senders and receivers. There is an increase in connection overhead in relation to this scheme due to the system resources required to manage the sessions. If some type of connection pool on an as-needed basis is not implemented, then managing these resources becomes very expensive and limits to the number of connections allowed are introduced.

In an asynchronous message-passing scheme the transmitter can send a message at will independent of the availability of the receiver. The receiver can process received messages when available as well. This means it is a form of non-blocking, connectionless communication in which the transmitter and/or receiver does not have to wait for the response from the other to continue to perform other tasks.

Typically, MOMs transmit messages under some combination of a:

Message-oriented and -distributed messaging middleware that is based on queuing, a.k.a. message queuing middleware (MQM), implements message queues that can transmit, receive, store, and forward messages (Figure 8.2). MQM is typically utilized within embedded devices in which performance is a challenge, as well as within devices that do not have a constant and/or stable networking access. Given the utilization of message queues, MQM addressed handshaking and performance goals by allowing the embedded device to process messages according to available system resources, as well as independent of the networking connections.

What differentiates MQMs are the types of queues supporting the messaging model, as well as the specific attributes of these message queues. These attributes include everything from size to naming convention to security access such as public versus private, permanent versus temporary, journaled versus non-transactional (no back-up copies) to name a few.

While there are many types of message queue model schemes available, one of the most common is based on some type of the FIFO (First In, First Out) queue model. Under FIFO, a queue stores ready messages (messages ready to be processed). Messages are added to the queue at the end of the queue, and are retrieved to be processed from the start of the queue. In the FIFO queue, all messages are treated equally regardless of their importance or receiver (Figure 8.3). Variations on an MQM based upon the FIFO queuing scheme include queues in which messages in the queue are processed in the order in which the smaller-sized messages are processed first, and/or messages are processed according to their importance (priority) in the queue for example.

8.1.1 Building on MOM: Transactional Middleware and RPC

One of the most common types of distributed transaction middleware is the RPC (remote procedure call). The RFC 5531 ‘RPC: Remote Procedure Call Protocol Specification Version 2’⁵ is a common industry standard which defines an RPC model for implementation where a thread of control logically winds through a caller and receiver task. As shown in Figure 8.4, RPC middleware simply allows synchronous communication across remote systems, where the caller on one embedded device can invoke a native language-based routine residing on a remote system in a manner similar to invoking a local procedure. In general, RPC implements a scheme in which:

• a caller first sends a message to the receiver task on a remote system

• the caller blocks, waiting for a reply message from the remote system

• after the reply message is received by the caller, the caller’s execution is resumed.

RPC is built upon some type of underlying core networking middleware such as TCP and/or UDP depending on the type of RPC scheme. RPC is also fundamentally overlying some type of MOM foundation (see Figure 8.5). RPC also acts as a basis for other types of distributed transaction middleware found within a variety of computer systems, such as Remote Method Invocation (a.k.a RMI; a variation of RPC but originating in the Java space), Distributed Component Object Model (DCOM), and Distributed Computing Environment (DCE).

8.1.2 Building on RPC: Object Request Brokers

An Object Request Broker (ORB) provides a layer to allow for creating an individual overlying middleware and/or application component that resides as multiple objects, on the same device and/or across more than one device. ORBs are an approach to allow for software interoperability, since they allow for integration within one individual application or middleware component – even if the integrated software came from vastly different vendors with different APIs. As shown in Figure 8.6a, an ORB acts as the foundation to the Common Object Request Broker Architecture (CORBA), and is based on industry standards from the Object Management Group (OMG).

A similar philosophy behind using ORBs lies behind the the popularity of using DAO (Data Access Object) design patterns in embedded systems designs. DAO originated in the Java space (Figure 8.6b), and has been used as a basis for DAO frameworks in real-world designs for abstracting, encapsulating, and managing accesses to various heterogeneous underlying resources in the form of objects.

An ORB handles any translation and transformation (marshalling) of data between overlying heterogeneous objects to allow for this intercommunication. Each object within the individual overlying component to an ORB integrates an ORB interface. It is the ORB interface that allows the objects that make up the overlying application and/or middleware software to communicate and provide remote invocation access to functionality.

An overlying ORB object becomes accessible to other overlying ORB objects for remote invocations over a network. Thus, depending on the implementation, an ORB is built upon the Internet Inter-ORB Protocol (IIOP) and other underlying core networking middleware for this support across networked devices. Also, depending on the ORB, more complex middleware such as RPC components can also act as a foundation.

When an ORB, such as within CORBA, manages the routing requests and responses between a client and a distributed object, an IDL (Interface Description Language) is used to describe the transmitted data. As defined by the OMG, IDL interface definitions are stored in some type of interface repository that the ORB then utilizes for tracking and managing communication with objects. The ORB then can also activate and deactivate objects by request, and can provide the types of services such as those shown in Table 8.1.

Table 8.1

Examples of CORBA Services

ORB Service Type	Description
Concurrency control	Managing data locks in support of multitasking environment
Event	Objects specify what notifications for events are of interest
Externalization	Manages data transmission and translation between ORB objects and some format of a data stream
Licensing	Manages objects that require active licenses for usage from a vendor
Live cycle	Definitions for creation, deletion, copying, and moving objects
Naming	Searching for objects by name
Persistence	Storage/retrieval of ORB data from non-volatile memory via a file system and/or database
Properties	Manages ORB object description details
Query	Manages database queries for ORB objects
Transaction	Manages transactions and insuring data integrity
Security	Managing authentication and authorization issues relative to data and ORB objects

8.2 Authentication and Security Middleware

Authentication and security middleware is software that is used as a foundation for implementing security schemes for overlying middleware and application software. This type of middleware is required in the case of using RPC middleware, for example, in which without some type of authentication and security middleware component, data are transported in an insecure manner with the routine call.

In general, authentication and security middleware typically provides at the very least some type of code security features. Middleware that helps to insure code security, validation, and verification can be implemented within an embedded device independently, and/or can be based upon core middleware components such as JVM or .NET components that with their very implementation and their respective higher-level languages contain this type of support. This can include everything from insuring valid type operations are performed, i.e., array bounds checking, type checks and conversions, to checking for stack integrity (i.e., overflow) and memory safety. For example, an embedded JVM and associated byte processing scheme will include support class loading verification and security, as well as garbage collection and memory management.

When it then comes to securing the actual data managed within an embedded device, cryptography algorithms are one of the most reliable implementations for insuring security via a middleware layer. Cryptography schemes utilize some combination of encryption keys, obfuscator tools, digital signatures, and/or certificates to name a few. This allows the sender to perform some type of encryption on the data before transmission, to help insure that ‘only’ the ‘intended’ receiver can decrypt the data. Again, here core middleware with an embedded JVM implementation for example can be used as a foundation to include some set of Java-based APIs for cryptography support for:

Access control is policy-based and provides support to insure only code that is allowed to execute on the embedded device is permitted. In this case, specific policies associated with a particular overlying software component are used to check and to enforce the access control scheme to provide protection. Evidence-based CAS (Code Access Security) enforces the check on code for everything from its origin to searching for ‘dangerous’ code within the software before permitting execution on the device. Again, if utilizing an embedded JVM scheme, then this can be built upon the pre-existing class loading implementation within the JVM.

Finally, authentication and authorization middleware simply provides functionality to determine whether an overlying component is what it claims to be. For example, this can include a scheme for verifying logins and passwords. After authentication, results are passed on to an authorization scheme that actually executes what is necessary to allow access to the device’s resources.

8.3 Integration Brokers

The implementation of an integration broker in an embedded system is typically due to the necessity of integrating vastly different types of overlying middleware and/or applications that must be able to process each other’s data. This overlying software can reside within the same device, or across networks within other devices. Figure 8.7 shows an example of such an ecosystem. Integration brokers allow applications and other middleware to exchange different formats of data, by managing the translation and transmission of these data. This means overlying software is not required to concern itself with any communication requirements of the software receiving the data. To achieve this, integration brokers provide some set of functionality that supports:

Integration brokers inherently support an interoperability interface and communication scheme that is an alternative to point-to-point with a design in which point-to-point communication would result in too many connections to be managed and maintained efficiently. This means the number of connections would decrease when overlying software utilizes the broker for intercommunication. In this case, dependencies between overlying software that communicate via the broker are non-existent, leaving only the dependency of this overlying middleware/application on the definition of the integration broker’s interoperability interface.

An integration broker is fundamentally built upon other types of middleware, such as ORBs, RPC, TP monitors, or MOM. Understanding what an integration broker’s middleware foundation is is important because, for instance, an MOM-based implementation will require overlying software that use the broker to communicate via messages. An integration broker based on some type of MOM implementation (via an integrated message broker) could then also include support for functionality ranging from message routing to message queuing and translation, whereas an RPC and/or ORB-type of RMI base requires overlying applications and/or middleware to trigger communication via procedure (RPC)/method (RMI) calls made, for example.

An integration broker is not only made up of some type of underlying communication broker, be it an MOM, RPC, and so on. At the highest level, as shown in Figure 8.8, an integration broker is also composed of components that handle the event listening and generation that resides upon some type of core networking middleware. For example, an integration broker’s ‘TCP listener’ component that utilizes underlying TCP sockets, whereas a ‘file listener’ component utilizes an underlying file system. An integration broker’s transformer component handles any translation of data required as these data pass through the broker on their way to the destination. This for example would include an ‘FTP adaptor’ subcomponent that supports FTP or an ‘HTTP adaptor’ subcomponent that supports HTTP.

8.4 Summary

For embedded devices that have enough memory and processing power, overlaying complex networking and communication middleware on top of core middleware is increasingly becoming a popular approach in embedded systems design to support additional requirements. What was introduced in this chapter included:

This chapter pulled it all together for the reader relative to demystifying these types of complex networking and communication middleware, and how they build upon the core middleware discussed in the previous chapters. The next and final chapter of this book concludes with a holistic view of demystifying designing an embedded system with middleware.

8.5 Problems

8.6 End Notes