19-03-2014, 03:23 PM
SCENE: A Service Composition Execution Environment Supporting Dynamic Changes Disciplined Through Rules
A Service Composition.pdf (Size: 414.2 KB / Downloads: 24)
Abstract
Service compositions are created by exploiting existing component
services that are, in general, out of the control of the composition developer.
The challenge nowadays is to make such compositions able to dynamically
reconfigure themselves in order to address the cases when the component
services do not behave as expected and when the execution context changes.
We argue that the problem has to be tackled at two levels: on the one side, the
runtime platform should be flexible enough to support the selection of
alternative services, the negotiation of their service level agreements, and the
partial replanning of a composition. On the other side, the language used to
develop the composition should support the designer in defining the constraints
and conditions that regulate selection, negotiation, and replanning actions at
runtime. In this paper we present the SCENE platform that partially addresses
the above issues by offering a language for composition design that extends the
standard BPEL language with rules used to guide the execution of binding and
re-binding self-reconfiguration operations.
Introduction
Service-oriented approaches are capturing a growing interest not only as a mean for
business to business integration, but also as the possible reference architecture to
support the development of systems exposing autonomic and dynamically changing
behavior [11]. Typical examples are the cases of applications able to reconfigure
themselves and to contact different services depending on contextual information
(e.g., the location of the final user), on QoS levels, on possible failures happening
while a service is running, and so on.
The dynamic nature of such systems precludes the a-priori identification of the
services defining the system and demands for run-time discovery and selection of
such services. In particular, we argue that discovery and selection have to be
supported at two different levels. On one side, the runtime platform executing systems
built by composing services should be flexible enough to support the discovery and
selection of alternative services, and the negotiation of their service level agreements.
The SCENE Composition Language
The constituents of a service composition in the SCENE composition language are
shown in Fig. 2. A Service Composition can exploit various Service Roles and can be
described by various Service Process Views each one describing the composition from
the view point of a specific role in the composition.
The service process view is composed of four main elements: a Process that in our
language is described using BPEL, one or more Rule Sets and Constraints and
Preferences to control the self-reconfiguration of the composition at runtime, and a
Data Model that includes all data types that are shared between the process and the
rules. These include the structure of the input and output data used by the process part to
communicate with the external services.
The process is composed of Activities that can be implemented as Requests to
external services. These requests can be served by some service roles. At runtime, the
rules are used to realize the Bindings between service requests and the concrete
implementation of service roles (Concrete Services).
Evaluation
We have developed some case studies to test the flexibility of the approach and its
applicability to concrete cases. The examples we have considered so far have been
defined within the SeCSE consortium and concern automotive and telecom domains.
The example presented in Section 2 is one of these. For that example, besides the BPEL
process sketched in Fig. 1, we have defined 15 rules. Some of the rules are those we
have presented in the previous sections. The others have a similar structure and are not
reported here for the sake of space.
Conclusion
In this paper we have focused on the definition of proper linguistic and infrastructural
mechanisms to support self-configuration of a service composition.
As future work we plan to extend the language and the platform to support
dynamic negotiation of service level agreements with component services and to drive
dynamic changes in the structure of the composition itself.
We also need to continue with the evaluation of the approach for what concern
both performances and usability.