Mixing Workflows and Components to Support Evolving Services

Françoise Baude, Virginie Legrand, Ludovic Henrio, Paul Naoumenko INRIA Sophia-Antipolis, I3S, Université de Nice Sophia-Antipolis, CNRS

2004 route des Lucioles – B.P. 93 – 06902 Sophia-Antipolis Cedex, France {First.Last}@inria.fr

Heiko Pfeffer, Louay Bassbouss, David Linner Technische Universität Berlin

Franklinstr. 28/29, 10587 Berlin, Germany {louay.bassbouss | david.linner | heiko.pfeffer}@tu-berlin.de

Abstract

Composite distributed services involve local and remote services that get orchestrated according to a specific business logic. This logic can be programmed applying a traditional general-purpose programming language, but is generally described using a workflow language that coordinates a set of given services; this service set constitutes the architectural basis of the resulting compound service. For the sake of adaptability, dynamic evolution is needed. For this, the services involved in the composition, or the composition itself might have to evolve. In other words evolution can occur both at the business logic level (workflow level) and the global architecture level. This paper presents a solution to ease such evolution for compound distributed services. More precisely our proposal enables the evolution of both the business logic and the underlying architecture.

In particular, we propose to rely on a distributed software component model to represent, and thus easily manage the set of local or remote software entities (services) involved in the composition. In our proposal, composite services are represented in a model that combines the use of a distributed and hierarchical software component model (the Grid Component Model standardized at ETSI), and a new timed-automata based workflow language. This combination makes explicit the separation between functional (logic) and non-functional (management i.e. architecture level) concerns, and as a consequence this approach should really help in defining the required and various sorts of evolution procedures in the context of compound services.

Keywords Workflows, GCM, Components, Service Evolution, Service Composition 1. INTRODUCTION 1.1. General context Composing services and allowing services and their composition to evolve at runtime is crucial for most of distributed applications. Indeed, as soon as the execution environment may change in an unplanned manner, services must be able to adapt to those changes. In a more challenging manner, one could also expect services to evolve automatically in order to provide better quality of services, matching new user requirements, or providing users with unforeseen functionalities.

The context of the research work presented in this paper is the BIONETS European project, aiming at bio-inspired evolution of services and network protocols. In this context, we came out with a new composition model, integrating both workflow-oriented orchestration and component-oriented composition. Additionally, our composition model features high evolution and adaptation capacities. In this paper, we present this new model, the architecture it features, and the evolution capabilities it enables. The originality and value-added of our model comes from the mixing -- and thus implied respective advantages -- of two service composition models, each specially focusing on some aspects of service composition: the workflow based composition approach mainly manipulates timed sequences of service invocations, whereas the component based approach focuses on the dependencies between ports of the different services forming a compound service. A consequence and a particularity of this mixed composition model is that, as each of the model focuses on evolution, the compound model benefits from their respective evolution capabilities. Consequently, our model is particularly targeted at evolution of services and of their composition. 1.2. Viewpoint and Motivations

Components or Services A first crucial aspect of the positioning of our work is the use of a component model as the service composition paradigm. The reasons for this choice are that components can easily encapsulate services, and that component-based architectures are better structured, so easier to adapt than pure service-based service oriented architectures. This point of view is already adopted by SCA where the needed services are seen as components within the resulting Service-Oriented Architectures [21]. Compared to more traditional ways of composing services together, a component encapsulating a service makes explicit its dependencies towards other services (components). Consequently, a component composition model permits a complete and very structured view of the complete application’s architecture that involves services. Components and workflows A component can be implemented and then published and accessed using different technologies and protocols. It can for instance be written in Java, and accessible through the Java RMI protocol; it can be written in a script-like or XML-based language, as BPEL, and accessible through the use of Web Services or REST protocols, etc. So, this versatility regarding the used technology is a plus, in that, in a Service Oriented Architecture built using components, it will be easy to mix heterogeneous components regarding their supporting technologies. In this paper, we specifically concentrate on the case where a service underlying logic can be specified as a flow of activities expressed in a workflow language (as e.g. BPEL). At runtime, one or several workflow engines should be associated to the execution of those flows. To take full advantage of the evolution capabilities gained by the reliance on a component-based approach, we also consider the workflow engine and every dependency to a service as components in the resulting executable architecture. Thus, from an execution and service specification outlook, components form the framework to assemble services along a spatial viewpoint, whereas workflows are convenient to define individual services and to coordinate different service invocations, along a rather temporal viewpoint. This clear separation of roles also corresponds to the view adopted by SCA-BPEL [21]. In other words, we champion the idea that component-based composition overlays service composition expressed by the mean of orchestration languages..

A two-level evolution The main novelty of this paper is to promote the mixing of workflow and component paradigms in order to fully enable evolution of complex applications. Evolution can thus occur at each level of the composition. Evolution of the service workflow can take some time to converge but can achieve new functionalities and adapt to entirely unforeseen changes in the environment, whereas evolution of the corresponding component composition is much faster but can only rely on service interface description to replace a service by an equivalent one. This component-level evolution does not entail any computation, however it is a powerful mechanism as a service can be replaced by a composition of several others, simply connecting their interfaces. As a consequence, component level evolution will converge much more rapidly. However, workflow evolution can bring new services into play by their coordination capacity, and achieve a much richer evolution. To summarize, evolution at the component composition level allows fast coarse grained evolution, like using a new service or adding a new component in the composition, whereas evolution at the workflow composition-level entails fine-grained evolution, allowing the functionality provided by a service to evolve, providing the same service in a different way, or evolving the offered service functionality. Consider a simple example illustrating the necessity of the two levels of evolution. Suppose one has a service invoking several other services, and one of those required services fails or disappears.

• Upon detection of failure, the first and simplest way to evolve is to find an equivalent component fulfilling the same service as the one that disappeared; evolution is technically easy to achieve as the binding between services can be changed dynamically. A new equivalent service is used instead of the faulty one. At the workflow level this is totally invisible.

• If no replacement service is found, then the overall service has to be fulfilled in a different manner; for this we rely on workflow evolution. At the workflow level, the evolution allows the composition to be done in a different manner, bypassing the faulty service, or requiring different ones (e.g. several services composed and coordinated accordingly); a new workflow is then computed that can replace the previous one and still provide the overall service. The new way of fulfilling the service can offer a better or worse quality of service, and several attempts might be necessary to fulfil the original service satisfactorily.

Our workflow model To allow evolution of a workflow graph, we need to rely on a workflow model that is sufficiently abstract to be independent of concrete used services. But, more importantly, we must devise some evolution mechanisms that can drive the evolution in such a way that the resulting workflow offers a similar functionality as the initial one. One important contribution of this paper consists in relying on genetic operators, and on an associated simulation tool to effectively make the workflow graph evolves in a suitable way. Our component model The component-based view corresponding to a compound service must also be evolvable. For this, we must rely on a component model that enables runtime reconfiguration of the bindings between components, modification of the set of involved components (its content). Hierarchical composition consists in building components from several other components; the resulting composite component has the status of first-class component. This naturally enhances the

