Complex Service Management
Originally, (Web) services were deployed and used with almost no actual control by the different parties. The simplistic assumption that their behavior was correct and everyone had to be happy with the functionality provided was unrealistic. The actual exploitation of services, imposed us to start conceiving different methods and tools to manage the complete life-cycle of deployed and running services with special emphasis on the actual run-time behavior.
Differently from other software systems, the problem is not the capability of controlling how the different service instances are activated and deactivated, but it is about the non-functional issues and the supervision of the service level agreements (SLAs) established with the different partners.
This problem has some key peculiarities. In many cases, the services we would like to utilize are not (fully) under our control. We may have cases in which we own the composition, which is the actual service we want to manage, but we have no complete access to (some of) the partner services. Moreover, the multi-tenancy implicit in service-centric applications requires that the same service (or service composition) be managed in different ways for the different users. The problem is intrinsically hierarchical: the effects on complete processes (i.e., service compositions) must be properly reflected on the single services that constitute the assembly, and also on the infrastructure on which they both —single services and compositions— are executed.
These characteristics have already motivated significant research efforts and standards (like Web Service Distributed Management), but we claim that none of provided solutions is able to address the problem completely and homogeneously. Our proposal is to build on top of existing standards and try to provide a holistic solution to distributed service management. First of all, we think that the interfaces provided to fully control the behavior of services must be extremely rich, and allow users to control the inner details of the services. We assume that some key features must be mandatory, while others could be optional. For example, mandatory features may be the possibility to start, stop, and suspend the execution of a given service instance, or even to monitor its basic behavior. On the other hand, more advanced capabilities, like security issues, SLA enforcement, fine-grained annotations and probing, and deep control of associated physical resources, may be optional and provided by some services in particular contexts (e.g., the services in the same domain as the user’s one).
This distinction between mandatory and optional features allows us to distinguish among at least three types of services (w.r.t. to management). Black-box services are those that only provide the basic features and allow the user to interact with them as if they were black boxes. Grey-box services provide some optional capabilities, but they do not provide complete access and freedom to the user, while white-box services implement the complete management API and allow the user to fully oversee and control the execution of service instances.
Since services can be composed, another important aspect is the composition of the different management capabilities. When we think of management features, the capabilities offered by the composition must be suitably supported by those provided by the single services. This is why the actual composition of the management APIs seems to be a promising research problem.
All these elements must be provided to the user seamlessly and homogeneously. Since some of the management capabilities offered by the different services may have a big impact on their performance, we also need the capability to switch them on and off on demand. Indeed, the more management is required, the slower a service becomes. Thus the fine-tuning of these additional features, w.r.t. their actual behavior, is mandatory to offer a usable solution.
These are some of the key challenges we foresee for the complete and effective management of services and service compositions. These are also the underpinnings of our work in the project and we hope to be able to provide useful solutions that fit well in the global SLA@SOI infrastructure.
Luciano Baresi and Sam Guinea
Tags: complex, Complex Service Management, composition, distributed, management, services, sla, Web services, ws-dm
