Real time, QoS-enabled SOA over Data-centric Middleware
A Service-Oriented Architecture (SOA) is an architectural style for building software applications that use services available in a network, such as the Web. It promotes loose coupling between software components so that they can be reused and reconfigured easily. Applications in SOA are built based on services, which are implementations of well-defined business functionality. These services can be consumed by clients in different applications or business processes.
Although SOA and Web Services are different, Web Services are a popular way to realize SOA concepts. They were implemented as services delivered over the Web using technologies such as XML, Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and Integration (UDDI) for defining, publishing, and using Web Services. Conventional SOA and web Service products available on the market have several shortcomings, however, with respect to addressing the needs of applications in mission-critical systems that require high availability and throughput, low-latency, and real time quality of service (QoS) properties.
The OMG Data Distribution Service (DDS) is a promising standard based upon proven technology for providing QoS properties such as scalability, fault-tolerance and extensibility to mission-critical systems. DDS provides a number of capabilities to meet the needs of applications in mission-critical systems, including (1) timely access to information from a wide variety of sources running over potentially heterogeneous hardware/software platforms and networks, (2) fault tolerant availability of non-volatile data for late-joining applications, (3) a data-centric information bus that aggregates, filters, and prioritizes the availability of this information to work effectively under the restrictions of transient and enduring resource constraints, (4) continuous adaptation to changes in the operating environment, such as dynamic network topologies, publisher and subscriber membership changes, and intermittent connectivity, and (5) standardized QoS policies and mechanisms that enable applications and administrators to customize the way information is published, maintained, delivered, received, and processed in the appropriate form and level of detail to users at multiple levels in net-centric systems.
Although DDS has high throughput, low latency/jitter, and rich QoS support, its underlying event structures are not as extensible as Web Services. To overcome these limitations and fully support next-generation mission-critical systems, therefore we propose to integrate Web Services and DDS technologies to create a QoS-enabled SOA that provides the following capabilities that are not available with either technology in isolation:
l QoS-enabled and real time transport layer for SOA
In the Java world, Java Message Service (JMS) has been used under SOAP to provide a reliable and scalable messaging mechanism to web services. But JMS cannot match DDS’s support for real-time QoS policies. We will therefore extend DDS to transport SOAP messages via its rich set of QoS policies. The resulting middleware platform will thus support services interactions with real time constraints that require sophisticated QoS policies, such as transport priority, latency budget, and ownership strength. Issues to investigate will include whether to use all DDS elements or only a subset of it, such as the DDS transport protocol (RTPS) and selected QoS policies.
l Data-centric implementation for SOA API
Web Services primarily addresses service registration, discovery, and invocation. The data-centric model provided by DDS is well-suited for service registration and discovery. In fact, service registration relies on the publishing service descriptions throughout a DDS domain and discovery can be realized via subscription. Issues to investigate include how combinations of DDS QoS policies can support sophisticated registration and discovery patterns. For instance, DDS QoS policies can limit the visibility of a service to a subset of the network via partitions. Likewise, DDS enables and simplifies a fault tolerant service registry. A DDS-based invocation would enhance services decoupling and promote asynchronous invocation of the service.
l Shared data space for SOA
This is a need for QoS-enabled SOA middleware that can share, exchange and process real-time data as quickly as possible. For example, financial services that exchange price data are highly time-sensitive, e.g., price data must be delivered to many financial institutions and traders quickly enough to capture opportunities before markets change. Web Services typically share data via databases. Using conventional relational databases in a real-time system is often prohibitively expensive in terms of latency as well as inherently sensitive in terms of fault-tolerance . In contrast, DDS provides a shared data space that supports both deterministic as well as fault-tolerant information sharing operations. Issues to investigate include identifying how DDS capabilities can be used to tune the usage and behaviour of that data space, such as the QoS policies for controlling the data lifespan, persistence, etc.
l WAN support for DDS
Web Services provide applications with the ability to access services from anywhere in the Web. To integrate effectively into such large-scale SOA environments, DDS must support WANs. Having a universal DDS data domain that spans the entire Internet is not realistic and may be not needed. But DDS must be able to cover an area wider than a LAN, which could be limited to groups of LANs. Issues to investigate include information scoping (partitioning), information security (encryption,authentication and authorization), features and limitations of multicast (-routing) in WAN environments, pluggable discovery-frameworks, etc.
The following picture shows our proposed integration of DDS in a SOA environment. It depicts the introduction of DDS as an additional transport protocol under SOAP and at the same level as JMS and HTTP. It also depicts the access of Web Services to the real-time data space provided by DDS.