Negotiation Protocols Definition · required for negotiation protocol specification are described in the UML class diagram of Figure 2.1. We identified two aspects of a negotiation

Fondo Investimenti per la Ricerca di Base (FIRB)Programma Strategico Tecnologie abilitanti per la

Società della Conoscenza-ICT

Negotiation Protocols DefinitionD. Ardagna∗, C.Batinio, M.Comerioo, Marco Comuzzi∗, F. De Paolio,

S.Gregao, B. Pernici∗

∗ PoliMi, o Milano-Bicocca

AbstractThis paper proposes an approach for the definition of Negotiation Protocols, the Optimization of Services Composition and amethodology for the redesign of services in order to support quality of service requirements for end users in a multi-channelscenario.

Data 04/11/2004Tipo di Prodotto Rapporto 2.2.2

Stato FinaleUnità responsabile Polimi

Unità coinvolte Polimi, Milano-BicoccaAutore da contattare Barbara Pernici

Versione 1.0

Index

1 Introduction……………………………………………………………………………………………………... 3 2 Negotiation Protocols…………………………………………………………………………………………… 3 2.1 Web service negotiation capabilities…………………………………………………………………………... 3 2.2 Coordination for negotiation enactment……………………………………………………………………….. 4 2.2.1 An example of protocol definition................................................................................................................... 6 2.3 Negotiation in process specification…………………………………………………………………………… 8 3 Services Composition with Quality of Service Constraints…………………………………………………. 10 3.1 MAIS Architecture Extension for QoS Optimization………………………………………………………… 11 3.2 The Reference Model…………………………………………………………………………………………. 12 3.3 Optimization Problem………………………………………………………………………………………… 16 3.3.1 Model Analysis……………………………………………………………………………………………... 17 3.3.2 Optimization Technique……………………………………………………………………………………. 18 3.3.3 Process Re-optimization……………………………………………………………………………………. 19 3.4 Process Specification………………………………………………………………………………………….. 20 4 Methodological guidelines for the redesign of services including Quality-of-Service and User Profile

issues…………………..………………………………………………………………………………………. 22 4.1. The Methodology……………………………………………………………………………………………. 23 4.1.1. Case study: Check-of-herd management………………………………………………………………….. 28 4.2. The registry of qualities in MAIS…………………………………………………………………………… 33 4.3. The role of QoS in Web Service Redesign…………………………………………………………………... 37 4.3.1. Phase 2: High-level redesign………………………………………………………………………………. 37 4.3.2. Phase 4: Customization……………………………………………………………………………………. 43 References……………………………………………………………………………………………………….. 51

1. Introduction

This paper discusses the MAIS approach for the definition of Negotiation Protocols, the Optimization of Services Compositionand the specification of quality of service requirements at design time using end user profiles. The problem of negotiating thecharacteristics of a service in a dynamic and loosely coupled environment in a Service Oriented Architecture (SOA) is becomingan emerging problem in the web service research field. An automated support to negotiation is useful when dealing with mobileor adaptive contexts, in which it is not assured that every time a service has to be invoked, it could be invoked with the same QoS,because of the variability of context-aware environment. Negotiation is used as support for the selection of candidate services and thecorresponding optimization. In the MAIS approach the services composition maximizes end-user preferences while guaranteeingglobal constraints, i.e., constraints over the overall process. Negotiation and service selection have an impact also in the servicespecification at design time. We have proposed a design methodology which support the redesign of an existing service in order tosupport quality of service requirements for end users in a multi-channel scenario.

The remainder of this paper is organized as follows. Section 2 discusses the negotiation protocol implemented in the MAISarchitecture. Section 3 describes how services can be selected in order to optimize end-users requirements in terms of Qualityof Services and, finally, Section 4 proposes a high level methodology for the re-design of services in multi-channel environmentincluding Quality of Service and User Profiles.

2

2. Negotiation Protocols

The problem of negotiating the characteristics of a service in a dynamic and loosely coupled environment in a Service OrientedArchitecture (SOA) is becoming an emerging problem in the web service research field. An automated support to negotiation isuseful when dealing with mobile or adaptive contexts, in which it is not assured that every time a service has to be invoked, it couldbe invoked with the same QoS, because of different problems, like failures in the underlying network, dynamic changing of the setof available services and services substitution. The architecture of the MAIS project for service provisioning is a straightforwardexample of adaptive context that can benefit from the introduction of automated support to negotiation.

In multiagent systems research many frameworks have been proposed for managing autonomous negotiation between heteroge-neous agents [12], but there is a lack of similar frameworks when dealing with emerging web service technologies. When consideringweb service environments, the problem of negotiation has been addressed only from the point of view of trust negotiation betweenparties involved in the realization of a business transaction [3]. The scope of this section is to propose a framework for the man-agement of different kinds of negotiation in a web service environment, considering the problem of the coordination of differentservices in a negotiation process. First it is proposed a language to allow services specify their negotiation capabilities in terms ofnegotiation protocol preferences and, then, a framework for the enactment of negotiation processes involving web services. Last,itis also discussed the representation of negotiation in process specification and its enactment.

The module Negotiator in the MAIS architecture is responsible of managing negotiations for setting the QoS parameters valuesand the price of a service. Negotiation is not required in every invocation, but the user or the process specification made by thedesigner are allowed to request, prior to the actual invocation and execution of a service, a negotiation to set its QoS and price. Todescribe how negotiations can be enacted in the MAIS architecture we focus on three main aspects:

1 Description and publication of web service negotiation capabilities;

2 Description of the coordination for negotiation enactment;

3 Specification of negotiation issues in MAIS processes.

The remainder of this section is organized as follows: Section 2.1 describes how services publish their negotiation capabilities;Section 2.2 discusses the problem of service coordination during the negotiation and Section 2.3 shows how negotiation can bespecified in processes. An extended analysis of problems treated in this chapter can be found in [?] and [?].

2.1 Web service negotiation capabilities

Every web service published on the registry could specify, besides other information, its negotiation capabilities in terms of prefer-ences over different negotiation protocols supported, that can be bilateral, multiparty or auction-based. The definition of negotiationcapabilities is the first step for the realization of negotiation-based service provisioning in a service oriented architecture.

Services define negotiation policies in order to specify their preferences using WS-Policy [5], which provides a flexible frame-work for the definition of policies and the association of policies to different services using XML-based languages. Elementsrequired for negotiation protocol specification are described in the UML class diagram of Figure 2.1. We identified two aspects of anegotiation protocol:

1 Static elements. Are related to establishing the number of participants, the roles that participants can assume, the type ofparticipants and temporal issues, like the instant at which the negotiation process will start and its length. While roles arefixed for a negotiation protocol, other static aspects are variable and negotiation participants could specify preferences on theirvalues. Preferences are contained in negotiation policies.

2 Dynamic elements. Are related to the definition of how static elements could be organized, and thus refers to the specificationof message flow, negotiation states and handling procedures for exception, contained in a BPEL4WS file. The definition ofthe structure of messages in the negotiation process is associated to the role that is allowed to post or receive them.

The language proposed for specifying preferences over static elements of different negotiation protocols is based on the classdiagram of Figure 2.1 and is used to characterize negotiation policies by which services could advertise their negotiation capabilities.A negotiation policy example is as follows.

3

Negotiation Protocols Definition

Figura 2.1: Negotiation capabilities elements

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy" xmlns:neg=".../negotiationMAIS" Name = "MyPreferences"><wsp:All><neg:NegFramework type="EnglishAuction"><neg:AuctionPreferences><neg:role>Participant</neg:role><neg:nMIn>2</neg:nMIn><neg:nMax>5</neg:nMax><neg:tStartMax>5</neg:tStartMax><neg:tStartMIn>1</neg:tStartMin><neg:lengthMax>60</neg:lengthMax>

</neg:AuctionPreferences><neg:handler>.../engAuctionHandler1.wsdl</neg:handler>

</neg:NegFramework></wsp:All></wsp:Policy>

In this example the neg namespace, defined in the MAIS registry, contains the definition of static elements of the negotiationprotocol and the nature of preferences that services are allowed to express on them. In this case the ticket booking service is ableto participate or desire to participate only in English ascendant auctions with more than 2 and less than 5 participants, that will startin 5 hours from the current time instant and that will last less than 1 hour. The service specifies that it participates in the auction asa common participant. The policy reports also a reference to the URI of the handler service that will participate autonomously tothe English Auction in place of the service. In order to separate the service business logic from its negotiation capabilities, in fact,services do not export directly a portType for each negotiation protocol supported, but they delegate the execution of negotiations toa handler service. The structure of handler services is analyzed in the next section.

As stated before, once a protocol is chosen, services are allowed to express preferences only on a subset of static aspects of it.This assumption relies on the hypothesis that all the services published on the MAIS registry know which protocols are supportedby the Negotiator and on which elements they can express preferences. The Negotiator has a BPEL4WS specification for everynegotiation protocol it is able to support and the structure of its negotiation messages. The above defined policy, thus, does nothave to specify these aspects of the contract that are already known to the Negotiator. Policies are attached to services using thespecification of WS-PolicyAttachment [4].

2.2 Coordination for negotiation enactment

After defining a language for publishing negotiation capabilities and preferences over protocols of web services, the next step is todescribe, see Figure 2.2, the negotiation enactment, which is the set of activities required to implement a negotiation process and,thus, to reach the agreement on a contract of outcomes of negotiation process between parties.

When the user or the orchestration engine signals to the Concrete Service Invocator that a negotiation is requested for setting thequality dimensions of a service, the service invocator forwards this information to the Negotiator module which is responsible of thenegotiation enactment. The Negotiator will search the registry and analyze services’ negotiation policies to identify which services

4


Figura 2.2: Negotiation phases.

to contact for the negotiation and to set definitively the characteristics of the negotiation protocol matching preferences expressed innegotiation policies. In the theater ticket scenario, for example, when the theater ticket service is selling last minute tickets, a userasserts that he wants to participate in the auction for tickets using a certain handler service and certain preferences, the Negotiatormodule should contact a certain number of participants, deciding the time at which the auction will start and its length in order tosatisfy all the constraints imposed by negotiation policies of services that will be involved in the negotiation process.

Once the Negotiator has information about participants, roles and protocol to be followed, the problem of protocol enactingis primarily a problem of coordination of different services. The Negotiator, thus, act as a coordinator of services involved in thenegotiation process. The problem of coordination of negotiating parties in a dynamic environment has been tackled from two sides[8]:

� Horizontal Coordination: it manages negotiation and it involves contacting negotiating parties, message brokering andnegotiation result notification to parties and to the service invocator in order to invoke the right service with the right qualityattributes established by the negotiation process. This form of coordination is called horizontal because it is common to theentire set of negotiation protocols the architecture is able to deal with;

� Vertical Coordination: it is the very problem of protocol enacting and is related to the implementation of dynamic aspects ofnegotiation protocol. Later in this section, it is shown an example of negotiation protocol specification using BPEL4WS.

Let us describe the situation in which the service invocator has discovered all the services that will participate in the negotiationprocess (i.e., the participants), and it has forwarded this information to the Negotiator with a reference to the negotiation protocolthat has to be followed in the negotiation process. The Negotiator acts as the unique coordinator of services discovered and thecoordination is described by means of WS-Coordination [6]. The UML sequence diagram of Figure 2.3 shows messages exchangedin the horizontal coordination phase.

The Negotiator “activates” services by sending to everyone involved a coordination context. The coordination context is a datastructure that contains the reference to the coordinator’s RegistrationPortType and information about the protocol that will be usedin the negotiation process. Nevertheless, the coordination context is used to mark messages belonging to the same conversation (i.e.,negotiation process) because the Negotiator can be coordinating, at the same time, different negotiations, for example an auction fortheater tickets and a direct negotiation of a user for purchasing a flight ticket.

After receiving the coordination context, each service registers to the coordinator specifying his role in the conversation andthe portType that exports the conversation operations; the coordinator replies with a reference to the portType that exports theconversation coordination operations. For instance, in the auction scenario, after receiving the coordination context, every serviceinvolved will register to the Negotiator specifying a portType, i.e., AuctionParticipantPortType for a participant. The Negotiatorreplies with a reference to his AuctionCoordinatorPortType that manages the auction protocol.

