flexible web services

1

Flexible Web Services

D. Ardagna, A. Avenali, L. Baresi, C. Batini, D. Berardi, D. Bianchini,C. Cappiello, M. Comuzzi, V. De Antonellis, F. De Rosa, M. D. Desideri,C. Francalanci, Leporelli, Matteucci, A. Maurino, M. Mecella, M. Melchiori,S. Modafferi, E. Mussi, B. Pernici, P. Plebani, and D. Presenza

1.1 Introduction

Cooperative information systems support the interaction between organiza-tions to reach common goals (De Michelis et al., 1997). In the Service OrientedComputing (SOC) paradigm, Web Services are fundamental elements for de-veloping applications (Dayal, 2001). SOC involves different layers and roles, asdescribed by the extended Service Oriented Architecture (SOA) (Papazoglouand Georgakopoulos 2003, Chung et al. 2003). The most popular service tech-nologies and standards, including SOAP and XML Protocol, WSDL, WSCL,WSCI, BPEL4WS, ebXML, and others provide a basic substrate for wiringtogether the different services constituting a distributed application (Alonsoet. al 2004). But, as argued also by (Yang et al., 2002, Hull et al., 2003), suchstandards lack both (i) of a formal semantics allowing to assess interestingproperties of the cooperative applications and (ii) of precise methodologiesand guidelines on their use and application in software development, (iii)management platforms to guarantee the global system behavior. The Seman-tic Web community, specifically the OWL-S Coalition (Smith et al. 2002) isdefining a specific ontology for Web Services, in order to be able to composethem in automatic way. Moreover, recent results and algorithms for automaticcomposition can be found in (Bultan et al. 2003) and (Berardi et al. 2003,Berardi et al. 2004). Comparable efforts have been done in WSMF/WSMO(Web Service Modeling Framework) (Fensel and Bussler 2002), which definesa fully-fledged modeling framework for describing the various aspects relatedto web services. Several systems and approaches has been proposed to sup-port inter-organization cooperative processes, by extending traditional work-flow management system technology to distributed, Internet-based scenarios:CROSSFLOW (Grefen et al. 2000) , WISE (Lazcano et al. 2000), MENTOR-LITE (Shegalov et al. 2001), E-ADOME (Chiu et al. 2000). e-FLOW (Casatiand Shan 2001) has been one of the first research prototypes addressing theissues of specifying, enacting and monitoring composite e-Services; other pro-posals include SELFSERV (Benatallah et al. 2003) in which services can be

2

composed and executed in a decentralized way and the PARIDE framework(Mecella et al., 2002) to support flexible e-service composition and invocation.In the METEOR-S Project, a framework for the annotation of Web Serviceswith quality of service parameters is proposed, in order to select the best avail-able components from a set of available components [?], to realize adaptiveworkflows.

Emergent workflow systems, e.g., (Jorgensen 2001) represent a differentapproach to static and adaptive workflow systems targeting processes withstrong requirements for adaptation to the context during process execution,coping with new future information appliances and a multitude of servicesacross the network. Awareness mechanisms are linked to emergent workflowsystems. Approaches such as ServiceFlow (Wetzel and Klischewski 2002) pointto the need for such flexible solutions. For the more general use of mobile ap-plications, it is also important to be able to adapt these systems to the user athand, thus making a case for simple user models to guide the adaptation. Ba-navar and Bernstein (Banavar and Bernstein 2002) highlight the importanceof semantic modelling in this respect.

A research issue is the specification of quality of service for flexible WebServices (Marchetti et al. 2004). Quality of service has been the topic of severalresearches and standardization efforts crossing distinct communities: the weband web-service community (Mani and Magarajan 2002), (Ran 2003), (Jin etal. 2002), (Zeng et al. 2004), the networking and internetworking communities(ITU 2001), the middleware community (Zinky et al. 1997). Even if differentin nature, the objectives of these efforts were at least intended (i) to identifythe relevant measurable characteristics affecting the quality of the servicesprovided by a given “object” (e.g., a web-service, a network infrastructure, amiddleware platform) and (ii) to define means (e.g. architectures, paradigms,components, and protocols) to implement an “object” whose values of its mea-surable characteristics satisfy some quantitative constraints. The definition ofservice level agreements in WSLA (Keller and Ludwig 2002) is based on theactual quality of service perceived by users, (ii) the clear and unambiguousassignment of responsibilities for enforcing each quality parameter value (andto possibly define the corresponding penalties in case of unsatisfactory lev-els). (Marchetti et al. 2004) propose a multilayer model to evaluate quality ofservices in a dynamically evolving environment.

1.2 The MAIS approach to web services

In the MAIS project, web service adaptive execution based on quality of ser-vice parameters is proposed, focusing on the dynamic selection selection ofservices from an extended UDDI registry based on functional and quality pa-rameters and dynamic service substitution mechanisms (Bianchini et al. 2005,Maurino et al. 2004).

1 Flexible Web Services 3

Processes are realized composing web services offered by different providers.As mentioned in Chapter ??, a web service is characterized both by functionalaspects (i.e., provided capabilities) and by non functional aspects (i.e., qualityof service levels), and therefore, several providers might offer the same servicewith different quality of service levels.

A MAIS process describes the composition of services as a flexible webservice, where service selection, and in some case dynamic composition, maybe performed at run time, during process execution. Flexible web service ex-ecution depends on the context of execution and the quality of service of thecomponents services. The MAIS approach allows both to dynamically selector substitute services and the dynamic composition of services in a high per-formance process orchestration environment.

In the present following, we first present the MAIS service model, thenwe discuss flexible service provisioning both in the MAIS-P and in the micro-MAIS environments.

1.3 The MAIS service model

We distinguish among the following types of services:

• concrete web service: a concrete service has associated quality of serviceparameters, binding information and a corresponding abstract service def-inition.

• flexible web service: a service composed and orchestrated by the MAISarchitecture according to its abstract service definition and its quality ofservice constraints, with a MAIS and a process definition in terms of theMAIS Process Language.

In the present section, first we present the MAIS Process Language (MAIS-PL) for the definition of flexible services, then we discuss the functionalitiesprovided by the MAIS-P architecture described in Chapter ?? to supportflexible service execution.

MAIS Service Description Language (MAIS-SDL)

• abstract service interface: the WSDL [9] web service definition languageis used to specify a porttype, with its operations and input and outputmessages.

• service behavior: A service is characterized by the set of messages it canexchange, and possibly by constraints on the possible conversations: in factusing a service typically involves performing sequences of operations in aparticular order (conversations); during a conversation, the service clienttypically chooses the next operation to invoke (on the basis of previousresults, etc.) among the ones that the service allows at that point. The

4

behavior of a service is meant as the set of all the possible conversations theservice supports [14]. A transition system is a formal tool for representingand reasoning on service behavior. A transition system is a tuple T =<A,S, S0, δ, F > where A is the set of operations/actions, S is the set ofstates, S0 ⊆ S is the set of initial states, δ ⊆ S × A× S is the transitionrelation and F ⊆ S is the set of final states. A transition system is verysimilar to an automata, but puts more emphasis on the possible alternativeoperations invocable at a certain point: an automata defines sets of runs(or traces or strings), i.e., (finite) length sequences of operations/actions,whereas in a transition system the modeling focus is in the alternatives“encountered” during runs, as they represent clients “choice points” [54,14].