reusability of components. The resulting SOA becomes multi-level and hierarchical. If moreover, components inside a composite can be distributed on several machines, a composite component grasps an effective representation of the physical location of each of the involved services. Compared to a flat architecture, a hierarchical one can be useful for instance to clearly delimitate and delegate management responsibilities. We will base our work upon a component model that is known to fulfil all those requirements: the Grid Component Model (GCM). Synopsis The underlying motivation of the research presented in this paper is to point up a natural workflow and component mixing. Yet, we believe this mixing to be promising with respect to effective evolution of SOAs. We embed a workflow in a distributed, dynamically reconfigurable and hierarchical component (see e.g. Figure 1). Workflow and component models are complementary. On one hand, workflows benefit from the reconfiguration ability of components, and thus can be dynamically modified at runtime (e.g. when an involved service is no more available and must be replaced). On the other hand, composition in time brings to users of component models the convenience of expressing the orchestration logic of the involved services using a workflow language. Moreover, the composition in time logic is evolvable, resulting in a up-to-date workflow plus its corresponding component architecture. Such a dynamic architecture is a mean to support the evolution problems raised by the dynamic availability of services or the dynamic adaptation of semantically equivalent services. Moreover, it would also allow the end user to design (e.g. thanks to some graphical tools) a service composition in a unified manner by specifying which are the needed service components and when they must be invoked.

Figure 1: Example of a composite component giving a high-level view of a composite service at runtime. The orchestration logic, given by the “ABC” graph, is embedded and interpreted by the component labeled “Workflow Engine”. The other components represent links to concrete services needed to run the graph. In the following, after a deep comparison with related works in Section 2, we present in Section 3, the workflow-based composition paradigm and how evolution of workflows can occur. Then we present the resulting component-based composition integrating such workflow in Section 4. Finally Section 5 presents an implementation of a common platform mixing the two composition paradigms. And we conclude in Section 6.

2. STATE OF THE ART AND RELATED WORK 2.1. Service composition and evolution in the context of workflows SOA and Web Services together with their various models for describing large-scale business processes are the success story of modern service composition approaches [5]. Here, service composition languages enable the manual creation of service compositions through graphic user interfaces to model a workflow of Web Services [2], which specifies the execution order of the single involved services. The most prominent language is the Business Process Modeling Language (BPEL), originating from the conflation of Microsoft’s block-oriented XLANG [15] and IBM’s graph-based Web-Service Flow Language (WSFL) [13]. BPEL has become an OASIS Web Service standard in 2002, referred to as WS-BPEL version 2.0, formerly BPEL4WS [10][12]. However, there are various other composition languages, featuring advantages and disadvantages within different use cases; van der Aalst et al. thus assent that there isn’t yet a holistically accepted standard for Web Service Composition [17]. For instance, ebXML containing the Business Process Specification Schema (BPSS) [16] represents an alternative composition language that is rarely used within Europe and the US, but is common in Asia. Inside workflow composition models that focus on the business logic and external services orchestration, solutions to offer the capability of evolution or adaptation exist. Those solutions generally start from a standard and well adopted workflow language to express the business logic, and then they focus on adding advanced capabilities to the interpretation engine so that external services can easily be replaced at will. Depending on the level of detail of semantic descriptions attached to the Web Services itself, a partially dynamic adaptation of service compositions to respond to service failures or changing environmental contexts is obtained by dynamically binding appropriate Web Services to service blueprints within a service composition plan during runtime [1]. Multiple semantic descriptions such as DAML-S [18] and OWL-S have been proposed within the scope of Semantic Web activities, enabling the dynamic discovery of Web Services and automatic integration of service into a service composition. Especially for mobile devices, more lightweight descriptions have been proposed in order to reduce the computation complexity entailed by semantic reasoning processes [14]. Another solution is promoted for instance by the SeCSE language and associated SCENE framework [24][25]. This approach is based on the idea to provide separated - yet coherently integrated - tools to describe the composition logic and the adaptation logic. The composition logic is expressed in the usual BPEL language, but it does not necessarily contain concrete bindings to specific services. The adaptation logic is expressed in terms of constraints that delimit the adaptation capability within certain ranges. Adaptation rules operationally define what needs to be done in the various cases, and, of course, have to be compatible with the constraints and have to take the preferences of the administrator into account. Zhang et al. [20] propose a policy specification language and respective hierarchical policy model to incorporate the user’s context during the binding phase of a service composition’s creation and thereby also provide a solution to adapt services based on a changing user context. Again, this solution focuses on an optimal replacement of single services, but cannot provide an alternative solution in case the service cannot be replaced by exactly one other service. Alternative sort of approaches use genetic algorithms to find an optimal binding for all abstract services of a service composition with respect to non-functional properties. For instance, Canfora et al. [19] have used genetic operators to enable a QoS-aware creation of service compositions by selecting the single

services within the composition based on their quality. However, they did not revise the structure of the service composition itself and thus didn’t address the problem of related semantic service descriptions. [26] also describes a genetic-based approach to find an optimal binding for all abstracts services of a service composition with respect to non-functional properties (e.g. QoS parameters). On the contrary, a few other approaches aim at enabling the adaptation of the business logic, i.e. orchestration or composition in time itself, as e.g. [27]. However, the automatic creation of appropriate service descriptions for automatically generated service compositions is challenging. The work we present in this paper (and more particularly in Section 3), also pertains to this challenging approach; indeed, we strongly believe that the transformation of the business logic is an important and complex matter that requires to rely on more sophisticated orchestration languages than the usual ones. We thus aim at modifying existing service compositions in order to produce different service orchestrations but still equivalent with regard to their functionality, differing only in their structure. The semantic description of the origin service composition can then be overtaken for the new one, since the service compositions are providing the same functionality. To achieve this kind of adaptability of service compositions, we propose to restructure the given service composition internally. Thus, in case a service fails or is no longer available, we could check and try to solve its replacement by another single service at the engine level, adopting approaches like [24][25]. However, we claim that it is worth to research an alternative solution by relying on the associated component-based architecture. Indeed, we believe that engine-level abstract to concrete service mapping might be limited, and that relying on general-purpose reconfiguration and adaptation capabilities offered by component models gives us more possibilities and flexibility to enact the modification and adaptation to the context of the compound service architecture. In case a simple one-to-one replacement is not possible, i.e. if there isn’t a service that can overtake the failed service’s functionality completely, we aim at evolving the service composition through the application of genetic operators towards a composition that provides the same functionality, but realizes the failed part of the composition differently. Thus, a service composition may evolve in a way that a failed service A is replaced by a combination of services B and C. 2.2. Service composition and evolution in the context of component models Inside component models, adaptation is guaranteed by reconfiguration of the component composition. Reconfigurability is guaranteed for most models (like Fractal [33], GCM [36], CCM [34], and CCA [39]) by the presence at runtime of a component container. As soon as component manipulation is allowed by some control structure, a reconfiguration API or language can be designed. Fractal and GCM are particularly well suited for component adaptability, because they come with high reconfiguration capabilities, even a specific language for expressing component reconfiguration and adaptation has been designed [37][38]. Adaptation offered by a component model is more general than the one provided by approaches like e.g. [24][25]. This is due to the fact that, with a component approach we are able to manage a more profound, i.e. architectural, modification of a compound service. For example, we can effectively add or remove external services (i.e. components) at runtime if needed. Additionally, the component-based view of compound services is recursive (any involved component can itself correspond to a compound service). The benefit is that the designer, or a manager of the resulting