The activation and registration phases refer to the horizontal coordination of the negotiation protocol. The next step, in fact, is theexchange of protocol specific messages, i.e., offers in the auction by services involved. In the management of the protocol specificinteractions between handler services the Negotiator assumes two roles:

� Negotiation Broker: referring to horizontal coordination, the Negotiator delivers protocol specific messages to proper re-ceivers and notifies negotiation results;

� Protocol-compliance checker: the Negotiator checks if conversations between services are compliant to the protocol specifiedin the coordination context; in an English auction, for instance, a participant is not allowed to post two consequent bids.

5


Figura 2.3: Coordination for service selection

The Negotiator, see Figure 2.4, exports a different portType for every negotiation protocol supported (i.e., different kinds ofauctions, bilateral or multiparty negotiation) and each service that will handle the negotiation exports at least a single portType forthe negotiation protocol specified in the policy of the correspondent service.

Figura 2.4: PortType exported by the handler and the Negotiator

2.2.1 An example of protocol definition

In order to act as a protocol-compliance checker, the Negotiator needs a web service compliant definition of negotiation protocolssupported by the platform. The Negotiator uses this meta-definition to define the rules of the protocols and to define fault handlersfor managing exception generated by a non compliant behaviour of services involved. BPEL4WS ([7]) is used for the definition ofmeta-protocols for negotiation.

The following example is related to the definition of an English auction negotiation protocol. A timeout is associated with theauction, services involved can place bids until the timeout expires, the highest bid wins the auction; a bid is described by a sender idand an amount that he wants to pay. The Negotiator receives offers and notify results to the participants and to the service invocator.The compliance rule that the Negotiator has to check every time a new offer is submitted is that one service is not allowed to posttwo consequent offers. When, in fact, the last bidder is the same as the current bidder, the Negotiator throws an exception to signala non compliant behaviour; the exception handler, in this case, will be the refusal of the bid submitted.

<process name="auctionMetaSpec"...

6


<partnerLinks><partnerLink name="buying"/>

</partnerLinks><variables>

<variable name="lastBidder" type="xsd:string"/><variable name="currBidder" type="xsd:string"/><variable name="tmpSender" type="xsd:string"/><variable name="tmpAmount" type="xsd:string"/><variable name="winnerAmount" type="xsd:string"/><variable name="winnerID" type="xsd:string"/>

...</variables><faultHandlers>...</faultHandlers><sequence><while condition="t < TIMEOUT"><receive partnerLink="bidder"portType = "bidPT"operation = "sendBid"variable = "offer"

</receive><assign><copy>

<from variable="offer" part="sender"/><to variable="currBidder"/>

</copy></assign><switch><case condition="lastBidder=currBidder">

<throw faultName="invalidBid" faltVariable="..."/></case></switch><assign><copy>

<from variable="offer" part="sender"/><to variable="tmpSender"/>

</copy><copy>

<from variable="offer" part="amount"/><to variable="tmpAmount"/>

</copy></assign><switch><case condition="tmpAmount>winAmount">

<assign><copy><from variable=tmpSender/><to variable="winnerID"/></copy><copy><from variable="tmpAmount"/><to variable="winnerAmount"/>

</copy></assign></case></switch><assign><copy>

<from variable="offer" part="sender"/><to variable="lastBidder"/>

</copy></assign>

</while>...results notification...

</sequence></process>

The process specified in the example is considered a meta-protocol because it does not refer to a particular abstract or con-crete service. Roles in the negotiation protocol are specified only by names in the partnerLinks element, the Negotiator obtainsa specification of the actual negotiation protocol enriching the meta-specification with the information provided by participants inthe horizontal coordination phase. This mechanisms is similar to the already considered difference between abstract services andconcrete implementations: in the meta specification partnerLinks are defined only from an abstract point of view, the coordinationcontext gives a concrete binding to actual services involved in the negotiation process.The bidPT portType, for instance, will beevery time substituted by the protocol specific interaction portType of the service that is placing the current bid.

7


2.3 Negotiation in process specification

The need for establishing web service parameters for invocation using negotiation is not only addressed by the problem of a concreteservice invocation. The designer of the MAIS architecture is responsible of designing process that will involve the orchestrationof different services published on the registry. The process is always specified at abstract service level. The process orchestrationengine and the concrete service invocator will have to discover concrete services in the registry that will implement an instance ofthe process.

In this contest, it is described an extension to BPEL4WS to include the need for specification of the negotiation of service qualityparameters.

A typical scenario could be the process of week end travel setting. The designer wants to describe a process in which everyFriday night the same user, who requested the definition of the process, is contacted and asked if he wants to spent the holiday away.The user specifies the place where he wants to go and the process is responsible of setting up the accommodation and the travel tothe place chosen by airplane, only if the weather is fine. The process is composed by the orchestration of 3 different services, aweather forecast service, a hotel booking service and a flight book service; once the user express his required destination, the processcontacts the weather forecast service, if the forecast for the week end is good, he step up for booking accommodation and the flight.The BPEL4WS extension does not consider the problem of orchestration of different services, but it is a way to express negotiationpolicies at the level of abstract process definition. The user, in fact, using the language define in Section 2.1, could specify that thephase of finding concrete service for the implementation of an instance of the process should be negotiation-based. In the weekend setting example, we may want to specify that every first week end of a month a sell side auction for establishing the cost of theweather forecast service will be held. The contract established by the auction will last for the entire month, unless the user becomesunsatisfied of the quality of service (the forecast is always wrong!) and specifies, while choosing the place for thew week end, alsothe need for re-organizing the auction even if it is not the first week end of the current month. An example of the extension proposedis reported in the next example. In the example we use another BPEL4WS extension represented by select and unselect activities.The select is used to state that, once a particular concrete service has been chosen to implement the abstract definition reportedin the invoke activity, it will be chosen for every similar invocation until an unselect removes the association between the abstractspecification and the concrete implementation.<process name=weekEndSetting>partnerLinks and roles definitions<sequence><receive parterLink="userPreferences"

portType="userPrefPT"operation="expressingPreferences"variable="preferences"/>

<invoke partnerLink="Forecasting"portType="ForecastPT"operation="requestForecast"inputVariable="..."usingNegPolicy="userPolicySellSideAuction"><select portType="ForecastPT"/>

accommodation and flight booking specification<while condition="getDay()<"processExpirationDate"><receive parterLink="userPreferences"

portType="userPrefPT"operation="expressingPreferences"variable="preferences"/>

<switch><case condition=(getDay()=Friday && negPrefs="Unchange")><invoke partnerLink="Forecasting"

portType="ForecastPT"operation="requestForecast"inputVariable="...">

</invoke></case><case condition=(getDay()=Friday && negPrefs="Change")><unselect portType="ForecastPT"><invoke partnerLink="Forecasting"

portType="ForecastPT"operation="requestForecast"inputVariable="..."usingNegPolicy="userPolicySellSideAuction">

</invoke><select portType="ForecastPT"></case>

</switch>accommodation and flight booking specification

</sequence></while></process>

The negotiation-based discovery of a concrete service that implements the abstract part the process specification refers to is

8


requested by passing a certain negotiation policy as argument of the usingNegPolicy element. The policy, in the example, willcontain preferences for a sell side auction with a certain number of participants and time constraints and is generated autonomouslyby the user interface using the values of a form that the user fills for specifying his preferences. The policy could be more complexin the case, for example, of the request of a direct bilateral automated negotiation of the cost of the service forecast. The policy, inthis case, besides other preferences, will contain a reference to the web service that the user will use in the negotiation process tocontract autonomously the price with the weather forecast service bilateral negotiation handler.

9

3. Services Composition with Quality of Service Constraints

With the development of the Service Oriented Architecture (SOA), complex applications can be composed as high-level businessprocess from a variety of available services with different characteristics. In the MAIS project service descriptions can be retrievedfrom an enhanced UDDI registry which stores information about quality parameters on the provider side. Usually a set of functionalequivalent services can be selected, i.e. services which implements the same functionality but differ for the quality parameters.

In the MAIS project, complex concrete services contains an abstract process definition which will be instantiated and executedusing simple concrete services supplied by a Service Provider (SP).

The services composition is implemented dynamically and the best set of concrete services available at run time, according toend-user preferences, can be identified. The execution of the composite service is afterward supported by the Process Orchestrator.

Quality of Service (QoS) constraints can be specified at local or global level. A local constraint allows to select a concrete serviceaccording to a desired characteristic, for example a concrete service is selected such that its price or its execution time are lower thana given threshold. Global constraints are constraints over the whole composite service execution, i.e., constraints like The overallexecution time of the composite service has to be less than 3 seconds or the total price has to be less than 2 $.

Other approaches proposed in the literature partially support QoS constraints at a global level. For example the work in [14]allows to specify constraints only locally. If only local constraints are considered, the service composition is very simple and can beperformed at run time by a greedy approach which selects the best candidate service suitable for the execution.

Authors in [17] allow to specify global constraints that anyway are guaranteed only for the Critical Path (that is the path whichcorresponds to the highest execution time) of the composite service.

The MAIS project considers several quality dimensions, such as the total execution time, the lead time of the business process,price, data quality, and many others [1]. The service composition can be formalized as an optimization problem which selects theset of candidate concrete services for the execution of a composite process, maximizing the average quality level for the end user,while guaranteeing global (and possibly local) QoS constraints. In this paper the following quality dimensions will be considered:

� average execution time: the expected delay, between the time instant when a request is sent and the time when the result isobtained. Average execution time is measured in seconds;

� average execution time under performance degradation: in the MAIS project if a candidate concrete service is not availableat invocation time, then the Process Orchestrator can invoke another equivalent concrete service or even run the BehavioralCompatibility Engine module which can identify at run time a set of concrete services which replaces the faulty one. Underthis scenario a bound on the average response time can be specified in order to consider performance degradation (accordingto performability models [9]). Average execution time under performance degradation is measured in seconds;

� availability: the probability that the service is accessible. The availability is a number in the range [0,1];

� price: fixed price associated for the execution of the service for a specific provider. The price is measured in $;

� reputation: it is a measure of the service trustworthiness. It mainly depends on end user’s experience of using the service andit is defined as the ratio between the number of service invocations which comply the negotiated QoS over the total number ofservice invocations. The reputation is a number in the range [0,1];

� data quality: the data quality is the ability of a data collection to meet user requirements [2]. Data quality includes severaldimensions such as timeliness, accuracy, completeness which are measured on a proper scale.

Execution time and availability are the most important quality of service dimensions currently considered in Service LevelAgreement contracts for the outsourcing of IT services [11]. Many ISPs and ASPs guarantee 100% availability for their services;packet round-trip delay are often guaranteed to range in 85-100 msec, while execution time is service specific. Note that, a constrainton the average response time, E[t] less or equal to a given threshold R, is equivalent to a constraint on the critical quantile of theresponse time, such as 95% of the response times to be less than 5 seconds. If t has an exponential distribution, then the requirementP [t ≤ R] ≥ α is equivalent to E[t] ≤ βR; where β = −1/ ln(1 − α). In cases when the response time is not exponentiallydistributed, we can use Markov’s inequality P [t ≤ R] ≥ 1 − E[t]/R and consider the constraint E[t] ≥ (1 − α)R. Reputation isvery important especially if a service invocation corresponds to an economic transaction, while data quality is receiving increasinginterest in the research community. Note that, data quality constraints can consider individual data quality dimensions but also anaggregate measure of the data quality can be specified.

10


Our model can be extended in order to consider other dimensions (e.g., the process lead time). As it will be discussed in thefollowing sections, the selected QoS dimensions have a set of characteristics general for the optimization perspective. The problem ofselection of Composite Services (CS) with Quality of Service constraints can be modeled as an integer linear programming problem.The problem is NP-hard, since it is equivalent to a Multiple Choice Multiple Dimension Knapsack problem (MMKP) and we willdevelop a local search approach based on the HEU heuristic [13]. The remainder of this paper is organized as follows. Section 3.1discusses which are the modules of the MAIS framework which have to be extended in order to consider QoS optimization and globalconstraints. Section 3.2 introduces the reference model that will be adopted, while section 3.3 discusses the problem formulation andour local search approach. Finally section 3.4 discusses the BPEL4WS process specification considered by the optimization modulewhose implementation is under development.