• quality of service: quality of service specification may be associated to theservice or to its operations. Quality may be associated only to concreteservices. Quality of service dimensions for a given type of service are de-fined by the service providers community for that type of service [17]. Inaddition, in service specification, the quality of service dimensions pre-sented in Chapter ?? and listed in Appendix 2 may be used to specifyconstraints which are not domain dependent. The WSOL language [57] isused to define concrete service offerings at different levels. For each qual-ity dimension it is possible to specify if the quality is negotiable and theallowed negotiation types (offer request, different types of auctions). Pricemay be indicated as negotiable (this aspect will be discussed at the end ofSection ??.

• service ontology: services are classified in categories (as in UDDI registries)and each abstract service may be classified in one or more categories andrelated to other abstract services with generalization and composition re-lationships.An example is presented in Fig. 1.1: different abstract flight reservationservices provide different operations and are inserted in a service ontol-ogy for travel services. Concrete services may have a QoS specificationassociated.

• binding information: binding is defined in terms of the channel of invoca-tion. In particular, the most relevant information is the adopted protocolfor service invocation(e.g., HTTP or SMTP). Binding is described as inWSDL for concrete services.

Both abstract services, concrete services, and flexible services are publishedin an extended UDDI [56] MAIS Service Registry. The MAIS Registry allowsretrieving services by example, specifying functional (service name, requiredoperations, categories) and non-functional (QoS) properties.

MAIS Process Language (MAIS-PL)

MAIS processes are defined using the abstract part of the BPEL (BusinessProcess Execution Language) process specification language [1]; this choice


Registry: MAIS E-service ontology

� � � � � � � �

� � � � � � � � �

QoS

QoS

QoS

QoS

QoS

QoS

QoS

E-Service Ontology

Fig. 1.1. MAIS service description

makes the MAIS-PL compatible with current BPEL orchestration engines.Source-target links are not considered in the realization, since they allow goto-like execution flows for which the semantics is not precisely defined and it isnot possible to evaluate global execution properties.

The BPEL file is associated with a number of annotations which provideinformation for realizing a flexible web service, allowing dynamic selection andsubstitution of services as described below.

The MAIS Process Language allows the definition of flexible processes interms of the following elements (see Fig. 1.2):

• MAIS-SDL: the MAIS-SDL is used to define the characteristics of abstractservices which are invoked in the process composition.

• quality constraints: quality constraints may be specified on the process oron a subset of the composed services. The MPEC language (MAIS Pro-cesses Constraints Language) is an XML-based language designed in thecontext of the MAIS project with the purpose to express QoS constraints.For instance, in the example a global and a local constraint (on servicehotel.reservation) are expressed on the cost quality parameter.

6

Invoke hotel.reservation

Invoke train.reservation

Quality constraints:

cost <1000

Hotel.reservation.cost<600

Preferred:

-ACMEHotels

-ItalianHotels

Negotiate:

- lowest price (offer request)

Invoke flight.reservation

not late lateProbability=0.8 Probability=0.2

Fig. 1.2. MAIS-PL Example

• selection constraints: preferred concrete services may be associated to ab-stract services (e.g. ACMEHotels and ItalianHotels in the figure).

• probability of executing a given execution path: for optimizing service se-lection, it is useful to take into consideration information about the prob-ability of possible executions. This is particularly important when cyclesand alternative execution paths are present. A probability of executionis associated to switches in the flow, and cycles are associated with themaximum number of expected iterations, and possibly with a probabil-ity of execution the ith iteration. Such information may be derived fromexecution logs.

• negotiation: negotiation preferences may be associated to each service in-vocation activity.

The flexible process is specified by the process provider, which providesannotations to the process. Such annotations, however, may also be enrichedin the service request phase, taking into account user preferences, additionalconstraints, either explicitly formulated or imposed by the execution context.


1.4 MAIS-P

In the MAIS-P (MAIS Provider) architecture, the full potential of MAIS webservice dynamic selection, negotiation, and mediation are exploited. First,we will illustrate service publication and selection from a Service Registry.We discuss optimization of service selection in composed services, then, weillustrate flexible invocation mechanisms during process execution.

1.4.1 Web service publication and selection

MAIS-P realizes a typical Service Oriented Architecture (SOA) and the MAISRegistry holds the Service Broker role. UDDI, the best known service registrynowadays available, allows only keyword-based searching methods. For thisreason, UDDI often delivers results unuseful in real scenarios where automaticsearch, high precision, and high recall are mandatory.

The MAIS Registry aims at extending current UDDI Registry implementa-tions considering both at publication and retrieval time the e-Service semanticaspects, too. Abstract services listed in composed service processes need notto correspond exactly to services stored in the registry. As shown below, theMAIS service registry provides functionalities for selecting services similar toa given MAIS-SDL description. Exploiting the model introduced in the pre-vious section and the matchmaking mechanisms discussed in the following,the MAIS Registry is able to group the published services according to theirfunctional similarity. The same matchmaking mechanisms are also used byMAIS Registry to support retrieval methods based on a query-by-exampleapproach. In this way, the MAIS Registry users are able to look for a servicesubmitting to it the set of required functionalities.

The advantages of such an approach are manifold. First of all, MAIS Reg-istry supports the designer during the definition of the processes which arecomposed by abstract services. Secondarily, the MAIS Registry can be usedindependently of the rest of MAIS-P as a typical service registry providingenhanced retrieval functionalities.

Both service publication and retrieval functionalities provided by MAISRegistry are based on a matchmaking functionality to evaluate how much aservice description matches with another one. We present two different ap-proaches which are used during service publication and retrieval: the first oneis based on a deductive reasoning process on service semantic descriptions,while the second one on a semantic similarity analysis of the terms used inservice descriptors. Both approaches rely on a domain dependent ontology,used to conceptualize domain knowledge with a commonly accepted vocab-ulary supplied by the domain expert, completed with a pre-existing, domainindependent basic ontology, such as WordNet [30].

8

The deductive approach to service matching

The deduction-based matchmaking is based on reasoning supported by do-main ontological knowledge and allows for recognizing different kinds of matchamong service descriptions. We formalize service descriptions by means of theSHOIN (D+) Description Logic that can be easily translated into the OWL-DL semantic web language. A service is formally described as a conjunction ofconcepts representing respectively a service category and one or more serviceoperations with I/O parameters. Semantic descriptions of abstract servicesare organized in a service ontology according to generalization/specializationhierarchies and composition relationships.

Matching between a service request R and a service advertisement S isbased on the satisfaction in the domain ontology of semantic relationships be-tween concepts corresponding to elements in the service descriptors. Followingcurrent directions in the literature [15], we consider several kinds of match,that can be intuitively described as follows:

• pre-filtering, if categories of R and S are the same or are related in anygeneralization hierarchy in the domain ontology, then the other kinds ofmatch are checked, otherwise the match fails;

• exact match, to denote that S and R have the same capabilities, that is,they have names of operations, input parameters and output parametersthat are equivalent in the domain ontology;

• plug-in match, to denote that S offers at least the capabilities of R, that is,the operations in R can be mapped into operations of S and, in particular,their names, input parameters and output parameters are related in anygeneralization hierarchy in the domain ontology;

• subsume match, to denote that R offers at least the capabilities of S, likein plug-in match, but with the roles of R and S exchanged;

• intersection match, to denote that S and R have some common operationsand some common I/O parameters, that is, some pairs of operations andsome pairs of parameters respectively are related in any generalizationhierarchy in the domain ontology;

• mismatch, otherwise.

The proposed deductive approach ensures a relevant requirement, that isthe matching flexibility, since it would be unrealistic to expect only exactmatch between the request and the advertisement as emphasized in [41].

The similarity-based approach to service matching

The similarity-based matchmaking aims at measuring the similarity degreeamong two services by analyzing the terminological relationships in the do-main ontology (e.g., hyperonomy, synonymy) between the terms used in theservice descriptors. In particular we can state that two terms have affinity onthe basis of existence of a terminological relationships path between them in


the domain ontology. The similarity between two services Sa and Sb is definedby the Global similarity coefficient (GSim) defined as a composition of twoother similarity coefficients, i.e. Entity-based similarity coefficient (ESim) andFunctionality-based similarity coefficient (FSim) [16]:

GSim(Sa,Sb) = w1 ·NormESim(Sa,Sb) + w2 ·NormFSim(Sa,Sb) ∈ [0, 1] (1.1)

NormESim and NormFSim are respectively the values of ESim and FSim

normalized to the range [0, 1]. In more detail, ESim considers all the I/O pa-rameters defined in the service descriptor and provides a measure of theiroverall similarity, independently from the operation to which a particular pa-rameter is associated. In this way, ESim measures how much two services arebased on the same information set.

On the other side, FSim performs a similarity analysis considering in moredetail the operations (their names and corresponding I/O parameters) thatservices are able to perform and its value reflects how much two services per-form the same functionalities. In this case, each operation in Sa is comparedwith all the operations in Sb in order to identify which is the operation inSb more similar to the considered operation in Sa. Such a comparison is per-formed considering the affinity between the operation names and the affinitybetween the information set involved, i.e., the I/O parameters.

Weights w1 and w2, with w1, w2 ∈ [0, 1] and w1+w2 = 1, are introduced toassess the relevance of each kind of similarity in computing the GSim. The useof weights in GSim is motivated by the need of flexible comparison strategies.

Service retrieval process

In the retrieval process, the deduction-based approach is used to classify thematch between the desired service R (defined by a set of requested function-alities) and available abstract services Sa into one of the five kinds of matchillustrated before. Successively, similarity evaluation can be exploited to fur-ther refine and quantify the functional similarity between R and Sa, accordingto the following rules:

• if exact or plug-in match occurs, from the request viewpoint the abstractservice provides completely the required functionalities, so GSim(R,Sa) isset to 1 (full similarity) without computing the similarity coefficients;

• if mismatch occurs, GSim(R,Sa) is directly set to zero;• if subsume or intersection match occurs, the abstract service fulfills the

request only partially and similarity coefficients are computed to quan-tify how much the abstract service satisfies the request; in this case,GSim(R,Sa) ∈ (0, 1).

Only available services for which the GSim(R,Sa) is equal or greater thana given threshold in ∈ [0, 1] are selected and ranked with respect to the GSim

values.

10

Semantic relationships between abstract services can be exploited to makemore efficient the retrieval procedure, according to the following intuition:if an abstract service Sa matches with a given service request R, then alsoabstract services that provide the same capabilities of Sa (as expressed bymeans of semantic relationships) match with R. Then, after abstract servicesthat match with the request are identified, concrete services belonging to thecorresponding compatibility classes in the service ontology are returned asranked list by the retrieval process, by setting the GSim value of each concreteservice to the GSim value of the corresponding abstract service.

Publication process

From the user perspective, the MAIS Registry does not affect the publicationprocess. In this way, service providers who aim at publishing their services inthe MAIS Registry perform the same operations required by UDDI.

Similarity-based matchmaking is involved in the initial service ontologyconstruction and once the registry user submits a publication request. Initially,the service ontology is constructed by considering a initial set of services. Inthis phase, the abstract services are obtained according to a semi-automaticprocedure supervised by a domain expert. Such a procedure, first constructscompatibility classes according to the GSim values of each pair of servicesand a clustering process, then for each class an abstract service is defined bymeans of an integration process of the service interfaces. In the publicationphase of a service to be registered, the service descriptor is compared to thedescriptors of abstract services stored in the service ontology and the similarityis evaluated. According to the obtained GSim values, the registry is able toassign the service to one of the existing compatibility classes. It might happenthat none of the existing abstract service is close enough to the service beingregistered. In this case, the domain expert is in charge of defining a newabstract service and, consequently, a new compatibility class.

1.4.2 Behavioral compatibility and building new services

The Behavioral Composition Engine (BCE in short) is in charge, inside theMAIS-P architecture, (i) of evaluating the substitutability between servicesby specifically considering their behavior, and possibly (ii) of building a newservice to be substituted instead of a previous one, if no substitute service isavailable.

The static compatibility described in the previous section is essential tocheck, but another challenging problem is raised by the very dynamic natureof the service interaction, which is based on an exchange of messages which canbe ordered in complex sequences. This requires reasoning on the behavioralfeatures of services, i.e., to describe and examine the possible sequences ofmessages each of them can send or receive.

The BCE component described in this section focuses only on behavioralaspects, assuming that the names and types of the exchanged messages are


homogenized and that semantic compatibility is guaranteed (by the otherMAIS-P components).

The BCE , given a service to be substituted, and a set of possible candidateservices (chosen among those ones which are statically compatible by theselection function of the Registry):

1. verifies if one service exists among the candidate services, which presents“at least” the same behavior: all the conversations supported by the sub-stituted service should be supported by the new one;

2. if such a verification is positive (a service is found among the candidateones), the new service is returned to the other MAIS-P components;

3. otherwise, the BCE tries to synthesize a new service, composed of vari-ous services among the candidate ones, such that the component services,suitably coordinated by the BCE , realize the same behavior as the sub-stituted service: each conversation supported by the substituted serviceis “simulated” through an appropriate interleaving of invocations to thecomponent services.

4. if the synthesis is successful, such a new “virtual” service is returned as asubstitute;

5. otherwise the substitution is impossible.

In the following, we will refer to (i) the “‘old” service to be substitutedas the substituted service, to (ii) the “new” service to be used instead of theold one as substitute service, either simple or obtained by composition (i.e.,virtual), to (iii) a new virtual service obtained by composition as compositeservice, and (iv) to the services taking part in a composition as componentservices.

By using the transition systems as formal tool to represent the servicebehaviors, the two issues of identify a candidate substitute service providingat least the same behavior of the substituted one, and of synthesizing a newcomposite service, to be used as virtual substitute, out of different componentservices, can be addressed in the following ways:

Identifying a simple substitute. All the possible conversations the sub-stituted service can execute should be available also by the substituteservice. Additional conversations available in the substitute service arenot relevant, as a client of the substituted service would be not able toinvoke them.

Synthesizing a composite substitute. .An interesting relation existing among transition systems is the one ofbisimulation, which intuitively can be considered as the notion of behav-ioral equivalence. Among the various transition systems that are bisimilarto the one describing the service behavior, there is the execution tree,which is the “unfolding” of the (finite) transition system. As discussed indetails in [13, 12], then the issue of composition can be formalized as a la-beling of the execution tree of a desired service (i.e., the virtual substitute

12

to be synthesized) such that each action in the execution tree is labeledby the component service that executes it, and each possible sequenceof actions on the desired service execution tree corresponds to possiblesequences of actions on component service execution trees, suitably inter-leaved. The important result is that such labeled execution tree, if exists,has a finite representation as a transition system, with transitions labeledby an action and the component service performing the action.In [12] is presented a technique that reduce service composition synthesisto satisfability in (deterministic) PDL, and if a composition exists returnsa finite transition system of such a composite service. From that, sometechniques [12] allow to derive an orchestration schema (i.e., a BPELspecification), which by coordinating the component services provides avirtual service substituting the previous one. Such a technique is exptime.We would like to remark that the transition system of the substituted ser-vice is used as input to the synthesis, whose aim is to create a compositeservice “behaviorally equivalent”. As an example, in Figure 1.4 we showtwo possible component services, and the transition system of a compos-ite service that is a substitute of the service shown in Figure ??. Thereader should note that the transition system of the desired service tobe synthesized, and the one of the composite service, are not structurallysimilar.

lstart

readyToPlaysa

(a) Component service 1

lstart

readyToPlayst

(b) Component service 2

l {2}

l {1}

start

readyToPlay_1

st {2}

sa {1}

readyToPlay_2

(c) Composite service

Fig. 1.3. Synthesis of a composite service

The BCE realizes the two previous techniques in an integrated fashion.It receives from the other MAIS-P components (i) the specification of thesubstituted service (consisting both of the WSDL specification and of thebehavioral one), (ii) a set of candidate service specifications (again both theWSDLs and the behaviors) and (iii) a semantic matching among the typesand messages used in the various service specifications. All the services are


then abstracted into the corresponding transition systems (by an AbstractionModule).

First a Simple Substitutability Checker verifies (by trying one after theother) if among the candidate services there is at least one that is directly asubstitute. If there is, (the specification of) such a service is returned to theother MAIS-P components.

If not, the Synthesis Engine takes in input all the transition systems, pro-cesses them according to our composition technique and produces in outputthe transition system of the composite service, where each action is annotatedwith (the identifier of) the component service(s) that executes it. Finally, suchabstract version of the composite service is realized into a BPEL specification(by a Realization Module), that can be executed by an orchestration engine.Therefore such a BPEL specification is returned, in order to be orchestratedthus providing the virtual substitute service.

From an implementation point of view, all the different modules of the BCEare realized as Java components, and offer to the other MAIS-P componentsa web service interface.

1.4.3 Invocation Mechanisms

As illustrated in Fig. ?? in Chapter ??, the MAIS platform invokes web ser-vices through the Concrete Service Invoker. This may used directly to invokeweb services, or by a process orchestrator to execute flexible services (as de-scribed in Sect. 1.4.5). In both cases, the Concrete Service Invoker acts likea message broker. It receives the messages sent by the clients and dispatchesthem to the correct service instance. Clients can be human users or softwareapplications that interact with the MAIS framework using the Platform In-voker. A particular client is the Process Orchestrator, which interacts withthe Concrete Service Invoker during the orchestration of complex concreteservices

If the service invoked by the clients is a concrete service, the task of theConcrete Service Invoker is quite simple, and only consists in dispatchingmessages. In this case, the Concrete Service Invoker receives messages thatare already formatted using the WSDL description of the concrete service thathas to be invoked and, once that the messages are received, sends them to theinstance of the concrete service selected by the client. The same procedure isapplied for the response messages that are generated by the concrete services.

More complex is the invocation of flexible web services, where the ConcreteService Invoker not only has to redirect messages, but it has also to i) selectan instance of a concrete service that can be considered similar to the invokedabstract service (see Sect. 1.4.1), or the concrete services for each componentservice in case the web service is composed, ii) translate the messages format-ted using the WSDL description of the abstract service into messages that canbe interpreted by the selected concrete service (i.e., this messages must suitthe WSDL description of the concrete service), and iii) monitor the invocation