service-oriented architecture can thus get a scalable (because hierarchical) yet complete view of all involved services; this view can even be an up-to-date one in case evolution occurs, because, evolution at the component-level effectively translates in modifying the component architecture. Moreover, as one can choose to rely on a very open and extensible software component model (as the one we are relying upon in section 4), it becomes possible for a manager to inject personalized adaptation rules that could address not only abstract to concrete service mapping but anything related to the architectural organisation of the used services. For instance, the management layer could be in charge of inserting personalized adapters in the architecture, so that additional operations are executed before and after using a specific service component (those operations could be logging, security checks, or parameter transformation). 2.3. Service composition using workflows and components Workflows or orchestration [28] usually encompass what is called composition in time; that is, a workflow provides a composition plan focusing on the selection of services involved in the composition, and especially, on the order in which these services are invoked. A component-based architecture usually provides a composition plan focusing on expressing ports (or interface) dependencies: for each component, for each port required by this component, the composition specifies which provided port from another component ports should be connected to fulfil the overall service. Such a composition paradigm is sometimes called composition in space. Services can be seen as components; indeed, a service can be wrapped in a component, and so manipulated as a component, the SCA industrial specification [21] calls such a component a "service component". Mixing workflow and component models is natural, and quite easy from a technological point of view [22][23]. A workflow language can be used to implement the core of any component, as it is proposed in particular by the SCA-BPEL part of the SCA specification [21]; a component concretizes as an envelope that can be put around any software. This envelope can generally be configured so that entry points for invoking the software can be made along any needed technology (the most popular one being web services). Those entry points define the interfaces provided by the component. In [29], the author sketches the advantages of combining Component based Software Engineering (CBSE) and Service Oriented Architecture, illustrating the SCA approach. The presented and exemplified architecture shows that an SCA component implemented in BPEL can orchestrate other SCA components (through their provided interfaces). Most interesting is the fact that such mixing has the potential to offer the advantages of the two worlds. [22] and [32] are among the few attempts to explicit this fact. In particular, [22] mostly (and only) insists on the reuse pattern capability. In short [22] highlights the two following facts. First, a BPEL workflow expressing a specific business logic regarding an orchestration of services can be considered as a component, and as a consequence, can serve as one building block reusable as any other component when assembling a new component. Second, as BPEL engines are usually tied to a specific technology for invoking external services (this technology is Web Services in the case of BPEL4WS, and external services are represented as partner links within the workflow), software that is not accessible through this technology can not easily be involved in orchestrations. Consequently, wrapping software into components and offering the required entry point through a proxy that translates an e.g. Web Service invocation into any other required specific technology enables to reuse any existing software. However, only a few arguments have been made so far [22] in order to further highlight the advantages of such a

mixing, behind obvious reusability. It is the purpose of this paper to further develop one of those advantages, i.e. the one which pertains to the evolution capability of the resulting composition of services. Indeed, we will show in the sequel that mixing workflow and component composition models allows the resulting composition to evolve in both the time and space composition dimensions. Obviously, it will also make it clear that a more advanced evolution capability in each of the two dimensions leads to a more evolvable resulting composition. The ICENI Framework [30][31] proposes a component architecture where components are annotated with a workflow formalism. The objectives of the framework are to schedule efficiently the components, and to place them on a set of resources. Thanks to the annotations, the framework infers a so-called Execution Plan, allowing to execute the components in a given order on an optimal choice about the set of resources. In [32], the authors present STCM, a spatio-temporal model based on GCM and AGWL (Abstract Grid Workflow Language), supporting both composition in time and composition in space. In this approach, a GCM component is extended with temporal ports and also extended to the concept of task. Although these works provide some good arguments to combine time and space, they are very tied to a particular workflow language (i.e. AGWL for STCM or ASKALON for ICENI) and can only orchestrate static internal tasks. The work we present in this paper aims at providing a generic solution and framework to dynamically orchestrate both internal and external services. 3. STRUCTURAL EXECUTION OF SERVICE COMPOSITIONS BY WORKFLOWS 3.1. MOTIVATION Workflow languages have a long history, which started with the notion of process languages [3] to define the execution order of multiple processes within a complex system. With the emerging role of Service Oriented Architectures (SOA) and their related notion of composability to realize complex business processes out of Web Services, workflow languages have been adapted to serve as control structure for these large-scale processes [17]. However, workflow languages (and business processes in general) are designed for long-lasting transactions that are not subjected to continuous changes. Within the scope of the BIONETS project, we were facing a network topology that is continuously changing and thus requires rapid adaptation and modification of services to their environmental context. Here, special emphasis is put on evolvable services that are capable of a long-term adaptation of their internal structure to provide novel service-functionality and to ameliorate services with regard to their non-functional property. We have chosen timed automata as the underlying concept to express such composed evolvable services because of several reasons. First, automata theory is a well-researched formal method to model composed services and is therefore independent from the exact syntax and semantics of novel composition languages itself, such that the derived concepts can be applied to nearly every modern workflow language in place today. Moreover, automata theory provides rich links to research in the area of abstract algebra, which promises to achieve evolution on automata level through modifications on a corresponding algebraic level [4]. In addition, a continuously changing environment implies challenges with regard to service availability and recovery. Especially in composed applications, the chances are high that one or more service become unavailable and have to be replaced during runtime. Therefore, time is considered as an elementary part of a service composition’s behaviour, which means that the replacement of a service can be triggered by a timer, which is part of the service composition