3.1 MAIS Architecture Extension for QoS Optimization

Figura 3.1: MAIS Functional Architecture

In order to maximize the QoS perceived by the end user while guaranteeing global constraints, the current MAIS functionalarchitecture has to be extended. The module involved in the QoS optimization process is the Concretizator. The invocation of acomposite service is performed implementing the following steps:

� The Platform Invocator forwards the service invocation request to the Concrete Service Invocator.

� The Concrete Service Invocator forwards the requests, the process specification and the user context to the Concretizator.

� The Concretizator selects the set of candidate services by accessing the MAIS registry.

� If a candidate service profile provides negotiation than the Negotiator is invoked. The Negotiator interacts with the ServiceProvider and obtains the final specification for the QoS profile and the price.

11


� The Concretizator identifies the optimum execution plan, i.e., the set of concrete services that will support the execution ofthe composite service. For each abstract service the optimum concrete service is identified. The Concretizator stores the set ofcandidate services considered in the optimization process and their corresponding QoS profile.

� The Process Orchestrator start the process execution.

The Process Orchestrator manages the state of the composite service and interacts with the Concrete Service Invocator at runtime, when service requests are executed.

A composite service execution is performed implementing the following steps:

� The Process Orchestrator create a new instance of the composite service whose execution starts with the invocation of the firstconcrete service performed by the Concrete Service Invocation. Note that, possibly multiple concrete service can be invokedat the same time if parallel sequences exist.

� The process execution state is updated if a concrete service execution terminates or a triggering event is verified. Anotherservice is then invoked in order to continue the process execution. If a concrete service identified in the execution planis not available at run time or the user changes his context, then the Process Orchestrator invokes the Concretizator again,compelling the re-optimization of the process. This can require possibly the re-negotiation of services. The re-optimizationcould be performed possibly for each concrete service invocation in order to keep the optimization plan up to date. This canbe useful if the set of candidate services is changed significantly during the process execution and for example new servicesare advertised by a SP with lower price or with a different quality profile. The set of candidate services considered in there-optimization process is stored by the Concretizator.

The re-optimization and negotiation phase could be time consuming and the re-optimization could not be performed for everyconcrete service invocation but only periodically. Note that, according to the results presented in [17], a global optimization approachcan be very useful especially in static environment. In dynamic environments, where the set of concrete service or their profileschange frequently, or if the process execution takes a very long time, then the service composition performed by local approachescould be more effective since even with global approaches global constraints could not be guaranteed (if an optimum plan is obtainedby considering the characteristic of a service which is not available at run time, then a global constraint could not be satisfied sincean alternative service available at run time could have a worse QoS profile).

If a re-optimization is performed, then the Process Orchestrator sends the composite service execution state to the Concretizator.In this way a portion of the composite service specification can be eliminated from the optimization problem. For example taskswhich correspond to conditions that were not verified in the past, will not be executed and can be eliminated in the re-optimizationprocess, as it will be discussed in the following section. Vice versa, tasks already executed are introduced as constraints in there-optimization [17]. In general the re-optimization is more simple to solve, since the number of variables and constraints can bereduced.

Finally, if a concrete service is not available at run time and it can not be substituted by an equivalent one, then the ProcessOrchestrator invokes the Behavioral Compatibility Engine module and the concrete service is modified by a composition of services.

3.2 The Reference Model

In the MAIS project a concrete composite service is modeled as an Activity Diagram where each task t j corresponds to a concreteservice invocation. The goal of the optimization process is to identify a set of concrete services ws j , such that the QoS is maximized,while some global constraints are guaranteed. In the following, we assume that the activity diagram can be modeled as a DirectedAcyclic Graph (DAG). If an activity diagram contains some cycles, then they have to be unfolded. The method adopted in theliterature [17] is to examine execution log and determine the maximum (or average) number of times each cycle is taken in pastexecutions. If an upper bound for cycles execution can not be determined, then the optimization process can not guarantee thatglobal constraints are satisfied [17]. Furthermore, we assume that conditional branches are specified by disjoint sets of conditions.This limitation can be relaxed as it will be discussed in section 3.4.

In this section we define three concepts used in the remainder of the paper, Execution Plan, Execution Path and Serial Path:

� Execution Plan: a set of couple (tj , wsj) indicating that task tj is executed by the concrete service wsj .

� Execution Path: a sequence of tasks of the activity diagram which do not include conditional branches. We will denote witheplli an execution plan limited to the set of task included in the execution path ep l. As an example, the activity diagram reportedin Figure 3.2, includes two execution paths which are obtained by considering the branch condition after the synchronizationpoint. As shown in this example, an execution path can include parallel sequences.

12


Quality Dimension Aggregation functionPrice Sum of price of services involved in the

execution planReputation Average reputation evaluated over the set of

services involved in the execution planData Quality Average value of the data quality provided

by the set of services involved in the execution planExecution time Sum of the execution time of the services involved in

the execution of a serial path of the execution planAvailability Product of the value of availability provided by the services

involved in the execution of a serial path of theexecution plan

Tabella 3.1: Aggregation function for the QoS evaluation of Execution Plans

� Serial Path: a sequence of task from the begin to an end state of the activity diagram. A serial path will be denoted with sp.

Table 3.1 shows how to evaluate each quality dimension for an execution plan. Price, reputation and data quality are evaluated byconsidering all tasks included in the execution plan, vice versa, time and availability dimensions are evaluated for every serial path.Note that an aggregate measure of the data quality can be obtained by considering a weighted average of the quality dimensions ofeach task or vice versa, as discussed in [17], in a more conservative way by considering the minimum or maximum value of thequality dimension of each task. In the following we will adopt the former approach and we will formulate the optimization problemas an integer linear programming (ILP) problem. Note that if, vice versa, the latter approach is considered, then we can anywayformulate the problem as an ILP problem since the set of candidate services which do not satisfy data quality constraints can befiltered from the list of candidate services identified by the Negotiator and data quality constraints can be removed from the problem.

The CS problem is multi-objective and a Simple Additive Weighting (SAW) technique is used to evaluate the overall value frommultiple quality dimensions [10]. The SAW method is one of the most widely used techniques to obtain a dimension’s score froma list of dimensions having different units of measure. The raw values for each quality dimension need to be normalized in order toproduce a final scalar value for the dimension. The final value or score for an execution plan is calculated by multiplying the qualitydimension’s weight by its normalized value and then summing across the quality dimension.

Quality dimensions can be modeled by a matrix Q l = [qli,j ] where the number of rows equals the number of candidate plans I ,

the number of columns equals the number of quality dimensions J and q li,j expresses the value of the execution plan epl l

i for the j-thquality dimension. In the normalization phase positive criteria, i.e. quality attributes such that the higher the value the higher thequality, and negative criteria, i.e. quality attributes such that the higher the value the lower the quality, are scaled in different ways,as defined in equations (3.1) and (3.2) respectively:

Positive criteria: vli,j =

{ql

i,j−minQlj

max Qlj−minQl

j

if maxQlj �= min Ql

j

1 else(3.1)

Negative criteria: vli,j =

{max Ql

j−qli,j

max Qlj−minQl

j

if maxQlj �= min Ql

j

1 else(3.2)

where min Qlj = mini∈I ql

i,j and maxQlj = maxi∈I ql

i,j are the minimum and maximum values respectively, for the qualitydimension j. Note that if max Ql

j = min Qlj then every execution plan is characterized by the same value for the quality dimension

j, the quality dimension is not a differential characteristic for the execution path ep l and vli,j is set to 1.

Reputation and availability are examples of positive criteria, price and execution time are vice versa negative criteria. The overallscore associated with an execution plan epl l

i is evaluated as:

Score(eplli) =J∑

j=1

wjvli,j (3.3)

J∑j=1

wj = 1 (3.4)

13


Figura 3.2: Process Execution Path

14


where wj ∈ [0, 1] represents the weight assigned by the end user to the j-th quality dimension. Note that the evaluation of v li,j

requires the assessment of the maximum and minimum value of each quality dimensions for each execution plan. This can be donewithout considering all of the possible execution plans, since, for example, the execution plan of maximum price can be obtained byconsidering the set of candidate services with maximum price.

As an example, let us assume that we are interested in two positive quality dimensions and there are 4 possible execution plansfor a given execution path, i.e. I = 4 and J = 2. Let be the quality matrix Q:

Q =

⎡⎢⎢⎣

6 78 32 124 9

⎤⎥⎥⎦

If the set of weight is w1 = 0.8 and w2 = 0.2 then the score for the first execution plan is score(epl1) = 0.8∗ 6−28−2 +0.2∗ 7−3

12−3 =0.62.

In the remainder of the paper the following notation will be adopted:

WSj := set of candidate concrete services for the execution of task t j ;wsi,j := i-th concrete service, candidate for the execution of task t j ;

ri,j := wsi,j average execution time;ci,j := price for wsi,j execution;ti,j := wsi,j reputation;ai,j := wsi,j availability;

dqi,j := normalized aggregate value of data quality of ws i,j ;R := execution time bound for the composite service;

RD := execution time bound for the composite service, under performance degradation;TRestart := average time required for the re-invocation of a faulty service;

A := availability bound for the composite service execution;B := budget for the composite service;T := reputation bound required for the composite service;

DQ := data quality bound required for the composite service. DQ is a real number in the range [0,1];A := set of tasks included in the composite service specification;Al := set of tasks included in the Execution Path ep l;L := number of execution path arising from the composite service specification;

%Esec(epl) := frequency of execution for the execution path ep l.

Our approach starts from the work presented in [18, 17] and implemented in the AgFlow architecture. The main limitations oftheir methodology are the followings:

� only the Critical Path is considered;

� the global plan is identified by optimizing individually each execution path and merging the solutions according to the hot path.The hot path of a task tj is defined as the execution path which is more frequently executed for task t j . In the aggregation, ifexecution plans has a common subset of concrete services, then the merge is performed by assigning to each task the solutionidentified for the hot path.

In Zeng et al. work [18, 17], the fulfillment of availability and response time constraints is guaranteed only for the Critical Pathunder the hypothesis that if the execution of a task in another path of the activity diagram fails, then it can be restarted without addingany delay to the overall execution of the process, but anyway this is not verified neither a-posteriori. Furthermore, their hot pathtechnique does not guarantee the fulfillment of any global constraints. Let us consider the example reported in Figure 3.3. Thereare two Execution Paths ep1 and ep2 which include respectively tasks t1 and t2, and t1 and t3. Execution frequency are reported inparenthesis and hence ep2 is the hot path. The Figure indicates also the price and average execution time associated with candidateservices. Let us assume that the end user requires the execution of the process and asks that the cost is less or equal to 6$, while

15


the overall response time is less or equal to 7 seconds. In Zeng et al. approach the optimum execution plan epl 1∗ includes ws2,1 andws2,2, while the optimum execution plan epl2∗ includes ws1,1 and ws1,3 (which are the only feasible solutions for each individualexecution path). The hot path method identifies as global solution the set of services ws 1,1, ws2,2, ws1,3, anyway note that if at runtime the execution path ep1 is taken then the budget constraints is violated since the cost of execution of ws 1,1 and ws2,2 is 9$. Byenumerating all of the possible combinations of concrete services, one can determine that this problem has no solution, then in theMAIS architecture the Behavioral Compatibility Engine module is invoked.

Figura 3.3: An Infeasible Solution Example

3.3 Optimization Problem

The CS problem can be formulated as an integer linear programming problem. Let y i,j be the binary decision variables of theproblem; yi,j equals 1 if the candidate service wsi,j executes the task tj , 0 otherwise. Let us indicate with xj the start time of tasktj and with rj its duration.

Assuming that the overall goal is to maximize the average score of the execution plan, the CS problem can be formulated as:

P1)∑L

l=1 %Esec(epl)Score(eplli)

The objective is to maximize the overall score of the execution plan obtained as a weighted average over the execution frequency%Esec(epl) of all possible execution paths.

The remainder of this section describes the constraints of the ILP model.Assignment constraints. Each task tj in the solution has to be assigned to a concrete service, that is for every j one variable y i,j

has to be set to 1. This condition can be expressed by the following constraint family:

∑i∈WSj

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

Composite service duration. The duration of each task can be expressed by the following constraint:

∑i∈WSj

ri,jyi,j = rj ; ∀j ∈ A (3.6)

16


that is, for constraint (3.5) only one candidate service is selected and hence the duration of a task is given by the concrete serviceexecution time. Furthermore, we have to include precedence constraints for subsequent tasks in the Activity Diagram. If t j → tkindicates that task tj and tk are connected by a link in the Activity Diagram, then we have:

xk − (rj + xj) ≥ 0; ∀tj → tk (3.7)

that is, if a task tk is a direct successor of task tj , then the execution of task tk must start after task tj termination.Execution time and execution time under performance degradation constraints can be expressed as:

∑j∈sp rj ≤ R; ∀sp (3.8)∑

j∈sp−{k} rj + 2rk ≤ RD − TRestart; ∀k ∈ sp; ∀sp (3.9)

Here we assume that if a service fails, then the Process Orchestrator will invoke another equivalent service and, under thehypothesis of a single fault in the composite service execution, a concrete service is executed at most twice. We assume that theservice is selected by accessing the MAIS registry and the concrete service which offers an execution time lower than the faultyservice is selected. Furthermore the query specifies some restriction on the service characteristics in order to guarantee that globalconstraint are not violated. If the service selection fails, the query returns an empty set, than the process is re-optimized. Note thatconstraint family (3.9) is equivalent to the following set of (non-linear) constraints:

∑j∈sp rj + maxj∈sp rj ≤ RD − TRestart ∀sp

Availability constraint. The value of availability of a serial path in the DAG is obtained as the product of the availability of theset of tasks in the path, under the hypothesis of stochastic independence among concrete services [9]. The product

∏i∈WSj

ayi,j

i,j isequal to the availability of task tj since, for equation (3.5) only one y i,j is equal to 1. The availability requirement for the compositeservice can be specified as:

∏j∈sp

∏i∈WSj

ayi,j

i,j ≥ A; ∀sp (3.10)

Price, reputation and data quality constraints. Constraints on total price, reputation and data quality of the composite servicedescend directly by their definition reported in table 3.1.

∑j∈Al

∑i∈WSj

ci,jyi,j ≤ B (3.11)1

|Al|∑

j∈Al

∑i∈WSj

ti,jyi,j ≥ T ; ∀l (3.12)1

|Al|∑

j∈Al

∑i∈WSj

dqi,jyi,j ≥ DQ; ∀l (3.13)

Other contraints. Local constraints can be included in the model as a special case of global constraints. For example if theend-user requires that the price for task tj1 has to be less or equal to 2$ then the following constraint is introduced:

∑i∈WSj1

ci,j1yi,j1 ≤ 2

Global constraints can also refer to a subset of tasks. Let us consider the following example: the duration of two subsequent tasktj2 and tj3 has to be less or equal to 5 sec. This can be formalized as follows:

rj2 + rj3 ≤ 5

3.3.1 Model Analysis

The Problem P1) has integer variables and a non-linear constraint (the availability bound expressed by equation (3.10)). Theavailability bound can be linearized by applying the function ln. Equation (3.10) then becomes:

