Integration Challenges of
SOA-Based Enterprise DRE Systems
Enterprise distributed real-time and embedded (DRE) systems, such as supervisory control and data acquisition (SCADA) systems, air traffic control systems, and shipboard computing environments, are growing in complexity and importance as computing devices are networked together to help automate tasks previously done by human operators. These types of systems are required to provide quality of service (QoS) support to process the right data in the right place at the right time over a networked grid of computers. QoS properties required by enterprise DRE systems include the low latency and jitter expected in conventional real-time and embedded systems, and the high throughput, scalability, and reliability expected in conventional enterprise distributed systems. Achieving this combination of QoS capabilities is hard because these systems work in constrained environments with a limited amount of resources that can vary depending on the location of the system. Moreover, this level of QoS requires in depth knowledge of low-level programming techniques, for example, properly interfacing with sockets to write efficient networking protocols, which the application developers of enterprise DRE system may not possess.
To address these challenges, enterprise DRE systems are increasingly being developed using applications composed of components running on feature–rich service-oriented architecture (SOA) middleware frameworks. These components are designed to provide reusable services to a range of application domains that are composed into domain-specific assemblies for application (re)use. SOA middleware is intended to alleviate problems of inflexibility and reinvention of core capabilities associated with prior monolithic, functionally-designed, and “stove-piped” legacy applications developed using just the capabilities required for a specific set of requirements and operating conditions. SOA-based systems, conversely, are designed to have a more general range of capabilities that enable their reuse in other contexts. Moreover, these systems are developed in layers, for example, layer(s) of infrastructure middleware services (such as naming and discovery, event and notification, security and fault tolerance) and layer(s) of application components that use these services in different compositions.
Combining stringent QoS requirements in DRE systems with the transition to SOA component frameworks has created a particularly vexing problem for researchers and developers of large and layered enterprise DRE systems: The inadequacies of system architectures may not be ascertained until years into development. At the heart of this problem is the serialized phasing of layered system development, shown in Figure 1, which postpones the discovery of design flaws that affect system QoS until late in the lifecycle, that is, at integration time. A hallmark of serialized phasing is that application components are not created until after their underlying system infrastructure components, such as naming and discovery, event and notification, security and fault tolerance, and resource management.
Characteristics and complexities of serialized phasing in enterprise DRE systems
As shown in Figure 1, SOA-based enterprise DRE systems built using serialized phasing often do not adequately test the implementations, configurations, and deployments of infrastructure components under realistic workloads until the application components are done. Moreover, both application and infrastructure components are hosted on the same target platform. Each component must, therefore, be properly deployed and configured to achieve the desire QoS. As a result, it hard to know how well the system will satisfy key QoS properties due to disconnects in the phasing of infrastructure and application component development. Moreover, handcrafted software designs used in many enterprise DRE systems to address these concerns make it hard to conduct “what if” experiments on alternative system architectures and implementations to determine which valid configurations can obtain performance goals for a particular workload. Making any significant changes to these types of handcrafted systems late in their lifecycle can be costly due to the impact on the design, implementation, deployment, and (re)validation of many application and infrastructure software/hardware components.