itself. This model allows us to consider service compositions as self-sustaining with regard to their ability to adapt to environmental context changes. It has already been shown that timed automata and time Petri nets are equivalent [5]. In fact, it was even proved that timed automata prossesses are (although they are equivalent with timed Petri nets in terms of timed language acceptance) strictly more expressive in terms of weak timed bisimilarity, such that Petri nets have to be extended by the concept of priorities to obtain the same expressiveness as timed automata [6]. Therefore, all results stemming from this thesis, centered on a timed automaton-based model, can be overtaken for models based on Petri nets. Moreover, all common workflow languages for the description of business processes can be mapped to this formal model. Within our work, we thus focus on the evolution of service compositions expressed by an automata based workflow model. We already presented first results with regard to the application of genetic operators to modify the structure of workflow based service compositions [7] as well as results on the adaptation of workflows during runtime [8]. In this paper, our main goal is to restructure the internal constitution of service composition based on the set of currently available services and their respective service composition in order to come up with service compositions that are functionally equivalent or similar to the origin one, but are a better fit to the current environmental context with regard to their non-functional properties. Moreover, this modification gives us multiple ways to express a certain behaviour by means of a service composition, such as a higher probability of finding a suitable service composition that is only built upon the set of currently available services. This process of evolving the workflows structure may be initiated by either an internal or external trigger. In the former case, a timeout mechanism expressed within the workflow itself initiates the replacement of a certain services and thus can lead to the restructuring of the workflow graph. In the latter case, the component model has failed to replace a certain services one-on-one by another, such that the workflow has to be evolved towards a solution that expresses the same behaviour with a different arrangement of services. Here, the trigger comes from the component system. In section 3.2, we introduce a formal model for workflows that represent a service composition. Within the scope of section 3.3, we show how this model can serve as a basis for achieving evolution on service composition level. 3.2. MODELING SERVICE COMPOSITIONS WITH WORKFLOWS Within this section, we introduce a runtime for service compositions. A service composition is defined by (1) a workflow graph specifying the execution order of the single services, (2) a dataflow graph defining the data passage between the services, and (3) a set of abstract services based on the input, output, precondition and effect (IOPE) parameters of this composition. The formal definition of the two control graphs as well as the respective service model has already been defined in [9]; we repeat the definition of the workflow graph for convenience. A service composition is defined as a 2-tuple <Ɵ, Ω> consisting of a workflow and a dataflow graph, which operate on a given set of services. Definition 3.1 (Workflow Graph): A workflow graph Ɵ is a timed automaton, where

• Ʃ is a finite alphabet. The alphabet represents the actions which are identified by the single services within the service composition.

• S is a finite set of locations defining the service composition’s current state,

• s0 ϵ S are the initial locations defining the initial state of the service composition, • X is a set of clocks, • I:S→C(χ) assigns invariants to locations, restricting the system in the amount of time it is

allowed to remain in the current state, and • is the set of transitions, denoting the execution of a

service (represented by an action α). The passage of a transition (and thus the execution of a service) thereby depends on whether the according guard is met.

Definition 3.2 (Dataflow Graph): A dataflow graph Ω is a labeled directed graph Ω={N, P, E}, where

• N is a final set of labeled nodes, which is equivalent to the set of locations S held in the according workflow graph Ɵ

• P is a set of port mappings represented by 2-tuples p = (p1; p2) indicating the passage of the output from port p1 to the input port p2, and

• E ⊆ N × P × N is a final set of labeled directed transitions.

Each location represents the data generated by the execution of action αi; we therefore label a node with d(αi) indicating the output data from action αi. If a transition is passed within a workflow graph Ɵ entailing the execution of action αi, all outgoing transitions from location d(αi) within the according dataflow graph are passed. A transition passage d(αi) ��,  � � d(αj) within Ω effectuates that the output at port pm from action αi is redirected to input port pn of action αj in case action αi is executed within Ɵ.

A workflow graph thus consists of a set of locations that are connected by labeled directed transitions. The workflow graph can operate on a set of variables and clocks, where the latter ones are real-valued variables that possess the special property that they always progress together. States can be labeled with so-called invariants, which are Boolean formulas operating on clocks. For instance, an expression like x<3 would ensure, that the automata can only remain in the according location as long as the clock x is smaller than 3. The transitions are annotated with guards, actions, and a set of clocks. A guard is a propositional logical formula that can operate on all available clocks and variables and has to evaluate to a Boolean. In case the guard of a transition is true, the transition can be passed to enter the next location, otherwise not. The set of clocks identifies the clocks that are set back to zero when a transition is passed. An action is identified with a service invocation, i.e. in case a transition is passed, the annotated service is invoked. Note that the action only corresponds to the invocation itself, i.e. reaching the next location from the current one does not consume time nor does it assure that the service has already finished its execution. This invocation style allows us to reinterpret the semantics of timed automata without changing their classic meaning. In general, every automaton is precisely within one state at every point in time, where the state is given by the current location and the current allocation of all variables. Thereby, parallelism cannot be expressed by a single automaton per se. However, by identifying an action with a service invocation (instead of relating it with a service execution that already has generated the respective output when reaching the next location), parallelism can be expressed by a sequence of states, where the passage of the next transition is not restricted by guards. More details on the realization of the timed automata’s semantics enabling parallel execution of

services can be found in [9]; it is not discussed in greater detail here, since it does not impact the evolution of service compositions itself. 3.3. EVOLUTIONARY SERVICE COMPOSITIONS

3.3.1. Objectives The executability of a service composition depends on the availability and executability of its constituting services. The set of available services for the execution of a composition is constituted not only by the services on the node where the execution request was issued, but also by the available services of nodes currently forming a node island with the node where the request was issued. Since some services may not be movable between nodes or the node where the service request was issued does not provide sufficient capabilities for the execution of any service, remote execution of services is required. However, the existence of islands of nodes is always only temporary. Thus, the unavailability of a service referenced by a service composition is quite likely. The challenge can be addressed by the similarity of service compositions. Two services A and B may provide similar functions, such that a service composition that references service A may also work fine if service B is executed instead of service A. Thus, if A is unavailable, B can be used instead. Even particular combinations of services (i.e. sub-graphs of a composition) are replaceable by other combinations of services. This fact is utilized in our algorithm for graph-based genetic programming. For a particular service composition, the algorithm searches for other service compositions that behave similarly, but build on a different set of services. The objective of this work is to guarantee the executability of a service composition with best effort. 3.3.2. Genetic Operators for Service Composition Evolution The goal of our simulation with Genetic Programming (GP) on service composition graphs centers on the practical investigation of the applicability of GP for the solution of search problems in the area of service-oriented software. Within [7], we introduced algorithms for the application of two genetic operators on service composition graphs, a cross-over operator and a mutation operator. In addition to the choice for order and frequency for their application genetic operators are the decisive means of genetic programming. Based on the definition of service composition given in section 3.2, we are able to define rules for the graph structure, ameliorating the algorithm for the crossover algorithm. In [7], the cross-over operator basically selects a random number of services (i.e. edges representing services in the graph) from both compositions and swaps the selected services between the graphs. Therefore, some services need to be duplicated or others arranged for parallel execution. Moreover, the recovery of the data graphs for both compositions is expensive and often fails (although intentionally). The new cross-over algorithm does not select arbitrary services, but rather a complete sub-graph. The size of the selected sub-graph is chosen by random, but within a pre-defined range. At the periphery of the selected sub-graph all connections to the rest of the graph that will be broken in case of removal of the sub-graph are analyzed and used to form a signature for the set rule violations. This is done for all composition graphs of a generation the cross-over shall be applied to. However, the actual swapping of sub-graphs between any pair of composition graphs is just executed if the sub-graph signatures are equal. This proceeding may require running the selection procedure several times until appropriate sub-graph for an exchange are found, but guarantees from the beginning that the resulting service compositions will be executable.