17


∑j∈sp

∑i∈WSj

ln(ai,j)yi,j ≥ ln(A) ∀sp (3.14)

Note that A and ai,j are positive real numbers less or equal to 1, then their logarithm is negative. Hence the previous inequalitycan be written as a less or equal inequality with positive coefficients.

The constraints family (3.14) introduces capacity constraints [16]. Also constraints (3.12) and (3.13) written as demand con-straints (greater or equal inequality with positive coefficients) can be transformed in capacity constraints. The reputation t of aservice is a real number in [0, 1] and it is a positive criteria (the higher the value, the higher the reputation). We can consider thecomplementary reputation tc defined has tc = 1 − t and write Equation (3.12) as follows:

1|Al|

∑j∈A

∑i∈WSj

tci,jyi,j ≤ TC (3.15)

that is, intuitively, we can solve the CS problem by introducing constraints on the reputation of candidate services or in thesame way by expressing constraints on their untrustworthiness. Formally we can apply the transformation and constraints (3.12) and(3.15) are equivalent since we have the constraint (3.5), i.e., each task has to be associated with a concrete service. In the same waythe data quality constraint can be written as a capacity constraint by considering the complementary data quality dqc = 1 − dq:

1|Al|

∑j∈A

∑i∈WSj

dqci,jyi,j ≤ DQC (3.16)

After transforming availability, reputation and data quality constraints P1) is equavilent to a MMKP problem [13],A multiple-dimension knapsack problem is one kind of knapsack where the resources are multi-dimensional, i.e., there are

multiple resource constrains for the knapsack. Let us consider first another variant of the Knapsack, the Multiple choice Knapsack(MKP). Let there be n groups of items. Group l has n l items. Each item of the group has a particular value and it requires resources.The objective of the MKP is to pick exactly one item from each group for maximum total value of the collected items, subject to theresource constraint of the knapsack. In mathematical notation, let c l,k be the value of the k-th item in l-th group, w l,k the resourcerequirement and W the resource bound of the knapsack. Then the problem is:

max∑n

l=1

∑nl

k=1 cl,kxl,k∑nl=1

∑nl

k=1 wl,kxl,k ≤ W (3.17)∑nl

k=1 xl,k = 1; ∀l

xl,k ∈ {0, 1}; ∀l, k

The MKKP problem is an extension of the MKP problem where the resources are multi-dimensional. Formally let w l,k,i be theamount of resource i required by the k item in the l group and W i the amount of the i resource. Then the MKKP is obained from theprevious set of relations where equation (3.17) is replaced with the set of constraints

∑nl=1

∑nl

k=1 wl,k,ixl,k ≤ Wi; ∀i.The CS problem is a MMKP where each task corresponds to a group, each candidate service for a task is an item in a group and

each quality dimension corresponds to a resource dimension. Every instance of the MMKP can be formulated as a CS; hence CS isNP-hard.

3.3.2 Optimization Technique

The Knapsack problem and its variants are very well known problems in the Operations Research literature which provides severalmethods to solve the MMKP. For small instances of the problem, commercial integer linear programming solver can be adopted.Zeng et al. solved their optimization problem by the IBM OSL library. In our extension of their work, we introduce a greater numberof constraints since we guarantee execution time and availability constraints for every path and not only for the critical path. Hence,it may be that, for instances of reasonable size, commercial solvers could be inefficient and a more specific technique has to bedeveloped.

In our approach we solve P1) in two steps. In the first step we solve a CS problem for every execution path as in the Zeng et al.approach, that is we solve the following L sub-problems:

18


P2) Score(eplli)∑i∈WSj

yi,j = 1; ∀j ∈ Al∑i∈WSj

ri,jyi,j = rj ; ∀j ∈ Al

xk − (rj + xj) ≥ 0; ∀tj → tk ∈ Al∑j∈sp rj ≤ R; ∀sp ∈ Al∑

j∈sp−{k} rj + 2rk ≤ RD − TRestart; ∀k ∈ sp; ∀sp ∈ Al

−∑j∈sp

∑i∈WSj

ln(ai,j)yi,j ≤ − ln(A) ∀sp ∈ Al∑j∈Al

∑i∈WSj

ci,jyi,j ≤ B

1|Al|

∑j∈Al

∑i∈WSj

tci,jyi,j ≤ TC

1|Al|

∑j∈Al

∑i∈WSj

dqci,jyi,j ≤ DQC

yi,j ∈ {0, 1}; ∀i, j

rj , xj ∈ R+; ∀j

Each problem is solved by lp_solve a state of the art open source integer linear programming solver which implements the branchand bound technique.

In the second step, we first look for a feasible solution of the overall CS problem, and then we enhance the solution by applyingthe HEU heuristic [13]. The HEU heuristic implements a local search approach which on average identifies solutions 94% lower thanthe optimum with a complexity O(mn2k2), where m is the total number of constraints, n is the number of tasks in the compositeservice and k is the number of candidate concrete services for each task. The HEU heuristic could be very efficient since theexecution time grows only linearly with the number of constraints.

Current work focus is on the first step of the optimization approach and a Java tool which translates a BPEL4WS specificationto a set of equations and constraints according to lp_solve API is under development.

In the following, we will apply the solution approach to some case studies in order to evaluate the performance of lp_solve forthe solution of the problem and possibly start with the implementation of the HEU heurisitic.

3.3.3 Process Re-optimization

If a concrete service identified in the execution plan is not available at run time, then the Process Orchestrator sends to the Concretiza-tor the process state and requires the process re-optimization. The re-optimization is easy to solve since, tasks already executed areintroduced as constraints and tasks which correspond to conditions that were not verified in the past can be eliminated from theprocess specification and the number of variables and constraints can be reduced. Let us consider the process reported in Figure3.4 and let us assume that the Process Orchestrator requires the process re-optimization when task t 2 terminates. In this case theexecution path ep2 can be neglected since it will not be executed (c1 was evaluated to true), and the decisions made for the selectionof t1 and t2, can be included in the model as constraints by setting the corresponding variables to 1.

19


Figura 3.4: Process Re-optimization

3.4 Process Specification

The current implementation of the Concretizator accepts as input an unfolded activity diagram that is only <sequence>, <switch>and <flow> BPEL4WS constructs [15] are considered. Furthermore, we assume that conditional branches are specified by disjointsets of conditions. Under this assumption the Multi-choice and Syncronizing Merge workflow patterns can not be specified [15] (theMulti-choice workflow pattern introduces a point in a process where, based on a decision, a number of branches are chosen andexecuted as parallel threads, vice versa, the syncronizing merge is a point where multiple threads converge in a single thread). Thislimitation can be relaxed as follows. Let us consider the process reported in Figure 3.5, where C 1, C2 and C3 are disjoint conditionsand a parallel path. Formally the process can be modeled with an equivalent branch composed by three disjoint conditions. Notethat, in the worst case scenario, both task t1 and t2 are executed in parallel and hence if a budget constraint exists, then only theexecution path ep2 has to be considered in the optimization process.

Future work will consider an extension of the language accepted by the Concretizator, unfolding procedures will be implementedand workflow patterns will be further analyzed in order to identify ad-hoc techniques for their optimization.

20


Figura 3.5: Multi-choice and Syncronizing Merge Workflow Patterns

21

22

4. Methodological guidelines for the redesign of services including Quality-of-Service and User Profile issues.

In this chapter, a methodology for the process of redesign of existing services to adapt themselves to multi-

channel contexts, i.e., to user profiles and technology environments is proposed.

Traditional development processes need to be rethought to take into account requirements of different nature

(technological, social, organizational, etc.) at the right stage of the development. Moreover, a re-design

methodology is useful since most of the functionalities that are in use –or needed– have been already implemented

and available on-line. Finally, even multi-channel services that need to be maintained and adapted to novel

technologies and environments will take advantage of such a methodology.

The methodology adopts models and techniques that have been developed in MAIS. In particular, the Quality of

Service (QoS) model supports the description of technological and user requirements. The Atomic Interaction

Unit (AIU) technique addresses the decomposition of service interfaces and interactions in atomic units. The

reflective architecture supplies dynamic information on the actual channels and devices. Although the

methodology has been conceived and tested in the context of MAIS, its validity goes behind the MAIS solutions

since many other projects are developing models and middleware solutions to address multi-channel contexts in

much a similar way.

The methodology has been developed and tested in the domain of the information system of the Italian National

Data Base of Bovine Registry (BDN). It is an identification and registration system of animals of the bovine

species. The main objectives are to look after the public health and the livestock; supply information to address

product traceability by maintaining the production flow of bovine meats; finally, ensure efficiency and

effectiveness in the management and control of the European Union grants, e.g. financings in the Common

Agricultural Policy framework.

