This chapter gives a solution to design Service Oriented Architectures which defines and manages Service Level Agreements to enforce Quality of Services and achieves adaptivity at runtime. The validation of this proposed approach is performed through an actual case study in the context of the multimedia application domain.
TopIntroduction
Service-orientation is one of the buzzwords of the moment among many different business areas. In the software world, service-orientation (Michelson, 2005) means designing, building or migrating pieces of software so that they are independent from the context in which they can be exploited. Service Oriented Architectures (SOA) (MacKensie, Laskey, McCabe, Brown, Metz & Hamilton, 2006; Raibulet & Demartini, 2004) are built on the following concept: they make large usage of services, as if the last were software components ready to be exploited through a series of strategies which overcome issues and difficulties that arise from such a usage.
Given the ubiquitous diffusion of the Internet, a requester can take advantage of service providers virtually located in any place on the globe. Loose-coupling (Hagel & Brown, 2002; He, 2003) between services and their providers can be now fully achieved by exploiting those providers which best suit requests, choosing among many of them due to the connection ability granted by the Internet. Exploiting services offered by entities that are unknown at design time poses a great stress on the quality aspects of the service provisioning. A solution to these problems should have a way to request not only services identified by a name or a function, but also characterized by their qualities.
The Quality of Service (QoS) (Mani & Nagarajan, 2002) concept is becoming more popular as service-orientation spreads in the software community. If a system wants to be sure on the quality levels of a service, it should have a way to describe those needs and to exploit them explicitly at runtime. QoS enable this by modeling the user expectations or requirements as qualities with measurable properties and acceptable values or ranges. As an example in the multimedia context we might consider the “HD Video” as a quality request: this refers to the picture size of a media and it has some specific values associated to it, such as 1280x720 and 1920x1080 pixels. When evaluating the quality of a requested media, we might then refer to its picture size to establish different levels of quality: “Low” when it is different from the two values given above (because of potential up or down scaling resulting in quality issues), “Medium” or “Sufficient” when it equals 1280x720 pixels and “High” when it equals 1920x1080 pixels. If a user wants to watch a “HD Video”, a QoS-enabled architecture would be able to deliver a content that will satisfy the user request by providing videos with “Medium” or “High” levels of quality related to their picture size.
Requesting a service from a provider becomes therefore more complex, as it contains more than just a function invocation along with data useful to its execution. The requester and the provider have to agree on quality properties and levels specific for a single service request. Booking of services may be of interest and this should be included in the negotiation with the provider. Service Level Agreements (SLA) (Jin, Machiraju, & Sahai, 2002) represent a valid mechanism to achieve the foretold goals, and even more. They hold the description of the requested service along with quality constraints, validity period of the request and other terms. SLA can be negotiated between two parties and when an agreement is reached, the SLA contain the assurance on the quality levels.
Even using SLA to ensure that the QoS guaranteed by the provider of a service are those expected by the requester, unforeseen problems may arise at provisioning time and hinder the execution workflow either with low levels of quality or even with an interruption of the provisioning of a service. Runtime adaptivity (Cheng, de Lemos, Giese, Inverardi & Magee, 2009; Raibulet, 2008) seems to be the solution to overcome these issues. Essentially, it means that a system is constantly aware of itself and of its execution environment (e.g., by monitoring the state of the provisioning and by having a list of different providers for a given service). Should a problem arise that could slow or stop the execution workflow, the adaptive mechanisms would have the ability to switch from the current provider to another one at runtime. SLA are especially appropriate for this task since they can also hold the information on the strategies adopted by the requester, in case the provider does not meet the agreed QoS.