Figure 2: Exemplary analyzes of signature for rule violations

Figure 2 exemplarily shows the identification of problems that may result from the removal of the marked sub-graph (pale red circle) for the remaining graph and the sub-graph itself. The problems A-E can be categorized as follows:

A Critical for sub-graph, missing input halts execution; uncritical for remaining graph, unassigned output has no direct effect on execution stability

B Critical for sub-graph, missing input halts execution; uncritical for remaining graph, unassigned output has no direct effect on execution stability

C Critical for sub-graph, services of sub-graph cannot be reached on execution; uncritical for remaining graph, all service can be reached when being executed

D Uncritical for sub-graph, end of execution flow as a valid option; uncritical for remaining graph, all service can still be reached on execution

E Uncritical for sub-graph, unassigned output has no direct effect on execution stability; critical for remaining graph, missing input halts execution

The new algorithm for the cross-over operator that is utilized for simulation works with information as in the above points. During the cross-over process the algorithm searches for compensations of the critical problems and tries to avoid uncritical problems at best effort. 3.3.3. Simulation The simulation is built on eight steps as depicted in Figure 3, while the last four steps are repeated in a loop. In the first step a reference service composition Cref is created. The reference service composition will serve as orientation for the genetic algorithm. Cref is the simulation correspondent to a real-world service composition that was successfully executed before and is no longer executable because of the absence of one or multiple constituting services. In the

second step, a number of input parameter vectors is created and summarized as vector Vi. In the third step the Cref is executed on Vi to derive a number of vectors that comprise the respective outputs and gains for each vector of input parameters in Vi. This vector of output vectors is summarized as Vo. Later on Vo will serve as reference for the fitness evaluation. In step 4 an initial set of executable service compositions Γzero is created. These service compositions correspond to other executable service compositions on the same node. In step 5 the current service composition Γk is executed with the input parameter vectors in Vi. In step 6 the distance of the execution results for all Cn to Vo is calculated as a measure of similarity between all Cn with Cref. In step 7 this distance is utilized to select the m service compositions closest Cref. If a predefined threshold is reached, i.e. a service composition is found that behaves with a certain tolerance similar to Cref the simulation is terminated. Otherwise all m selected service composition in Γk are exposed to the genetic operators and a new ‘generation’ Γk+1 is created. After step 8 the simulation algorithm is continued with step 5.

Figure 3: Simulation Steps

3.3.4. Evaluation and Results In general, the simulations showed the applicability of genetic algorithms on service composition graphs to generate structurally different variations. For most parameterization of the simulation the best approximation of an existing service composition based on the remaining services could be found within few generations (less than ten). Nonetheless, no simulation under realistic parameterization resulted in a distance between reference service composition and generated service composition of zero. The reason can probably be searched in the heuristics for the selection of generated service compositions, which may need improvement. Currently the selection is only based on the fitness, while only the fittest (closest distance to reference service composition) of a generation are selected to replace the less fit service compositions of the preceded generation. However, the reference service composition can be approximated. The following figures show which parameters had the biggest impact on the results of a simulation run and generation these result could be first observed.

Figure 4: Lower plot is a result of a simulation run with less service compositions in generation zero than in the first plot. The best distance value in the simulation with less service composition in generation zero is reached in a later generation than in simulations with more service composition in the generation zero.

Each plot in Figure 4 depicts a blue and a red graph. The blue graph shows how the average distance of all service compositions in one generation developed from generation to generation. The red graph depicts for each generation the service composition with the closest distance to the reference service composition in terms of execution results. The distance here denotes the norm of the vector that comprises the single distances for all reference (training) data. Both simulations depicted in Figure 4 were executed over 50 generations. The parameter investigated for the plot of Figure 4 was the number of service compositions in generation zero and respectively following generations. The results show that the higher number of service compositions per generation result in the need for less generation to achieve a good service composition with sufficient similarity to the reference composition.

Figure 5: Impact of number of gains on the distance between service compositions

Figure 5 shows that a higher number of gains within the origin service composition considerably affects the initial distance between the origin service composition and the ones generated through the application of genetic operators. However, when comparing the results given in Figure 4 and Figure 5, we can observe that the algorithm is capable to make up for this slow start within approximately 10 iterations. Thus, the developed algorithms enable the functional approximation of a service composition that lost executability due to the disappearance of constituting services. For this evolved composition, the semantic descriptions can be overtaken such that it can be automatically discovered during upcoming service discovery procedures and does not have to be created again. 4. GCM-BASED SPATIO-TEMPORAL COMPOSITIONS 4.1. The Grid Component Model (GCM) Among the existing component models, we chose to focus on GCM that allows component system to be evolvable and hierarchically designed. The Grid Component Model (GCM) [1] is a component model defined by the European Network of Excellence CoreGrid and implemented by the EU project GridCOMP. GCM extends the Fractal Component Model [2] to address Grid concerns. From Fractal, GCM inherits a hierarchical structure with strong separation of concerns between functional and non-functional behaviours, including life-cycle, introspection, and configuration management. In GCM, each component can be a composite one, which is composed of other components interconnected with bindings; or a primitive one that directly encapsulate business code. Components have server interfaces that receive invocations, and client interfaces that emit invocations; a binding always connects a client to a server interface. Large scale distributed applications usually have numerous similar components, so the GCM defines collective interfaces which ease design and implementation of such parallel components by providing synchronisation and distribution capacities. There are two kinds of collective interfaces: multicast (one-to-many) and gathercast (many-to-one). The GCM also allows the component controllers to be designed in the form of components, and benefit from such a design. This enables the autonomic adaptation of the component management. The Architecture Description Language (ADL) of both Fractal and the GCM is an XML-based format that contains both the structural definition of the system components (subcomponents, interfaces and bindings), and some deployment concerns. As it expresses and exposes structure of the system, and gives an API for manipulating the component composition at runtime, the GCM is particularly well adapted to express evolving systems: adaptation of the application is expressed as structural reconfiguration of the component composition. As non-functional concerns are defined as component systems, the component management concerns can also evolve and be reconfigured at runtime. There is a reference implementation of the GCM component model that has been realized using the ProActive middleware (more details are given in section 5). 4.2. General Architecture of a GCM component embedding a Workflow The idea we push forward, is to embed in a GCM composite component one functional component that would be in charge of orchestrating the service composition, acting as a workflow interpreter. This interpreter is in charge of enacting the service graph corresponding to

