Real time issues in building Quality of service in Distributed Systems

Introduction
DOC middleware has evolved tremendously over the past few years. Initially, it facilitated the seamless inter-operation of various applications over a variety of heterogeneous environments. Its growing acceptance has opened its applicability to a broader variety of applications, whose demands are far beyond inter-operability. This is especially true for nextgeneration applications such as e-commerce, autonomous process control, and global event notification systems. These advanced applications require a wide range of quality of service (QoS) support, where resources are managed both prior to and during run-time. For example in mission critical telecommunication systems and distributed electronic medical imaging systems, a failure to meet certain deadlines can result in significant loss of property and even life. Therefore, these systems must be analyzed and monitored both off-line and on-line to ensure that resources are properly allocated and managed. Also, these applications must be able to autonomously reflect upon situational factors as they arise in the run-time environment and adapt to these factors while preserving the integrity of key mission-critical activities. These requirements have driven R&D efforts in DOC middleware to develop QoSenabled DOC middleware which simplifies the development of advanced applications that can leverage the advances in networks and end-systems end-to-end. Two major research efforts in this area have been: Quality Objects (QuO): This is a DOC middleware extension, which supports adaptive QoS specification, measurement, and control . ACE QoS API (AQoSA): This is a unified QoS API in the Adaptive Communication Environment (ACE) [2] that abstracts various network QoS protocols like RSVP and Diff-

Technical Challenges & Solution Approaches

Some of the most challenging requirements for new and planned QOS systems can be characterized as follows: Multiple QoS properties must be satisfied in real-time Different levels of service are appropriate under different configurations, environmental conditions, and costs The levels of service in one dimension must be coordinated with and/or traded off against the levels of service in other dimensions to meet mission needs and The need for autonomous and time-critical application behavior necessitates a flexible distributed system substrate that can adapt robustly to dynamic changes in mission requirements and environmental conditions. Although conventional COTS software cannot meet all of these requirements, todays economic and organizational constraintsalong with increasingly complex requirements and competitive pressuresare making it infeasible to built complex DRE system software entirely from scratch. Thus, there is a pressing need to develop, validate, and ultimately standardize a new generation of adaptive and reflective middleware [Bla99] technologies that can support stringent DRE system functionality and QoS requirements.

Unified Middleware-centric QoS API

Application developers need standardized interfaces to allow QoS specification and to receive guarantees from the underlying network and QoS infrastructure. As the different QoS protocols become more and more mature, the need for a QoS API that applications can use as a unified interface to the underlying QoS protocols has grown tremendously. Firstly, the Applications would like to shield themselves from the protocol specific details. Secondly, although the QoS protocols provide a mechanism for allocating resources between two end systems, they are not sufficient to address the translation required from the application level QoS parameters to the network level QoS parameters. Thirdly, the adaptive applications require a uniform mechanism to get notified of changes to the available resources so they can re-negotiate the QoS. All these considerations motivate the design of a unified QoS API that addresses these issues in a platform/protocol independent way. Once the unified API is developed, it can be exposed to the applications through middleware like CORBA. This allows the applications to get QoS guarantees through standard middleware APIs and at the same time leverage all the usual features of a middleware. The API can also be integrated with higher level middleware services. At this level, the API would have added functionality like binding QoS to specific application data flows or translating standard QoS flow requirements to network QOS.

QoS Event Notification for Adaptivity:

AQoSA provides applications with a platform-independent API for receiving notifications when the underlying network QoS changes. ACE applications often use an event handling model based on the Reactor pattern , which allows servers to decouple event demultiplexing/dispatching from their application specific event handling. In RSVP, the notifications are carried in RSVP events AQoSA receives and handles RSVP events uniformly for different network-level QoS implementations via the Reactor pattern [11]. In this pattern, asynchronous event demultiplexer such as Select or WaitForMultipleObjects, handles event demultiplexing and an associated reactor notifies previously registered application-specific event handlers so they can adapt to QoS state change events. Extensibility: AQoSA enables new network- and end system-level QoS mechanisms to be integrated without tedious refactoring of its public APIs, e.g, it is straightforward to extend AQoSA to support other QoS models. To accomplish this, AQoSA extends the existing ACE framework components by introducing new capabilities allow applications and underlying DOC middleware to manage QoS multicast or unicast sessions. Moreover, AQoSA applies several patterns to ensure that new network-level QoS implementations can be easily integrated without changing applications that use its API.