14

to check if the constraints that led to the selection of a particular concreteservice are respected.

The first step, which is called service concretization, is performed usingthe concretization service explained in Sect. 1.4.4, and it is executed when theConcrete Service Invoker receives the first call for flexible web service. TheConcrete Service Invoker retrieves the identifier of the flexible web servicethat has to be invoked, and collects the constraints that have to be respectedduring the concretization phase. These constraints are expressed in terms ofa) functional constraints derived from the WSDL description of the abstractservice, b) behavioral constraints derived from the BPEL description of theflexible service and c) quality of service constraints derived from the executioncontext and stated using the WSOL language. Once that all this informationis collected, the Concrete Service Invoker exploits the Concretizator to re-trieve an ordered list of concrete services that can be invoked in place of theabstract service (or for each abstract service composing the process). The firstelement of the list is the optimum service and, for every concrete service, theConcretizator provides: the WSDL description, which is useful to locate andinvoke the service, the BPEL description, which is useful to understand thebehavior of the service, and the WSOL description, which is useful to monitorthe service during its execution. With this information the Concrete ServiceInvoker is able to execute the second step and invoke the service.

Since the invoked abstract service and the selected concrete service can bedifferent in terms of functional interface and exported behavior, the ConcreteService Invoker needs a wrapping mechanism that allows translating the pa-rameters and adapting the behavior [?]. In the MAIS framework, wrappersare created in a semi-automatic way by the MAIS Registry for every pair ofcompatible services, and allow both translating abstract parameters into con-crete parameters and adapting abstract behavior to concrete behavior. Basedon the response of the Concretizator, the Concrete Service Invoker retrievesthe correct wrapper (or mediator) from the registry and begins to invoke theconcrete service.

During the invocation, the Concrete Service Invoker is also responsibleboth for the monitoring activity and the logging activity. The first activity isperformed using the Reflective Architecture described in the Chap. ??. TheConcrete Service Invoker checks whether the quality of service levels declaredby the selected concrete service are respected and, if not, it performs theconcrete service substitution, which starts with the observation of the currentconstraints. If the actual constraints are equivalent to the constraints used forretrieving the list of concrete services, the Concrete Service Invoker selectsthe next service in the list, retrieves the correspondent wrapper, and proceedswith the invocation. Otherwise, if the constraints are different or if the list isempty, the Concrete Service Invoker performs another service concretizationusing the new values. In the case that the Concrete Service Invoker is unableto substitute an abstract service, even using the concrete service substitution,


it raises an exception towards the module that has requested the abstractservice invacation and stops the invocation.

The logging activity, instead, aims at creating an archive where all theinformation that concerns the interaction between clients and services arestored. This information is useful to analyze historical behavior of both theConcretizator and the Concrete Service Invoker, and can be exploited by theRecommendation Environment to optimize the service selection (see Chapter??).

1.4.4 Concretization and Optimization

The Concretizator module identifies dynamically at run time the best set ofconcrete services such that the QoS for the end user is maximized and globalconstraints are guaranteed.

Web service selection introduces an optimization problem, both consider-ing atomic web services and in particular when composed services are invoked.We assume in MAIS to have a utility function to rank services according touser preferences, and QoS constraints as specified in the previous section.

In the literature, several proposals for selecting concrete services in a pro-cess have been proposed. Some work, e.g., [48], allows specifying constraintsonly locally. If only local constraints are considered, service selection in com-posed services is very simple and can be performed at run time by a greedyapproach which selects the best candidate service suitable for the execution.The work presented in [18, 20, 19] proposes a genetic algorithm for the webservice selection with global constraints. The work is based on the reductionformulas presented in [21] to consider process constructs such as cycles. How-ever, only sub-optimum solutions are identified since tasks specified in cyclesare always assigned to the same Web service.