the composite service. In this section we introduce the general architecture we adopted to map and execute a workflow in a flexible way. 4.2.1. General Approach To fulfill the requirements presented in Section 1, we rely on the GCM, making our model distributable, evolvable and hierarchical. First, we represent each involved orchestrated service by a component. The set of services are then orchestrated thanks to a dedicated component, the Workflow Manager, in charge of interpreting and enacting the orchestration. This component is to be considered as the central point in the composition, in broad terms as the nervous system of the orchestration from which all necessary service orchestration is dictated. The workflow embedded in a GCM component, characterized by an ADL and a service graph thus becomes an entity that is able to execute and reconfigure itself, benefiting from non-functional features like distribution, reconfiguration, or security.

Figure6 : The ABC Orchestration sample graph.

We focus now on the workflow engine interpreting the service graph. An instance of such an engine is illustrated by Figure 7 that interprets the service graph given by Figure6. The composition orchestrates 3 services, A, B and C and implements a function f. Our idea is to put in each composite component, one specific component Workflow Manager in charge of interpreting the service graph. In this simple form, the composite would contain exactly 3 components A, B, C besides the Workflow Manager. As exemplified in Figure 7, the graph is mapped on a GCM component containing two kinds of component: (1) The workflow engine interpreting the graph and (2) The service invokers and adaptors, acting as proxies towards the involved services (i.e. A, B, and C). These two kinds of components are detailed in the next sections. On Figure6, A, B and C are linked together according to a composition in time: the interpretation engine has to invoke A then B and C. This orchestration is translated in Figure 7 by the introduction of a workflow interpreter component (the so-called Workflow Manager component); in the GCM view, components A, B and C are not directly bound together according to the composition in space vision, but indirectly through the Workflow Manager (following the composition in time vision).

Figure 7 : The GCM component corresponding to the sample graph ABC, shown on

Figure6 The ABC Orchestration component offers a non-functional controller allowing the management of the orchestration lifecycle thanks to actions such as deploy, stop, or suspend, a service graph execution, the interface is named fr.inria.gcm.orchestration.OrchestrationController (detailed below) /** An interface describing the actions to perform on a process definition **/ public interface fr.inria.gcm.orchestration.OrchestrationController {

/** Stops the process **/ public void stop ();

/** Starts the process **/ public void start(); /** Suspends the process **/ public void suspend (); /** Deploys the orchestration on the Workflow Engine **/ public void deploy (Object workflow); } When the deploy() method of the OrchestrationController interface is invoked, the workflow definition is effectively deployed on the workflow engine and a Service_Invoker_Adaptor component is created for each involved service. The workflow is enacted using the function f(), which is the functional and business method of the interface of the component, it is stopped

using the stop() method. 4.2.2. The Workflow Manager Component Figure 8 shows the elements composing the Workflow Manager component. It is composed of two elements, the Process Manager and the Engine. The Process Manager component is in charge of processing the workflow to create the corresponding service adaptors, and of effectively controlling the workflow deployment and execution. The Engine Component is in charge of effectively enacting the workflow, and enables actions such as start, stop, or suspend to be performed. It is the component and not the workflow engine that interacts effectively with the involved services.

Figure 8 : The Workflow Manager composite component

The implementation of the interpretation engine can be either a dedicated and embedded workflow engine, like the Timed Automaton interpretation engine in the case of this paper, or a component that delegates the workflow interpretation to an external engine (as we successfully did with the Active BPEL engine for instance); more details on this wrapping are given in Section 5. 4.2.3. Service Invoker and Adaptor One of the main advantages of using a hierarchical and reconfigurable component model is that intermediate components can be introduced easily, and added or reconfigured at runtime. These components can be simple proxies (as shown in Figure 9 ), bound to external services, as well as more sophisticated adapters collaborating to successfully achieve the service invocation (as shown in Figure 10).

Figure 9: A simple Invoker and adaptor

Figure 10 shows a composition forming a Service Adaptor component. It contains a chain of intermediate components (C1 .. Cp) that can pre-process (resp. post-process) the invocation (resp. reply from) of the actual service. For example, suppose that a service invocation S fails and that the invoker component is dynamically rebound to a semantically equivalent service S’. Suppose additionally that S’ requires a special authentication. The component-based process management system can easily introduce a processing component that will perform the authentication and then call the service.

Figure 10: Example of a complex service invoker and adaptor

This adaptation ability leads naturally to the management of the workflow/component entity according to the context and the available services, offering to the orchestration the ability of being adaptable (i.e. to contextual changes), and ultimately even autonomous. 5. REALIZATION AND EXAMPLE A workflow engine that is capable of executing service compositions as formally introduced in Section 3.2 has been implemented in Java; details can be found in [40]. It exposes a general control interface that implements the primitives start(), suspend(), resume(), and stop() to initiate, halt, resume, and terminate the execution of a given workflow. This interface is accessed by the components to control the general execution of workflows. The evolutionary algorithm discussed in section 3.3 can be triggered by the primitive evolve(wf, sim), where wf denotes a link to the workflow that should be evolved and sim defines the level of similarity the evolved workflow should have compared to the origin one. Here, sim is a real-valued variable between zero and one, where a value of one specifies the equivalence of the two workflows. This degree of similarity is derived within a fitness evaluation procedure that computes the similarity of services compositions with regard to their functional and non-functional properties by means of a fuzzy-logic based model; details on this evaluation technique can be found in [41]. The following of this section presents our approach that combines the two kinds of compositions (spatial and temporal) and then shows the architecture that mixes workflows and components enhancing workflows with added value such as dynamic service binding. This implementation has been realized based on the reference implementation of the GCM: GCM/ProActive. A GCM reference implementation is based on ProActive1[35]. In this implementation, an active object is used to implement each component. As a consequence, this implementation also inherits some constraints and properties w.r.t. the programming model: (i) components 1 http://proactive.inria.fr

communicate by asynchronous method calls with transparent futures: a method call on a server interface adds a request in the server’s queue; (ii) futures (place-holders for request results) allow replies to asynchronous method calls to be sent automatically; (iii) the synchronisation is data-flow oriented, it is called wait-by-necessity: futures can be forwarded to any component in a non-blocking manner, execution is only blocked if the value of a result is needed (accessed) before being received; (iv) there is no shared memory between components; each component is mono-threaded. ProActive middleware also enables the deployment of components on various and heterogeneous architectures. We show first below the integration of the Timed Automata interpretation engine in a GCM component and then show how workflow reconfiguration is enabled. 5.1. Wrapping Timed Automata interpretation engine in a GCM component Figure 11 shows the resulting component corresponding to the ABC orchestration graph taken as example throughout the paper. The Timed Automata interpretation engine is integrated by simply using its corresponding Java classes to implement the generic GCM component that was labeled Engine on the Figure 7. At first, the OrchestrationController.deploy() method has to be invoked to deploy the process in the Timed Automata interpretation engine, and to generate the Invoker_and_Adaptor components corresponding to the involved services. Once the orchestration is deployed, one can use the functional method f() to effectively start the workflow. The Timed Automata component will then invoke A, B, and C according to the workflow it executes.

