a quality-driven web service composition methodology for ubiquitous services

JOURNAL OF INFORMATION SCIENCE AND ENGINEERING 26, 1957-1971 (2010)

1957

A Quality-Driven Web Service Composition Methodology for Ubiquitous Services*

HEEJUNG CHANG AND KANGSUN LEE+

Department of Computer Engineering MyongJi University

Yongin Kyungki, 449-728 Korea

Ubiquitous computing enables computational services pervasive. Web service is an

efficient technology to provide interoperability between components dispersed on net-works and various devices, regardless of platforms and languages, and thus, is massively used to develop ubiquitous computing applications. In order to provide transparent ser-vices in ubiquitous environment, we need to consider various quality constraints during execution of web services, selection of contexts to use, and determination of operational devices. In this paper, we define a quality model for ubiquitous computing applications, and propose a quality-driven web service composition methodology. EWC (Event-driven Web service Composer) is our tool for supporting the proposed methodology. We illus-trate how users can benefit from EWC to provide ubiquitous services transparently, with an example of monitoring diabetics. Keywords: web services composition, quality model, multi-criteria decision making, ubiquitous computing, dynamic reconfiguration

1. INTRODUCTION

Ubiquitous computing technology allows users to obtain services through the computer network, anytime and anywhere. Web service is an enabling technology to develop ubiquitous services by providing efficient interoperability mechanism between distributed components with the purpose of being accessed and used ubiquitously by suppliers and customers [1, 2]. Ubiquitous services should be composed in a quality- driven fashion, in order to operate transparently and seamlessly through networks and various devices [3, 4]. However, most quality-driven web service composition methods are limited partially due to the following reasons.

• Composition approaches give only limited consideration to qualities such as response

time and availability [5-7]. In ubiquitous environments, where various contexts, events and devices are coupled to provide successful services, we need to consider quality in context (e.g. contexts precision and up-to-date) and operational devices (e.g., device availability) to satisfy users.

• Most composition approaches evaluate quality by an objective function to be minimized (e.g., response time or cost) or maximized (e.g., availability) with constraints to be satisfied [7-9]. An efficient mechanism should be devised to address conflictions between quality factors, which are hard to express in monolithic objective functions.

Received June 15, 2009; revised September 4, 2009; accepted December 21, 2009. Communicated by Chih-Ping Chu. * This work was supported by Defense Acquisition Program Administration and Agency for Defense Devel-

opment under the contract UD080042AD, Korea. + Corresponding author: [email protected].

HEEJUNG CHANG AND KANGSUN LEE

1958

• Ubiquitous computing can be characterized as a nondeterministic and complex inter- networking environment in which contexts change dynamically. However, most quality-driven composition approaches tend to be static so that the process of web service composition is done once in off-line, and never be changed later even when severe fail- overs on quality occur for the services.

In this paper, we propose a quality-driven web service composition methodology for ubiquitous applications and introduce EWC (Event-driven Web services Composer) to implement our methodology. Our methodology evaluates the quality of ubiquitous web services in three dimensions: QoS (quality of services), QoC (quality of contents), and QoD (quality of devices). QoS considers quality during the execution of web services, while QoC and QoD addresses quality in the content with which the web services work, and in the devices on which the web services operate, respectively. Based on MCDM (multi-criteria decision making) techniques, we evaluate various quality factors and provide a priority ordering of web services that resolve conflicting quality constraints. EWC also monitors the composed web services in order to dynamically reconfigure them if unexpected events occur and affect quality negatively.

This paper is organized as follows. In section 2, we present a three-dimensional quality model to address QoS, QoC and QoD. Section 3 explains our quality-driven web service composition methodology for handling multi-criteria quality. Section 4 introduces EWC, as an enabling tool for our methodology. Section 5 gives an example of DiabetesMonitoring service to illustrate how we can benefit from EWC to develop ubiquitous services. Section 6 reviews related efforts and section 7 summarizes this work with future works to achieve.

2. MULTI-CRITERIA QUALITY MODEL

Ubiquitous environment forms from the convergence of a variety of services and devices, and therefore, various quality factors are involved to provide transparent and seamless services.