In the MAIS project, the problem of Web Services composition (WSC)with QoS constraints has been modeled as a mixed integer linear program-ming problem (MILP) as in [59]. We have shown (see [8]) that the problem isNP-hard, since it is equivalent to a Multiple Choice Multiple Dimension Knap-sack problem. In our approach cycles are unfolded according to the maximumnumber of iterations (the maximum number of iterations can be evaluatedfrom past executions by inspecting system logs or can be specified by thecomposite service designer). In the following we assume that an abstract ser-vice specification has a single initial task t1 and a single final task tk. We givethe following definitions:Execution Path. A set of tasks {t1, t2, . . . , tn} such that no ti, tj belong toalternative branches. Execution paths will be denoted by epl. Note that anexecution path can include parallel sequences.Sub path. A sub path of an execution path epl is a sequence of tasks[t1, t2, . . . , tn], ti ∈ epl ∀i, from the begin to the end task which does notcontain any parallel sequence. A sub path will be indexed by m and denotedby spl

m.

16

Critical Path. The critical path of an execution path epl is the sub path whichcorresponds to the highest execution time of the execution path.Execution Plan. An execution plan of an execution path epl is a set of orderedcouples (tj , wsi,j), indicating that task tj included in epl is executed by agiven Web service wsi,j . Execution plans will be indexed by k and denoted asepllk.Global Plan. The global plan is a set of ordered couples (tj , wsi,j), whichassociates every task tj to a given Web service wsi,j and satisfies local andglobal constraints for all execution paths.Note that, the set of execution paths of a composite service identifies all thepossible execution scenarios of the composite service. Authors in [59] sepa-rately optimize each execution path and obtain the global plan by composingseparate solutions according to the frequency of execution. Their approachhas several limitations. First, in the optimization of a single execution paththe fulfillment of availability and response time constraints is guaranteed onlyfor the critical path. Furthermore, the global plan is obtained as the merge ofseparate execution plans. If a task belongs to multiple execution paths, thenthe task is executed by the service identified for the most frequently executedexecution path. In [8] we have shown that in this way the fulfillment of globalconstraints cannot be guaranteed.

Symbol Description

ei,j wsi,j execution time

ai,j wsi,j availability

pi,j price for wsi,j execution

ri,j wsi,j reputation

WSj candidate Web services for task tj

A set of tasks included in the composite servicespecification

Al set of tasks included in the execution path epl

freql frequency of execution for the execution path epl

L number of execution path

Table 1.1. Flexible web service representation for the optimization problem

The WSC problem is multi-objective and a Simple Additive Weighting tech-nique is used to evaluate the overall value of QoS from multiple quality di-mensions. Here we formulate the problem by considering only the followingset of quality dimensions: (a) execution time, (b) availability, (c) price, (d)reputation. The formulation could be easily generalized to other dimensionsaccording to specific application requirements considering all interested QoSdimensions proposed in the MAIS project under the hypothesis that the aggre-gated value for quality dimensions can be evaluated as sum, average, product,min or max of the corresponding quality dimension of component services. Inthe following, the notation reported in Table 1.1 will be adopted. We propose


a formulation of the WSC problem as a global optimization problem, not op-timizing separately each execution path as in [59]. We model the WSC as aMILP by introducing the following decision variables: yi,j is equal to 1 if theWeb service wsi,j executes task tj , 0 otherwise; xj is the start time of tasktj and ej is task tj duration. Every execution path epl is associated with aquality matrix Ql [59]. The score function for the execution path epl is definedas the weighted sum:

score(epl) = w1max Ql

1−exeTimel

max Ql1−min Ql

1+ w2

availl−min Ql2

max Ql2−min Ql

2

+w3max Ql

3−pricel

max Ql3−min Ql

3+ w4

repl−min Ql4

max Ql4−min Ql

4

where wj ∈ [0, 1] represents the weight assigned by the end user to the j-thquality dimension, stored in the end user profile (see Section 1.4.1). Our goalis to maximize the weighted average of the score of execution paths whereweights are given by execution path frequency of execution freql (as the cy-cles maximum number of iterations the frequency of execution of executionpaths is evaluated from log of previous executions). The WSC problem is for-mulated as:P1) max

∑Ll=1 freqlscore(epl)

∑i∈WSj

yi,j = 1; ∀j ∈ A (1.2)

∑i∈WSj

ei,jyi,j = ej ; ∀j ∈ A (1.3)

xk − (ej + xj) ≥ 0; ∀tj → tk (1.4)∑j∈spl

m

ej ≤ exeT imel; ∀splm ∈ epl (1.5)

exeT imel ≤ E; ∀l (1.6)

availl =∏

j∈Al

∏i∈WSj

ayi,j

i,j ; (1.7)

availl ≥ A; ∀l (1.8)

pricel =∑

j∈Al

∑i∈WSj

pi,jyi,j (1.9)

pricel ≤ B; ∀l (1.10)

repl = 1|Al|

∑j∈Al

∑i∈WSj

ri,jyi,j (1.11)

repl ≥ R; ∀l (1.12)

where tj → tk indicates that task tk is a direct successor of tj . Note that,in our formulation the execution time constraint is guaranteed for every subpath (equation 1.5 and 1.6) and not only for critical paths as in [59]. P1) hasinteger variables and a non-linear constraint family (the availability boundsexpressed by equations 1.7 and 1.8). Availability bounds can be linearized byapplying the logarithm function. We have solved P1) by CPLEX 8.0, a state ofthe art integer linear programming solver. The solver identifies the optimumsolution, i.e., for a given composite Web Service, the optimum global planis identified. Finally, for each abstract service, candidate services are rankedaccording to the value they provide to the cost function under the assumption

18

that a single service substitutes the optimum one, while guaranteeing globalconstraints.

The effectiveness of our approach has been tested on a wide set of randomlygenerated instances. The number of tasks has been varied between 7 and 70while the number of candidate Web services per task has been varied between10 and 50. QoS values have been randomly generated according to the valuesreported in the literature. We have compared our solutions with the solutionsprovided by the local optimization approach. For every test case, we first runthe local optimization algorithm. Then, we perform our global optimizationincluding as global constraints the value of the quality dimensions obtainedby the local optimization. Results shows that the global optimization givesbetter results, on average 20-30%, than local optimization. Optimization timevaried between 0.1 and 1.8 sec on a 3 GHz Intel Pentium IV Workstation.

When an abstract composite service is invoked, the Concretizator selectsthe set of candidate services by accessing the MAIS registry. If a candidateservice profile provides negotiation than a Negotiator is invoked.

The Negotiator provides an infrastructure for managing negotiation ofQoS parameters with the service providers [24]. Auction based and bilateralautomated negotiation algorithms are considered. Auctions are exploited toobtain information about the price of candidate service profile, bilateral multi-attribute negotiation protocols are used to negotiate the entire QoS profileof each candidate service. Services express preferences, using WS-Policy, onboth the negotiation protocol features, such as the auction length or number ofparticipants, in which they are able to participate. The strategy to be followedin the negotiation process can be directly provided by service candidates oronly notified to the Negotiator :

• In auctions, services delegate the participation to an auction handler inwhich the service strategy is coded; the already cited policy contains onlya reference to this service that handles the negotiation;

• In bilateral negotiations, the Negotiator provides strategy that can beparameterized by the candidate services, in terms, for instance, of degreeof concession to the counterpart at each turn of the bargaining. Once thestrategies are notified, the Negotiator simulates the negotiation process asa trusted third party.

As stated previously, the Negotiator invocation is optional, and it is performedonly when the candidate services provide policy specifications to enact nego-tiation.

1.4.5 Orchestrator

The main requirement for the MAIS-P orchestrator is the ability to supportthe execution of inter-organizational business processes [38, 45, 34]. Althoughthe need for a distributed execution of business process was already a re-


quirement for inter-organizational workflows it is much more urgent whenconsidering ”web processes” [40]. Indeed web processes require:

• scalability to support execution of a large number of process instances;• efficiency to guarantee acceptable performance in spite of potential prob-

lems due to the network execution environment;• adaptivity: to cope with unpredictable changes of properties of network

environment;

Distributed execution of web processes offer advantages in terms of:

• scalability: execution load can be distributed among different hosts takinginto account actual load of each computational node;

• fault-tolerance: avoiding single point of failure execution of processes canbe moved to alternative computational nodes;

• efficiency: having the possibility to execute processes on different hoststhere are more chances to optimise performances in term of throughput orcompletion time;

• autonomy: each organization contributing to execution of the business pro-cess with their own computational resources has full control on resourcesallocated for the process.

Process and Enactment Model

As explained in Chap. ??, within the MAIS architecture the Orchestratorcomponent is responsible to enact the workflows describing the processes thatcooperating organizations established to follow in order to reach their com-mon goals. The processes enacted by the MAIS Orchestrator are defined bya triple ([A], Wf [A], Qc[A]) where A is the set of activities involved in theprocess, Wf [A] the dependencies on execution of activities in A (workflow)and Qc[A] a set of quality constraints over elements in A. Within the MAIS-P implementation the Wf [A] component is expressed in BPEL4WS [1] andQc[A] as MPEC expressions.

Within the MAIS Orchestrator a pool of execution engines running inparallel and distributed across different hosts carries out the enactment of aMAIS-P process (see Sect. 1.4.5). Each execution engine provides the followingfunctionalities:

• model translation: translates Wf [A] into a control flow graph Cf [B] whereB is the subset of basic activities of A. The edges in Cf [B] representcontrol flow between definitions;

• message dispatching : delivers messages from clients to the right process in-stance according to massage correlation rules defined for BPEL4WS. Sincemessage dispatching may imply process instantiation this functionality isalso responsible for instantiation of new process instances along with theirinitial receive activity instance;

• activity instances acquisition: acquire an activity instance for execution;

20

• activity instances execution: execute an activity instance according to thecorresponding definition;