The BDN is used by institutional subjects (i.e., veterinary services of Local Health Units (LHU), the Italian

Ministry of Health, the regions and autonomous provinces, etc.); and by private subjects (i.e. animal owners,

heads of slaughterhouses and ear-tag suppliers). Moreover, generic citizens can access the BDN to collect

information. The need of making services available to a wide variety of subjects makes the BDN an ideal case

study to develop multi-channel services.

The Istituto Zooprofilattico Sperimentale of Abruzzo and Molise (IZSAM) has already developed a complete set

of services to support Web access. Ongoing projects aim at migrating them to support other channels like mobile

phones (using SMS, MMS, WAP), PDA, fixed multi-frequency telephones. The layered architecture of the BDN

is facilitating the migration process since only the redesign of the higher layers is needed. Since the BDN

organization of services and the layered architecture reflect state-of-the-art solutions for e-services, the

methodology presented can be applied in general re-design contexts.

23

The following paragraphs present the methodology and its phases. Moreover, a case study derived from a real re-

design process in the BDN context is discussed.

4.1. The Methodology

The aim of the methodology is to adapt existing services for a multi-channel use; moreover, the service should be

adaptable to user profiles, channel technologies by exploiting information gathered from a reflective architecture

(e.g., a user’s geographical position). The methodology is based on existing specifications, and information about

communication channels and available technologies.

Fig. 1 Input/Output description of the methodology

Fig. 1 shows the high-level inputs of the methodology. “Actual service” is the specification of the service that is

under redesign in terms of interfaces and interactions. “Logical Data Diagram” is the definition of the data

structure of the service (e.g., ER schema), if available. The next inputs define the requirements for the new

services. “New services provided by new channels” are the requirements derived from the characteristics of the

available channels; in other terms, the channel qualities that influence the definition and the design of services.

For example, the localization of the terminal device is a channel quality that may affect the service design in

certain domains. “Quality requirements” defines the QoS dimensions (which will be described in the following

chapters) that are related to user needs and technical characteristics of new channels. A “User profile” defines the

characteristics of the users enable for further customization of services. The last input is the set of MAIS models

and techniques that support the development of the enriched services.

24

Fig. 2 The five steps of the methodology

Fig. 2 shows the phases of the methodology with inputs and outputs for each phase. Note that the fourth phase,

called “Customization”, groups two sub-phases in which the service model is verified and adapted with respect to

actual technical characteristics of new channels and user profiles. In the following sections, we will examine in

detail the first four phases. The last one deals with the development and deployment of services, which is out of

the aim of this paper.

Actual service modelling

If the actual service under re-design already has a description in terms of UML diagrams, this phase becomes

simply a verification of completeness and consistency of the existing model; otherwise, the abstract model of the

service is defined starting from available documentation, interface descriptions and interaction specifications. The

resulting UML diagrams highlight the logical and operational structure of the service. Activities of groups of

users, basic services that are part of the service, and associated logical data entities need to be specified.

The UML Use-Case Diagram allows for modelling the association of each user role with the set of operations

(basic services) that can be accessed when interacting with the system. The information is gathered from the

analysis of the actual service and the reference domain. For example, in the BDN context, activities have been

collected in the manual for the management of the bovine vital statistics [22].

The UML Class Diagram represents the logical entities involved in the project, and their associated relationships.

If the logical schema of the system is available, such diagram will represent a view of the global logical data

diagram highlighting only entities and relationships involved in the service. When the logical schema is not

available, the UML diagram will be derived directly from the context. An example of the determination of a view

25

of the logical data schema is shown in the case study. The interactions between instances of the entities are

represented by means of UML Sequence Diagrams, which are built starting from the actual service and the

available specifications. The goal of this diagram is to highlight the temporal sequence of the messages between

the involved entities.

High-level redesign

The main objective of this phase is to redesign the service architecture, described by the UML diagrams, in the

light of new requirements promoted by the new channels characteristics and by domain characteristics. Inputs of

the phase are: 1) user quality requirements that are QoS related to user and domain needs 2) new services

provided by new channels that define the qualities available for the considered channels. The purpose is to

identify the intrinsic qualities for the new services with respect to new opportunities opened by new channel

qualities.

For example, in the BDN context, a new user requirement is the knowledge of the position of a vet on the

territory. Such information is supported by localization techniques introduced by mobile devices. This new

requirement suggests redesign services to (a) support assistance planning by dislocating vets on the territory and

(b) manage urgent visits by locating the nearest available vet. Moreover, since the services could be accessed by

different devices (cellular phones or PC browsers), interfaces, interaction modes and contents should be adaptable

to better support user activity.

Another requirement is: sensitive data must be available only for privileged user security. In the BDN, there is

generic information available to everybody (e.g. tracing of bovine heads) and sensitive information available only

to certain users (e.g., management of the farm register of a herd). So, the design of data management should be

addressed not only on the base of needed operations, but also on the security requirements. If new channel

services make available a “secure” channel, the separation between sensitive and generic data will simplify the

deployment of services with mandatory QoS.

According to these new requirements, the UML diagrams produced in previous phase need to be revised and

probably significantly modified. For example, the use of localization information should trigger the redesign of

the data model to take into account a partition of the territory, instead of simply introducing an attributes that

represents the location in existing entities. Anyway, the Class Diagram needs to be modified and new basic

services need to be introduced in the Use-Case Diagrams and Sequence Diagrams.

Behaviour modelling

The objective of this phase is to model the interface of the analyzed service and the interaction between the user

and the service by the use of the Atomic Interaction Units (AIU) [26]. These units describe the interaction

26

independently from specific devices; anyway, they are expressive enough to let designers interface complex

services.

The phase starts with the analysis of the UML diagrams and the selection of suitable AIUs from the available set.

The decomposition of the service in AIU is completed by the description of the interaction between the system

and user by means of UML Activity Diagrams. Each activity state represents an AIU and models the activity of

the user specifying the parameters of the interaction unit. The transition between states is triggered by the user

action. Note that since we are addressing multi-channel services, it is likely that more than one activity diagram

can be selected to support the same set of operations. An example will be given in the case study.

Customization

The first three phases of the methodology have dealt with abstract characteristics of services described by ideal

requirements (even if they are related to realistic channel quality descriptions). The customization phase takes into

account the actual deployment environment by introducing specific channel characteristics and ideal user profiles.

The purpose is to validate and revise the model to deliver the new enriched multi-channel service.

In the channel customization sub-phase, the abstract assumptions that have driven the previous phases are

validated by considering the access devices and network connections that are available to users and providers.

For example, in the BDN context, we have considered:

Personal computer: that supports the current distribution channel of services analyzed in the BDN context.

Mobile device (PDA, etc.): that appears to be useful to vets during, for example, a control in a property by

giving access to the BDN to verify information about the herd or to introduce new data concerning the

control.

Mobile phone (WAP, GSM, GPRS, and UMTS): that is potentially useful in many contexts. For example,

a vet could be notified about controls to be made to herds through SMSs, or keepers could access ad-hoc

information.

Multi-frequency telephone: that may be exploited for vocal interaction with BDN by keepers without

internet access.

Considering again the re-designed services with vet localization described in High-level redesign section, the

service models need to be evaluated in the light of available technologies to verify if the implementation will meet

the requested precision level. In the case study, two technologies (triangulation techniques of telephone cells for

the GSM protocol, and satellite techniques based on

GPS devices) will be considered.

In multi-channel contexts, users switch from a device to another to perform similar activities in different

conditions. Therefore, there is the need of getting detailed information on the QoS of exploited channels to adapt

27

automatically the accessed services: a reflective architecture supports the discovery and measurement of

characteristics of the underlying technology.

On the base of channel QoS, services should perform differently. For example, different transmission speed

should influence a service interface: a more complex and detailed interface will be supplied through channels with

high transmission speed; a simplified version will be supplied to users with lower quality channels. Consider, for

example, an InteractTable interaction unit. The specialization of the AIU for a mobile phone or PDA,

characterized by reduced dimension of the display, results in a reduction of the number of tuples and also of the

number of information fields to be visualized. The choice of fields is made during the determination of the table’s

minimal element, corresponding to the set of more significant fields for the required service. Such differences

have to be included in the UML descriptions produced in the previous phases. In particular, the data model

defined in the second phase and the activity diagrams defined in the third phase.

The channel customization phase might reveal an inadequacy of the service specification delivered by the

previous phases; therefore, it is necessary to iterate from the second phase of the methodology and proceed with a

new design phase, or iterate from the third phase and proceed with a different selection of AIUs. Otherwise, we

can move forward to the next step.

The objective of the service customization sub-phase is to characterize users with attributes by the definition of

detailed profiles. Profiles allow for the services adaptation to the users’ different needs. The study and the

determination of the profile require a preliminarily in deep analysis of user behaviour, which is out of the scope of

this methodology. A first task in this phase is the definition of user roles, and the association of services with

roles. The goal is to discriminate among services that need to exhibit a different behaviour for different roles

although they have similar functionalities. In the BDN domain, examples of roles are keepers, veterinarian and

ear-tag producer. In the case study, a more detailed description is provided.

Given user roles, the task becomes the definition of profiles differentiating each individual user within users with

the same role. In order to improve the system adaptability and the usability of the provided services, specific

peculiarities of each user should be highlighted. The MAIS User Profile Registry can be exploited for this

purpose. Such a model describes the static and dynamic characteristics to obtain detailed and complete profiles.

For example, a vet can be identified according to his/her own specialization (bovine, swine, equine, etc.). For this

reason, the answer to a control request to be executed in a herd is also determined by a system following this

characteristic. Hence, we have to visualize mainly the herds of the denoted species and not the others, because

they result not relevant for the given user.

Another example of personalization is given by the analysis of Activity Participations and Body Functions of each

user as presented in [23]. For example, if the user profile reveals a poor education in a specific field, the system

should be able to supply a simplified interaction mode to access a service in that field; this could be obtained by

avoiding expert terminology and using exemplifying figures.

28

4.1.1 Case study: Check-of-herd management

The project of identification and registration of bovine animals manages traditional events related to the life of the

cattle, such as the ear tags used for the identification of individual heads, the passports for the animals, and the in-

farm registers held in a farm. Moreover, it manages a database, the BDN, containing all the information related to

the breeding, the care and the slaughtering of bovine animals.

The task of developing e-services to access the BDN has been given to IZSAM by the Italian Government,

according to the Government Business model. Today, a complete set of services is already available via Web.

Unfortunately, only a small part of the breeders, the most important source of information, is active user of the

BDN (about 5.000 on 220.000 corresponding to 2.3%), since most of them assign the management of their herds

to “delegated” users, among which the most important are Professional Organisms (e.g., Coldiretti, CIA, etc.) and

the LHUs.

The main reason for such a limited utilization of services is that only few keepers and consumers own computers

and Internet connections. Instead, almost all of them own mobile phones. Therefore, to promote the BDN to

breeders (better defined as “keepers of animals”), and final users (consumers), it is worth developing phone-based

access.

Since 2002, a pilot WAP service that provides information on every bovine head is available. This is one of the

most popular services because, for example, a consumer with a WAP-enabled mobile phone can verify

immediately the origin and movements of a piece of meat just bought in a butcher's shop. In 2003, two prototypes

have been implemented in the multi-channel scenario: the first one allows PDA (Personal Digital Assistant) users

to interact with a subset of functionalities of the BDN; the second one allows updating and querying the BDN

through vocal interaction via fixed multi-frequency telephone. Detailed information can be found in [24]. The

described experiences make IZSAM one of the most innovative agencies of the Italian Public Administration in

the multi-channel context.

The objective of the case study presented in this section is to apply the methodology in a concrete example, and

demonstrate its feasibility and effectiveness. In particular, we consider the macro-service “checks of herd

management”. A macro-service is an aggregated set of elementary services to supply complex features (Fig. 3).

This macro-service, only available as a Web application, supports the Veterinary Service of the LHU in the

management and planning of the periodic visits to the herds. The “Plan controls” service creates a list that

includes the herds not checked in a given period and new head births or head entries. Controls are assigned to

delegated vets by the “Communication of controls assignment” service. After a control, the vet writes a report and