Figure 11: Architecture of the GCM Component embedding a Workflow

5.2. Managing the dynamicity As previously claimed, the use of a component model to execute workflows enables dynamicity and agility. The component is itself capable to detect if a link to a service S is broken (via the Invoker_and_Adaptor component). These components can be equipped or associated with a mechanism that searches a semantically equivalent service S’ and replaces automatically the link. Nevertheless, the equivalent service might not be found, in that case a more profound workflow

reconfiguration must be achieved. In our approach, the Adaptor_and_Invoker component delegates this task to the Evolution Framework presented in Section 3. A new workflow graph is then computed and has to be re-deployed. To this aim, the Evolution Framework has to invoke first the stop() method to stop the orchestration, then it invokes the deploy() method to send the new graph to the engine. Once the new workflow is deployed, the start() method re-launches the orchestration. Deploying a new workflow definition deletes the obsolete services adaptors and creates the newly required ones. 6. CONCLUSION AND FUTURE PROSPECT In this paper we have shown how to appropriately combine component composition models and workflow composition models, and how this combination can lead to highly evolvable compound service-oriented applications. For this we have designed a framework to integrate a workflow interpretation engine within a component-based platform. Involved services are seen as components that can then be expressed as workflows, programmed (in the common sense, e.g.. in Java), or simply considered as external services (without worrying how they are implemented, deployed and managed). This view leads us to the user point of view expressed on Figure 12. The user composes services (given by letters on the figure) and workflows (represented very schematically by small graphs on the figure). Each workflow is of course different and each delegates some of the processing to services it is bound to. But this allows a recursive view as those bound services can also be expressed as workflows, and can even be the result of a previous composition, i.e. be a composite component including a workflow and the needed services. Moreover, being based on a distributed component model, all involved components can be deployed by the component platform itself or just externally used (no management and control is possible on a service offered by a tier; however, our component-based design view still encompass it). The great advantage, we believe, of our approach is that the composition view expressed by the figure is not only the one used and obtained at design time, but it corresponds also closely to the effective architecture that exists at runtime. Also, compound services can evolve at runtime in a richer manner than usual workflow or component models alone. Workflows can evolve in a very rich manner, using genetic operators to produce new workflows as shown in 3.3. Components and services links can evolve by changing dynamically the bindings between services, but also the set of services composing a service can evolve by adding or removing sub-services of a service; these reconfiguration capacities are directly provided by the use of GCM.

Figure 12: A complex compound application: the user point of view

Among the future works, we identify engineering tasks for better integration of workflow and components, especially from the execution platform side. Indeed our proposal suggests a very integrated view from the user point of view but, at runtime, the two models only communicate via a well-defined control API. This has the advantage to show that our approach applies for any component and workflow models but it might hinder performance. For example, in our current implementation, threads are used within the Timed Automaton interpretation engine to trigger a service invocation; at the component level, a ProActive/GCM thread is also activated to effectively manage the invocation. Merging the two threads is obviously a performance optimization worth to be worked on if targeting an industrial-level usage. From a more research-oriented point of view, the proposed solution suggests further improvements in the usage we made of the component model. Indeed, the GCM is richly equipped with non-functional capabilities, i.e. control parts of GCM components can themselves be implemented as GCM-based distributed component systems. As a consequence, we could envision refining our proposition taking better advantage of some of the non-functional features of GCM. Indeed, in this paper we presented a solution for combining workflows and components expressing the business logic; but management can also be defined as GCM components and thus as workflows. Such workflows would express different management aspects, such as deployment, and would benefit from the evolution capacities presented in this paper. This would push even further the idea of taking advantage of workflows within component-based models, as some preliminary and recent works have already shown [32][42].

REFERENCES [1] M.H. ter Beek, A. Bucchiarone, and S. Gnesi: "A Survey on Service Composition Approaches: From Industrial Standards to

Formal Methods". Technical Report 2006-TR-15, 2006. [2] OASIS Committee, " Web Services Business Process Execution Language Version 2.0“ March 2006. [Online]. Available:

„http://docs.oasis-open.org/wsbpel/2.0/wsbpel-specification-draft.html” [Accessed: October, 2007]. [3] Dick, A. J., Hull, M. E., and Jackson, K. 2005. Specifying process and measuring progress in terms of information state. J.

Syst. Softw. 76, 3 (Jun. 2005), 311-322. [4] P. Dini, and D. Schreckling , "Notes on abstract algebra and logic: Towards their application to cell biology and security" in

in Proc. of DEST, Thailand, Feb. 2008 [5] Haar, S.; Simonot-Lion, F.; Kaiser, L. & Toussaint, J. Equivalence of Timed State Machines and safe Time Petri Nets.

Proceedings of WODES 2002, Zaragoza, 2002, 119-126. [6] Berthomieu, B.; Peres, F. & Vernadat, F. Bridging the Gap Between Timed Automata and Bounded Time Petri Nets.

Lecture Notes in Computer Science : Formal Modeling and Analysis of Timed Systems, Volume 4202, 2006, 2006, 82-97 [7] David Linner, Heiko Pfeffer, and Stephan Steglich: A genetic algorithm for the adaptation of service compositions.

Proceedings of Workshop on Technologies for Situated and Autonomic Communications (SAC) at 2nd International Conference on Bio-Inspired Models of Network, Information, and Computing Systems (BIONETICS 2007), Budapest, Hungary, December 10-12th, 2007, ISBN: 978-963-9799-05-9

[8] H. Pfeffer, D. Linner, and S. Steglich: Dynamic Adaptation of Workflow Based Service Compositions, In Proceedings of the 4th international Conference on intelligent Computing: Advanced intelligent Computing theories and Applications - with Aspects of theoretical and Methodological Issues (Shanghai, China, September 15 - 18, 2008). D. Huang, D. C. Wunsch, D. S. Levine, and K. Jo, Eds. Lecture Notes In Computer Science, vol. 5226. Springer-Verlag, Berlin, Heidelberg, 763-774, 2008.

[9] H. Pfeffer, D. Linner, and S. Steglich: Modeling and Controlling Dynamic Service Compositions, In Proceedings of the 2008 the Third international Multi-Conference on Computing in the Global information Technology (Iccgi 2008) - Volume 00 (July 27 - August 01, 2008). ICCGI. IEEE Computer Society, Washington, DC, 210-216, 2008.

[10] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana. Business Process Execution Language for Web Services, Version 1.1, May 2003. [Online]. Available: http://www.ibm.com/developerworks/library/specification/ws-bpel/. [Accessed: November, 2007].

[11] A. Bucchiarone and S. Gnesi. A Survey on Services Composition Languages and Models. In A. Bertolino and A. Polini, editors, in Proceedings of International Workshop on Web Services Modeling and Testing (WS-MaTe2006), pages 51–63, Palermo, Sicily, ITALY, June 9th 2006.