Interaction between execution engines is based on blackboard architecture.By means of a common blackboard, executions engines share definitions of pro-cesses being executed and states of process instances. Each execution enginecontinuously accesses the blackboard looking for data required by one of thefunctionality listed above. Execution engines also publish on the blackboardintermediate data and further requests resulting from processing of previouslyretrieved requests.

Since each engine has responsibility to retrieve activity instances to exe-cute each engine can rule execution of activity instances according both toavailability of local computational resources and to local business policies.

To reduce access to global blackboard each engine store in a local buffer asubset of the activity definitions. In order to limit the number of definitionsstored locally, engines try to predict which are the most often used.

Prediction is based on estimated value for definitions kept within the localbuffer: the value of a definition is the expected benefit that the action ofkeeping that definition within the buffer gives in terms of reduced number ofaccess to the blackboard.

Each time an activity instance is retrieved from the blackboard the valueof its definition is updated assigning a reward value 1 to it, the values of allother definitions are updated assigning them a reward value 0.

Whenever a new activity is encountered engines decide whether replaceone of the stored definition with the new one. Decision is take according tosome policy such as ε-greedy [55]. The acquisition and execution of activityinstances is done according the following procedure:

1. take an activity instance a from the backboard;2. update values of stored definitions using a;3. update values of stored definitions using a;4. if definition d of a is within the local buffer then goto (6);5. read d from the blackboard;6. if a definition can be discarded from the buffer then replace it with d;7. execute a according to semantic of d returning the next activities to

execute;8. write next activities to the blackboard9. goto (1)

MAIS Orchestrator Architecture

The MAIS Orchestrator is a Multi-Agent System [39, 35]. The architectureintroduced here relies on the WANTS agent framework. The WANTS frame-work is an experimental platform aiming to provide developers with Multi-Agent Systems abstractions like agents, environment sensors, actuators andbehaviours. The main goal of the framework is to facilitate the development


of self-adaptive open applications suitable to run on Wide Area Network tak-ing into account the concepts of self-sufficiency, autonomy, situatedness andembodiement [52].

MAIS-P orchestrator inherits from the WANTS framework the tuple spacecoordination mechanisms [53, 5], which appears suitable to develop applica-tions observing the priciple of parallel loosely coupled processes [32]. Or-chestrator agents run on different hosts and exploit tuple-based coordina-tion mechanisms in order to coordinate their actions. Interactions betweenorchestrator agents are mediated by external marks (tuples) available fromtheir environment. The environment of an agent is the set of tuple-spacesan agent is aware. Interaction among agents is enabled only if they share apart of their environment. In Fig. 1.5 the environment of the agent A1 isTS1, TS2, TS3, TS4, TS5. Interaction between A1 and A2 is possible sincethey are both access to tuple-spaces TS1 and TS5.

TS 2

TS 3 TS

3

TS 4

TS 2

TS 1

TS 5 TS

7

TS 8

TS 6

A1 A2

TS 2

TS 3 TS

3

TS 4

TS 2

TS 1

TS 5 TS

7

TS 8

TS 6

TS 2

TS 3 TS

3

TS 4

TS 2

TS 1

TS 5 TS

7

TS 8

TS 6

A1 A2

Fig. 1.4. Agents with partial overlapping environments

Orchestrator agents discover available tuple-spaces at start-up and wrapthem within location object. Location object monitor requests towards tuple-spaces as well responses for agents. The main purpose of location object is toenable monitoring of QoS of embedded tuple-space service. In current imple-mentation the tuple-space services are provided by JavaSpace services avail-able within the Jini architecture [2].

The orchestrator receive service requests from the rest of the systems bymeans of specialized Web agents playing the role of interface agents. Webagents are created upon reception of a service request. Web agents translateWeb Service requests as tuples published within a location of its environmentand wait for a response from execution agents. Web agents terminate afterreturning result to requesting client.

22

Most of the agents within the community fulfil the role of execution enginedescribed in the previous paragraph. Each agent playing the role of executionengine uses its environment (i.e., the set of known locations) to implementthe blackboard of te execution model introduced in the previous paragraph.The execution engine role is activated whenever an agent retrieves an activityinstance from its environment.

Each agent has a ”vegetative” role aimed to acquisition and maintenanceof computational resources required to carry out other functionalities. Orches-trator agents exploit the MAIS Reflective Architecture to fulfil this role. Thisrole enables agents to adapt their behaviour to changes in available resources.

The individual agent architecture consists of a network of:

• sensors: each sensors maintain a reference to a location and enable agentsto read signal from that location and translate them in internal stimuli forbehaviours. However, some kind of sensors is designed to measure prop-erties (QoS) of their location (e.g round-trip time). Such sensors are thebase to implement actions of the ”vegetative” role (e.g. to produce a stim-ulus when the round trip-time or the writing failure ratio is above somethreshold);

• actuators: like sensors they maintain a reference to a location but theymodify the content of their location upon receiving stimuli from be-haviours: they may produce, remove or transform marks from an agentenvironment. Actuators acting upon the environment may produce a re-ward that is stored within internal environment. All the basic functional-ities of the orchestrator agents introduced in the previous paragraph areimplemented as actuators.

• behaviours: they all run in parallel transforming and propagating internalstimuli to other behaviours and to actuators; examples of behaviour is the”interpret” behaviour controlling the execution of basic activities of theworkflow and the ”move away” controlling selection of alternative locationfor sensors and actuators;

• internal environments: represent both store for marks taken from the en-vironment and reward values produced by actuators. Internal environmentrepresent the base for implementing the value system of the agent.

All the above elements have their own thread of execution and are linked bymeans of weighted links. Propagation of stimuli between behaviours dependsalso on the actual weight of links. From this point of view behaviours act asneurons of an artificial neural network and indeed, the weight of links can beupdated adopting some learning rule.

During their activity orchestrator agents have to coordinate each other inorder to distribute their work among different locations containing activityinstances awaiting to be processed. The coordination strategy adopted for theorchestrator agents is fully distributed controlled by local rules of agents.


1.4.6 Service Cost and Price Models

A Model of Infrastructural Costs

Grid computing is the hardware platform proposed in the literature [46, 37] toprovide web services. Grid scalability and availability are key characteristicsto support high load and high variability of web services [60].

The service providers and their customers often negotiate utility based Ser-vice Level Agreements to determine costs and penalties based on the achievedperformance levels. The service provider needs to manage its resource to max-imize its profits. Utility based optimization approaches are commonly used toprovide load balancing and to obtain the optimal trade-off among job classesfor QoS levels. One main issues of these systems is the high variability of theworkload. The ratio of the peak load to light load for Internet applications ina business day is usually on the order of 300% [23]. Due to such large vari-ations in loads, it is difficult to estimate workload requirements in advance,and worst-case capacity planning is either infeasible or extremely inefficient.

The capacity planning of the hardware platform is performed guarantee-ing that the average utilization of IT resources is lower than 60% [7]. Withvalues of utilization greater that 60%, small variations of throughput wouldcause a substantial growth of response time and, overall, performance wouldbecome unreliable. This empirical rule of thumb, which is commonly appliedin practice [23], has been provided a formal validation. It has been formallydemonstrated that a group of aperiodic tasks will always meet their deadlinesas long as the bottleneck resource utilization is lower than 58% [6].

In order to handle workload variations, many data centers have startedimplementing autonomic computing infrastructures and employ self-managingtechniques for resource allocations [22]. In such systems, resources are dynam-ically allocated among applications considering short-term demand estimates.The goal is to meet the application requirements while adapting the IT archi-tecture to workload variations.

Figure 1.6 shows the hardware architecture of a modern data center. Ap-plications are allocated and de-allocated on demand on heterogeneous serverclusters by the dispatcher. Each server can run under different operatingsystems and instantiate application processes on demand. Operating sys-tem, applications and data are accessed by storage networking technologies(SAN/NAS systems). The main components of the dispatcher [22] include amonitor, a predictor and a resource allocator. The system monitor measuresthe workload and performance metrics of each application, identifies requestsclasses and estimates requests service time. The predictor forecasts systemload conditions from load history. The allocator determines the best systemconfiguration as well as the assignment of applications to servers.

Research results [60] have shown that autonomic techniques allows im-proving service providers revenues by 20-30%. In order to evaluate SP profitswe have developed a simulator which implements dynamic resource allocation.

24

Fig. 1.5. Autonomic Infrastructure Architecture

In the MAIS project the overall profit of the SP includes the revenues andpenalties incurred when QoS guarantees are satisfied or violated. The rev-enue depends on the request response time in a discrete fashion. The revenuegained per request is a step-wise function of the response time and increaseswith the achieved performance level.

The allocator policy is designed to maximize the revenue while balancingthe cost (or energy) of using the resources. The allocator can establish therequest volumes and the scheduling policy at each server. The allocator canalso decide to turn ON or OFF servers depending on the system load. In[60] we have shown that the maximization of service providers revenue is aNP-hard problem and we have developed a meta-heuristic solution based onthe tabu-search algorithm in order to support the evaluation of revenues andcost-benefit analysis for Service Providers.

Results have shown that our resource allocator policy is effective and turn-ing OFF servers improves revenues when the load is light (i.e., the infrastruc-ture utilization is lower than 50%). For higher utilization all servers availableat the data center are turned ON and only the load balancing and schedulingproblems have to be considered. Furthermore, the resource allocator often fa-vors the use of dedicated servers for request classes instead of evenly balancingthe load among servers, since dedicated servers give better performance.

Pricing Models

Two pricing models will be discussed: tariff-based proces and negotiatedprices.


Tariff-based pricesMAIS services are economic goods composed by services provided by physi-

