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.
-
Issues related to self-optimization and
self-healing is introduced
in a numerical simulation example in grid computing.
-
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.
-
Dynamic adaptation, further self-optimization, self-healing and self-configuration
issues are introduced in a mobile environment via multimedia and
transactional examples.
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).