notifies the irregularities discovered in the herd (e.g., presence of heads that have not been registered in the farm

register, use of illegal substances, etc.) by the “Registration of control data” service. The Veterinary Service

visualizes the report by the “Visualization of control data” service, records irregularities by “Confirmation of

irregularities” and fixes the financial fines for the keeper by the “Notification of financial fines” service.

29

Fig. 3 The composition of the "Checks of herd management" macro-service

The re-design activity starts with the analysis of the specifications in the “operating manual of the bovine registry”

[22] (high-level specifications), the logical data schema provided by IZSAM (low-level specifications) and the

actual Web application to produce the logical structure of the macro-service. The results of such analysis are the

UML diagrams describing entities and relationship involved in the interaction, and the temporal sequence of the

interaction messages between the system and the involved users. In particular, the Class Diagram has been

produced deriving classes and relationships from the logical data schema (Fig. 4) and defining classes that

represent the environment (e.g., network and devices).

Fig. 4 A view of the logical data diaram

The second phase of the methodology takes into account the new perspective introduced by the new channels. In

our case study, we have considered cellular phones that introduce access limitations in terms of performance (e.g.,

size of the screen and bandwidth) and change the user requirements in terms of the expected interaction modes. A

major new characteristic is the localization of the user that becomes a novel quality requirement for the re-

designed service. For example, localization of users can be exploited to supply vets with plans according to their

actual position on the territory. Moreover, real-time communication between vets and Veterinary Service can be

exploited in case of emergency. Consider the following scenario: the keeper communicates an emergency to the

Veterinary Service that assigns the task to a vet on the base of its position and its traceability.

30

Therefore, the “Plan controls” service needs to be redesigned to take into account these new requirements. In the

Usecase Diagram, new interactions between the user and the system have been introduced. In the Class Diagram,

classes and attributes that describe the data have been updated to address localization. A new reflective class

“Position” has been added to get vet and herd positions and new reflective attributes (e.g., bandwidth and speed),

has been added in the “Network” class. Details on the definition of reflective classes can be found in [25].

To illustrate the third phase, consider the "Visualization of control data" service. The resulting Activity Diagram

that describes the selected AIUs is shown in Fig. 5. The diagram starts from the FillList that requests the vet

personal code. As the user sends input data, the next activity is activated to get the herds assigned to the vet. The

result is modelled as an InteractTable that visualizes the herds, with a predefined set of attributes. When the vet

selects a certain herd, the systems moves to next activity; instead, when the vet selects the Quit command (and

sets the output

as NULL), the system goes back to the previous activity. The “Select_Action”, modelled with a SelectChoice

AIU, allows the system to proceed in two different ways: if the vet does not accept the assignment, the system

returns to the herd selection; otherwise, the service terminates.

Fig. 5 Activity Diagram used for modeling the AIU of the “Request of controls to be carried out in herds” service.

In the channel customization sub-phase, the technical characteristics of the new channels are considered to

evaluate the new features introduced in the “High-level redesign” phase. For example,

how precise is the localization of a vet on the territory is evaluated. We have considered two technologies:

triangulation techniques of telephone cells for the GSM protocol, and satellite techniques based on GPS devices.

The former allows for localization of users with a precision (100m-10Km) that depends on orography, the latter is

characterized by a greater precision (5m-30m). If the former technique is used, the “Plan controls” service may be

31

characterized by a low precision and may be difficult to implement. In fact, on certain territorial zone (e.g.

mountain zone) the dimensions of telephone cells and the particular morphology of the territory do not permit to

evaluate with an acceptable precision the nearness of two places. If only this technical is available, we need to go

back to the second phase and review the design of the service. Instead, the use of satellite technique is adequate to

support the designed services.

Moreover, AIUs have been specialized to meet quality requirements (e.g. response time) for each chosen channel.

For example, the InteractTable “Interact_Herds” reporting a list of herds needs different displaying strategies

depending on exploited devices. A possibility to differentiate the AIU is given by the Mode parameter. When the

list is displayed on a PC connected to the Internet, the parameter could be set as Full since it is possible to

represent the list entirely, since the dimensions of the screen and the bandwidth of the network support it. Instead,

if the user interacts with a mobile phone, the small dimensions of the screen and the bandwidth restriction suggest

displaying only a slice of information at a time. In this case, the parameter is set as Manual to visualize only the

name and the address of the first herds of the table, leaving the possibility to the user to obtain the remaining

information (holding code, keeper, telephone number, etc…) with further explicit requests. Therefore, the Activity

Diagram shown in Fig. 5 needs to be modified. In particular, as shown in Fig. 6, “More information” must be

introduced between the available choices of the Select_Action. Such choice involves a transaction to a new

activity modelled by a Browse-Message AIU that supports the visualization of further requests.

Fig. 6 Activity Diagram specialized for mobile phone.

Finally, the service customization leads to a specialization of the services according to the user profiles, i.e., roles,

to the declared preferences and to information automatically detected during previous work sessions.

32

Fig. 7 Users’ hierarchy in the BDN domain.

The BDN differentiates the users on the base of the role associated with them. Accessing rules are established by

the Italian Ministry of Health, which assigns roles to every user category. The users’ hierarchy of the BDN

domain is represented in Fig. 7. The User class is a generalization of the Regions, the Ministry, the Ear-tag

Producer, the Slaughter House, and the Delegated classes. This last class is a generalization of the Keeper, the

Professional Association, the Veterinary Service and

the Delegated Veterinarian classes. The definition of roles allows the system to provide users only with services

associated with specific roles; e.g., the “confirmation of irregularities” and the “Notification of financial fines”

services are only available for the “Veterinary Service” role.

Consider again the InteractTable AIU; the layout of the displayed table could be specialized to facilitate the

identification of the information of primary interest to the user. The system sorts the table according to the

preferences and features of the vet. Moreover, the system takes into account the previous assignments to a certain

vet, so reassigning to the same person a herd to check whether the verified anomalies have been dismissed. The

definition of a new value, Automatic, for the parameter Mode specializes the InteractTable accordingly.

Moreover, when a user accesses the service via mobile phone, the parameter should be set as Manual (to consider

channel and device

profile) and as Automatic (to consider the user profile, including vet position). A new value, Specialized, captures

this new situation. Moreover, since the data model defined in the second phase identifies different data types (e.g.,

local data that are available to local agent and complete data that are available to managers only); the association

with roles allows for the identification of different delivery channels that can be classified with different security

levels. This was an example of inadequacy: in facts, the initial design turned to be unsatisfactory for the user

needs, and the second phase need to be activated again to redesign the data model.

The analysis of the case study has verified adequacy and effectiveness of the methodological phases previously

described. In particular, the different examples given in this section have verified with success the correctness of

the subdivision on phases and the proper inputs collocation. The methodological process has resulted particular

simple to use and to be covered on the different phases consolidating the choices previously made.

33

4.2. The registry of qualities in MAIS

In order to meet the requests of the user, the service provider can act on a wide spectrum of qualities, defined at

all levels of the architecture. Correspondingly, the user can express its own requirements not only in terms of

functional needs, but also in terms of quality requirements. In cooperation with the research unit of Politecnico di

Milano, we have defined a MAIS Quality of Service (QoS) Registry to collect, define, and relate all quality

dimensions managed in the MAIS adaptive environment. In this section we provide a general overview of the

Registry.

The QoS Registry has been built according to a bottom up process, extracting from the deliverables, and research

reports produced in the MAIS project the quality dimensions considered relevant for each part of the adaptive

environment. Over 240 QoS dimensions have been identified and described in the Registry according to the

following schema, inspired by the ISO 9126 Software Quality model: characteristic (name and definition),

possible sub characteristic (name and definition), metrics (name and definition), method of measure, possible

range of values.

Quality dimensions are not distributed uniformly among the different MAIS models, since about 45% pertain to

the Architectural Model, 25% to the Channel Model, 15% to the E-service Model, 8% to the Context Model, and

the remaining ones are of uncertain attribution.

Concerning the Architectural model (about 100 dimensions defined), most of the quality dimensions refer to

device qualities (altogether one third of the total set of qualities), and can be classified more properly as technical

characteristics. A wide set of devices is taken into account such as: CPU, memory, printer, speaker, audio

controller, media access, speaker, microphone, modem, keyboard and other input devices, PDAs, and various

types of assistive technologies, such as pointers, screen readers and others. Typical technical characteristics

concern performance, availability, response time, power, frequency, and, when applicable, security characteristics

such as authentication.

Concerning the Channel Model (about 50 quality dimensions defined), relevant dimensions are interoperability,

maintainability, reconfigurability, security, reliability, throughput, bit rate, lifetime, fairness, flexibility, delay,

robustness, transfer and release error, resilience, electromagnetic pollution, power consumption.

Relevant qualities of the e-service Model (about 30 quality dimensions defined) are usability, mentioned in four

different sub-layers of the e-service model, accessibility, adaptivity, security, availability, price, time related

qualities such as response time, and different qualities related to data and information provided by the service,

such as accuracy and timeliness.

Finally, in the Context Model (17 quality dimensions assessed), relevance is given to accessibility, adaptability,

adaptivity, accuracy, perceivability, and performance issues.

In order to check the completeness of the quality dimensions set with respect to standard sets provided in the

literature, we have verified that device and network technical characteristics are widely covered, together with

related metrics and methods of measure, while software qualities cover only a limited set of characteristics and

34

sub-characteristics of the ISO 9126 standard; they are accessibility, learnability, operability, related to usability,

analyzability and changeability related to maintainability and fault tolerance related to reliability. In fact, quality

aspects typical of the software development process, such as testability and portability, are not issues being

addressed in the project.

The QoS Registry is now used in MAIS as a monitoring tool for achieving completeness in the approach to

quality and real integration among the different groups involved in the project. First of all, it can be adopted in

order to reach completeness, i.e. providing for each quality characteristic a definition, a metric, a method of

measure, and achieve consistency, i.e. eliminating synonyms, etc. Furthermore, in the first phase of the project,

quality dimensions have been defined independently, and only a negligible number of them have been related to

each other in order to characterize the dependencies existing among them, such as, for example, dependencies

among response times of different devices and network layers.

As we will see in the next sections, we are now working to guarantee these levels of representation.

The quality model proposed for the MAIS project focuses on the service negotiation between service provider and

user. The QoS Registry classifies the quality of service dimensions needed at different phases according to the

SOC paradigm. At service discovery time, the goal of the negotiation activity is to find a service provider that may

satisfy the required quality levels. The MAIS architecture finds the suitable provider and defines a contract.

During service provisioning (run time), the MAIS environment provides adaptation at different levels to maintain

the values of all quality parameters defined in the contract inside their admissible ranges. Another environment

currently investigated concerns redesign of services in terms of new channels (e.g. form internet to cellular

phone). Our research unit has mainly focused research in the redesign environment.

In cooperation with the research unit of Politecnico di Milano, a taxonomy for Qos Registry has been built that

focuses on the negotiation phase and regards mostly the provider side (both as service provider and as invocation

platform for service provisioning), analyzing the interaction with the user both at discovery time and at run time,

according to the preferences contained in the user profile (Fig.8).

35

Fig.8 Taxonomy of Quality of Service Dimensions

From the provider perspective, we distinguish between non-negotiable quality dimensions that characterize the

services supplied, and negotiable dimensions related to the resources used by the provider to offer services. These

dimensions can be contracted between the user and the provider. The user can express preferences or define

constraints on these dimensions in the service selection phase. On the provider side, negotiable quality dimensions

include, for example, bandwidth, price, and response time. They are used during the negotiation phase both at

discovery time, in order to choose one of the functionally equivalent services, and at run time, for achieving the

agreement on the desired quality level of the selected service.

On the user side, negotiable dimensions are used in the negotiation phase performed at discovery time, in order to

determine the user-specific access configuration. The configuration is based on the preferences contained in the

user profile and according to the technical characteristics of devices made available by the user.

In Table 1, we present how the proposed taxonomy may be applied to quality dimensions provided in the e-

service Model. Analogously, we might define quality dimensions for the Context, Channel, and Architectural

Models.

QoS

Quality dimensions -Provider