cal resources (such as the network elements dedicated to data transport, thehardware necessary to process data, etc.) and digital information goods (forinstance, data and content), under the supervision and management of soft-ware components. Service providers supply packages of elementary services;a package can contain one or more elementary services, each one either pro-duced by a service provider itself or alternatively bought from other serviceproviders through an intermediate market [44, 4]. Each final user demandsone or more application services. The simple model introduced in this sectionaims to spot out the mechanisms underlying the creation of final prices for thesupply of multi-channel electronic services. In the relevant cases the adoptionof non linear pricing schemes appears suitable [3, 25]. In such cases the amountcharged to a final user for the provisioning of an application service cannotbe derived by a unit price multiplied by a suitable measure of the quantity ofservice provided.

The term tariff refers to a general scheme that allows to define the amountof money paid by a final consumer depending on the different ways a serviceis provided and utilized. A tariff may be represented by a function of a vectorof characteristics that describe all the relevant aspects related to the ways aservice is utilized in an elementary period. The tariff may also change dynam-ically (e.g. depending on the congestion status of the required elementary ser-vices); moreover, it can be determined on the basis of the information relatedto the customers’ behaviour, the strategic interaction among service providersand the regulatory regime (i.e intermediate and/or final price controls and/orantitrust constraints).The idea that the composition of elementary services may support a multi-tude of heterogeneous applications services, i.e. defined by different quality ofservice (QoS), represent a crucial issue in the development of models relatedto multi-channel electronic services [42, 31, 49, 33] (Parris and Ferrari 1992,Murphy and Murphy 1994, Courcoubetis et alii 1997, Wang et alii 1997, Kellyet alii 1998, MacKie-Mason et alii 2002).In our model we assume an economic system constituted of three types ofagents: the service providers that signals tariffs and capacity associated tothe packages of elementary services, the final users which ask for applicationservices and an intermediator that selects the set of tariffs that maximizesthe consumers’ surplus (we take inspiration from the framework proposed inMacKie-Mason et alii 2002 and the approach used in [43] to allocate resourcesin a production distributed system). Note that we suppose that the cost struc-ture is a private information of each service provider and that the announcedtariffs (with the related capacities) allow them to cover their costs.Let us consider a set L = {1, . . . , L} of elementary services provided by a setof providers F = {1, . . . , F}. A set N = {1, . . . , N} of users demands a mul-titude of application services. Let M = {1, . . . , M} be the set of the possibletypes of application services, each one characterized by a specific QoS. Let

26

xi = {xi1, . . . , x

iM} be a vector associated to the final user i’s where xi

j is thequantity of application service j assigned to i. The preferences of each user iare defined by a quasi-linear utility function: xi

0 + ui(xi), where xi0 > 0 is the

numeraire commodity and ui(xi) is a concave function. Each service providerf proposes a set Of of tariff schemes (to keep notation simple let us assumethat each tariff is univocally numbered by a label k); contemporarily, f de-clares the capacity Rf,k

l that he is willing to provide for elementary service lin package k. Once a user has demanded an application service j, the inter-mediator determines one set Vj ⊆ L of the elementary services that belongto application service j (in general there can be several sets of elementaryservices composing j, but to keep the model simple we consider only one);moreover, the intermediator specifies the amount vj,l of each elementary ser-vice l ∈ Vj needed to application service j. When each set Vj has been defined,the intermediator selects among the announced tariffs those maximizing theconsumers’ surplus, represented by the sum of the single user utility func-tions minus the overall amount of money paid for the acquired packages ofelementary services. Without loss of generality, we assume that the generictariff k ∈ Of is a two part tariff Ak +

∑l∈Bk

pkl qk,i

l , where Bk ⊆ L is thek-th package proposed by f , Ak is the per-user fixed fee related to Bk, qk,i

l isthe amount of elementary service l ∈ L in Bk supplied to final user i, whilepk

l is the unit price to supply the elementary service l ∈ L. Finally, based onthe previous assumptions, the formulation of the considered problem is thefollowing:

max∑

i∈N ui(xi)−∑f∈F

∑k∈Of

((Ak

∑i∈N yk,i) +

∑l∈Bk

(pkl

∑i∈N qk,i

l ))xi

j ≤∑

l∈Vj ,k∈Ofvj,lq

k,il j ∈M, i ∈ N

qk,il ≤ yk,iR l ∈ Bk, k ∈ Of , f ∈ F , i ∈ N

qkl ≤ Rf,k

l l ∈ Bk, k ∈ Of , f ∈ Fxi

j ≥ 0 j ∈M, i ∈ Nyk,i ∈ {0, 1} k ∈ Of , f ∈ F , i ∈ Nqkl ≥ 0 l ∈ Bk, k ∈ Of , f ∈ F

where R is a sufficiently large number.A Negotiation-based pricing modelBeside the tariff-based pricing model described in the previous section, anegotiation-based pricing model for multichannel service provisioning has beenalso proposed.

In this case, each user negotiate both QoS dimensions values and the priceof the service directly with the MAIS service provider; after the negotiationphase, the autonomic computing infrastructure is responsible of managingresources to provide the service adhering to the QoS that has been settledduring the negotiation process.

Initially, the negotiation model proposed considers MAIS as a simple In-ternet Service Provider that sells bandwidth to its users with QoS guarantees,


exploiting the IP DiffServ Internet with lightweight QoS management speci-fication [47].

The negotiation protocol adopted is a bilateral iterated single-encounterbargaining. Thus, in each simulation, a set of users will be considered, theprovider negotiates in a bilateral fashion with one single user per time instant;n QoS dimensions are negotiated, with 1 ≤ j ≤ n. The user and the providerexchange offers, each offer is constituted by a vector Xi = (qj), where i = c, sidentifies the participant and qi,j is the value proposed or offered for the i-thquality dimension, and a price Pi is the relative price. Participants generateoffers and counter-offers by evaluating two different functions, i.e., quality andutility functions. The quality function Qi(X) states how much a QoS profile isworth to the participant i. Besides, when considering pricing issues, a utilityfunction Vi(Qi(X), P ) is defined. In the simplest case, users are interested inmaximising the quality-price ratio, the provider tries to leverage the productof quality and price.

When considering MAIS as a multichannel service provider, the modelhas to be extended to match the fact that services may be provisioned ondifferent kinds of channels with their own QoS profiles (see Chapter 2 forthe MAIS channel model). In this case, the channel related QoS dimensionbecome the negotiated attributes. For instance, considering the PDA channel,the following QoS dimensions may be negotiated:

• Screen size, using discrete resolutions;• Color depth;• Bandwidth.

Beside channel specific QoS dimensions, service related QoS should be alsonegotiated, such as service availability and response time.

Once the negotiated attribute are defined, the negotiation process betweenthe MAIS provider and its user can be simulated. It should be noticed thatusers may want to negotiate the QoS of a service and the relative price thefirst time the service is requested, maintaining the agreement on the followingrequests. Besides, in order to provide more flexibility to the service requests,each time a service is invoked, users may declare the willingness to negotiateQoS and price.

Simulations have been conducted analyzing user and provider satisfactionin terms of relative utility values on the agreements obtained from the ne-gotiation process. Furthermore, in each case, the negotiation based scenariohas been compared with a non-negotiated QoS and price allocation policyby which each user request is accomplished as-is until the provider has spareresources to allocate it, such as bandwidth in the case the provider is anInternet Service Provider. Considering the more complex scenario of multi-channel service provisioning, the non-negotiated scenario coincide with thetariff based pricing approach proposed in the previous section, in which theprovider publishes tariffs for its provided service and do not allow any kindof negotiation.

28

Simulation results show how the non-negotiated policy performs betterwhen a small group of users is considered, i.o e., a number of users whoserequests do not saturate the provider’s resources. When the number of userrequests grows, a threshold can be identified above which the negotiationbased scenario starts outperforming the non-negotiated one. Thus, in the caseof service provisioning, a classical, non-negotiated QoS setting and pricingpolicy is optimal when considering a small number of users, while, in thecase of a high number of requests, negotiation should be introduced to selectrequests that best fit both the provider and the users interests in terms oftheir relative utility values.

1.5 Micro-MAIS

In the micro-MAIS architecture, the process is executed on small devices,which can also perform some of the process activities when the network ispartitioned and some of the nodes are unreachable. In this case synchroniza-tion mechanisms are discussed.

The execution of a business process in a mobile environment – with dif-ferent devices connected through different network technologies – needs newstrategies with respect to the traditional solutions adopted for centralizedprocesses. These solutions rely on a single engine that knows and controls allsystem resources, but mobility demands for decentralized executions carriedout by a federation of heterogenous devices. All these requirements lead to anew strategy that stresses the independency among actors – to minimize thenecessity of interaction and knowledge sharing – and thus increases reliability.

In MAIS, we focus on solution based on process partitioning, and in adap-tive process execution in ad hoc networks.

1.5.1 Process Partitioning

The MAIS approach to distributed process execution is based on partitioningrules. Partitioning rules define how to create a set of cooperating workflowsfrom an abstract process representation.

The MAIS-PL flexible web-service description defined in Section is en-riched with the specification of a possible local coordinator associated to eachcomponent service. The number of coordinators is predefined for each processspecification.

To partition the original workflow in a set of workflows coordinated bylocal coordinators, graph transformation [10] techniques will be adopted.

A typed graph transformation system G = 〈TG, C,R〉 consists of a typegraph TG, a set of structural constraints C over TG, and a set R of rulesp : L → R over TG. The type graph defines the types of nodes and edgesthat can be used to create graphs. The set of structural constraints identifiesconstraints on how nodes and edges are linked, and rules state how graphs


can be modified. In particular, a graph transformation rule r : L → R wherethe left-hand side L defines the pre-conditions that must hold on the graphto enable the rule while the right-hand side R describes the post-conditions,that is, the modifications on the graph after applying the rule.

Usually, rules must be composed to perform significant transformations.Thus, a transformation sequence s = (G0Rp1(o1) · · ·Rpn(on)Gn) in G, brieflyG0Rs∗GGn, is a sequence of consecutive transformations using the rules of Gsuch that all graphs G0, . . . , Gn satisfy the topological constraints.