[12] F. Curbera, Y. Goland, J. Klein, F. Leymann, D. Roller, S. Thatte, and S. Weerawarana. Business Process Execution Language for Web Services (Version 1.0), July 2002.

[13] F. Leymann. Web Service Flow Language (WSFL 1.0). In IBM, May 2001. [14] H. Pfeffer, D. Linner, C. Jacob, and S. Steglich. Towards Light-weight Semantic Descriptions for Decentralized Service-

oriented Systems. In Proceedings of the 1st IEEE International Conference on Semantic Computing (ICSC 2007), volume CD-ROM, Irvine, California, USA, 17-19 September 2007.

[15] S. Thatte. XLANG - Web Services for Business Process Design, 2001. [16] UNCEFACT and OASIS. ebXML Business Process Specification Schema Version 1.0.1, 2001. [17] W.M.P. van der Aalst. Don't go with the flow: Web services composition standards exposed. to appear. IEEE Intelligent

Systems, Jan/Feb 2003. Electronically accessible from http://www.tm.tue.nl/it/research/patterns/ieeewebflow.pdf. [18] A. Ankolekar, M. Burstein, J. R. Hobbs, O. Lassila, D. Martin, D. McDermott, S. A. McIlraith, S. Narayanan, M. Paolucci,

T. Payne, and K. Sycara. DAML-S: Web Service Description for the Semantic Web. In The Semantic Web - ISWC 2002: First International Semantic Web Conference, Sardinia, Italy, June 2002.

[19] G. Canfora, M. Di Penta, R. Esposito, and M. L. Villani. An approach for QoS-aware service composition based on genetic algorithms. In GECCO ’05: Proceedings of the 2005 Conference on Genetic and Evolutionary Computation, pages 1069–1075, New York, NY, USA, 2005. ACM.

[20] Baopeng Zhang , Yuanchun Shi , and Xin Xiao, A Policy-Driven Service Composition Method for Adaptation in Pervasive Computing Environment, The Computer Journal Advance Access published on December 21, 2007.

[21] BEA,IBM, Interface21, IONA, Oracle, SAP, Siebel, Sybase: SCA White Paper, Building Systems using a Service Oriented Architecture, http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications.

[22] Zhile Zou, Zhenhua Duan, Building Business Processes or Assembling Service Components: Reuse Services with BPEL4WS and SCA, Fourth IEEE European Conference on Web Services (ECOWS'06), pp.138-147, 2006

[23] Philippe Collet, Thierry Coupaye, Herve Chang, Lionel Seinturier, Guillaume Dufrene, Components and Services: A Marriage of Reason, Research Report RR-2007-17 CNRS I3S Laboratory, Sophia-Antipolis, France

[24] SeCSE (Service Centric System Engineering) Project. http://www.secse-project.eu. [25] Di Penta, M., Esposito, R., Villani, M. L., Codato, R., Colombo, M., and Di Nitto, E. WS Binder: a framework to enable

dynamic binding of composite web services. In Proceedings of the 2006 international Workshop on Service-Oriented Software Engineering (SOSE '06). ACM Press, 2006

[26] C. Gao, M. Cai, H. Chen, QoS-aware Service Composition Based on Tree-Coded Genetic Algorithm, International Conference on Computer Software and Applications Conference, 2007, COMPSAC 2007, pp.361-367

[27] Yuhong Yan; Yong Liang; Han Liang, Composing Business Processes with Partial Observable Problem Space in Web Services Environments, International Conference on Web Services, 2006. ICWS '06. pp.541-548

[28] Peltz, C. Web Services Orchestration and Choreography Computer, IEEE Computer Society, 2003, 36, 46-52 [29] Krämer, B. Component meets service: what does the mongrel look like?, Innovations in Systems and Software Engineering,

Springer, 2008, 4, 385-394 [30] Mayer, A. McGough, S.; Furmento, N.; Lee, W.; Newhouse, S. & Darlington, J. ICENI dataflow and workflow:

Composition and scheduling in space and time UK e-Science All Hands Meeting, 2003, 634 [31] McGough, S.; Young, L.; Afzal, A.; Newhouse, S. & Darlington, J. Workflow enactment in ICENI UK e-Science All Hands

Meeting, 2004, 894-900 [32] Bouziane, H.; Perez, C. & Priol, T. A software component model with spatial and temporal compositions for grid

infrastructures Lecture Notes in Computer Science, Springer, 2008, 5168, 698-708, EuroPar’08 [33] E. Bruneton, T. Coupaye, M. Leclercq, V. Quéma, and J.-B. Stefani. The Fractal Component Model and Its Support in Java .

Software Practice and Experience, special issue on Experiences with Auto-adaptive and Reconfigurable Systems. 36(11-12), 2006.

[34] CORBA Component Model, V3.0, CCM homepage: http://www.omg.org/technology/documents/formal/components.htm, 2005

[35] L.Baduel, F.Baude, D. Caromel, A. Contes, F. Huet, M. Morel, and R. Quilici. Grid Computing: Software Environments and Tools, chapter Programming, Composing, Deploying for the Grid (chapter 9).Springer,2006.ISBN: 978-1-85233-998-2.

[36] F. Baude, D. Caromel, C. Dalmasso, M. Danelutto, V. Getov, L. Henrio, and C. Pérez GCM: A grid extension for Fractal autonomous distributed components/. Annals of Telecommunications 64(1), 5-24, 2009 http://www.springerlink.com/openurl.asp?genre=article&id=doi:10.1007/s1224300800688&sa%20campaign=Email/ACE/Paginated

[37] M. Rivera, L. Henrio, B. Bannour, A Reconfiguration Framework for Distributed Components , SINTER Workshop Software Integration and Evolution @ Runtime, ACM,

[38] P.-C. David and T. Ledoux. Safe dynamic reconfigurations of Fractal Architectures with FScript. In Proceeding of Fractal CBSE Workshop, Nantes, France, 2006.

[39] The Common Component Architecture (CCA) Forum home page, 2005. http://www.cca-forum.org/. [40] H. Pfeffer, L. Bassbouss, and S. Steglich: Structured Service Composition Execution for Mobile Web Applications, In

proceedings of the 12th IEEE International Workshop on Future Trends of Distributed Computing Systems (FTDCS 2008), Kunming, China, 2008.

[41] Heiko Pfeffer, Steffen Krüssel, and Stephan Steglich: Fuzzy Service Composition Evaluation in Distributed Environments, In Proceedings of The International Conference on Advances in Human-oriented and Personalized Mechanisms, Technologies, and Services (I-CENTRIC 2008), Sliema, Malta, October 2008, IEEE Computer Society, Conference Publishing Services (CPS), Los Alamitos, California, pp. 335-342, ISBN 978-0-7695-3371-1

[42] M. Lienhardt, A. Schmitt, J.-B. Stefani. Oz/K: A Kernel Language for Component-Based Open Programming, in: 6th ACM International Conference on Generative Programming and Component Engineering (GPCE), ACM Press, 2007.