Our quality model considers quality in three dimensions − QoS (quality of services), QoC (quality of contents), and QoD (quality of devices). Quality of service considers quality during the execution of web services and includes performance, interoperability, security, and so on. Successful services depend on the quality of information exchanged among web services. The information must be correct, real, fresh, and available at the right time. QoC refers to the quality of content with which the web services work and the information exchanged. Examples of QoC are precision, correctness and resolution of context. Web services are deployed on various devices and they should promise high quality to operate correctly. QoD addresses the quality of devices and the physical envi-ronment in which the web services operate. Examples of QoD are processor speed, mem-ory capacity and power of devices [19]. Table 1 summarizes our quality model.

QUALITY-GUARANTEED WEB SERVICES FOR UBIQUITOUS ENVIRONMENT

1959

Table 1. Our quality model in ubiquitous environment.

Dimensions Quality Factors Description

Price Price refers to payment for value generated by using web services.

Usability Usability is a quality factor that evaluates how closely web services are built on a consumer’s perspective such as consumer interface suitability.

Reputation Reputation formed explicitly or implicitly by web services consumers.

Response Time

Response Time refers to duration from the time of the request message sent from a web services user to the time of the response message returned to the web services. (ResponseTime = CompleteResponeTime – UserRequestTime)

Maximum Throughput