In the MAIS approach, we concentrate on AGG (Attributed Graph Gram-mars) to model and validate our rules. AGG allows users to specify complexstructures as graphs and exploits the Java type system to associate attributeswith values. It also supports layered rules where layers fix the applicationorder among rules. The interpretation starts with level-zero rules and thenmoves to higher ones. Besides pre- and post-conditions (left- and right-handside graphs), AGG also supports negative application conditions, that is, sub-graphs in the left-hand side that must not exist to enable the rule.

In order to describe a MAIS-PL process as a typed graph we adopt an ex-tended version of the UML profile for automated business processes, describedin [36] as summarized in Table 1.2.

BPEL Primitive Graph Element

Basic Activities Basic activities are rendered as Activity nodes.Each of these nodes has an attribute device,which stores the name of the device that controlsthe activity, a type, equal to normal, and a name

equal to the one of the UML activity.

Links between activities Links are rendered as edges of type follow be-tween Activity nodes.

Structured activities Structured activities are rendered with twospecial-purpose Activity nodes. Their attributestype and name have the same values and are equalto Start<Name> and End<Name>, where <Name>is the type of the corresponding UML structuredactivity (e.g., Loop or Switch). Each structuredactivity is also associated with a number, whichis assigned to the variable value of the two addedActivity nodes.

Table 1.2. Translation guidelines

The application of partitioning rules – and the execution of disconnectedoperations – requires that the workflow meets the following requirements: (1)The control of the execution of a specific task can be assigned to a singledevice; (2) The StartLoop and EndLoop nodes of While structured activitiesmust be assigned to the same device; (3) The Start node of Pick, Switch, and

30

While structured activities is in charge of evaluating the condition; (4) Theworkflow has no global variables and all the variables are passed as parametersbetween different actors. If all requirements are met, the partitioning processstarts identifying where to partition the workflow and how to maintain theexecution flow across structured activities. Then it defines the sub-workflowsby creating local views.

Rules are organized in layers that govern their applicability. Rules thatbelong to “low” layers are applied before those of “high” layers. Within eachlayer, rules can triggered in a non deterministic way.

The lowest-level rules (layer 0) are devoted to synchronizing (delegating)the execution flow between two activities of a Sequence that are executedby different devices. Fig. 1.7 shows the AGG rule Add delegate that synchro-nizes Sequences split on different devices. The rule can be applied if thereis an Activity node (either simple or structured), controlled by an actor A1

followed by another Activity node controlled by a different actor A2. Theright-hand side of the rule introduces two new special Activity nodes wherethe former is controlled by A1, and the latter by A2. These two nodes add apair of invoke/receive activities to forbid the second activity to start beforethe completion of the first one. Notice that this rule is also able to partitionSequences that belong to Flow activities. The delegation (synchronization) isdescribed by the delegate arc between the two newly introduced Activitynodes.

1:Activity

device=A1

2:Activity

device=A2

name=N

follow

:=

1:Activity

device=A1

2:Activity

device=A2 name=N

follow Activity device=A1 type=”Normal” name=”Do “ +N+” To “+ A2

value=0

Activity device=A2 type=”Normal” name=”Execute “ +N+ “from “+A1

value=0

delegate

follow

AddDelegate

Fig. 1.6. Example of partitioning rules

Rules of layer 1 and layer 2 addressing the problem of partitioning struc-tured activities, like Switch or Pick ones. The partitioning of While activitiesis slightly more complex. The number of iterations is not known a-priori andthe variables that control the loop can be updated by any actor involved inthe activities that belong to the loop. Consequently, like for other structuredactivities, we introduce a Flow activity before the StartLoop node, with thegoal of communicating to the other devices involved in the While activityif the condition is satisfied. We also add another Flow activity before the


EndLoop node to communicate to the other devices if the loop condition isstill satisfied.

Rules at layer 3 address the problem of notifying the branch followed bythe execution of a given structured activity. The last set of rules (layer 4)removes extra arcs added in layer 1.

After extending the host graph (BPEL process), we can create the localviews to decentralize the workflow execution. By “local”, we mean that eachactor only knows its tasks, i.e., its sub-workflow. More details about localviews in business processes can be found in [58]. To create views, we set thecontext in terms of the actor (device) for which we want to produce the viewand apply the following rules: (1) We remove all activities whose execution isnot controlled by the current actor; (2) We translate all structured activities,with the exception of Sequences, that do not include “local” activities intoSequences with no tasks. For more details about our partitioning rules thereader is referred to [11]

1.5.2 Adaptive Workflow

Mobile Device j

Service 3 Service 4

Network Service Interface

Wireless Stack (802.11x, Bluetooth)

Mobile Device i

Service 1 Service 2



Mobile Device Coordinator



Coordination Layer

Predictive Layer

WorkflowAdapter

Workflow Execution

EngineRewritingRules

WorkflowSchema

Mobile Device j

Service 3 Service 4



Mobile Device i

Service 1 Service 2






Coordination Layer

Predictive Layer

WorkflowAdapter

Workflow Execution


WorkflowSchema

Mobile Device j

Service 3 Service 4



Mobile Device j

Service 3 Service 4



Mobile Device i

Service 1 Service 2



Mobile Device i

Service 1 Service 2






Coordination Layer

Predictive Layer

WorkflowAdapter

Workflow Execution


WorkflowSchema




Coordination Layer

Predictive Layer

WorkflowAdapter

Workflow Execution


WorkflowSchema

Fig. 1.7. The Architecture for adaptive workflow on MANETs

Figure 1.8 shows the architecture supporting cooperative work on MANETs.The various MANET devices are equipped with some wireless network inter-faces and specific hardware for calculating distances from neighboring devices(Wireless Stack in the figure), while the Network Service Interface (NSI) pro-vides the upper layers with the basic services for sending and receiving mes-sages (through multi-hop paths) to/from other devices, by abstracting thespecific routing protocols [26, 29, 28]. Services (i.e. specific applications sup-porting the device users’ tasks1) are accessible to other devices and can be

1 Some of these services are applications that do not require human intervention(e.g., an image processing utility), whereas others act as proxies in front of humanactors (e.g., the service for instructing human actors to follow a peer is a simple

32

coordinated and composed in a cooperative process. In contrast, the coor-dinator device presents the Predictive Layer on top of the Network ServiceInterface, signaling any probable disconnection to the upper CoordinationLayer.

The Predictive Layer implements a probabilistic technique [27] which canpredict if all devices will still be connected in the successive moment. Ata given time instant ti in which all devices are connected, the coordinatordevice collects all device distance information and builds a next connectiongraph, i.e. the most likely graph at the next time instant ti+1, in which thepredicted connected and disconnected devices are highlighted. In predictingat ti the next connection graph, the technique considers not only the currentsituation, but also recent situations and predictions (i.e., at ti−1, ti−2, etc.),specifically considering distances calculated in the recent past.

In the interval [ti, ti+1], the coordinator layer enacts the appropriate ac-tions to enable all devices to be still connected at ti+1; as an example, if thecoordination layer realizes a workflow management system, then, on the basisof the current prediction, the coordination layer may restructure the workflowschema.

Specifically, the Workflow Adapter module is in charge of catching discon-nection events incoming from the Predictive Layer and, on the basis of thecurrent workflow execution state (taken from the Workflow Execution En-gine module, which is also in charge to manage activity assignments), appliestransformation rules, stored in a specific rule database, to modify the work-flow schema of the cooperative work (e.g., it adds a new node in the processgraph representing the “Follow Peer X” activity). The processes are modelledthrough Petri nets, and the transitions in the resulting net are fired under thesatisfaction of some conditions, expressed through an algebraic formalism.

The approach is a combination of local connection management amongdevices and of global management of both network topology and task assign-ment. The local connection management consists in monitoring and checkingone-hop communications between a device and its neighbors; it is realized asspecial services running on hand-held devices that implement techniques ableto estimate and calculate distances and relative positions (angle and direc-tion) between a specific device and its direct neighbors. Conversely, globalmanagement consists in maintaining a consistent state of the network and ofeach its constituting peer: it manages the network topology (and its predictednext states) and tasks each peer is in charge of, as well as services that peersoffer (i.e., a service registry). On the basis of that information the coordina-tor applies possible bridge choice algorithms and/or executes workflow taskreassignment when needed.

We argue that in emergency scenarios we can obtain a more effective coor-dination among team members through the proposed pervasive architecture:

GUI that alerts the human operator by displaying a pop-up window and emittinga signal).


each team member is equipped with an hand-held device and all together theyconstitute a MANET, whose topology is both influenced by and influences thecooperative process to be enacted.

References

1. Business Process Execution Language for Web Services Version 1.1.2. Jini Architecture Specification 2.0.3. Nonlinear Pricing. Oxford University Press, 1993.4. Pricing Communication Networks: Economics, Technology and Modelling. John

Wiley, 2003.5. Rowstron A. Run-time systems for coordination. In Klusch M. Tolksdorf R.

Omicini A., Zambonelli F., editor, Coordination of Internet Agents: Models,Technologies, and Applications, chapter 3, pages 61–82. Springer-Verlag, March2001.

6. T.F. Abdelzaher, K.G. Shin, and N. Bhatti. Performance Guarantees for WebServer End-Systems: A Control-Theoretical Approach. IEEE Trans. on Paralleland Distrib. Systems, 2002.

7. D. Ardagna and C. Francalanci. A Cost-Oriented Approach for the Design ofIT Architectures. Journal of Information Technology, 2005.

8. D. Ardagna and B. Pernici. Qos evaluation in web service selection. Politecnicodi Milano, Technical Report n. 2005.20, 2005.

9. Ariba, Microsoft, and IBM. Web Services Description Language (WSDL) 1.1.W3C Note, March 2001.