Negotiable Qualitydimensions

Intrinsic Service QualityDimensions

Service Delivery QualityDimensions

Negotiable Qualitydimensions - Provider

DeviceCharacteristics

User Profile

Negotiable Qualitydimensions - User

36

Negotiable Quality Dimensions

Quality dimensions - Provider

Negotiable

Quality

dimensions –

User

Intrinsic

Service Quality

Dimensions

Service

Delivery

Quality

Dimensions

Negotiable

Quality

dimensions -

Provider

Device

Charac.

User

Profile

e-service

Model

Reliability

Accountability

Traceability &

Audibility

Non repudiation

Data Reliability

Robustness

Security

Bandwidth

Price

Security

Accuracy

Completeness

Response time

Provisioning Time

Service Availability

Timeliness (Data)

Availability (Data)

Usability

(Use

context)

Usability

(pleasure)

Table 1 - Taxonomy for the e-service Model quality dimensions

Non-negotiable dimensions in the e-service Model are, for example, service and data reliability as intrinsic

characteristics of the service and robustness and security of the application as criteria related to the resources used

for the service delivery. At the e-service Model there are many general (non domain-specific) negotiable

characteristics, such as the service price, security and availability. Response time and the provisioning time are

two important efficiency indices of the service. Response time is referred to the time interval between the time

instant in which the user sends the service request and the time instant in which the user gets a response. The

provisioning time instead considers the time interval required for the complete service delivery. The two indices

might coincide for services that are completely delivered in an electronic way.

As regards the user side, there are only dimensions related to usability contained in the User Profile. Indeed, the

quality dimensions associated with the user devices are located at the Channel model level.

Note that many quality dimensions belonging to different models are related to each other. For example, response

time depends on both channel characteristics (i.e. networks dimensions) and architectural characteristics (i.e.

dimensions related to resources involved in the provider delivery architecture). As another example, usability

depends on many different characteristics such as response time, accessibility, performance, and adaptability. The

taxonomy of qualities is currently extended to consider dependency relationships, in order to build the so called

“light” model of qualities.

37

4.3. The role of QoS in Web Service Redesign

In this chapter, QoS role in the methodology is addressed by discussing in depth the involved phases. The primary

objective of the methodology is to adapt existing services for a multi-channel use by considering QoS related to

service definition and provisioning as a description of technological and user requirements.

Activities to address QoS can be summarized as follows:

• Define new functional and non functional requirements;

• Compare user quality requirements with the MAIS QoS Registry (QR) and extract relevant QoS

dependency sub-trees;

• Classify extracted qualities in terms of the MAIS classification;

• Check the compatibility of quality requirements with negotiable and non negotiable qualities of the MAIS

infrastructure.

• Compare user quality requirements with the MAIS User Profile (UP) Registry (UPR);

• Build the QoS/UP Matrix on the base of intrinsic dependencies and application domain relevance;

• Check compatibility of QoS/UP with negotiable and non negotiable qualities of the MAIS infrastructure.

Next paragraphs discuss these activities as part of the phases: High-level redesign and Customization.

4.3.1. Phase 2: High-level redesign

The second phase of the methodology aims to redesign the service architecture, described by UML diagrams, in

the light of new requirements enabled by the new channels and by domain characteristics.

Inputs necessary for this phase are:

• New services provided by new channels: new opportunities for the enrichment of the service under re-

design derived from the technical characteristics of the available channels. For example, localization

techniques introduced by mobile devices are new available technical characteristics that support a new

opportunity: the knowledge of the position of a user on the territory. This information allows to specify

new requirements for the enrichment of the service;

• User quality requirements: quality dimensions related to user and domain needs. They are considered in

an abstract way and they must be verified in the customization phase.

38

Fig. 9 shows the four sub-phases of the high level redesign phase that are discussed in the following paragraphs.

The final output is an enriched UML Diagram set that defines the logical and operational structure of the

redesigned service.

Analysis of User Quality requirements (UQR)

In the first sub-phase of the High-level redesign phase it’s necessary to locate the quality dimension related to user

quality requirements that are described in an high-level language. The MAIS QoS Registry is used to locate and to

define the QoS in the right mode.

Examples of UQR are the following:

1. Sensitive data must be available only for privileged user;

2. Perform actions on the territory in short time;

2.2 QoS classification

2.3 Marge and Matching

2.4 New service modeling

User Quality requirements

(UQR)

Non-negotiable

QoS (provider)

and

Negotiable User New service

requirementsUML

diagrams

Negotiable QoS:

(provider

and device

2.1 UQR analysis

QoS

Domain

knowledge

Enriched UML

diagrams

New service provided

by new channels

Fig. 9 High-level redesign phase subdivision

39

3. The service must be easy to understand, learn and use for every user of the domain.

The UQR analysis associates the following QoS with the considered UQR:

1. Security;

2. Precision of localization;

3. Usability.

Some QoS are easily located (the first UQR is clearly referred to the system security), for others a domain expert

is necessary to associate a proper QoS with a UQR (e.g. precision of localization).

In the last step of this sub-phase, a qualitative value (e.g. low/medium/high) must be associate with each QoS. On

proposed examples the associated values are the following:

1. Security = HIGH;

2. Precision of localization =HIGH;

3. Usability = MEDIUM/HIGH.

QoS Classification

In this sub-phase, the qualities previously identified are classified according to MAIS model shown in Fig.8. The

model specifies quality dimensions in the following way:

• Negotiable dimensions used in the negotiation phase performed at run time. They are classified in two

categories:

o Negotiable quality dimension – Provider: qualities dimensions related to the resources used by the

provider to offer services;

o Negotiable quality dimension – User: qualities dimension required by the final users or related to

the user device characteristics;

• Non-negotiable quality dimensions that characterize the service delivery from the provider side. They are

classified in two categories:

o Intrinsic service quality dimension;

o Service delivery quality dimension.

40

Continuing with the example, such taxonomy allows the classification of the qualities previously introduced as

follows:

• Security: non-negotiable QoS related to the service delivery;

• Precision of Localization: negotiable QoS related to user devices characteristics.

• Usability: negotiable QoS related to user profile.

Merge and matching

In this sub-phase, the operation of merge and matching is executed among quality dimensions previously located

and new opportunities introduced by new channels. Negotiable dimensions related to provider and device

characteristics are the only quality aspects that must be considered. Non-negotiable dimensions and negotiable

dimensions related to final user will be directly modelled in the UML diagrams.

In this moment, a domain expert analyses the results of the merge and matching operation and defines the

requirements for the enrichment of the service.

For example, localization is enabled by localization techniques (e.g. Triangulation techniques of telephone cells

for the GSM protocol) introduced by mobile devices. Using this new opportunity, a expert domain formalises new

requirements. For example, in the domain considered in the methodology (IZS), the localization can be used to

supply the vet with an itinerary to follow to accomplish herd controls. This itinerary is planned considering the

actual position of the vet on the territory.

New service modeling

In the last sub-phase, modifications to UML diagrams produced in the Actual service modeling phase are realized.

The sequence of operations that are necessary to modify the models is shown in Fig. 10. UML diagrams are

modified accordingly to new service requirements defined in the previous sub-phase. Initially, the use-cases

diagram is modified by the revision of previously modelled use-cases and by the introduction of new ones. As

second step, the activity diagrams are introduced to describe each new/revised use case.

Moreover, new attributes, methods and classes are introduced in the class diagram. Finally, a set of sequence

diagrams are used to model the interaction between user and system.

41

Fig. 10 New service modeling subdivision

In this sub-phase not only functional aspects of the service but also the quality aspects must be modelled. So, the

UML Profile proposed by OMG [21] is used. This extension of standard UML permits to model qualities of

service using two different diagrams.

The QoS Characteristics diagram for modelling quantifiable aspects of QoS is shown in Fig. 11.

Fig. 11 The QoS characteristics diagram

The constructors involved in the QoS Characteristics diagram are:

• QoS Characteristic: is the constructor for the description of non-functional aspects (e.g., latency,

throughput, capacity, scalability, availability etc…). The attribute isInvariant specifies when the QoS

Characteristic can or cannot update the value of dimensions dynamically.

New \ Revised

use-cases

New \ Revised

activities

New \ Revised

classes

New \ Revised

interactions

Enriched UML diagrams

UML diagrams New service requirements

42

• QoS Parameter: is used for the parameterization of the units and types for the description of value

definitions, or some specific methods for the quantification of the values.

• QoS Dimension: is used for the quantification of QoS Characteristics. It is characterized by the

following attributes:

o direction : defines the type of order relation (increasing or decreasing);

o unit : defines the unit for the values of the dimension;

o statisticalQualifier : gives the type of statistical qualifier (e.g. maximum value, minimum value,

range etc…) when the value of the dimension represents a statistical value.

• QoS Category: is used for grouping QoS Characteristics. Examples of general groupings are:

Performance, Dependability and Security.

• QoS Value: associates a quantifiable QoS values to a specific QoS Characteristics.

• QoS Dimension Slot: represents the value of a primitive QoS Dimension or a reference to another QoS

Value.

• QoS Context: allows describing the context of quality expression when it includes multiple QoS

Characteristics.

QoS Context connects the QoS Characteristics diagram with the QoS Constraints diagram in the following way:

Fig. 12 connection between QoS characteristics diagram and Constraints diagrams

A QoS Constraints diagram is used for defining any kind of restriction impose on QoS characteristics. This

diagram considers technological characteristics and so it is modelled in the channel customization sub-phase.

43

4.3.2. Phase 4: Customization

The high-level redesign phase of the methodology produces the logical design of the analyzed service. The quality

aspects, in this phase, are considered in an abstract way.

On the contrary, the goal of the customization phase is the production of the physical design of the service

considering two important aspects: adaptability to the available channels and to user profile.

The customization phase is divided in two sub-phases: channel and service customization.

Phase 4a: Channel customization

Fig. 13 Channel customization sub-phase subdivision

Fig. 13 shows the five steps of the channel customization sub-phase. In the following paragraphs, each step is

described in details.

Analyze relationships among QoS and extract relevant QoS tree

The goal of this sub-phase is the extraction of relevant QoS tree starting from the MAIS QoS tree and the

previously analyzed quality dimension.

Tools of MAIS system:

Reflective Architecture

4a.1 Analyze relationships among QoS

and extract relevant QoS tree.

4a.2 Set weight for every QoS. 4a.3 Set range of values for every QoS.

4a.4 Assumption evaluation.

4a.5 UML diagrams modeling

Technical characteristics

of the new channels

Enriched service models

Assumption revision

44

The activities involved in this sub-phase are:

• Check the presence of the considered quality dimensions in the MAIS QoS tree. Such verification

process is realized crossing the tree and finding the related quality.

• Starting from the identified node, analyze the relationships among QoS described by the MAIS tree.

• Focusing on the considered domain, identify the suitable relationships among QoS.

• Extract the identified QoS tree.

Fig. 14 An example of relevant QoS tree

For example, considering Usability and IZS as specific domain, Fig. 14 represents the output of this sub-phase.

Each node shows a quality dimension included in the MAIS registry and each line identifies the relationships

among the qualities.

Set weight for every QoS

In this sub-phase, a weight is associated with every node of the identified tree. This weight is a numeric value that

represents the level of influence among a parent node and its child. The numeric value is decided by a domain

expert and can be dissimilar in different domains.

For example, the level of influence between Usability and its child nodes for the IZS domain is shown in Fig. 15.

USABILITY

COMPREHENSIBILITY LEARNABILITY OPERABILITY PLEASANTNESS

SCREENQoS NETWORKINTERFACEQoS

RESOLUTION SIZE CONTRAST BRIGHTNESS COLORDEPTH

45

Fig. 15 An example of relevant tree with weights for every nodes

Following this procedure, the weights are assigned to each node using a top-down approach.

Set range of values for every QoS

This step of the channel customization is performed in concurrency with the previous described step. In fact, the

goal is to identify the range of possible values for the technical characteristics of the available channels that are

represented as leaf node in the QoS tree.

An example of values for the technical characteristics related to ScreenQoS is shown in Fig. 16.

Fig. 16 An example of relevant tree with range of values

Assumption evaluation

Considering the range of values for the technical characteristics identified in the previous step, it’s necessary to

associate qualitative values (e.g. low/medium/high) to each node of the tree using a bottom-up approach.

Such operation permits to estimate the compatibility between the qualitative value associated with the root of the

tree and the value associated with the QoS during the user quality requirements analysis.

USABILITY

0,2 0,4 0,3 0,1

SCREENQoS

RESOLUTION

[800x600]…[1024x640] SIZE

[1.0”…19.0”]

CONTRAST

[….]

BRIGHTNESS

[…]

COLORDEPTH

[16bit…64bit]

COMPREHENSIBILITY LEARNABILITY OPERABILITY PLEASANTNESS

46

In the following the Usability compatibility estimation is considered. During the second phase of the methodology

the value “MEDIUM/HIGH” has been associated with this QoS. It’s necessary to execute the following operation

to perform the estimation of the compatibility:

• A set of tuple composed by a single value (included in the range defined in the previous step) for each

technical characteristic are established. Considering the range of values proposed for Resolution, Size and

Color depth of available screens, examples of possible tuples are the following:

T1 = <800x600, 5.0” , …, 32 bit> ; . . . ; Tn= <1024x640, 19.0”, …, 64 bit>

• The domain expert associates each tuple with a qualitative value. This value represents the level of quality

of the parent node. In the proposed example, T1 and Tn determine different ScreenQoS value:

T1 ScreenQoS = LOW; . . .; Tn ScreenQoS = HIGH

• Considering the qualitative value associated with each tuple, it’s possible to establish a range of values for

the parent node. For example, ScreenQoS is characterized by the following range: [LOW…HIGH].

• This bottom-up approach is used to assign a range of qualitative values to each node. So, in the analyzed

example, it’s possible to assign to Usability the following range: [LOW…HIGH].

• Finally, it’s possible to estimate the compatibility. During the second phase of the methodology the value

“MEDIUM/HIGH” has been associated with this QoS. The range of values [LOW…HIGH] is suitable to

satisfy such value so the assumptions performed in the high-level redesign phase are satisfied and it’s not

necessary to come back to the second phase.

If there is incompatibility between the required value for a QoS and the range of possible values identified in the

previous step, it’s necessary to use a top-down approach to underline in the tree the QoS characterized by a low

value. For doing this operation not only the range of value but also the weight associated with each node must be

considered. Incompatibility is resolved using one of the following possibilities:

• Consider new channel characterized by different technical characteristics. This operation is used to

increase the range of possible values;

• Come back to high-level redesign phase and revise the service considering the discovered limitations.

47

UML diagrams finalization

In the last step of this phase, UML diagrams are updated and modified. This operation must take into account the

assumption evaluation performed in the previous step.

Moreover, the QoS Constraints diagram must be modelled. This diagram (shown in Fig. 17) is used for defining

any kind of restriction impose on QoS characteristics.

Fig. 17 The QoS Constraints diagram

The constructors involved in the QoS Constraints diagram are:

• QoS Constraint : limits the allowed values of one or more QoS Characteristics. The QoS Context

establishes the vocabulary of the constraint, and the QoS Constraint the allowed values.

• QoS Required : can be defined by the client or by the provider. When a client defines this kind of

constraint, the provider must provide services with the quality constraint required by the client. When the

provider defines its Required QoS constraint, the client must achieve some quality requirements to get

the quality offered.

• QoS Offered : can be defined by the client or by the provider. When the provider defines an Offered QoS

constraint, it is the provider who must achieve the constraint. When a client defines an Offered QoS

constraint, the client must achieve the constraint invocating the service.

• QoS Contract : establishes an agreement between all constraints.

• QoS Compound Constraint : is the combination of a set of constraints that ensemble represent a QoS

Constraint for a single mode of execution.

48

Phase 4b: Service customization

Fig. 18 Service Customization sub-phase subdivision

Fig. 18 shows the four steps of the service customization sub-phase. In the following paragraphs, each step is

described in details.

UP – QoS mapping

The goal of this step is the creation of the UP/QoS Matrix that defines the dependencies between the QoS

previously described and the UP characteristics. Reference user profiles for the considered domain are extracted

from the UP MAIS Registry and considered to set the matrix.

For example, considering Usability as quality dimension, Fig. 19 shows the UP/QoS Matrix for the IZS domain.

QoS

UP

Comprehensibility

Learnability

Operability

Pleasantness

Is_ltf_pref. X X

Is_ltf_skills X X

ICF_rel_capab. X

ICF_body_funct. X X X

Expertise X X X

Delivery pref. X X X X

Fig. 19 An example of QoS/UP Matrix

4b.1 UP – QoS mapping User Profile (UP)

Mapping table

4b.2 Set weight for each mapping

4b.3 Assumption evaluation

Table with weight

4b.4 UML diagrams revision

Assumption revision

49

QoS dimensions (Comprehensibility, Learnability, Operability, Pleasantness) are the columns of the matrix, user

profile dimensions are (Is_ltf_pref., Is_ltf_skills, ICF_relational_capabilities, ICF_body_function, Expertise,

Delivery preferences) the rows of the matrix.

The “x” highlights the dependency between a QoS and a UP dimension. In the proposed example, the Operability

dimension is related to Is_ltf_skills (ability to perform a particular operation), ICF_relational_capabilities

(capacity to interact with the system), ICF_body_function (physical and psychological condition of the user),

Expertise and Delivery preferences.

Set weight for each mapping

In this sub-phase, a weight is associated with each identified dependency with a procedure similar to the one

proposed in the channel customization sub-phase. Weights are numeric values that represent the level of influence

between QoS and UP dimensions. Numeric values are domain dependent and therefore assigned by domain

experts.

Considering the IZS specific domain, the QoS/UP Matrix shown in Fig. 20 can be characterized by the following

weights for each identified dependency.

QoS

UP

Comprehensibility

Learnability

Operability

Pleasantness

Is_ltf_pref. 0,1 0,5

Is_ltf_skills 0,2 0,2

ICF_rel_capab. 0,1

ICF_body_funct. 0,4 0,5 0,2

Expertise 0,3 0,2 0,1

Delivery pref. 0,2 0,1 0,4 0,5

Fig. 20 QoS/UP Matrix with weights

Assumption evaluation

The matrix produced in the previous step is used to evaluate the assumptions taken in the high-level redesign

phase.

In the following, the activities to be performed are listed and applied to Operability/Delivery-preference

dependency as an example.

50

• For each QoS dimension, consider the weight associated with each crossing to identify the UP

characteristics that are relevant for that QoS. For example, operability is influenced by delivery-

preference quality (the highest weight in the column). Assuming that a possible value for the delivery

preference is:

o Delivery preference = text message.

the crossing between operability and delivery pref. is set to “LOW”.

• Check if the QoS of the modelled service is compatible with the UP characteristics. For example, the

check for operability fails since the strongest UP requirements (delivery preference) do not mach the

assumption that the modelled service has “HIGH” operability, given by graphical capabilities.

If the check does not fail, there are two possibilities. The UP characteristics fit perfectly the assumed

QoSs, or there are only partial compatibility and some adaptations need to be performed. In the latter

case, the next step is performed. Partial compatibility may occur when QoS ranges partially overlap or

when there exist different UP characteristics to be addressed.

UML diagrams revision

This step is executed only when partial compatibility is detected in the previous phase. UML diagrams must be

modified to realize alternative versions of the service. New quality constraints are posed and alternative sets of

UML diagrams are produced.

51

References

[1] M. Akbar, E. Manning, G.Shoja, and S. Khan. Heuristic solution for the multiple-choice. In Conference

on Computational Science, 2001.

[2] G. Alonso, F. Casati, H. Kuno, and V. Machirayu. Web Services: Concepts, Architectures and

Applications. Springer-Verlag, Heidelberg, New York, 2004.

[3] C. Cappiello, C. Francalanci, and B. Pernici. Data quality assessment from the user’s perspective. In IQIS

2004, 2004.

[4] C. Cappiello, P. Missier, B. Pernici, P. Plebani, and C. Batini. Qos in multichannel is: the MAIS approach.

In International Workshop on Web Quality, Munich, 2004.

[5] F. Casati, B. Benatallah, and H. Skogsrud. Trust-serv: Model-driven lifecycle management of trust

negotiation policies for web services. In Proceedings of the 13th World Wide Web Conference, New York

NY, USA, May 2004.

[6] M. Comuzzi and B. Pernici. Description of web service negotiation capabilities. In Proceedings of the 1st

EDOC Workshop on Contract Architectures and Languages, Monterey CA, USA, September 2004.

[7] M. Comuzzi and B. Pernici. Negotiation for Web Service selection. In Proceedings of the 5th VLDB

Workshop on Technologies for E-Services, Toronto, Canada, August 2004.

[8] D. Box. et al. Web Services Policy Attachment (WS-PolicyAttachment). IBM, Microsoft, BEA,

September 2004.

[9] D. Box. et al. Web Services Policy Framework (WS-Policy). IBM, Microsoft, BEA, September 2004.

[10] F. Cabrera. et al. Web Service Coordination (WS-Coordination).

http://www- 106.ibm.com/developerworks/library/ws-coor/, September 2003.

[11] T. Andrews. et al. Business Process Execution Language for Web Services (BPEL4WS), May 2003.

[12] M. Gillman, G. Weikum, and W. Wonner. Workflow management with service quality guarantees. In

ACM Sigmod 2002, June 2002.

[13] H.C.-L and K. Yoon. Multiple Criteria Decision Making. Lecture Notes in Economics and Mathematical

Systems. Springer-Verlag, 1981.

[14] A. Hiles. E-Business Service Level Agreements. The Rothstein Catalog on Service Level Books, 2002.

[15] N. R. Jennings, P. Faratin, A. Lomuscio, S. Parsons, C. Sierra, and M. Wooldridge. Automated

negotiation: Prospects, methods and challenges. International Journal of Group Decision and Negotiation,

10(2):199–210,2001.

[16] Z. Maamar, Q. Z. Sheng, and B. Benatallah. Interleaving Web Services composition and execution using

software agents and delegation.

[17] P. Wohed, W. P. van der Aalst, M. Dumas, and A. H. M. ter Hofstede. Pattern based analysis of bpel4ws.

[18] L. Wolsey. Integer Programming. John Wiley & Sons, 1998.

52

[19] L. Zeng, B. Benatallah, M. Dumas, and J. K. andH. Chang. Qos-aware Middleware for Web Services

composition. IEEE Transactions on Software Engineering, May 2004.

[20] L. Zeng, B. Benatallah, M. Dumas, J. Kalagnamam, and Q. Z. Sheng. Quality driven web services

composition. In WWW2003, May 2003.

[21] UML Profile for Modeling uality of ServiceQuality of Service and Fault Tolerance Characteristics and

Mechanisms. OMG report (September 2004).

[22] Manuale Operativo per la gestione dell’anagrafe bovina. (operating manual of the bovine registry) Decreto

del 31 gennaio 2002. Versione del 10 maggio 2002.

http://www.anagrafe.izs.it/presentazione_new/manuale_operativo.pdf.

[23] Graziani P., Billi R., Burzagli L., Gabbanini, Palchetti, Bertini E., Kimani S., Sbattella L., Barbieri,

Bianchi and Batini C. Definition of User Typologies. (2003) MAIS project internal report R 7.3.1.

[24] Colangeli P. and ZippoD. Accesso Multicanale alla BancaDati Nazionale. IZSAM internal report, 2004.

[25] Adorni M., Arcelli F., Raibulet C. and Tisato F. Architectural Reflection in Adaptive Systems.

Proceedings of the 2004 Conference on Software Engineering (SEKE2004), accepted to be published,

2004.

[26] Bertini E. and Santucci G. Modeling Internet based applications for designing multi-device adaptive

interfaces. Proceedings of the International Conference on Advanced Visual Interfaces, (AVI 2004),

Gallipoli, June 2004.

Documents

Negotiation Protocols Definition · required for negotiation protocol specification are described in the UML class diagram of Figure 2.1. We identified two aspects of a negotiation