Service Infrastucture (KM-SI)
WP-JRA-2.3: Service Infrastructure
The property commonly referred as self-* is a collection of one or more reflexive properties expressing the ability of changing some aspects of the working behaviour of a computing entity. In most cases self-* can be translated to some of self-configuration, self-optimization, self-healing, self-protection but there are various further self-* properties. The aim of autonomic computing is to incorporate most of the self-* properties into computing systems.
The driving force behind developing self-* functionalities is identified as the complexity of integrating large-scale heterogeneous computing systems into a single one. The most notable trends nowadays in this direction are Grid and mobile computing. Accordingly, the self-* chapter is organised around these two computing platforms. The design space of self-* services is extensive, hence, instead of a taxonomy-like presentation, some representative cases are chosen to introduce and demonstrate various aspects of self-* issues, their use cases and the best practices. More specifically:
Some high-level models that are governing self-management are introduced. They are usually based on some analogy to emulate self-* behavior found in nature.
Autonomic brokering plays a crucial role in establishing self-* behavior in Grid computing. Grids must be instrumented with flexible, decentralized decision making capabilities, whereas clients need a robust distributed computing platform that allows them to discover, acquire, federate and manage the capabilities necessary to execute their decisions.
Dynamic self-deployment of services that is a novel and unique technique. It is an example for supporting different phases of service lifecycles by self-* capabilities, bootstrapping in the certain example.
Software systems built on top of Service-Oriented Architectures (SOA) use a triangle of the three operations "publish", "find" and "bind" in order to decouple the participants in the system.
The problem of "finding" services is usually referred to as Service Discovery. Service Discovery is defined as the act of locating a machine-understandable description of a Web Service that may have been previously unknown and that meets certain criteria. Traditionally, SOA-based systems rely on centralized discovery mechanisms, such as centralized service registry standards (e.g., UDDI or the ebXML registry, ebXMLRR) or centralized indices. By contrast, there are many research approaches that rely on decentralized storage, mainly to get away from the single point of failure problem that centralized registries pose, and to increase scalability. Such approaches include distributed UDDI clouds, P2P-based service registries (e.g., PWSD or the P2P registry proposed by Schmidt and Parashar). Distributed approaches also include agent-based solutions, such as DASD (DAML Agents for Service Discovery). Another interesting research question in Service Discovery is how queries can be formulated, i.e., what retrieval mechanisms are used. The usual approach here is to use keyword matching, using results from the Information Retrieval community. A variant of keyword-based searching is the Vector Space Search Engine presented by Platzer and Dustdar. More advanced than these approaches is signature-based matching. These approaches use the (WSDL) interfaces of Web services to inform the search. Prominent examples include Woogle, SPRanker, WSQBE and the Service Discovery Framework presented by Zisman et al. Semantics-based approaches use Semantic Web Services technologies for Service Discovery, such as OWL-S (or its predecessor DAML-S), SAWSDL or WSMO. Context-based approaches, which include the query context (such as location or user preferences) in the discovery process can be seen as an extension to the other matchmaking approaches (rather than a replacement). Much work in this area has been carried out by Zisman, Spanoudakis et al. Another orthogonal topic is QoS-based service discovery, i.e., finding services that comply to certain non-functional constraints. Lately, languages are being proposed to enhance registries with QoS data, or to model QoS (QML). Work in the area of QoS-based WS matchmaking has been carried out by Kritikos and Plexousakis (OWL-Q).
The scope of Dynamic Binding is somewhat different to Service Binding: Dynamic Binding assumes that a service has already been discovered, and now has to be connected to. An early approach to dynamic binding has been developed within the SeCSE project (WS-Binder). Similarly scoped was the JOpera framework, that also incorporated some dynamic binding ideas. Recently, the VRESCo project proposed a new infrastructure for service-oriented computing, that also assumes that dynamic binding is the foundation on which loosely-coupled service-based systems are built. A topic closely related to Dynamic Binding is Dynamic Invocation. Dynamic Invocation considers that it is not so easy to dynamically invoke recently discovered, previously unknown Web services. Apache WSIF is the well-established service framework used for Dynamic Invocation. However, recent toolkits such as DAIOS advance the concepts of Dynamic Invocation to include topics such as RESTful Web services and service mediation between incompatible services.
Seemingly, self-* services and service registry, discovery and binding are very loosely coupled but in an operational service based infrastructure they are related and may rely on each other. Most self-* functionalities, like self-healing and self-optimization for instance, obviously need information about the available services that can be obtained by service discovery. Self-deployment is both relying on the information of service registries and maintaining them. Also, version management is essential in the presence of self-deployment, from a practical point of view they are belonging to the same scope of problems. Self-* brokering in grids, that can be a potential solution for optimization, fault tolerance and adaptation, is strongly related to service discovery mechanisms. On the other hand, in certain cases service registry and discovery techniques may require some degree of self-* behavior to ensure fault tolerance or context awareness.
Service infrastructures are the technical foundation on which research within the other JRAs is based:
Adaptation and Monitoring of services demands for a strong infrastructural background (e.g., service monitoring is only feasible in a well-defined end-to-end service environment). Additionally, service adaptation has some clear requirements towards discovery of alternative services. Monitoring is also an essential functionality for establishing self-* services. Also, self-* and adaptability has much in common.
The same is also true for adaptable Service Compositions. Adapting compositions demands for a well-defined service infrastructure and mature service discovery mechanisms. Furthermore, Engineering and Design develops methodologies and techniques which are used to implement service infrastructures themselves, and introduces the life-cycle of services that is also relevant for autonomic services).