Advanced QoS capabilities: AQoSA binds multicast or unicast flows to reservations via a uniform and portable component called a QoS session . A QoS session represents the applications notion of the underlying network-level QoS. Though modeled originally using IntServ RSVP sessions, a AQoSA QoS session can also accommodate other QoS mechanisms. An AQoSA QoS session explicitly separates QoS properties of its sessions from lower-level socket data transfer aspects. Internally, the ACE QoS socket maintains an association between QoS sessions to which an application has subscribed. This separation of concerns also facilitates more advanced QoS functionality.

Demand for end-to-end QoS support, not just component QoS This area represents the next great wave of evolution for advanced DOC middleware. There is now widespread recognition that effective development of large-scale distributed applications requires the use of COTS infrastructure and service components. Moreover, the usability of the resulting products depends heavily on the properties of the whole as derived from its parts. This type of environment requires visible, predictable, flexible, and integrated resource management strategies within and between the pieces. Despite the ease of connectivity provided by middleware, however, constructing integrated systems remains hard since it requires significant customization of non-functional QoS properties, such as predictable latency/jitter/throughput, scalability, dependability, and security. In their most useful forms, these properties extend end-to-end and thus have elements applicable to The network substrate The platform operating systems and system services The programming system in which they are developed The applications themselves and

 The middleware that integrates all these elements together. Two basic premises underlying the push towards end-to-end QoS support mediated by middleware are that: 1. Different levels of service are possible and desirable under different conditions and costs and 2. The level of service in one property must be coordinated with and/or traded off against the level of service in another to achieve the intended overall results. To manage the increasingly stringent QoS demands of next-generation applications, middleware is becoming more adaptive and reflective.

Adaptive middleware [Loy01] is software whos functional and QoS-related properties can be Modified either: Statically e.g.,to reduce footprint, leverage capabilities that exist in specific platforms, enable functional subsetting, and minimize hardware/software infrastructure dependencies or Dynamically e.g, To optimize system responses to changing environments or requirements, such as changing component interconnections, power levels, CPU/network bandwidth, latency/jitter; and dependability needs. In mission-critical systems, adaptive middleware must make such modifications dependably, i.e. while meeting stringent end-to-end QoS requirements, Thus reflective middleware supports more advanced adaptive behavior and more dynamic strategies keyed to current circumstances, i.e. necessary adaptations can be performed autonomously based on conditions within the system, in the system's environment, or in system QoS policies defined by end-users.

Challenges and Opportunities

An increasing number of next-generation applications will be developed as distributed systems of systems, which include many interdependent levels, such as network/bus interconnects, local and remote end systems, and multiple layers of common and domainspecific middleware. The desirable properties of these systems of systems include predictability, controllability, and adaptability of operating characteristics for applications with respect to such features as time, quantity of information, accuracy, confidence, and synchronization. All these issues become highly volatile in systems of systems, due to the dynamic interplay of the many interconnected parts. These parts are often constructed in a similar way from smaller parts. To address the many competing design forces and runtime QoS demands, a comprehensive methodology and environment is required to dependably compose large, complex, interoperable DOC applications from reusable components. Moreover, the components themselves must be sensitive to the environments in which they are packaged. Ultimately, what is desired is to take components that are built independently by different organizations at different times and assemble them to create a complete system. In the longer run, this complete system becomes a component embedded in still larger systems of systems.

Given the complexity of this undertaking, various tools and techniques are needed to configure and reconfigure these systems hierarchically so they can adapt to a wider variety of situations. An essential part of what is needed to build the type of systems outlined above is the integration and extension of ideas that have been found traditionally in network management, data management, distributed operating systems, and object-oriented programming languages. The payoff will be reusable DOC middleware that significantly simplifies the building of applications for systems of systems environments.