Exploring data oriented architecture for System-of-Systems design

What does the term application mean to you? Today, many business and personal applications don’t reside on just a single machine. New age applications are distributed across a number of network connected machines. While our object oriented heritage succeeds within the confines of a single system, developing a cohesive application that spans multiple systems defies the fundamental assumptions and principles of object oriented design.


In this month’s column, we will look at a new approach, data oriented architecture, for development of applications that span multiple systems and how it simplifies large-scale multisystem applications development.


Issues facing next-generation applications

You may remember my October 2006 CompactPCI and AdvancedTCA Systems, Software Corner column where I described Model Driven Development, which in large part utilized a middleware standard called Data Distribution Service (DDS). DDS breaks down application development by identifying the data elements needed to execute an application, then grouping these data elements into topics. Once topics are identified, producers and consumers of these topics are defined.


I recently came across a white paper authored by Rajive Joshi of Real-Time Innovations, Inc. entitled Data Oriented Architecture (http://www.rti.com/mk/data-oriented-architecture.html). This white paper is an excellent read and contains a number of interesting concepts. Data oriented architecture is based upon DDS. Beyond that, the white paper draws a number of comparisons and contrasts to object oriented design principles and illustrates how an object oriented approach to the System-of-Systems application can increase complexity and risk incompatibility between the systems that make up the overall application. I will not try to describe everything the white paper discusses in this column, but I will describe the main points of the white paper as well as relaying some insights from a recent interview with Rajive Joshi.

Next-generation applications involve running across multiple systems. These System-of-Systems applications are characterized by their dynamically changing environments, high-availability requirements, instant response times, and integrating information across a variety of distributed platforms. The key technical challenges to the development of the System-of-Systems application are:

• Often the software running on the different systems is developed by different groups and enhanced independently.

• The information exchange between these systems is difficult to manage and may change dynamically, leading to something Rajive calls impedance mismatch between systems.

• Each system is changing dynamically, so it is not practical to have one centralized coordinating entity.

• Application scalability is another important consideration. As more resources are introduced into the System-of-Systems, the effect
on the application must be minimal.


Overview of data oriented design

The philosophy of the traditional object oriented design methodology is to define an object with attributes and expose methods, for example, code, that access that object’s information or services that object provides. In essence the methods represent exposing code and hiding the data within the object. Data oriented design works exactly the opposite way by defining a data model that characterizes the information exchange between systems. Subsequently, producers and consumers of the information exchange data model are defined. These producers and consumers participate in the information exchange and are probably developed using an object oriented approach. Each producer and consumer is a tightly coupled system where such an object oriented design methodology makes sense. The data oriented design model is shown in Figure 1.


The data model itself is not limited to the typical structure definition that might come to mind. The data model consists of the information and associated Quality of Service (QoS) profile. For example, a video stream might be an example of a data within the data model. That data model might have an associated data rate. Producers of that data must conform to that data’s data rate definition. Similarly, consumers must be able to consume the data at the data rate specified by the data model. This innovative approach allows the design and implementation of producers and consumers to be much more loosely coupled. No assumptions need be made relating to controlling a producer or consumer through the exposed control methods of that object. The data simply exists at the quality of service level specified, and an entity called the information exchange middleware deals with any violations or inconsistencies with the defined data model for the application. This information exchange object represents the application middleware in the concrete instance of the application.


Flight System-of-Systems

Rajive cites a System-of-Systems example of an air traffic system. There are two kinds of systems within a System-of-Systems:

• Edge Systems characterized by real-time, often mission critical exchange of information n
• Enterprise Information Systems, where more of the non-time critical history, status, and operation and maintenance information flows


In the air traffic example, the LAN within each airplane represents an edge system. Likewise the control tower LAN represents another edge system. These two systems must communicate in real-time with high reliability, otherwise air traffic system safety is compromised.

A third system in this System-of-Systems application is the airport LAN. This is an Enterprise Information System that deals with baggage, arrival and departure times, flight reservations, and flight history. The airport LAN communicates with the control tower system to get flight status.


This example amply illustrates “System-of-Systems” and application development challenges for this environment. Airplane manufacturers develop the airplane systems. Another entity puts together control tower LANs. The airport LAN can stem from yet another source. Each of these independent systems are adapting and evolving at their own rates. Yet the information between these systems must be the invariant within the overall System-of-Systems. Scalability issues are obvious within this example. As the airport grows larger, more planes may fly in and out. As airports are opened, planes must be equipped to communicate with them and with control tower LANs. Figure 2 depicts the flight System-of-Systems.


Data oriented design in this example might define communication streams between control tower and airplane systems as bidirectional, guaranteed delivery of audio and telemetry information. Producers of the telemetry information are the airplane control systems. Consumers are the alarm systems within the control tower.


Once the data model is defined, each system can work toward the data model contract that it has producer(s) and/or consumer(s) for independently of the other systems. This approach guarantees that no mismatches of data will occur when the systems are integrated into the overall application.


Data model middleware

Real-Time Innovations, Inc. is a com-pany that develops middleware for the development and integration of some of the world’s most demanding real-time applications.


The RTI Data Distribution Service middle-ware implements the data oriented architecture described here. This middleware links as a library into each application with services available to publish or subscribe to information defined within the overall defined data model.

Listeners can also use the API to monitor data model health. For example, if QoS parameters of parts of the data model are violated, there are registration functions that listeners can use to be notified of these events. Also, as publishers and subscribers are added or removed, this information is available through the listener API as well. However, as producers and consumers scale within the overall application, the RTI middleware manages this, so essentially zero administration is required by the application as systems within the application scale up or down.


I asked Rajive if data oriented Architecture might give rise to data oriented tools similar to how C++ and Java gave rise to object oriented development and modeling tools. Rajive believes that the data model is really a definition of the behavior of the middleware controlling the data definition. While tools oriented to a design philosophy can be helpful, they are not essential. The key is to design the data model, then configure the middleware to reflect the developed data model. Each component of the system can use the traditional object oriented development approach while conforming to the defined data model by using the middleware APIs, significantly lowering integration risk within a project.


The RTI middleware conforms to the DDS standard and linkable libraries. APIs are available in a large number of languages and operating system platforms.


Rajive also noted a unique feature of the RTI middleware that extends to embedded databases such as SQL. He mentioned that databases, in essence, are also a source and/or sink of data. Database concepts map very nicely into the data oriented architecture way of thinking. So for instance, the RTI middleware allows the application to add an SQL component and connect with a given QoS using the RTI real-time connect middleware. When changes are made in the database, those changes get propagated throughout the DDS system. Also, updates can also become automatically available for the SQL database in the same manner. In essence, the RTI middleware becomes a bridge between the database and the rest of the System-of-Systems.



For those interested in learning more about data-oriented architecture, I recommend visiting www.rti.com. There are a number of excellent white papers and a demonstration of data oriented design using shapes available for download. The shapes demonstration allows you to actually see data oriented design in action and is a great introductory “hands-on” experience to data oriented architecture.

I think we can all see how applications have been evolving toward operation across a variety of systems where interaction between these systems must be loosely coupled in order for the application to be resilient enough to operate through an ever-changing environment of systems. Data oriented architecture is a significant enabler and a critical concept for efficiently developing next-generation System-of-Systems applications.