Maximum Throughput refers to a maximum number of responses that can be processed in unit. (MaximumThroughput = max(NumberofProcessDur-ingMeasureTimMeasuredTime)

Availability It is a measurement which represents the degree of which web services are available in operational. (Availability = 1 – downtime/MeasuredTime)

Accessibility Accessibility represents probability of which web services platform is accessi-ble while the system is available. (Accessibility = NumberofAckMessage/ NumberofRequestedMessage)

Successability Successability is probability of returning responses after web services are successfully processed. (Successability = NumberofSucessfulResponse/ NumberofRequestedMessage)

Interoperability Interoperability indicates the degree of which messages are appropriately exchanged and used by using specifications.

Reliable Messaging

Reliable Messaging refers to guaranteeing to exchange messages without any errors as senders of receivers intended.

Observability Observability is the feature to provide the management information of web services and its related resource.

Confidentiality Controllability is the feature which can change the internal information of web services and its related resources from outside.

Integrity Integrity is to protect from unauthorized service/message modify, delete and create. It uses access control and briefing message.

Authentication Authentication is to verify and object that can be trusted for the transmission.

Access Control Access Control is the control over access on service/message for each actor’s right.

Quality of Services

Privacy Privacy is the protection of information between web services user and provider.

Precision Precision describes how exactly the provided context information mirrors the reality.

Probability of Correctness

Probability of Correctness denotes the probability that a piece of context information is correct.

Resolution Resolution denotes the granularity of information. Up-to-Dateness Up-to-Dateness describes the age of context information.

Input Size Input Size refers to data size of web service’s input parameters. Output Size Output Size refers to data size of web service’s output parameters.

Quality of Contents

Amount of Data Amount of Data is amount of web service’s holding contents.

Processor Speed Processor Speed refers to device’s processor on which the web services operate.

Memory Capacity

Memory Capacity refers to device’s working memory on which the web services operate.

Power It is battery capacity of device on which the web services operate.

Quality of Devices

Network Speed Network Speed refers to bandwidth and latency.


1960

Fig. 1. A multi-criteria quality driven web service composition method.

3. MULTI-CRITERIA QUALITY-DRIVEN WEB SERVICES COMPOSITION METHODOLOGY

Quality factors in Table 1 are measured simultaneously and often conflict with each others. Our web service composition method is based on PROMETHEE (Preference Ran- king Organization METHod for Enrichment Evaluations), a well-known MCDM (Multi- Criteria Decision Making) solution [10]. For the given priority order of multi criteria, PROMETHEE performs pair-wise comparisons repeatedly to resolve conflictions of the comparative factors [11]. PROMETHEE requires two types of information. The first is information on the relative importance (i.e., the weights) of the criteria considered. The second is information on the decision maker’s preference function which he/she uses to compare the contribution of the alternatives in terms of each separate criterion [19].

In order to apply PROMETHEE to our problem, we structure the problem hierar-chically as shown in Fig. 1. Firstly, a user specifies the comparative significance among the quality dimensions, and then determines the ordering of quality factors within each quality dimension. For a given ordering of quality factors, our method systematically determines weights of the quality factors based on rank order centroid method [12, 13].

3.1 Weighting Quality Tradeoffs

In our method, the weight wl of the lth ordered factor among n quality factors is ex-pressed as follows.

1 1 ( 1, 2, ..., )n

lk l

w l nn k=

= =∑ (1)

As shown in Fig. 1, we first rank the quality dimensions (QoS, QoD, and QoC) and then rank quality factors according to their importance within each dimension. The weight qwij of the jth ordered quality factor in the ith ordered quality dimension is expressed as follows.


1961

1 1 ( 1, 2, ..., )

1 1 ( 1, 2, ..., )

ij i j

a

ik i

b

jk j

qw dw qw

dw i aa k

qw j bb k

=

=

= ×

= =

= =

∑

∑

(2)

where, a is the number of quality dimensions, b is the number of quality factors within a dimension, dwi is the weight of the ith ordered quality dimension, and qwj is the weight of the jth ordered quality factor.

3.2 A Multi-Criteria Quality-Driven Web Service Composition Method

In this section, we present our methodology for quality-driven web services compo-sition. Detailed procedure is presented as follows:

Step 1: Definition of abstract workflow. Abstract workflow defines how web services are formed into a new ubiquitous web

process using BPMN (Business Process Modeling Notation) [14]. With BPMN, web services are represented as tasks, while the order that activities are performed in is rep-resented as flows. In addition, we use event notation of BPMN to represent context. The context is any information that can be used to characterize the situation that relates to the interaction between a user and an application.

Step 2: Selection of quality factors. Based on the function of each task and its operational constraints, we specify qual-

ity factors in three dimensions: QoS, QoC and QoD.

Step 3: Determination of quality weights. According to the significance order of quality dimensions and quality factors within

each dimension, weights of quality factors are determined systematically according to the equations as shown in section 3.1.

Step 4: Definition of the constraints of quality factors. A constraint quantifies a quality factor with an extremum (minimum, maximum) or

a preference function. A “minimum” constraint indicates that the given quality factor should be minimized to satisfy users, as in the case of cost. Then, we decide a preference function. In pair-wise comparison of alternatives, the preference function translates the deviation (x) between the values of a given quality factor. A preference function quanti-fies the degree of preference with a value ranging from zero to one. If it is zero, “a” and “b” are indifferent. If it is close to zero, there is a weak preference for “a”. If it is close to 1, there is a strong preference for “a”. And if the preference function is 1, there is a strict preference for “a”. PROMEHTEE provides six basic types of preference functions [10]. We may use one of six types as shown in Fig. 2 to quantify various quality factors. In Fig. 2, threshold q, p, and s have to be fixed for each quality factors. The q is the value of an indifference threshold, while p is the value of a strict preference threshold and s is the


1962

value of an intermediate value between p and q. Type 1 is a usual criterion and is the im-mediate preference. Type 2 is a quasi-criterion that introduces an indifference threshold, while type 3 is a criterion with linear preference that continuously increases until the indif-ference threshold is reached. Type 4 is a level criterion that comprises indifference and preference thresholds, and type 5 is a criterion with linear preference that increases con-tinuously between indifference and preference thresholds. Type 6 is a Gaussian criterion that follows a Gaussian law with a fixed standard deviation. For examples, two web ser-vices are indifferent if their response times do not exceed a given threshold. In this case, we can select a preference function of type 2 in order to effectively express throughput cri-terion. In the case of price, two web services are considered as indifferent if their prices are all less than the minimum of the given budget. Within the given range of budget, the preference is weak (0.5) to the cheaper web service. However, if one of the web services exceeds the given budget, the preference is strict to the other one. Type 4 reflects these characteristics, and, therefore, can effectively model the price. Fig. 2 summarizes pref-erence functions discussed so far and illustrates their applicability to quality specification.

Step 5: Determination of the preference index. The preference index π(a, b) expresses the preference of service “a” compared with

that of service “b” considering all quality factors. Conversely, π(b, a) is the preference of service “b” compared with that of service “a” considering all quality factors. The pref-erence index is defined by

1( , ) ( , )

k

q qq

a b p a b wπ=

= ∑ (3)

where pq(a, b) is the selection priority of service “a” compared with that of service “b” considering a quality factor q and it is calculated using the preference function. wq is the weight associated with the quality factor q and k is the number of quality factors. For all quality factors, preference indexes are specified.

Step 6: Determination of outranking flows. Outranking flows between web service candidates are defined by preference in-

dexes. The outgoing flow ϕ +(a) indicates the extent to which service “a” is preferred over all others. The incoming flow ϕ−(a) indicates the extent to which the other alterna-tives are preferred over service “a”. ϕ(a) is the net flow of the web service a, and de-fines the overall preference comparing to other web services with similar functionality. Outranking flows are expressed as follows.

1( ) ( , )1

1( ) ( , )1

( ) ( ) ( )

b A

b A

a a bn

a b an

a a a

ϕ π

ϕ π

ϕ ϕ ϕ

+

∈

−

∈+ −

=−

=−

= −

∑

∑ (4)

where A is the set of all n alternatives. After step 6, we choose the web service that has the maximum ϕ value, as the opti-

mal web service to deploy for a given condition.


1963

Preference function Description Applicability

1, 0( )

0, 0x

p xx>⎧

= ⎨ ≤⎩

There is a strict preference for “a”.

Confidentiality, integrity and

privacy

1,( )

0,x q

p xx q>⎧

= ⎨ ≤⎩

In this case, “a” and “b” are indifferent as long as the deviation between the “a” and “b” does not exceed q.

Response time, maximum throughput

1, ( )

/ , x p

p xx p x p

>⎧= ⎨ ≤⎩

The intensity of preference increases linearly until this deviation equals p, after this value the preference is strict.

Usability, network speed

1, ( ) 0.5,

0,

x pp x q x p

x q

>⎧⎪= < ≤⎨⎪ ≤⎩

In this case, “a” and “b” are considered as indifferent when the deviation between “a” and “b” does not ex-ceed q, between q and p the preference is weak (0.5), after this value the preference becomes strict.

Price, up-to-dateness

1, ( ) ( )/( ),

0,

x pp x x q p q q x p

x q

>⎧⎪= − − < ≤⎨⎪ ≤⎩

In this case, user considers that “a” and “b” are comple- tely indifferent as long as the deviation between “a” and “b” does not exceed q. Above this value the preference grows progressively until this deviation equals p.

Reputation, precision

2 2( /2 ) , 1 0( )0, 0

x se xp xx

−⎧⎪ − >= ⎨≤⎪⎩

The preference still grows with the deviation x. The value of s may be easily fixed according to the experi-ence obtained with the Normal Distribution in Statistics. The value of s is the distance between the origin and the point of in-flexion of the curve.

Availability, successability

Fig. 2. Six types of preference function and their applicability to quality factors.


1964

4. EWC (EVENT-DRIVEN WEB SERVICE COMPOSER)

EWC is our tool to support the proposed methodology. In EWC, a user models his/ her personalized web service with BPMN and add events to consider dynamic changes of the services and context. Changes in services include the beginning and the end of a service, unexpected errors in the services, and so on. During execution, the EWC receives events, analyzes them, and reconstructs the web process dynamically. Fig. 3 shows the architec-ture of the EWC. Major components of the EWC are the Event-Driven Web Services Composition Designer, Event-Service Interaction Manager, Process Execution Planner, and Process Execution Manager. The Event-driven Web Services Composition Designer provides a graphical user interface for describing web services, context related, and the flow between them based on BPMN. The Event-Service Interaction Manager automati-cally generates “event-condition-action” rules that represent the relationship between services and events. The Process Execution Planner finds web service candidates by semantically searching available web services in the Internal Service Registry. The In-ternal Service Registry has service description files (*.wsdl) and quality description files (*.wsq). The Process Execution Planner determines the priorities for the candidates and finds the optimal web service for the given quality constraints as we explained in section 3.2. The Process Execution Manager executes and monitors the web services. If the de-ployed web services fail to meet quality criteria according to unexpected events, the Process Execution Manager reconfigures them with the help of Process Execution Planner.

Fig. 3. Overall architecture.

5. EXAMPLE: DIABETES MONITORING SERVICE

We illustrate the EWC with an example of DiabetesMonitoring service. The Diabe-tesMonitoring service evaluates patient’s status and alerts to patient’s family and medical professionals through events. If a patient’s blood sugar level is in danger, then the ser-vice searches the location of the patient and alerts the location of the patient to the pa-tient’s family. If the patient’s electrocardiogram is instable, then the service alerts to medical professionals with the location of the patient.


1965

Fig. 4. DiabetesMonitoring service.

In EWC, a user defines how web services are formed into a DiabetesMonitoring ser-vice using BPMN. In our example, the DiabetesMonitoring service is implemented with five tasks (evaluatingRisk, two searchLocations, alertToProtector, alertToPhysician) and two events (monitoringBloodSugar and monitoringElectrocardiogram) as shown in Fig. 4. We developed twenty five web services and ten event services as the candidates for the DiabetesMonitoring example. Quality factors of each service are specified in our xml- based description files (*.wsq). Then, we register the quality description files in EWC’s Internal Service Registry for the future dynamic discovery and bindings. In our example, quality factors have been specified with random numbers for simplicity. However, they could be easily replaced by vendors with real data, or measured by testers with various equations that have been proposed in many related research works [20].

The user also specifies desired quality factors for DiabetesMonitoring service, and prioritizes the quality factors by considering the functionality of each task and operational constraints. Then, EWC automatically determines the weight of each quality factor as discussed in section 3.1. For example, in a case of evaluatingRisk service, quality factors considered are successability, resolution, availability and network speed. Quality factors can be further constrained with preference functions, extremum, and thresholds. Then, EWC obtains quality information for candidate web services from the service registry and calculates outranking flow. After evaluating all tasks, EWC chooses the web service that has the maximum ϕ value for the optimal web service as we explained in section 3.2. Fig. 5 shows the steps of selecting quality factors, determining of weights, defining of the constraints, and determining outranking flows for the evaluatingRisk task. Fig. 5 sug-gests that the preference order of candidates for evaluatingRisk service is WS4, WS5, WS3, WS2 and WS1 (checkMethod, runCheck, diabetesEvaluate, evaluatingMethod and evaluatingRisk).

By considering all preference order of candidates, checkMethod, getLocationMethod, msgToProtector, and toPhysicianMethod are selected as the optimal web services to de-ploy for DiabetesMonitoring service as shown in Table 2. The EWC executes and moni-tors the web services. As soon as the deployed web service, msgToProtector for alertTo-Protector task is unavailable, the EWC reconfigures DiabetesMonitoring service and the second-ranked sendMsgProtector replaces the msgToProtector as shown in Table 3. EWC dynamically reconfigures the web services, if the deployed web services fail to meet the given QoC and QoD quality criteria according to unexpected events. Table 4 describes that the EWC reconfigures searchLocation task when the context correctness becomes lower to a given threshold. Table 5 also illustrates that the EWC reconfigures the web services if the device on which toPhysicianMethod service operates is unavailable. The seamlessness of composing web services is addressed in multi-phases – quality evaluation phase, web services selection phase and web service execution phase. In the


1966

Fig. 5. Steps of quality evaluation.

Table 2. Results of quality evaluation.

evaluatingRisk searchLocation alertToProtector alertToPhysician

cand

idat

es • checkMethod

• diabetesEvaluate • evaluatingMethod • evaluatingRisk • runCheck

• coordinatesMethod • findLocationMethod • getCoordinatesMethod • getLocationMethod • getPositionMethod

• alertingToProtector • alertToProtector • messageToP • msgToProtector • sendMsgProtector

• toPhysicianMethod • alertToPhysicianMethod • msgToPhysicianMethod • sendMsgMethod • sendToMsgMethod

sele

ctin

g

qual

ity fa

c-to

rs

1. Successability 2. Resolution 3. Availability 4. Network Speed

1. Probability of Correctness2. Price 3. Up To Dateness 4. Network Speed 5. Reputation 6. Response Time

1. Availability 2. Network Speed 3. Price 4. Precision

※ preferred order by user

pref

erre

d or

der

1. checkMethod 2. runCheck 3. diabetesEvaluate 4. evaluatingMethod 5. evaluatingRisk

1. getLocationMethod 2. coordinatesMethod 3. getCoordinatesMethod 4. getPositionMethod 5. findLocationMethod

1. msgToProtector 2. sendMsgProtector 3. alertingToProtector4. messageToP 5. alertToProtector

1. toPhysicianMethod 2. alertToPhysicianMethod 3. msgToPhysicianMethod 4. sendMsgMethod 5. sendToMsgMethod


1967

Table 3. Reconfiguration by unavailability.


preferred order


1. getLocationMethod 2. coordinatesMethod 3. getCoordinatesMethod4. getPositionMethod 5. findLocationMethod

1. msgToProtector 2. sendMsgProtector 3. alertingToProtector 4. messageToP 5. alertToProtector


availability test

1. checkMethod (O) 2. runCheck (O) 3. diabetesEvaluate (O)4. evaluatingMethod

(O) 5. evaluatingRisk (O)

1. getLocationMethod (O)2. coordinatesMethod (O)3. getCoordinatesMethod

(O) 4. getPositionMethod (O)5. findLocationMethod

(O)

1. msgToProtector (X)2. sendMsgProtector

(O) 3. alertingToProtector

(O) 4. messageToP (O) 5. alertToProtector (O)

1. toPhysicianMethod (O) 2. alertToPhysicianMethod

(O) 3. msgToPhysicianMethod

(O) 4. sendMsgMethod (O) 5. sendToMsgMethod (O)

notified event monitoringBloodSugar

executed service

1. checkMethod (O) 2. runCheck (O) 3. diabetesEvaluate (O)4. evaluatingMethod


1. getLocationMethod (O)

2. coordinatesMethod (O)3. getCoordinatesMethod


(O)

1. msgToProtector (X)2. sendMsgProtector






Table 4. Reconfiguration by correctness of context.


preferred order


1. getLocationMethod 2. coordinatesMethod 3. getCoordinatesMethod4. getPositionMethod 5. findLocationMethod



availability test

1. checkMethod (O) 2. runCheck (O) 3. diabetesEvaluate (O) 4. evaluatingMethod


1. getLocationMethod (O)2. coordinatesMethod (O)3. getCoordinatesMethod


(O)

1. msgToProtector (O)2. sendMsgProtector






notified event

• searchLocation: getlocationmethod:Probability of Correctness • monitoringBloodSugar

executed service

1. checkMethod (O) 2. runCheck (O) 3. diabetesEvaluate (O) 4. evaluatingMethod


1. getLocationMethod (O)2. coordinatesMethod

(O) 3. getCoordinatesMethod


(O)

1. msgToProtector (O)2. sendMsgProtector






quality evaluation phase, the QoS Evaluator checks the quality factors of each web ser-vices are fully specified with reasonable range of values. Then, the CandidateWS Man-ager ensures if there exists a group of web services that will meet the given quality con-


1968

Table 5. Reconfiguration by device unavailability.


preferred order


1. getLocationMethod 2. coordinatesMethod 3. getCoordinatesMethod 4. getPositionMethod 5. findLocationMethod


1. toPhysicianMethod 2. alertToPhysicianMethod3. msgToPhysicianMethod4. sendMsgMethod 5. sendToMsgMethod

availability test

1. checkMethod (O) 2. runCheck (O) 3. diabetesEvaluate (O) 4. evaluatingMethod (O) 5. evaluatingRisk (O)

1. getLocationMethod (O) 2. coordinatesMethod (O) 3. getCoordinatesMethod (O)4. getPositionMethod (O) 5. findLocationMethod (O)

1. msgToProtector (O) 2. sendMsgProtector (O)3. alertingToProtector (O)4. messageToP (O) 5. alertToProtector (O)

1. toPhysicianMethod (O)2. alertToPhysicianMethod



notified event

• alertToPhysician:toPhysicianMethod:HWAvailability problem • monitoringElectrocardiogram

executed service

1. checkMethod (O) 2. runCheck (O) 3. diabetesEvaluate (O) 4. evaluatingMethod (O) 5. evaluatingRisk (O)

1. getLocationMethod (O)2. coordinatesMethod (O) 3. getCoordinatesMethod (O)4. getPositionMethod (O) 5. findLocationMethod (O)

1. msgToProtector (O) 2. sendMsgProtector (O)3. alertingToProtector (O)4. messageToP (O) 5. alertToProtector (O)

1. toPhysicianMethod (O)2. alertToPhysicianMethod



straints. If exists, the CandidateWS Manager makes sure to deliver the optimal configu-ration of the web services to the Service Manager. The Service Manager deploys the comprising web services, and consistently monitors them. If any of the comprising web services underperforms the expected quality for the interesting events, the Service Man-ager makes sure the QoS Evaluator and CandidateWS Manager will redo their job be-fore the next event gathering cycle takes place.

6. RELATED WORKS

There have been many researches on the modelling and specification of QoS. Cur-rently, W3C and OASIS standardize QoS properties. Most approaches for modeling QoS are based on ISO/IEC9126. However, ISO/IEC9126 is mostly suitable for stand-alone applications, and has not been massively tested against web-based applications and ubiq-uitous computing applications. O’Sullivan et al. proposed an approach to formally de-scribe nonfunctional properties of services including payment, price, availability, obliga-tions, rights, security, trust, quality, discounts, and penalties [15]. Cardoso et al. pre-sented an approach based on time, cost, and reliability as important QoS criteria [16]. Ko et al. used execution cost, execution time, availability, successful execution rate, reputa-tion, and frequency as QoS properties [17]. Our quality model differs from them, since we consider quality with the combination of QoS, QoC, and QoD.

QoS-based service composition has been the subject of various research efforts. Usually, the consumer’s quality requirements are represented with quality properties. Then, mathematical or rule-based approaches are employed to find the best combination of web services for given quality constraints. Cardoso et al. proposed a QoS evaluation


1969

model of a composite web service based on workflow analysis [16]. Zeng et al. proposed a set of guidelines for service composition using user utility functions for QoS [6]. How-ever, they did not present a mechanism for resolving conflictions between quality factors. To resolve conflicts among quality constraints, Jaeger, Muhl, and Golze suggested a weighting technique to express relative importance [5]. Recently, MCDM technologies are applied to QoS-based service selection. Herssens et al. proposed an approach for dealing with trade-offs between QoS criteria during runtime service selection using PROMETHEE [11]. They selected five QoS characters: availability, latency, reliability, reputation and security. The weighting procedure depends on pairwise comparisons of quality factors. In the work of Seo et al., the web service selection process was described with MCDM. They resolved conflictions between quality factors by differentiating ser-vice levels. However, they assume that all levels of quality factors are given and did not propose a specific guideline to determine levels (or weights).

7. CONCLUSION AND FUTURE WORKS

Web service technology allows users to obtain services through computer networks, anytime, anywhere on any devices. In order to provide transparent services, various qual-ity factors should be considered to compose web services. Most researches on web ser-vice composition could not fully consider various dimensions of quality and possible conflictions between quality factors in ubiquitous computing environment. In this paper, we proposed a quality-driven web service composition methodology and developed EWC to support our methodology. Our methodology employs a multi-dimensional qual-ity model that addresses quality of service, quality of contents and quality of devices. And our methodology is based on MCDM approach but improves the previous works in two senses. Firstly, starting from the user’s specification of the priority order of quality factors, the weights of all quality factors are automatically determined by rank-order cen-troid method. Secondly, any conflictions between them are successfully resolved by em-ploying the systematic decision process. EWC realizes our composition methodology and determines the best combination of web services that meets both functional and non-functional requirements. Additionally, EWC monitors the deployed web services using events and dynamically reconstructs the web services when unexpected accidents may cause quality fail-overs. With the help of EWC, we are able to provide services with high quality and satisfaction. We would like to improve our work by continuously ap-plying EWC to various ubiquitous applications, including defense applications where quality and dynamic reconfiguration are crucial for success.

REFERENCES

1. B. Sleeper and B. Robins, “Defining web services,” 2001, http://www.perfectxml. com/Xanalysis/TSG/TSG_DefiningWebServices.pdf.

2. Z. Maamar, “On coordination personalized composite web services,” Information and Software Technology, Vol. 48, 2006, pp. 540-548.

3. S. Vinoski, “Integration with web services,” IEEE Internet Computing, Vol. 7, 2003, pp. 75-77.


1970

4. S. Ran, “A model for web services discovery with QoS,” ACM SIGecom Exchanges, Vol. 4, 2003, pp. 1-10.

5. M. E. Maximilien and M. P. Singh, “Toward autonomic web services trust and se-lection,” in Proceedings of the 2nd International Conference on Service Oriented Computing, 2004, pp. 212-221.

6. L. Zeng, B. Benatallah, A. H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang, “QoS- aware middleware for web services composition,” IEEE Transactions on Software Engineering, Vol. 30, 2004, pp. 311-327.

7. M. C. Jaeger, G. Mühl, and S. Golze, “QoS-aware composition of web services: an evaluation of selection algorithms,” in Proceedings of the OTM Confederated In-ternational Conferences, 2005, pp. 646-661.

8. A. Padovitz, S. Krishnaswamy, and S. W. Loke, “Towards efficient selection of web services,” in Proceedings of Workshop on Web Services and Agent-based Engineer-ing, 2003.

9. T. Buchholz, A. Küpper, and M. Schiffers, “Quality of context: What it is and why we need it,” in Proceedings of the 10th International Workshop of the HP OpenView University Association, 2003, pp. 1-14.

10. J. P. Brans and Ph. Vincke, “A preference ranking organization method (the PRO-METHEE method for multiple criteria decision-making),” Management Science, Vol. 31, 1985, pp. 647-656.

11. C. Herssens, I. J. Jureta, and S. Faulkner, “Dealing with quality tradeoffs during ser-vice selection,” in Proceedings of the 5th International Conference on Autonomic Computing, 2008, pp. 77-86.

12. F. H. Barron and B. E. Barrett, “Decision quality using ranked attribute weights,” Management Science, Vol. 42, 1996, pp. 1515-1523.

13. D. L. Olson, Decision Aids for Selection Problems, Springer-Verlag, New York, 1996.

14. S. White, “introduction to BPNM,” http://www.bpmi.org/downloads/Introduction_to _BPMN89.pdf.

15. J. O’Sullivan, D. Edmond, and A. H. M. Hofsted, “Formal description of non-func-tional service properties,” Technical Report, No. FIT-TR-2005-01, Queensland Uni-versity of Technology, Brisbane, 2005.

16. J. Cardoso, A. Sheth, J. Miller, J. Arnold, and K. Kochut, “Quality of service for workflows and web service process,” Web Semantics: Science, Services and Agents on the World Wide Web, Vol. 1, 2004, pp. 281-308.

17. J. M. Ko, C. O. Kim, and H. Kwon, “Quality of service oriented web service com-position algorithm and planning architecture,” Journal of Systems and Software, Vol. 81, 2008, pp. 2079-2090.

18. Y. J. Seo, H. Y. Jeong, and Y. J. Song, “Best web service selection based on the decision making between QoS criteria of service,” Lecture Notes in Computer Sci-ence, Vol. 3820, 2005, pp. 408-419.

19. C. Macharis, J. Springael, K. D. Brucker, and A. Verbeke, “PROMEHTEE and AHP: The design of operational synergies in multicritera analysis,” European Jour-nal of Operational Research, Vol. 153, 2004, pp. 307-317.

20. OASIS, Web Services Quality Factors v1.0, Committee Draft, Organization for the Advancement of Structured Information Standards, 2008.


1971

Heejung Chang received B.S. and M.S. degrees in Com-puter Engineering from MyongJi University, Korea, in 2001 and 2003. She received Ph.D. in Computer Engineering with spe-cialization in Software Engineering from MyongJi University, in 2010. She has been a part-time lecturer at MyongJi University since 2003. Her research interests are software engineering and modeling and simulation. She has joined several projects in de-fense modeling and simulation, and web services techniques.

Kangsun Lee received B.S. and M.S. in Computer Science from Ewha Women’s University, Republic of Korea, in 1992 and 1994, respectively. She received Ph.D. in Computer Information Science and Engineering with specialization in modeling and simulation from University of Florida, FL, U.S.A., in 1998. During 1999-2000, she was a senior researcher at Software Re-search Center, Samsung Electronics Co., Ltd., in Republic of Ko-rea. She joined at Department of Computer Engineering, MyongJi University, Republic of Korea, in 2000 as an Assistant Professor and has been a Full Professor since 2009. Her research interests

are techniques and methodologies in Service-Oriented Architecture and their application to systems modeling and simulation. She has conducted several projects in defense mod-eling and simulation, and applied web services techniques to realize various defense simulators.

a quality-driven web service composition methodology for ubiquitous services

Documents