INDUSTRY Watch ter _ sale that operates on the customer, store and item data to accomplish the task. The consumer (or provider) of this message would have all the information necessary to execute the producer’s (or requestor’s) request, and its implementation is no longer tied to the behavior of the customer, store and item objects. If the definition of customer, store or item changes, the associated metadata is updated to inform the consumer of those changes, so that the data processing in the application logic can be adjusted accordingly. Thus, this approach is robust to the changes in the data structure, as well as the behavior of the participants. It is important to note that a design model by itself does not result in well-designed systems. Like object-oriented programming, data-oriented programming can also be misused and abused. Data-oriented programming provides the principles and guidance for building loosely coupled systems. However, design is fundamentally a human activity; models and tools can only facilitate the process.
Data-Oriented Integration Architecture
Large scale distributed systems of systems are often a mishmash of different architectural styles. They are systems created by independent parties, often using different middleware technologies, with misaligned interfaces. A naĂŻve approach to integrating such systems results in N*N point-to-point custom integrations for each pair of systems. This approach does not scale. Yet, it is often the outcome in practice. A better approach is to use a data-oriented programming approach and explicitly formalize the data and meta-data produced and consumed by a component or a system, then use a “data busâ€? to connect them. This results in a generic Data-Oriented Architecture framework (Figure 3). Component
Component
Component
Topic Topic
Data Bus (DDS Middleware Infrastructure)
Component
Figure 3
42
Component
Component
A data-oriented integration architecture for developing loosely coupled applications. Components can be added and removed independently, without any knowledge of other components. Data readers and data writers of data topics (data flows) can be created, used and deleted independently by a component, without requiring any centralized configuration or changes. Direct data paths are automatically established between data readers and data writers of a topic, and managed by the middleware infrastructure.
January 2008
Event Processing Engine
Database
Web Service
Topic Topic
Data Bus (DDS Middleware Infrastructure)
Enterprise Service Bus (ESB)
Figure 4
Workflow Engine (BPEL)
Legacy Bridge
Commercially available “out-of-the-box� integrations of popular application platform components speed up the integration task by providing automatic mapping of the application platform’s native data representation to an underlying agreed upon semantic data model, in accordance with the principles of data-oriented architecture.
Such a data bus can accommodate a wide variety of architectural styles, and reduces the integration problem from an O(N*N) problem to an O(N). The popular architectural styles can be seen as specializations of the generic data-oriented architecture, by appropriate assignment of roles to the various components. An example of middleware infrastructure able to provide a constantly available real-time distributed data bus is the RTI Data Distribution Service, which complies with the Object Management Group’s DDS open standard specification. The DDS middleware infrastructure takes on important responsibilities and provides the underlying infrastructure to realize a loosely coupled real-time service-oriented architecture (SOA). The data-oriented programming and design philosophy maps naturally to the data modeling and introspection capabilities provided by the DDS middleware. The resulting data-oriented architecture framework provides key capabilities that ease and facilitate the construction of system of systems and distributed systems in general. It addresses the challenges of (a) dynamic real-time adaptation and (b) scalability and performance. It can also facilitate integration by directly supporting the data-oriented design approach for loosely coupled systems, and thus aid in addressing (c) incremental and independent development and (d) impedance mismatch issues across systems of systems. Leading DDS implementations provide a low-latency, highthroughput messaging and data caching infrastructure, utilizing direct peer-to-peer communications to optimize the “end-to-end� performance. They do not require running any servers or daemons, thus there are no single points of failure or loading in a system either.
Rapid Development Using Integrated Application Platforms
Many application components can be rapidly developed by using off-the-shelf application platforms that have been a priori