10. L. Baresi and R. Heckel. Tutorial Introduction to Graph Transformation: ASoftware Engineering Perspective. In Proceedings of the First InternationalConference on Graph Transformation (ICGT 2002), volume 2505 of LectureNotes in Computer Science, pages 402–429. Springer-Verlag, 2002.

11. L. Baresi, A. Maurino, and S. Modafferi. Workflow partitioning in mobile infor-mation systems. In Proceedings of IFIP TC 8 Working Conference on MobileInformation Systems (MOBIS), pages 93–106, 2004.

12. D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M.Mecella. Au-tomatic Service Composition Based on Behavioral Description. InternationalJournal of Cooperative Information Systems, 2005.

13. D. Berardi, D. Calvanese, G. De Giacomo, M. Lenzerini, and M.Mecella. Auto-matic Service Composition Based on Behavioral Description. In Proceedings ofthe 1st Internation Conference on Service Oriented Computing (ICSOC 2003),Trento, Italy, 2003.

14. D. Berardi, G. De Giacomo, and M. Mecella. Basis for Automatic ServiceComposition. In Tutorial at the 14th World Wide Web Conference (WWW2005), Tokyo, Japan, 2005.

15. A. Bernstein and M. Klein. Towards high-precision service retrieval. IEEEInternet Computing, pages 30–36, 2004.

16. D. Bianchini, V. De Antonellis, B. Pernici, and P. Plebani. Ontology-basedMethodology for e-Service discovery. Accepted for publication on Journal ofInformation Systems, Special Issue on Semantic Web and Web Services, 2004.

34

17. Marchetti C., Pernici B., and Plebani P. A quality model for multichanneladaptive information. In WWW (Alternate Track Papers & Posters). New YorkCity, pages 48–54, 2004.

18. G. Canfora, M.di Penta, R. Esposito, and M. L. Villani. A lightweight approachfor qos-aware service composition. In ICSOC 2004 forum paper, 2004.

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 2005 Pro-ceedings, 2005.

20. G. Canfora, M.di Penta, R. Esposito, and M. L. Villani. Qos-aware replanningof composite web services. In ICWS 2005 Proceedings, 2005.

21. J. Cardoso. Quality of service and semantic composition of workflows. PhD.Thesis, Univ. of Georgia, 2002.

22. A. Chandra, P. Goyal, and P. Shenoy. Quantifying the Benefits of ResourceMultiplexing in On-Demand Data Centers. In ACM Self-Manage Workshop2003 Proceedings, 2003.

23. J. S. Chase and D. C. Anderson. Managing Energy and Server Resources inHosting Centers. In ACM SOSP 2001 Proceedings, 2001.

24. M. Comuzzi and B. Pernici. Negotiation support for web service selection. InProc. 5th VLDB Int. Workshop Technologies for E-Services, TES’04. Toronto,Canada, pages 28–39, August 2045.

25. Clark D.D. Internet cost allocation and pricing. pages 215–252, 1997.26. F. De Rosa, V. Di Martino, L. Paglione, and M. Mecella. Mobile adaptive

information systems on manet: What we need as basic layer? In Proceedingsof the 1st IEEE Workshop on Multichannel and Mobile Information Systems(MMIS’03), Rome, Italy, 2003.

27. F. De Rosa, A. Malizia, and M. Mecella. Disconnection prediction in mobilead hoc networks for supporting cooperative work. IEEE Pervasive Computing,2005.

28. F. De Rosa, M. Mecella, P. Faraglia, and F. Pascucci. Designing and imple-menting a manet network service interface with compact .net on pocket pc. InProceedings of the 1st International Conference on .NET Technologies (.NET2005), Plzen, Czech Republic, 2005.

29. F. De Rosa, M. Mecella, A. Ritucci, and G. Santoro. Peer-to-peer applicationson mobile devices: A case study with compact .net on smartphone 2003. InProceedings of the 2nd International Workshop on .NET Technologies (.NET2004), Plzen, Czech Republic, 2005.

30. C. Fellbaum (ed.). Wordnet: An Electronic Lexical Database and ElectronicCommerce. MIT Press, 1998.

31. Cocchi R. et al. Pricing in computer networks: motivation, formulation, andexample. IEEE/ACM Trans. Netw., 1(6):614–627, 1993.

32. Divitini et al. Inter–organizational workflows for enterprise coordination. InKlusch M. Tolksdorf R. Omicini A., Zambonelli F., editor, Coordination of Inter-net Agents: Models, Technologies, and Applications, chapter 15, pages 369–398.Springer-Verlag, March 2001.

33. Gupta A. et al. A stochastic equilibrium model of internet pricing. Jour-nal of Economic Dynamics and Control, 21(4-5):697–722, 1997. available athttp://ideas.repec.org/a/eee/dyncon/v21y1997i4-5p697-722.html.

34. Reichert M. et al. Enterprise-wide and cross-enterprise workflow-management:Challenges and research issues for adaptive workflows. In Enterprise-wide andCross-enterprise Workflow Management, pages 56–64, 1999.


35. Weiss G., editor. Multiagent systems: a modern approach to distributed artificialintelligence. MIT Press, Cambridge, MA, USA, 1999.

36. T. Gardner and al. Draft uml 1.4 profile for automated business processes witha mapping to the bpel 1.0. IBM alphaWorks, 2003.

37. S. Graupner, V. Kotov, A. Andrzejack, and H. Trinks. Service-Centric GloballyDistributed Computing. IEEE Internet Computing, 2003.

38. P. Grefen, K. Aberer, Y. Hoffner, and H. Ludwig. CrossFlow: Cross-Organizational Workflow Management in Dynamic Virtual Enterprises. Inter-national Journal of Computer Systems Science & Engineering, 15(5), 2000.

39. Ferber J. Multi-Agent Systems. Addison Wesley, 1999.40. Sheth A.P. Jorge Cardoso J. Semantic web processes: Semantics enabled an-

notation, discovery, composition and orchestration of web scale processes. InWISE, pages 375–376, 2003.

41. T. Kawamura, M. Paolucci, T. Payne, and K. Sycara. Semantic Matching ofWeb Services Capabilities. In Proc. of First Int. Semantic Web Conference(ISWC), 2002.

42. Simha R. Kurose J.F. A microeconomic approach to optimal resource allocationin distributed computer systems. IEEE Trans. Comput., 38(5):705–717, 1989.

43. Wu S.D Kutanoglu E. On combinatorial auction and lagrangean relaxation fordistributed resource scheduling. IIE Transactions, 31(9):813–826, 1999.

44. Tirole J. Laffont J-J. Competition in telecommunications. MIT Press, Cam-bridge, MA, USA, 2000.

45. A. Lazcano, G. Alonso, H. Schuldt, and C. Schuler. The WISE approach toElectronic Commerce. International Journal of Computer Systems Science &Engineering, 15(5), 2000.

46. A. Leff, J. T. Rayefield, and D. M. Dias. Grid Computing Service-Level Agree-ments and Commercial Grids. IEEE Internet Computing, 2003.

47. C. Francalanci M. Comuzzi and P. Giacomazzi. Trade-off based negotiationof Traffic Conditioning and Service Level Agreements in DiffServ networks. InProc. 19th IEEE Int. Conf. Advanced Information Networking and Applications,AINA’05. Taipei, Taiwan, pages 189–194, March 2005.

48. Z. Maamar, Q. Z. Sheng, and B. Benatallah. Interleaving web services compo-sition and execution using software agents and delegation.

49. Varian H.R. MacKie-Mason J.K. Pricing congestible network resources (invitedpaper). IEEE Journal on Selected Areas in Communications, 13(7):1141–1149,1995.

50. M. Mecella and B. Pernici. Building flexible and cooperative applications basedon e-services. Technical Report 21-2002, Dipartimento di Informatica e Sis-temistica, Universita’ di Roma ”La Sapienza”, Rome, Italy, 2002.

51. M. Mecella, B. Pernici, and P. Craca. Compatibility of e-Services in a Coopera-tive Multi-Platform Environment. In Proceedings of the 2nd VLDB InternationalWorkshop on Technologies for e-Services (VLDB-TES 2001), Rome, Italy, 2001.

52. Scheier C. Pfeifer R. Understanding intelligence. MIT Press, Cambridge, MA,USA, 1999.

53. Denti E. Rossi D., Cabri G. Tuple-based technologies for coordination. In KluschM. Tolksdorf R. Omicini A., Zambonelli F., editor, Coordination of InternetAgents: Models, Technologies, and Applications, chapter 74.

54. C. Stirling. Modal and Temporal Logics for Processes. In Banff Higher OrderWorkshop 1996. Springer Verlag LNCS 1043, pp. 149 – 237, 1996.

36

55. Richard S. Sutton and Andrew G. Barto. Reinforcement Learning:An Introduction. MIT Press, Cambridge, MA, 1998. http://www-anw.cs.umass.edu/˜rich/book/the-book.html.

56. UDDI.org. UDDI Technical White Paper.http://www.uddi.org/pubs/lru UDDI Technical Paper.pdf, 2001.

57. Tosic V., Pagurek B., Patel K., Esfandiari B., and Ma W. Management applica-tions of the web service offerings language (wsol). In WProceedings of CAiSE 03(15th International Conference on Advanced Information Systems Engineering).Velden, Austria, pages 468–484, 2003.

58. M. Weske W. M. P. van der Aalst. The p2p approach to interorganizationalworkflows. In In Proc. of Conference on Advanced Information Systems Engi-neering CAiSE, pages 140–156, Interlaken, Switzerland, 2001.

59. L. Zeng, B. Benatallah, M. Dumas, and J. Kalagnamam andH. Chang. QoS-Aware Middleware for Web Services Composition. IEEE Transactions on Soft-ware Engineering, May 2004.

60. L. Zhang and D. Ardagna. SLA Based Profit Optimization in Autonomic Com-puting Systems. In ICSOC 2004 Proceedings, 2004.

flexible web services

Documents