Qos-aware software components

D.A. Menasce
2004 IEEE Internet Computing  
I n previous columns, I've discussed some of the challenges in quality of service (QoS) for Web services 1 and the computation of response time in composite Web services. 2 In this installment, I address the more general issue of QoS in serviceoriented component-based distributed systems. The next generation of complex software systems will be highly distributed, component-based, and service-oriented. They will need to operate in unattended mode, possibly in hostile environments, and they'll be
more » ... nts, and they'll be composed of many "replaceable" components discoverable at runtime. Moreover, they will have to run on a multitude of unknown and heterogeneous hardware and network platforms. Three major requirements for such systems are performance, availability, and security. Performance requirements imply that these systems must be adaptable and self-configurable to changes in workload intensity. Availability and security requirements suggest that these systems also must adapt and reconfigure themselves to withstand attacks and failures. In this column, I focus specifically on QoS requirements for performance and describe the framework for QoS-aware distributed applications that I developed with my colleagues at George Mason University. 3 QoS-Aware Applications A QoS-aware application -or, more simply, a Qapplication -is dynamically composed of QoSaware components, or Q-components, which run on a single hardware platform. As Figure 1a (next page) indicates, before a Q-component becomes part of a Q-application, it must register with some service directory, such as in Universal Description, Discovery, and Integration. 4 A Q-application then can discover the Q-components that provide given services by interacting with the directory service. After this, a QoS negotiation between the Qapplication and the Q-component occurs. If the negotiation is successful, the Q-component becomes part of the Q-application; other compo-nents in the Q-application can then access the Qcomponent's services (see Figure 1b) . A Q-component's main tasks are to register its services, engage in QoS negotiation (which can result in QoS requests being accepted or rejected, or in counteroffers being made to the requester), provide services for concurrent requests while preserving QoS guarantees, and maintain a table of the QoS commitments made to other components. QoS negotiation is done at the session level -that is, in a sequence of service requests.
doi:10.1109/mic.2004.1273492 fatcat:aojfeyibejc2vhqp2s2bmvk66y