Deploying and managing Web services: issues, solutions, and

The VLDB JournalDOI 10.1007/s00778-006-0020-3

REGULAR PAPER

Deploying and managing Web services: issues, solutions,and directions

Qi Yu · Xumin Liu · Athman Bouguettaya ·Brahim Medjahed

Received: 12 August 2005 / Accepted: 19 April 2006© Springer-Verlag 2006

Abstract Web services are expected to be the keytechnology in enabling the next installment of the Web inthe form of the Service Web. In this paradigm shift, Webservices would be treated as first-class objects that can bemanipulated much like data is now manipulated usinga database management system. Hitherto, Web serviceshave largely been driven by standards. However, thereis a strong impetus for defining a solid and integratedfoundation that would facilitate the kind of innovationswitnessed in other fields, such as databases. This surveyfocuses on investigating the different research problems,solutions, and directions to deploying Web services thatare managed by an integrated Web Service ManagementSystem (WSMS). The survey identifies the key featuresof a WSMS and conducts a comparative study on howcurrent research approaches and projects fit in.

Keywords Service-oriented computing ·Interoperability · Web service management system

This research is supported by the National Institutes of Health’sNLM grant 1-R03-LM008140-01.

Q. Yu (B) · X. Liu · A. BouguettayaComputer Science Department, Virginia Tech,Blacksburg, VA 24060, USAe-mail: [email protected]

X. Liue-mail: [email protected]

A. Bouguettayae-mail: [email protected]

B. MedjahedDepartment of Computer and Information Science,University of Michigan, Dearborn, MI 48128, USAe-mail: [email protected]

1 Introduction

The Web is a distributed, dynamic, and large informa-tion repository. It has now evolved to encompass variousinformation resources accessible worldwide. Organiza-tions across all spectra have already moved their mainoperations to the Web, which has brought about a fastgrowth of various Web applications. This has dramati-cally increased the need to build a fundamental infra-structure for efficient deployment and access of theexponentially growing plethora of Web applications. Thedevelopment of enabling technologies for such an infra-structure is expected to change the business paradigmon the Web. Web services have de facto become the mostsignificant technological by-product. Simply put, a Webservice is a piece of software application whose inter-face and binding can be defined, described, and discov-ered as XML artifacts [9]. It supports direct interactionswith other software agents using XML-based messagesexchanged via Internet-based protocols. Examples ofWeb services include online reservation, ticket purchase,stock trading, and auction. Standards are key enablersof Web services [102]. Major industry players took alead to set up crucial standards. This has greatly facili-tated the adoption and deployment of Web services [56].Three key XML-based standards have been defined tosupport Web service deployment: SOAP [109], WSDL[113], and UDDI [110]. SOAP defines a communica-tion protocol for Web services. WSDL enables serviceproviders to describe their applications. UDDI offers aregistry service that allows advertisement and discoveryof Web services.

The fast increasing number of Web services is trans-forming the Web from a data-oriented repository to aservice-oriented repository [85,93]. In this anticipated

Q. Yu et al.

framework, existing business logic will be wrapped asWeb services that would be accessible on the Web via aWeb service middleware [104]. Web services will workas self-contained entities to fulfill users’ requests. Coop-eration among multiple Web services will additionallyimprove the quality of answers by providing value-addedservices [67]. Web services are anticipated to form theunderlying technology that will realize the envisioned“sea of services” [85].

One key challenge for Web services is interoperabil-ity. Seamless interoperation is the ultimate goal that Webservices aim to achieve. Interoperation moves Web ser-vices beyond the elementary framework built upon thethree key standards (i.e., SOAP/WSDL/UDDI). It alsohelps achieve robust service compositions. The Web ser-vice composition refers to combining outsourced Webservices to offer value-added services [92]. Process mod-eling languages are a major tool to compose Web ser-vices [51]. Typical examples include Business ProcessExecution Language for Web Services (BPEL4WS, theconvergence of XLANG [70] and WSFL [53]) [83], WebServices Choreography Interface (WSCI) [111], andBusiness Process Management Language (BPML) [16].A common characteristic of all these modeling langua-ges is that XML is used to depict Web services. The lackof well-defined semantics affects their ability to achieveseamless interoperability in the true sense. The conceptof ontology is the key to empowering Web services withsemantics [38].

Ontologies enrich Web services with expressive andcomputer interpretable languages. They help capturethe semantics of Web services. Ontologies were firstproposed in the artificial intelligence community to facil-itate knowledge sharing and reuse. They aim to con-struct a shared and common understanding of relevantdomains across people, organizations, and applicationsystems [40]. Ontologies function like metadata schemawith rich descriptive capacity [31,50]. They facilitate theinformation exchange of people and computers in termsof both syntax and semantics [58]. A typical example ofontologies is OWL-S, which is a OWL-based Web ser-vices ontology [63]. It aims at establishing a frameworkto describe semantic Web services. OWL-S would bea semantic-based substitution of those syntactic-basedWeb services languages for service description, serviceregistration, and service composition. Thus, integratingontologies into Web services could not only enhance thequality and robustness of service discovery and invoca-tion, but also pave the way for automated compositionand seamless interoperation.

Interoperability has been a central concern forenabling the service-oriented Web [65]. However, thefull deployment of Web services requires dealing with

additional issues including Quality of Web Services(QoWS), Web service management, and security/pri-vacy. As multiple Web services are expected to deliversimilar fuctionalities, QoWS is considered as a keyconcept in distinguishing between competing Web ser-vices [25]. The international quality standard ISO 8402describes quality as “the totality of features and charac-teristics of a product or service that bear on its abilityto satisfy stated or implied needs” [88]. The quality andusage of Web services is controlled and monitored via aset of management mechanisms [107]. We identify twotypes of management techniques. Control managementaims to improve the service quality through a set ofcontrol mechanisms (e.g., transaction, change manage-ment, and optimization). Monitoring management ratesthe behavior of Web services in delivering their func-tionalities in terms of the QoWS parameters. Securityand privacy mechanisms need to be developed to ful-fill the requirements of the Web service environment[39, 83]. Web service requests and replies are sent overthe Internet, and hence are subject to various securitythreats. Additionally, users’ sensitive information maybe divulged to unauthorized third parties during theWeb service interactions.

The objective of this paper is to survey the funda-mental issues and proposed solutions for successfullydeploying and managing Web services. Standards haveso far been the key enablers of Web services. The inten-sive standardization support reflects the strong industrybacking of Web services as a key mechanism for deploy-ing programmable functionalities on the Web. This is his-torically similar to the progress of another key enablingtechnology, the database management system (DBMS)technology. The DBMS technology has had tremendousprogress with the advent of the relational model whichwas instrumental in giving databases a solid theoreticalfoundation. Web services still have to have such a strongfoundational underpinning. The foundational work isstill in its infancy.

Current surveys focus mostly on the technologicalaspects in the development and deployment of Webservices, with little regard to their foundational under-pinning [9,82]. These surveys mainly fall into twocategories: descriptive or application-oriented. Forexample, Alonso et al. [9] give a comprehensive descrip-tion of Web services. However, the focus is mostly ontechnology-related definitions of the different standardsand products. Our survey takes a different approachin two major ways. First, we investigate the differenttechnologies from a foundational point of view, relat-ing each standard/technology to a set of parameters.Second, we investigate the related standards/technol-ogies from a research point of view, focusing on the

Deploying and managing Web services

functionalities that are provided and the fundamentalissues that are being addressed. Tsalgatidou et al. [100]present the basic Web service model and sketch theWeb service lifecycle in their work. They present anoverview of the key Web service standards, includingSOAP, WSDL, UDDI, and ebXML. Medjahed et al. [65]reviewed Web service technologies from a business-to-business (B2B) application perspective. It outlines themajor features of Web services and examines how theycould fit into the B2B interaction environment. Servicecomposition is presented as a powerful tool to com-bine inter-enterprise applications and enhance the B2Binteractions. Papazoglou et al. [82] provide a review ofthe Web service technologies as an application of ser-vice-oriented computing. They examine several majorfeatures of Web services. They also discuss how the Webservice features benefit the service-oriented architec-ture. In this paper, we conduct a state-of-the-art analy-sis of the Web service technologies with a focus on theresearch issues. Our aim is to lay a foundational frame-work for Web services, called Web Service ManagementSystem (WSMS). The WSMS is a comprehensive frame-work for the Web service life cycle, including developing,deploying, publishing, discovering, composing, monitor-ing, and optimizing access to Web services. In such aframework, Web services are treated as first-class ob-jects that are manipulated as if they were pieces of data.A set of parameters is proposed to analyze and assessWeb service technologies within the WSMS.

The remainder of this paper is organized as follows.In Sect. 2, we provide a historical perspective on theanalogy between Web services management and data-base management. In Sect. 3, we give an overview ofthe proposed WSMS. The WSMS is further presentedin a step by step fashion. We first present the standardWeb service reference model. We then describe the Webservice technologies using a layered stack approach. Aset of dimensions of Web services is defined. This setcorresponds to the key issues for deploying and manag-ing Web services. The WSMS architecture is then pro-posed to address these issues. From Sect. 4 to 7, wedetail the WSMS architecture by providing a detaileddescription of each of its components. In Sect. 8, wereview the current Web service deployment systems. InSect. 9, we evaluate these systems by mapping them tothe WSMS architecture. We then outline some futureresearch trends.

2 Towards a Web Service Management System(WSMS): historical perspective

Providing a solid framework for the deployment of Webservices aims at providing a powerful foundation much

like the relational paradigm provided for the databasefield. In the context of Web services, scientific commu-nities are expected to benefit from the ability to shareresources on a large scale that will lead to further innova-tion, collaboration, and discovery. Governments wouldbe able to better serve citizens and other constituen-cies by streamlining and combining their Web accessi-ble resources. Businesses would be able to dynamicallyoutsource their core functionalities and provide econo-mies of scale. This would translate into better productsat cheaper prices.

Fully delivering on the potential of the next-gener-ation Web services requires building a foundation thatwould provide a sound design framework for efficientlydeveloping, deploying, publishing, discovering,composing, monitoring, and optimizing access to Webservices. The proposed Web service foundation will en-able the deployment of Web Service Management Sys-tems (WSMSs) that would be to Web services whatDBMSs have been to data. We largely draw on theexperience and lessons learned from designing the data-base foundation. The transition from the early file sys-tems to databases is of particular interest. If one lookscarefully at the history of relational databases, one canclearly observe a striking parallel with the current sit-uation of Web services. Therefore, understanding therelated transition processes and resulting foundationalmodels will provide us with valuable insight and helpin designing a sound foundational framework for Webservices.

For the purpose of comparison, it is noteworthy tomention that the early file systems were developed forsingle users who had their own exclusive data space. Inaddition, because of the state of data storage technol-ogy back then, data sizes were very small. Computersystems were more computation bound (CPU bound)as opposed to being data bound (I/O bound). Moreimportantly, the growing deployment of computer sys-tems was coupled with a tremendous growth in datavolume and number of users sharing files. The new com-puting environment posed fundamental challenges inproviding uniform data representation, efficient con-current access to and recoverability of data, and ensur-ing correctness and consistency. As a result, the nascentdatabase research focused on laying the foundation forthe next-generation data management system to addressthese issues. Early work on the network and hierarchi-cal models set the foundational work in motion with theearly standardization-based models (e.g., DBTG model[2,1]). The field of databases enjoyed widespread accep-tance only after the relational model was proposed byCodd [25]. What made the relational model a successstory is the sound mathematical foundation upon which

Q. Yu et al.

it is built. The relational model is based on set theory andrelational calculus (declarative). This simple, yet pow-erful paradigm was met with instant success in industry[10] and academia [97]. New concurrency control mod-els were proposed. Optimization techniques based onalgebraic principles were also proposed. This activityspurred and sustained the deployment of databases asubiquitous tools for efficiently managing large quantitiesof data.

We observe that this historical perspective on man-aging data is quite similar with the evolution of Webservices. Web services deliver complex functionalitiesover the Web. The early function libraries (e.g., DLL onWindows) were also designed to wrap certain function-alities and make them reusable. The libraries providea set of APIs, upon which users can manually incorpo-rate the functionalities into their programs. In addition,the function libraries are only locally accessible. Theemergence of computer networks present new require-ments for sharing and reusing of functionalities. There isa need to integrate applications within or across organi-zations. Middleware technologies (e.g., RPC, COM, andCORBA) took a first step to support intra-organizationinteroperability. Web services came as a result to ad-dress the inter-organization interoperability. They aimto provide users an integrated access to the function-alities available on the Web. The development of Webservices has so far mostly been the result of standard-ization bodies usually operating on a consensus basisand driven by market considerations. In this context,innovation and long-term market effects are not usu-ally primary concerns. Because of the global nature ofthe Web, the standardization process has so far beenvery fragmented, leading to competing and potentiallyincompatible Web service infrastructures. Many compa-nies have invested very heavily in Web services tech-nologies (Microsoft’s .NET, IBM’s Websphere, SUN’sJ2EE, to name a few). These efforts have resulted in afast-growing number of Web services being made avail-able. The envisioned business model is expected toinclude a whole community of Web service providersthat will compete to provide Web services. It is impor-tant that this investment produce the expected results.To maximize the benefits of this new technology, thereis a need to provide a sound and clean methodology forspecifying, selecting, optimizing, and composing Webservices. This needs to take place within a secure envi-ronment. The underlying foundation will enable design-ers and developers to reason about Web servicesto produce efficient Web Service ManagementSystems.

2.1 Web services versus data

Despite similarities in nature and history, managing Webservices is different from managing data in many signifi-cant ways. First, data in traditional DBMSs are passiveobjects with a set of known properties, e.g., structure,value, functional dependencies, integrity constraints. Onthe other hand, Web services are active and autono-mous entities that have a set of functions rather thanvalues. Moreover, unlike the data in DBMSs, the run-time behavior of Web services when they are invokedmay not be precisely known. Second, accessing a ser-vice on the Web is similar to accessing data from a dis-tributed DBMS. For example, to access a Web service,the service requester must search in one or more ser-vice registries. However, Web services carry more com-plex information, which makes accessing services a morecomplicated process. This involves understanding thedifferent services’ syntactic and semantic descriptions,selecting the services providing the requested function-ality, understanding their communication protocols, andfinally engaging in a sequence of message exchangewith the selected services. Of significant importance aremore complex scenarios where requests for services mayrequire the composition of several Web services; vari-ous issues pertaining to individual Web services need tobe reconciled before they can be combined. Examplesinclude security protocols and policies, and Quality ofWeb service for optimization purposes.

3 Overview of the WSMS framework

A variety of definitions about Web services are givenby different industry leaders, research groups, and Webservice consortia. For example, the W3C consortiumdefines a Web service as “a software system designedto support interoperable machine-to-machine interactionover a network. It has an interface described in a machine-processable format (specifically WSDL). Other systemsinteract with the Web service in a manner prescribed byits description using SOAP messages, typically conveyedusing HTTP with an XML serialization in conjunctionwith other Web-related standards” [112]. IBM definesWeb services as “self-describing, self-contained, modu-lar applications that can be mixed and matched with otherWeb services to create innovative products, processes, andvalue chains. Web services are Internet applications thatfulfill a specific task or a set of tasks that work with manyother web services in a manner to carry out their part of acomplex workflow or a business transaction”. According


to Microsoft, “A Web Service is a unit of application logicproviding data and services to other applications. Appli-cations access Web Services via ubiquitous Web protocolsand data formats, such as HTTP, XML, and SOAP, withno need to worry about how each Web Service is imple-mented”. HP defines Web services as “modular and reus-able software components that are created by wrapping abusiness application inside a Web service interface. Webservices communicate directly with other web services viastandards-based technologies”. SUN perceives a Webservice as an “application functionality made availableon the World Wide Web. A Web service consists of a net-work-accessible service, plus a formal description of howto connect to and use the service”.

The aforementioned definitions give a high-leveldescription of the major objective and supporting tech-nologies of Web services. Interoperation amongmachines is the major design goal of Web services. Asthe supporting standards, WSDL enables XML servicedescription of Web services and SOAP defines a com-munication protocol for Web services. These definitionsgive an outside view of Web services. In thissection, we go a step further by setting up a compre-hensive WSMS framework to support the entire Webservice life cycle, including developing, deploying, pub-lishing, discovering, composing, monitoring, and opti-mizing access to Web services. We first present the Webservice reference model. We elaborate on the three keyplayers in this model. We also identify different layersthat enable the interaction in the Web service model. Wedefine a collection of dimensions across these layers. Themajor components of the proposed WSMS are devisedbased on these dimensions. Each component providesfunctionalities that address the issues specified by thecorresponding dimension.

3.1 Scenario

We consider a travel agency, named TravelAgency,providing the travel arrangement (e.g., transportation,itinerary, and accommodations) for its clients (Fig. 1).Assume a university professor, Joan, wants to attend aninternational conference in Sydney, Australia. Typicalservices needed by Joan might include airlines, ground-transportation (e.g., taxi and car rental), accommoda-tion (e.g., hotels and inns), and other entertainmentservices (e.g., restaurant and opera house). Joan needsto first search for the services that provide travel pack-ages. The search can be conducted in some well-knownservice registry. We assume that the TravelAgency islocated by Joan. Joan would then send her request to it.To offer a complete tour package, the TravelAgencyneeds support from its business partners (e.g., Air-

Company, Hotel, Restaurant, CarRental, andOperaHouse) to arrange flights, hotels, cars, and otherentertainment facilities. These companies all define theservice description for their Web services and publishthem on a well-known service registry, whereby theTravelAgency can search and locate them. TheTrav-elAgency needs to outsource services from these busi-ness partners to provide the entire travel package. SinceWeb services with similar functionalities might be pro-vided by competing business partners, there is a need tooptimize access to those Web services or compositionthereof with respect to the expected quality. In addition,the Web services need to be accessed in a reliable andsecure manner. This example articulates a typical Webservice usage scenario. It will serve as a running exampleto illustrate the various Web service concepts.

3.2 Web service reference model

Three types of participants cooperate to set up a Webservice model (see Fig. 2), including: service provider,service client, and service registry. Web services interactin three primary modes: service publishing, finding, andbinding. Interactions depend on the Web service arti-facts, which include the service implementation and theservice description.

– Participants in a Web services model are categorizedinto three types:– Service provider is the owner of the Web ser-

vices. It holds the implementation of the ser-vice application and makes it accessible via theWeb.

– Service client represents a human or a softwareagent that intends to make use of some servicesto achieve a certain goal.

– Service registry is a searchable registry providingservice descriptions. It implements a set of mech-anisms to facilitate service providers to pub-lish their service descriptions. Meanwhile, it alsoenables service clients to locate services and getthe binding information.

– Interactions with a Web service take place in threemodes:– Service publication is to make the service

description available in the registry so that theservice client can find it.

– Service lookup is to query the registry for a cer-tain type of service and then retrieve the servicedescription.

Q. Yu et al.

Fig. 1 A travel arrangement scenario

– Service binding is to locate, contact, and invokethe service based on the binding information inthe service description.

– Artifacts encompass the service implementation anddescription:– Service implementation is a network accessible

software module realized by the service pro-vider. It could be invoked by a service clientor act as a service client to interact with anotherservice provider.

– Service description could contain the syntacticand semantic information of the Web services.The syntactic information describes the input/output of the operations, the binding informa-tion, the data types, and so on. The semanticinformation encompasses the domain of inter-ests, business functionalities, QoWS issues, andso on.

3.3 Web service stack

The Web service stack contains five key layers: commu-nications, messaging, descriptions, discovery, andprocesses, which are shown along the vertical directionin Fig. 3. It is an extension of the W3C service stack[112]. Similar to the W3C service stack, each stack layerprovides certain functionality to support interoperationbetween Web services and service clients or among Web

services. However, we categorize interoperability intotwo dimensions: syntactic and semantic (see Sect. 3.4for details). Therefore, our service stack is distinguishedfrom the W3C stack by further identifying the syntacticand semantic interoperability offered by all layers abovethe messaging layer.

– Communications: The underpinning of the Webservices stack is the network, where the underlyingcommunications take place. A set of network pro-tocols helps realize the network accessibility of Webservices. The wide adoption of HTTP makes it thefirst choice of standard network protocol for Inter-net available Web services. Other network protocolscould also be supported, such as SMTP.

– Messaging: The messaging layer provides a doc-ument-based messaging model for interaction withWeb services. The messaging model works with awide variety of network protocols. For example, themessaging model can be combined with HTTP totraverse firewalls. In another case, combination withSMTP enables the interaction with Web services thatsupport asynchronous message exchanges.

– Description: The description (or representation)layer is for describing Web services. It wraps Webservices and specifies their functionalities,operations, data types, and binding informationusing a service interface. The WS discovery will rely


Fig. 2 W3C Web servicesreference model

on the WS representation to locate appropriate Webservices.

– Discovery: The discovery layer is for locating andpublishing Web services. It enables the usage of Webservices in a much wider scale. The service provid-ers can store the service descriptions in a serviceregistry via the publication functionalities providedby the WS discovery. Meanwhile, service requestorscan query the service registry and look for interestedservices based on the stored service descriptions.

– Processes: The processes layer supports morecomplex interactions between Web services, whichenables Web service interoperation. It relies on thebasic interaction functionalities provided by thetechnologies at lower layers in the Web service stack.For example, it needs Web service discovery andrepresentation for querying and locating Web ser-vices based on their descriptions. The selected Webservices are used to construct the process, whichconsists of a sequence of coordinated Web services.

3.4 Key dimensions for building a WSMS

The variety of the Web service technologies constitutesa rich solution space of Web services. Each technologyhas specific design requirements depending on the usagescenarios. Therefore, it is important to determine the rel-evant requirements for deploying and managing Webservices. In this section, we identify a set of dimensionsto evaluate the Web service technologies. These dimen-sions are in line with the key requirements for deploy-ing and managing Web services. We take the Web ser-vice stack as a starting point and extend it to addressthe developing trends of Web service technologies. The

dimensions are defined according to the vertical layersof the Web service stack (see Fig. 3). They include inter-operability, security & privacy, Quality of Web Services(QoWS), and management.Interoperability This dimension refers to the extentto which participant Web services would cooperate toaccomplish a common objective. For example, in theaforementioned scenario, the TravelAgency needs tointeroperate with the AirCompany and Hotel to serveits clients. The common objective of the three parties isto provide satisfactory services for travelers. Good inter-operability is a must for them to achieve this goal. Webservices are designed to bring together applications fromgeographically distributed and heterogeneous environ-ments and provide interoperability among them [94].Interoperability could be achieved via three main ap-proaches: standards, ontology, and mediation. A stan-dard is a specification or format that has been approvedby a recognized standardization organization or is ac-cepted as a de facto standard by the industry. Severalstandardization efforts in Web services have been initi-ated by a focused group of companies, and have thenbeen adopted by different organizations such as OASIS(Organization for the Advancement of Structured Stan-dards) and W3C. These consortia aim at standardizingthe different aspects of Web service interactions (e.g.,message format, interaction protocols) [9]. An ontologyis a formal and explicit specification of a shared conceptu-alization [28]. “Conceptualization” refers to an abstrac-tion of a domain that identifies the relevant conceptsin that domain. “Shared” means that an ontology cap-tures consensual knowledge. The development of ontol-ogies is often a cooperative process involving differententities possibly at different locations (e.g., businesses,

Q. Yu et al.

Fig. 3 Web service stack and key dimensions

government agencies). All entities that agree on using agiven ontology commit themselves to the concepts anddefinitions within that ontology. “Explicit” means thatthe concepts used in an ontology and the constraintson their use are explicitly defined. “Formal” intendsthat the ontology should be machine understandableand describe using a well-defined model or languagecalled ontology language. Mediators provide an inte-grated view or mediated schema over multiple heter-ogeneous and autonomous services [46]. This schemarepresents generally a synthesized view over a specificapplication domain. Users access the integrated viewthrough a uniform interface. Each service is connectedto a wrapper that enables its participation in the system.It translates between the servicec6s concepts and thoseat the mediator level.

Interoperability is the core functionality that Web ser-vices endeavors to achieve. Interoperation occurs at twolevels: syntactic and semantic.

– Syntactic interoperability is concerned with thesyntactic features of Web services. Examples of syn-tactic features include the number of parametersdefining a message and the data types of those param-eters. XML helps achieve syntactic interoperabilityby encoding syntactic information into XML doc-uments. Additionally, XML provides platform andlanguage independence, vendor neutrality, and exten-sibility, which are all crucial to interoperability.

– Semantic interoperability is the most challengingissue for achieving the truly seamless interoperation.It deals with semantic properties of Web services.Examples of semantic features include the domainof interest of a Web service and the functionalityprovided by an operation. The envisioned Seman-tic Web is gaining momentum as the potential silverbullet for empowering Web services with semantics.

Interoperability could be achieved at different layersas depicted in Fig. 3 [65]. The communication layer pro-vides protocols for exchanging messages amongremotely located partners (e.g., HTTP, SOAP). It ispossible that partners use different proprietary com-munication protocols. In this case, gateways should beused to translate messages between heterogeneous pro-tocols. The objective of interoperability at this layer isto achieve a seamless integration of the communica-tion protocols. The content (description) layer provideslanguages and models to describe and organize infor-mation in such a way that it can be understood andused. Content interoperability requires that the involvedsystems understand the semantics of content and typesof business documents. For instance, if a Web servicereceives a message that contains a document, it mustdetermine whether the document represents a purchaseorder or a request for quotation. Information transla-tion, transformation, data mediators, and integrationcapabilities are needed to provide for reconciliation


among disparate representations, vocabularies, andsemantics. The objective of interoperability at this layeris to achieve a seamless integration of data formats, datamodels, and languages. The process layer is concernedwith the conversational interactions (i.e, joint businessprocess) among services. Before engaging in a transac-tion, the service providers need to agree on the proce-dures of their joint business process. The semantics ofinteractions among partners must be well defined, suchthat there is no ambiguity as to what a message maymean, what actions are allowed, what responses are ex-pected, etc. The objective of interoperability at this layeris to allow autonomous and heterogeneous partners tocome online, advertise their terms and capabilities, andengage in peer-to-peer interactions with any other part-ners. Examples of concepts for enabling process inter-operability include process wrappers and applicationadapters [19,13].Security & privacy Security is an important issue fordeploying Web services. Web services enable interop-eration at the risk of letting outside intruders attackthe internal applications and databases since they openup the network to give access to outside users to theseresources [42]. Web service security needs to be con-cerned with the following aspects: authentication, autho-rization, confidentiality, and integrity. Authentication isused to verify a claimed identity while authorizationis to check whether a user is authorized to perform arequested action. Confidentiality is to ensure that infor-mation is disclosed only to authorized recipients by,for example, encrypting the message. Lastly, integrityrefers to the protection of the information from beingtampered with by, for example, putting digital signa-tures on the messages. Privacy is another major concernof Web service deployment [89]. During service inter-actions, personal data or business secrets (e.g., billinginformation, shipping address, or product preference)might be unintentionally released [5]. Conventional pri-vacy protection mainly relies on law enforcement andrestriction of social values. Emerging technologies forpreserving privacy in Web services include digital pri-vacy credentials, data filters, and mobile privacy pre-serving agents [91].QoWS The proliferation of Web services is expectedto introduce competition among large numbers of Webservices that offer similar functionalities. The concept ofQoWS is considered as a key feature in distinguishingbetween competing Web services [104]. QoWS encom-passes different quality parameters that characterizethe behavior of a Web service in delivering its func-tionalities. These parameters can be categorized intotwo major quality classes: runtime quality and businessquality. Quality parameters in these two classes can be

further extended to include more quality aspects of Webservices to fulfill the requirements of different applica-tion domains, such as Accessibility, Integrity, andRegulatory.Management Web service management refers to thecontrol and monitoring of Web service qualities andusage. Web service management mechanisms are highlycoupled with the QoWS of a Web service. We iden-tify two types of management: control and monitoringmanagement.

– Control management aims to improve the servicequality through a set of control mechanisms. Typi-cal control mechanisms include Web service trans-action, Web service change management, and Webservice optimization. Transactions help improve thereliability and fault-tolerance of Web services.Change management deals with the highly dynamicenvironment of Web services. It takes a series ofactions to identify the changes, notifying the cou-pled entities, and adopting appropriate operations toresponse the change. Web service optimization helpsusers identify Web services and/or their combina-tions to best fulfill their requirements.

– Monitoring management rates the behavior of Webservices in delivering its functionalities in terms ofeach QoWS parameter. Monitoring Web servicebehavior would be crucial in either calculating theQoWS parameter values or assessing a Web serviceclaim in terms of promised QoWS.

Control and monitoring management might some-times work cooperatively. For instance, the Web serviceoptimization would need the monitoring process to getthe QoWS parameter values of different Web servicesand/or their combinations. These values would guide theoptimization process to return the optimized solutionsthat best fulfill users’ requirements.

3.5 The WSMS architecture

In this section, we present the WSMS architecture.The design of the WSMS architecture leverages theresearch result in DBMSs. Web services will be treatedand manipulated as first-class object in the proposedWSMS. The key components in this architecture aremodeled after those in DBMSs. The functionality ofeach component aims to address the issues raised by thekey dimensions. The interoperation frameworkconsists of six subcomponents: communication, WS mes-saging, WS discovery, service registry, WS representa-tion, and WS processes. The collaboration of these

Q. Yu et al.

Fig. 4 The WSMS architecture

subcomponents provides mechanisms to efficient accessand interoperation with Web services. The security/pri-vacy component guarantees that the access and inter-operation can be conducted in a secure and controlledmanner. The QoWS component lays out a set of qualitymetrics that can be used to advertise and discover Webservices. Some of the metrics can also be used to specifyquality level agreement, such as payment, price, etc. Themanagement component offers monitoring, transaction,change management, and optimization functionalities.The proposed WSMS provides value added featuresto enable reliable and optimized deployment of Webservices. The architecture also reflects the relationshipamong different components. In what follows, we give adetailed description of the major functionality of eachcomponent (Fig. 4).The WS Interoperation Framework The interopera-tion framework is at the core of the WSMS architec-ture. It addresses the interoperability issue of Web ser-vices through the collaboration of its six subcomponents.WS-messaging combines with an underlying communi-cation protocol (e.g., HTTP and SMTP) to enable ba-sic interaction with Web services. A Web service takes

the incoming message as the input to one of its meth-ods and responds with the output of the method as areturning message. WS-representation defines the Webservice interface containing a set of supported methods.It specifies the signature of each method, which is similarto IDL in the middleware systems. However, WS-rep-resentation goes beyond the IDL-like syntactic servicedescription. It incorporates more expressive languageconstructs (e.g., ontologies) for describing the proper-ties and capabilities of Web services in an unambiguousand computer-interpretable manner. Other informationcould also be specified in WS-representation, such asquality of service parameters, security and transactionrequirements, etc. The semantic service descriptioncaters for the loosely coupled interoperation betweenWeb services. It helps Web services determine the func-tionality, requirement, and quality of their interopera-tion partners. Descriptions of Web services are storedat service registries. WS discovery provides the queryand publication functionalities for locating and pub-lishing Web services in a service registry. Interactionwith the registry is through WS messaging. WS pro-cesses rely on the basic functionalities provided by the


discovery, presentation, and messaging components tosupport the complex interactions between Web services.The processes involve the invocation of a sequence ofWeb services. Service coordination defines the externalinteraction protocols for a WS process, whereas servicecomposition defines the schemas for its internal imple-mentation.The WS security/privacy component The security/privacy component ensures that interactions with Webservices are conducted in a secure fashion while sensitiveinformation can be preserved as required. The securitymechanisms need to be applied to all aspects of Webservices, including messaging, query, publication, coor-dination, composition, control, and monitoring. Typicalsecurity functionalities that can be implemented by thesecurity module are auditing, authentication, access con-trol, and data encryption. Privacy is usually expressed bypolicies which reflect that the habits, behaviors, actionsor other rights of the service users must be protected.Instead of relying on laws and social values, the pri-vacy module enforces the policies from a technologicalperspective.The QoWS component The QoWS component rec-ords the quality aspects of a Web service. It reflectsthe runtime and business requirements of Web services,such as response time, availability, reliability, cost, andreputation. Because it is anticipated that there will bemultiple competitors to provide similar functionalities,the WS query process uses QoWS as a major criteria toselect the “best” Web services. The QoWS componentprovides functionalities to define appropriate metrics tocharacterize QoWS and devise techniques to use it inoptimizing service-based queries.The WS management component The WS manage-ment component is for monitoring and controlling theinteractions with Web services. The monitoring moduleexamines the behavior of the underlying communica-tion, WS messaging, and WS processes, and reports theruntime and business properties of Web services to theQoWS component. The control module provides trans-action, optimization, and change management mecha-nisms to deliver the functionalities of Web services in areliable, adaptive, and optimal fashion.

Figure 5 describes the proposed WSMS architectureusing the W3C concept map model [112]. In this figure,rectangles represent concepts and lines with arrows rep-resent relationships. The key components in the WSMSarchitecture are represented by the concepts. In additionto these key components, the concept map also includesthe Web service (represented by WS) concept. The func-tionalities of each component are reflected by its rela-tionships with the WS concept or other components.

The proposed WSMS provides a foundational frame-work for the Web services. It formalizes the steps in theentire Web service life cycle. The design of each com-ponent in the WSMS architecture follows key researchissues (called dimensions) in Web service environments.Since the Web services are designed to achieve seamlessinteroperability, the interoperation framework stays atthe core of the WSMS architecture. The framework iscomposed of several horizontally separated layers; eachlayer contains components that provide correspondinginteroperation functionalities. The security/privacy,QoWS, and management components offer supplemen-tary support (e.g., security, privacy, control, andmonitoring) for the interoperation framework. Thesefunctionalities are orthogonal to the horizontal layersin the interoperation framework; they can be appliedacross these layers. This is different from the ExtendedService Oriented Architecture (ESOA) [82]. The ESOAcontains three horizontal layers: basic service, servicecomposition, and management layers. The separation ofdifferent layers is based on the advancement of theirfunctionalities. The basic service layer provides sim-ple functionalities such as messaging, description, anddiscovery. The composition layer provides the function-alities for the consolidation of multiple service into a sin-gle composite service. The management layer providesadvanced administration capacities for managing crit-ical Web service-based applications. Additionally, theESOA extends the Service Oriented Architecture (SOA)by addressing the new requirements introduced by Webservices. The layers added in ESOA provide functional-ities that overlap with existing SOA layers. However, theWSMS architecture is not developed by adding layersto an existing architecture. We take consideration of thekey research issues of Web service when designing theWSMS architecture. Therefore, there is a clear function-ality separation of different components in a WSMS.

In [80], Web service management approaches havebeen investigated to support production-quality Webservice applications. The Web service managementframework relies on a manageability information modeland management infrastructure services to make Webservices measurable and manageable. Specifically, themanageability information model describes the man-ageability information of Web services. Managementinfrastructure services define standard interfaces for themanagement functionalities, such as metering, monitor-ing, mediation, etc. We take an integrated approachand a broader scope to present the WSMS architec-ture. Management approaches investigated in [80] arecomplementary to those covered in the managementcomponent and fit into the the proposed WSMS

Q. Yu et al.

Fig. 5 A concept-map description of the WSMS architecture

architecture. There are some other research effortunderway to provide architectural support for Web ser-vices such as Web Service Management Framework(WSMF) [39], Web Service Architecture (WSA) [112],Web Services Conceptual Architecture (WSCA) [52],Semantic Web enabled Web Services architecture(SWWS) [22], Service Bus [57], and Web Service Inter-operability framework (WS-I) [118]. These architectureshave addressed several similar components covered inour WSMS architecture. These components are designedto address the key research issues in the entire Webservice life cycle. Unlike these architectures that pres-ent the components in an isolated manner, we take anintegrated approach to investigate the functionalitiesof each component in the proposed WSMS architec-ture. We further examine the relationship between thesecomponents and how they could collaborate to set upthe WSMS to enable the entire Web service life cycleincluding developing, deploying, publishing, discover-ing, composing, monitoring, and optimizing access toWeb services.

4 Web service interoperation framework

Web services are designed to bring together distrib-uted and heterogeneous applications in a large scale and

provide interoperability between them [94]. Distribu-tion, heterogeneity, and scalability are the three key is-sues for application interoperation. Computer networksbridged isolated machines to form a distributed system.Different applications can thus build up communica-tions via various network protocols. This enables theprimary form of interoperation between applications.Interoperation at this stage requires complex low-levelprogramming, which is time consuming and error prone.Remote Procedure Calls (RPCs) take a step further byhiding the complexity of building distributed applica-tions. They abstract away the heterogeneity of appli-cations from different aspects, such as platforms andlanguages. RPC enables simpler and more efficient in-teroperation between applications. A middleware takesRPC as its kernel technology and further evolves itby incorporating security, faulty tolerance, and failurerecovery mechanisms. It provides a full-fledged interop-eration solution in an intra-organization scale. Becauseorganizations are rushing to move their main operationsto the Web, there is a need for interoperation of applica-tions from a much wider spectrum. Web services are theresult of the various standardization efforts to enableapplication interoperation on the Web.

Web service interoperation occur at two levels: syn-tactic and semantic levels. We evaluate the key technol-


ogies that support syntactic and semantic interoperationin this section. These technologies will be mapped ontothe corresponding layers in the Web service stack basedon their functionalities: WS messaging, WS representa-tion, WS discovery, and WS processes. After presentingthe supporting technologies at each layer, we follow witha discussion of how further development of these tech-nologies can address the current open issues.

4.1 Messaging layer

Web services are heterogeneous and loosely coupled.The Web service environment can no longer fulfill thesymmetrical requirement of conventional middleware,where communication protocols link uniform objectmodels and libraries. In addition, Web services may bedeployed at different organizations across the Internet,which requires the communication protocols to workthrough firewalls. The use of document-based messag-ing model caters for the loosely coupled interactionrelationships. To deal with heterogeneity, the messag-ing model works with a wide variety of transport proto-cols. For example, interaction with Web services that sitbehind firewalls requires the messaging model to becombined with HTTP. In another case, combination withSMTP enables the interaction with Web services thatsupport asynchronous message exchanges [9]. In addi-tion to the document style interactions, the messagingmodel also supports RPC style interactions. This adaptsWeb services to the legacy applications developed onthe conventional middleware, which communicate withRPCs. In this section, we present several technologiesthat support WS messaging: SOAP, WS addressing, andWS routing.SOAP [109] SOAP is a WS messaging standard thatenables communication among Web services in a WSMS.It provides a lightweight messaging framework forexchanging XML-based messages. SOAP is indepen-dent of languages and platforms. It supports two typesof communications: messaging and RPCs. It is designedto work with a great variety of transport protocols. Thepredominant protocol that is combined with SOAP isHTTP, which helps achieve the synchronous commu-nication. A SOAP message contains one XML element(Envelope) and two child elements (Header andBody). The Envelope defines the namespaces for theremaining content of a SOAP message. The Headeris an optional element. It can carry auxiliary informa-tion in a SOAP message for supporting authentication,transaction, and payment. The Header enables a SOAPmessage to be extended in an application-specific man-ner. TheBody is the mandatory part of a SOAP message.It specifies the information to be carried from the initial

message sender to the ultimate message receiver. Formessage exchanging, the Body part encompasses theexchanged information, while for RPCs, Body includesthe remote method name, its associated address, and thearguments thereof.WS-routing [106] SOAP does not specify the actualmessage path along which a SOAP message is to travel.The message path consists of several intermediaries thata SOAP message will visit. SOAP needs to rely on theunderlying transport protocols and follow their messagepath models. Therefore, it is impossible to specify whichintermediaries the SOAP message can visit when it trav-els to its destination. WS-routing enables SOAP pathto be specified as a SOAP message header. It consistsof a sequence of references to the intermediary SOAPnodes. The sequence specifies the visiting order of theSOAP message. When a message arrives at an interme-diary node, the node will remove the reference thereofand send the message to the next node based on thespecified order. An intermediary node can also incorpo-rate new nodes or remove existing nodes to change themessage path.WS-Addressing [69] WS-Addressing defines a proto-col-neutral mechanism to address WS messages. It helpsidentify WS endpoints through predefined XML ele-ments. It specifies an endpoint reference as the combi-nation of an address and several reference properties.Thus, the target WS instances can be uniquely located.WS-Addressing defines how WS instances endpoints aredescribed. It also specifies how address description canbe encoded in SOAP messages. The SOAP messages willcarry standardized header blocks, which can identify aunique WS instance.WS-Reliability [98] WS-Reliability is a SOAP-basedprotocol for addressing reliable messaging requirement.The reliability features include guaranteed delivery,duplicate elimination, and message ordering. WS-reli-ability specifies how to reply to a message to guaranteereliable messaging. An acknowledge message or a fail-ure message is sent as a reply. The reply is correlated witha message by references to the message ID. A messageID is globally unique. It is also used in duplication elim-ination. Messages with the same message ID are treatedas duplicates. WS-reliability uses a sequence numbermechanism to track and enforce the message order. WS-reliability is defined as the SOAP head extensions.

SOAP and its complementary specificationsprovide a simple and lightweight messaging frameworkfor exchanging XML-based messages between Webservices. However, the downside of XML-based messag-ing is that it represents information in a rather expen-sive way, which demands intensive document parsing.When a large number of Web services participate in the

Q. Yu et al.

interaction, the message exchange would become veryfrequent. This could greatly reduce the performance,which brings along the scalability problem. Twoalternatives to the XML-based types are attachingbinary data to the SOAP messages or using URLs thatpoint to the actual data. Another trend that extendsSOAP would be along with the asynchronous messageexchange. The RPC style interaction requires tightlycoupled relationships, where applications are stronglydependent on each other. When interactions occursacross multiple organizations, the coordination wouldbecome significantly challenging. Asynchronous inter-actions avoid direct invocations by batching and rout-ing requests via queues. Therefore, asynchronous SOAPwould be a technological choice to achieve cost effectiveinteractions.

4.2 Representation layer

The representation layer is used to describe Webservices. It wraps Web services and specifies their func-tionalities, operations, data types, and binding informa-tion using a service interface. The discovery layer relieson the representation layer to locate appropriate Webservices. Since XML and ontologies are the two pre-dominant languages for defining the service interfaces,we identify two types of Web service representations:XML-based and ontology-based.

4.2.1 XML-based representation

In this section, we describe a general framework forthe XML-based representation that is symbolized byWSDL. We will then describe more application-specificframeworks that facilitate interoperabilty at the repre-sentation layer.WSDL [113] WSDL is the current industry standardfor WS description. It goes beyond IDLs in the con-ventional middleware in two major ways. First, WSDLspecifies the mechanisms to access a Web service in addi-tion to the service name and signatures. Second, WSDLdefines the location to invoke a Web service, wherebythe service requestor can locate the service and interactwith it using SOAP. WSDL mainly focuses on the syn-tactic description of Web services using XML. It doesnot allow the specification of Web service semantic fea-tures. For example, no constructs are defined to describedocument types (e.g., whether an operation is a requestfor quotation or a purchase order).

A WSDL document describes programming inter-faces and accessing formats of a Web service. It de-fines a Web service at two levels: the application leveland the concrete level. WSDL helps service requestors

access a Web service through a clear separation of theabstract and concrete descriptions of a Web service. Atthe abstract level, the WSDL description includes threebasic elements: Type, Message, and PortType.Types define the type of the data that are relevant forthe information exchange. Although WSDL can sup-port any type system, it adopts XML Schema Definition(XSD) as the canonical type system to achieve max-imum interoperability and platform neutrality. Mes-sage represents an abstract definition of the transferreddata. A message consists of one or more logical parts.Each part associates with a type of XSD or other typesystems. These logic parts provide a flexible way todescribe the abstract content of messages. PortTypeis a set of abstract operations provided by an endpointof a Web service. An endpoint of a service can supportfour transmission primitives: one-way, request–response,solicit–response, and notification. At the concrete level,the WSDL description provides information of bindinga concrete service endpoint. It specifies three aspectsof binding information: communication protocols, dataformat specifications, and network addresses. Bindingdescribes the first two aspects. It specifies the commu-nication protocol, such as SOAP and HTTP. It alsospecifies the data format of the operations and mes-sages. Port and Service elements describe the net-work addresses. A Port specifies a single address forbinding a service endpoint. A Service, on the otherhand, aggregates a set of related ports.

The WSDL documents describe primary informationfor accessing Web services. WS-Policy [96] andWS-Agreement [44] are two specifications that comple-ment WSDL. WS-Policy provides a framework to enableWeb services to specify policy information. The policyis used to convey conditions on an interaction betweentwo Web service endpoints. WS-Policy enables the Webservice provider to specify a condition under which itprovides the service. The Web service requester uses thepolicy to convey the information that which kind of ser-vice it wants. WS-Agreement provides the mechanismsfor service providers to specify agreement terms for theusage of their services. These specifications would beused for customizable description of web services.Other XML-based frameworks There is a large num-ber of XML-based frameworks for enabling interopera-bility at the representation layer. Interactionsbetween different partners require that the involved sys-tems understand the semantics of content and types ofthe exchanged documents. In what follows, wedescribe a representative set of XML-based interoper-ability frameworks. An exhaustive list of frameworkscan be found in [20]. Web services may adopt theseframeworks to capture the semantics of documents


processes. For example, Web services may use cXMLto carry out interactions among businesses according tothese frameworks [20].

eCO introduces xCBL (XML Common BusinessLibrary) to define business documents [20]. xCBL con-sists of a set of XML core documents that are used torepresent common interactions in business transactions.The main motivation for establishing core documentsis that some concepts are common to all business do-mains and thus can be expressed in a common format.Examples of such core documents are: purchase orders,invoices, date, time, and currencies. Business partnersmay use and extend these documents (e.g., adding newelements) to develop their own business documents.Businesses are not limited to a specific set of pre-defineddocuments. However, this may hamper interoperabilitysince companies would need to be aware of newly cre-ated documents.

cXML (Commerce XML) consists of an XML-basedschema language and a protocol for onlinepurchasing transactions [20]. It targets business trans-actions that involve non-production Maintenance, Re-pair, and Operating (MRO) goods and services. cXMLdefines a set of XML DTDs to describe procurementdocuments in the same spirit as xCBL (e.g., order re-quest, order response). It provides the following ele-ments for describing product catalogs: Supplier, Index,and Contract. The supplier element describes generalinformation about a supplier (e.g., address, orderingmethods). The index element describes the supplier’sinventory (e.g., product description, part numbers, clas-sification codes). The contract element describes thenegotiation agreements between a buyer and a supplieron product attributes (e.g., price, quantity).

Universal Business Language (UBL) defines ageneric XML interchange format for business docu-ments [73]. It aims to resolve the discrepancy in XMLdocuments used in different application domains. UBLconsists of three key components: a library of reusabledata components, a set of common business documents,and customization of UBL for specifying trading rela-tionships. The data library and the common businessdocuments are both defined as XML schemas. The stan-dardization of the XML business schemas provides acommercial syntax for business documents that can beuniversally understood and recognized.

RosettaNet [3] aims at standardizing product descrip-tions and business processes in information technologysupply chain applications. RosettaNet’s supply chaininclude information technology products (e.g., boards,systems, peripherals, finished systems) and electroniccomponents (e.g., chips, connectors). The RosettaNetBusiness Dictionary contains vocabulary that can be

used to describe business properties (e.g., business name,address, tax identifier). The RosettaNet Technical Dic-tionary contains properties that can be used to describecharacteristics of products (e.g., computer parts) andservices (e.g., purchase order). The RosettaNet Imple-mentation Framework specifies content of messages,transport protocols (HTTP, CGI, email, SSL) for com-munication and common security mechanism (digitalcertificates, digital signatures).

ebXML (Electronic Business XML) [34] defines anarchitecture and a set of specifications for Web ser-vice interactions. It is sponsored by UN/CEFACT andOASIS. At the content layer, companies interact throughbusiness documents. A business document is a set ofinformation components that are interchanged as partof a business process. Business documents are com-posed of three types of components: core components,domain components, and business information objects.Core components, stored in the core library, are infor-mation components that are re-usable across industries.Domain components and business information objectsare larger components stored in the domain library andbusiness library respectively. Core components are pro-vided by the ebXML library while domain componentand business information objects are provided byspecific industries or businesses.

4.2.2 Ontology-based representation

As a non-trivial extension to WSDL, ontologies enablethe semantic description of Web services. Ontologiesoriginate from the AI field. They are mainly used tomodel knowledge-based systems. A major distinctionbetween Web services and knowledge systems is thatWeb services are dynamic. Therefore, using ontologiesto model the dynamic service processes and behaviorswould be an important future trends in both Web serviceand ontology areas [30,29]. The ontology-based WS rep-resentation enriches the Web service description withmachine interpretable semantics. It uses the ontologylanguage constructs to describe the functionalities ofservices. WS-discovery can locate appropriate Web ser-vices based on the functionality information of Web ser-vices. The ontology-based model can also specify thebehavior of service operations, including the precondi-tions and effects of performing an operation of a Webservice. WS-processes can rely on the behavior informa-tion to decide the order of different Web services thatparticipate in the process.OWL-S [27] OWL-S is an OWL-based ontology fordescribing Web services. OWL (Ontology Web Lan-guage) is a revision of the DAML+OIL web ontology

Q. Yu et al.

language incorporating lessons learned from thedesign and application of DAML+OIL. OWL-S(an extension of DAML-S, a DAML+OIL upper ontol-ogy for Web service) aims at setting up a frameworkfor semantic Web services. OWL-S depends on ontol-ogies to realize the automatic service discovery, invo-cation, composition and interoperation, and executionmonitoring. The Service class sits on top of the hier-archical structure. It consists of three components: aServiceProfile, a ServiceModel, and a ServiceGrounding.

The service profile represents the capacities of theservice. It helps a searching agent discover services thatfulfill certain requests. Specifically, an OWL-S profilecontains three types of information: information aboutthe service provider, functional description, and a hostof service characteristics. The provider information con-tains the contact information of the service providingentity. The functional description specifies the transfor-mation introduced by the service. It provides the re-quired inputs and the generated outputs. It also specifiesthe preconditions needed to execute the service and theexpected execution effects.

The service model describes the execution process ofthe service. OWL-S defines the ProcessModel, as asubclass of ServiceModel to give a detailed perspec-tive on how a service operates. A process can gener-ate two kinds of effects: data transformation and statetransition. For data transformation, the process receivessome inputs and produces some outputs, whereas forstate transition, the process starts based on some precon-ditions and produces some effects. The process modelconsists of three types of processes: atomic, simple, andcomposite. An atomic process is directly invocable byreceiving an input message and returning an outputmessage. The atomic process needs to be grounded toa WSDL operation to enable the execution. Similarly,the input and output of the process also needs to begrounded to the corresponding WSDL messages. A sim-ple process mainly serves as a tool for abstractions. Itmay provide a view of some of the specialized uses ofatomic processes. It may also simplify the presentationof some composite services for planning and reasoning.Simple processes are not grounded to any WSDL oper-ations, so they are not invocable. A composite servicecombines several other processes (either composite ornon-composite) with a set of control constructs. OWL-S defines a minimal set of control constructs, whichconsist of Sequence, Split, Split + Join, Choice, Unor-dered, Condition, If-Then-Else, Iterate, Repeat-While,and Repeat-Until. A composite service is not associ-ated with a grounding. Therefore, it is not invocableeither.

A grounding enables access to the service. It specifiesthe description elements needed to interact with the ser-vice. The grounding specifies the concrete level of theservice description. In contrast, the service profile andservice model specify the abstract part of the servicedescription. The core function of a grounding is to real-ize the abstract inputs and outputs of an atomic processas concrete messages. The messages serve as a vehicle tocarry the inputs and output in some transmittable for-mat. OWL-S depends on WSDL to ground its atomicprocesses due to the similarity between the groundingand WSDL’s binding.WSMF and WSMO [39,48] Web Service ModelingOntology (WSMO) is an ontology for describing severalaspects of semantic Web services. It takes Web ServiceModeling Framework (WSMF) [39] as a starting point.WSMF consists of four main parts, including goals, on-tologies, mediators, and Web services. The goal definesthe problems that a Web service is expected to address.The ontology defines the formal semantics for the termsused in other elements of WSMF. The mediator is usedto address interoperability problems, such as data mis-matches and process sequence mismatches. The Webservice part defines several elements to describe a Webservice, including the precondition, post-condition, dataflow, control flow.

The WSMO refines WSMF and defines these ele-ments in a formal fashion. The WSMO definition of aWeb service consists of four parts, including nonFunc-tionalProperties, usedMediators, capability, and inter-face. The nonFunctionalProperties describe theproperties that are not directly related to a Web ser-vice’s functionality, such as service providers, cost, per-formance, reliability, security, etc. These properties aremainly used to help software agents discover and selectWeb services. They can also be used for negotiation.The usedMediators define the mediators used by aWeb service. For example, a Web service can use theconcepts and relationships elsewhere by importing on-tologies through ontology mediators (ooMediators).It can also use wgMediator to address interoperabilityproblems between a Web service and goals. The capa-bility defines the functionalities of a Web service. Ithelps software agents locate a desirable Web service. Acapability can be modeled by using preconditions, post-conditions, and effects. The interface describes howWeb service functionalities can be fulfilled. It can beused to help software agents invoke and combine Webservices. The WSMO definition describes the interfaceof a Web service from a twofold view, including cho-reography (from user’s prospective) and orchestration(form other service provider’s perspective). The chore-ography describes the information about how to interact


with a service to make use of its functionalities, such asMessage Exchange Pattern (MEP). The orchestrationdescribes the information about how a Web service isoutsourced to provide a value-added service. It has atight relationship with the Problem Solving Pattern(PSP), which specifies a sequence of activities to achievea given requirement. The Web Service ModelingLanguage (WSML) [47] provides a formal syntax andsemantic for WSMO. It is based on well-known logicalformalisms, including first-order logic, description logic,and logic programming.

In a nutshell, the XML-based service representationdescribes the syntactical information of Web services.Similarly to IDLs, it specifies the input and output for-mat of a set of operations offered by a Web service.However, the XML-based service representation doesnot usually provide rich semantics of services, whichare paramount for discovery and composition of looselycoupled Web services. The ontology-based service rep-resentation enriches the Web service description withmachine interpretable semantics. It uses the ontologylanguage constructs to describe the functionalities ofservices. In addition, it can also specify the behaviorof service operations, including the preconditions andeffects of performing an operation of a Web service.Since different ontologies might be used for servicedescription, a major issue of ontology-base a servicerepresentation is mapping between disparate serviceontologies.

4.3 Discovery layer

The discovery layer provides a query and publicationframework for publishing and locating Web services. Itenables the usage of Web services in a much wider scale.Service providers can store the service descriptions in aservice registry via the publication functionalities pro-vided by WS discovery. Meanwhile, service requestorscan query the service registry and look for their inter-ested services based on the stored service descriptions.The standardization effort that aims to provide a WSdiscovery framework is UDDI.UDDI [110] UDDI defines a standard to publish andquery Web services in a WSMS. It integrates Web ser-vice description and discovery to help service requestorslocate their desirable services. The core component ofUDDI is a service registry. The registry stores the gen-eral information of Web services. The information canfacilitate service requestors in querying different Webservices. UDDI provides a service query API to locateappropriate Web services. It also defines a service pub-lication API for service providers, who can use it toadvertise their services.

UDDI encodes three types of information aboutservices: white pages, yellow pages, and green pages. Thewhite pages contain the contact information of businessentities and the Web services they provide. UDDI usestwo elements to express white pages information, includ-ing businessEntity and businessService. ThebusinessEntity describes a business organizationthat provides Web services. It specifies the informationof service providers, including names, briefdescription, and contact details. Each businessEnti-ty may include one or more businessService ele-ments. The businessService describes a collectionof related Web services offered by an organization spec-ified by a businessEntity. The yellow pages containthe classification information of businesses and services.Different business or services are classified based ontheir functionalities. Examples of such categories in-clude restaurants, hotel, etc. The yellow pages specifythe category to which the businesses or services belong.The green pages contain the information about tech-nical details of Web services, including bindingTem-plate andtModel. ThebindingTemplatedescribesthe information about concretely binding an endpoint ofa service. The tModel describes the technical specifica-tion of a Web service, such as a Web service type, aprotocol used by Web services, or a category system.

UDDI provides well-defined programming interfacesfor users to inquire and update the service registry data.The inquiry API and publication API are both basedon SOAP messages. The inquiry API enables servicerequesters to find and get details about Web services.The publication API enables service providers to pub-lish services, update services information, and updatethe security mechanism.

The major usage mode of current Web service dis-covery technologies is design time discovery [9]. Usersquery the service registry, retrieve the service descrip-tion, and write the client code to invoke the service. Toaccessing Web services at large, it requires WS discoveryto support dynamic binding. However, a significant chal-lenge for dynamic binding is to unambiguously describeWeb service using machine interpretable languages. Inaddition, issues such as fault-tolerance and load-balanc-ing also need to be addressed [9].Semantic UDDI [78] An approach for empoweringthe UDDI registries with semantic capabilities is pre-sented in [78]. It shows how DAML-S Service Profilescan be mapped into the UDDI records providing a wayto record semantic information within a UDDI registry.It also shows how the UDDI registries can be modifiedto use the semantic information provided by DAML-S.The proposed approach identifies two types of attributesin a DAML-S Service profile: UDDI-like and DAML-S

Q. Yu et al.

specific attributes. The UDDI-like attributes are mappeddirectly from the DAML-S Service Profile to UDDIrecords as they already exist in UDDI. This is the casewith provenance information such as the name and ad-dress of the service provider. The DAML-S specific attri-butes, such as geographicRadius, qualityRating, precon-dition, and effect, are represented using the tModelmechanism defined in UDDI. The mapping of DAML-S specific attributes requires the specification of a setof fifteen (15) UDDI tModels, one for each attribute.BusinessService records use these tModels to index thevalues they store from the DAML-S Service profile theyintend to represent. One of the tModels, the DAML-StModel, has a special meaning; it states that the ser-vice advertised has a DAML-S service representation,and its value is the URI of the DAML-S service that isrepresented by the current profile. A DAML-S match-ing engine uses ontology-based information for searchrequests to obtain the UDDI keys which are in turnused to retrieve the service descriptions from the UDDIregistries.ebXML Registry [34] Another example for a Web ser-vice registry standard is the ebXML (electronic businessXML) registry. The ebXML registry acts as a databasefor data regarding business to business communication.It follows a similar concept like the UDDI registries,but is broader in scope. An ebXML registry is capa-ble of storing arbitrary data including XML documents,text documents, images, sound and video [33]. Instancesof such content are referred to as a RepositorytItems.RepositorytItems are stored in a content repositoryprovided by the ebXML Registry. In addition to theRepositoryItems, an ebXML Registry is also capable ofstoring standardized metadata that may be used to fur-ther describe RepositoryItems. Instances of suchmetadata are referred to as a RegistryObjects.

The ebXML registry includes two major specifica-tions. The ebXML Registry Information Model specifi-cation defines the types of metadata and content thatcan be stored in an ebXML Registry. The compan-ion document ebXML Registry Services and Protocolsdefines the services provided by an ebXML Registry andthe protocols used by clients of the registry to interactwith these services. The ebXML registry offers two sep-arate interfaces, the LifeCycleManager Interface and theQueryManager Interface. The LifecycleManager han-dles the submission of objects, the classification schemesof object and the removal of obsolete objects from theregistry. The QueryManager interface enables the dis-covery of Web services. It consists of two parts allow-ing search with SQL expressions and Filter expressions,respectively.

WS-MetadataExchange [4] Web services use metada-ta (i.e., service description information) to describe whatother Web services need to know to interact with them(e.g., WSDL description). The Web services metada-ta exchange (WS-MetadataExchange) enables the re-trieval of metadata associated with a Web service. Whileservice registries, such as UDDI and ebXML registries,are used to store metadata about Web services, WS-MetadataExchange is intended for the retrieval ofsuch metadata. However, it is not intended to provide ageneral purpose query or retrieval mechanism for othertypes of data associated with a service, such as statedata, properties and attribute values. The WS-Metada-taExchange defines two request–response interactionsfor getting service’s metadata: Get and Get Metadata.When the type of metadata sought is clearly known,(e.g., WSDL), a requester may indicate that only thattype should be returned by using the Get request. Whenadditional types of metadata are being used, or are ex-pected, or when a requester needs to retrieve all of themetadata relevant to subsequent interactions with anendpoint, a requester may indicate that all availablemetadata, regardless of their types (e.g., WSDL, WS-Policy, etc.), are expected. This is done by sending a GetMetadata message. The WS-MetadataExchange speci-fication is an initial public draft release and is up forreview for later submission to a standards body, likelyOASIS.

4.4 Process layer

The messaging, representation, and discovery layersachieve simple interactions with Web services, whereservice requestors invoke a single operation. The pro-cess layer supports more complex interactions betweenWeb services. It relies on the basic interaction function-alities provided by the technologies at lower layers inthe Web service stack. For example, it needs the discov-ery and representation layers for querying and locatingWeb services based on their descriptions. The selectedWeb services are used to construct the process, whichconsists of a sequence of coordinated Web services. Thebenefits offered by the process layer lie in four majoraspects. First, Web service processes enable organiza-tions to outsource existing Web services, which avoidsdeveloping new applications from scratch and ensuresa rapid time-to-market deployment. Second, it reducescomplexity, because complicated services can be incre-mentally constructed out of relatively simple designs.Third, application development based on Web servicesreduces business risks as reusing existing services avoids


Coordination Choreography

Orchestration Coordination

Contains

Describes Coordination Protocols

Provides Orchestration Models

Conversation Conversation Conversation

Fig. 6 Key concepts in the process layer

the introduction of new errors. Finally, the possibilityof outsourcing the “best-in-their-class” services allowscompanies to increase their revenue.

Figure 6 illustrates the relationships between the keyconcepts in the process layer. Web service coordina-tion and composition offer technological support to con-struct complex Web service processes. Coordination andcomposition are highly related but focus on differentaspects of a process. Coordination provides externalprotocols for enabling collaboration among multipleWeb services, whereas composition refers to the pro-cess of developing a composite Web service. A com-posite Web service is defined as a conglomeration ofoutsourced services [67]. Three concepts that are re-lated to coordination and composition are conversation,choreography, and orchestration. A conversation is asequence of message exchanges between a service andits requester [17]. A coordination protocol contains a setof justified conversations. Coordination protocols aredescribed by a choreography, which tracks the messagesexchanged by multiple Web services. Although a cho-reography involves multiple parties, no single party hasa full control of the conversations. Orchestration refersto an executable Web service process. It is controlled bya single party. An orchestration model (e.g., statecharts,Petri Nets, pi-calculus) specifies the order and condi-tions to invoke the component services in a compositeservice achieved through the composition process.

4.4.1 Web service coordination and choreography

Coordination protocols specify the procedures that par-ticipant Web services need to follow to achieve theirinteroperation. They are analogous to service interfaces,which describe how to interact with Web services. Theimplementation details are hidden from service reques-tors. Coordination protocols are public documents whichcan be published in some service registries. This enablesdesign-time discovery and runtime binding. Coordina-

tion protocols are described by a choreography. Currentproposals that support Web service coordination andchoreography including WS-Coordination, WS-CDL,and BPSS.WS-coordination [74] WS-Coordination aims tosetup a framework for supporting coordination proto-cols. The framework includes two major components:coordinator and participants. The participant relies onthe coordinator to interact with other participants. WS-Coordination defines a coordination protocol, acoordination type, and a coordination context to spec-ify the interactions between the participants and theircorresponding coordinators. Specifically, a coordinationprotocol defines a set of rules to guide the interaction be-tween a coordinator and its participants. A coordinationtype is a collection of related coordination protocols. Acoordination context specifies a data structure, whichmarks the messages that belong to the same coordina-tion. There are three modes of interactions between theparticipants and their corresponding coordinators: acti-vation, registration, and protocol-specific interactions.In the activation mode, a participant sends a requestto its corresponding coordinator for setting up a newcoordination context. Once the participant initiates aninstance of coordination type, the new context is cre-ated. In the registration mode, a participant registerswith a coordinator to join the execution of a coordina-tion protocol. The coordinator will notify the participantwhen the coordination protocol is being performed. Inprotocol-specific interactions mode, the participants andtheir coordinators exchange protocol-specific messages.The three modes of interactions are supported by ei-ther of the two architectures: central and distributedcoordinations. In the former, all participants commu-nicate with a single coordinator, whereas in the latter,each participants communicate with its own coordina-tor. WS-Coordination identifies the key component forbuilding a coordination framework. However, it doesnot specify a language to define the coordination pro-tocols. Such a language is specified by WS-CDL, whichwill be introduced next.WS-CDL [115] Web Services Choreography Descrip-tion Language (WS-CDL) is an XML-based languagethat describes the cross-enterprise collaborations of Webservices from a common viewpoint. It describes the rulesand agreement to which the participant services need toconform. The main feature of WS-CDL is that neitherit is an executable process language (which is differentfrom WSFL or XLANG), nor it depends on any spe-cific process implementation language. The advantageof this feature is that WS-CDL can support interoper-able collaborations between Web services regardless oftheir supporting platforms or programming models.

Q. Yu et al.

The WS-CDL describes a Web service participant intwo aspects: static coupling and dynamic coupling. Thestatic coupling specifies the static collaboration con-tact-points of the service participant. It contains theinformation about roles and relationships. Each Webservice participant needs to show the observable behav-ior so as to join collaborations. Such behavior is specifiedby a role. Based on the role, a relationship describes themutual commitment between two participants. Partici-pants are obliged to conform to their roles and relation-ships with others to join collaborations. Thedynamic coupling contains the information about thecommunication and synchronization between Web ser-vice participants in a collaboration.

The core of WS-CDL is the definition of choreog-raphy. A choreography constructs a collaboration ofWeb service participants based on their roles. A cho-reography contains several react elements. The reactelement identifies the actions that react to the availabil-ity of variable information and constraint conditions. Achoreography also contains a recovery mechanism tosupport transactional interaction between Web serviceparticipants. A choreography defines a recovery blockusing a recover element. Once an exception occursin a recovery block, a compensation activity would beperformed to recover from exceptional conditions. Inaddition, a choreography can be reused to create a newchoreography.BPSS [34] The Business Process Specification Schema(BPSS) of ebXML is available in UML and XMLversions. The UML version only defines a UML classdiagram. It is not intended for the direct creation of abusiness process specification but provides a represen-tation of all the elements and relationships required forits creation. The XML version allows the creation ofXML documents representing ebXML-compliant busi-ness process specifications. ebXML provides a set ofcommon business process specifications that are sharedby multiple industries. These specifications, stored in thebusiness library, can be used by companies to build cus-tomized business processes. Interactions between busi-ness processes are represented through choreographies.To model collaboration in which companies can en-gage, ebXML defines Collaboration Protocol Agree-ments (CPAs). A CPA is an agreement by two tradingpartners which specifies in advance the conditions underwhich the trading partners will collaborate (e.g., termsof shipment and payment).

4.4.2 Web service composition

Web service composition is a process that combines out-sourced Web services to offer value-added services [92].

Web service composition is different from traditionalapplication integration, where applications are tightlycoupled and physically combined. Web services adopt adocument-based messaging model, which supports theintegration of loosely coupled applications that areacross multiple organizations. WS composition can beconducted in three different fashions: process/program-ming, interaction, and planning.Process-based composition Most existing Web servicecomposition techniques require programming to someextent for constructing the orchestration model[23,14,24]. Composers first need to study the compo-nent services that are described using WSDL or someontology languages and understand the functionalitiesof the services and the supported operations. A furtherstep analysis requires to identify the way operationsare interconnected, services are invoked, and messagesare mapped to one another. The process-based com-position scheme makes the process of composing ser-vice demanding for composers. Composers need to bedomain experts who are familiar with the service descrip-tion language, the service orchestration algebra, and thecorresponding programming skills. Since common userscannot act as a service composer, the programming-based scheme hinders common users from composingWeb services at large.

BPEL4WS is a process-based composition approach.It combines the key features of XLANG and WSFL [84].BEPL4WS models the behavior of a businessprocess based on the interactions with the involved busi-ness partners. It establishes grammar guidelines todescribe the business process based on XML, includingits control logic and message format. It uses WSDL tomodel the services in the process flow. It also depends onWSDL to describe the external services that are neededby the process. A major design goal of BPEL4WS is toseparate the public aspects of business process behaviorfrom the internal ones. The separation helps businessesconceal their internal decisions from their business part-ners. Moreover, internal changes of the process imple-mentation no longer affects the public business proto-col. Therefore, BPEL4WS has both abstract and execut-able business processes to support the separation. Anabstract process also refers to the business protocol. Itspecifies the public aspects in the business interactions.Specially, an abstract process only deals with the ex-changes of public messages between business partners.It is isolated from the execution of a process flow. There-fore, an abstract process will not release any internal de-tails of the process to its partners. An execution processcontains the logic and state of a process. It specifies thesequence of the Web Service interactions conducted inthe business process of each business partner. A busi-


ness process consists of several steps called activities.BPEL4WS supports two types of activities, includingbasic activities and structured activities. Basic activitiesmanage the interactions of the process with its externalresources. Its major task is to receive, reply, and invokeWeb services. Structured activities control the overallprocess flow. They specify the sequence of Web servicesin the flow. BPEL4WS also defines a set of control con-structs to enable the sequencing mechanism, which issimilar to XLANG. BPEL4WS provides a set of mecha-nisms to support transactions and handle exceptions. Ituses a scope element to aggregate several activities in atransaction. When an error occurs, a compensation pro-cedure will be invoked, which is also similar to XLANG.Interactive composition The interactive compositionscheme blurs the distinction between composers andcommon users. Composers are required to have a cleargoal and know the tasks that need to be performedto accomplish the composition. Common users can beguided through a set of steps to finish a composer’s task.The composition scheme will work interactively withthe common users to help them achieve the orchestra-tion model. The orchestration process can start fromusers’ goals and work backward by chaining all relatedservices. It can also start from some initial states andachieve the users’ goals by adding services in the for-ward direction. At each step, the scheme will choosea new service based on the task specified by the users.The interactive scheme can also capture the constraintsand preferences during the interaction process. The con-straints and preferences can serve as additional criteriato select services for the composition.

An interactive composition approach is proposed in[95]. It adopts the OWL ontologies to model the com-ponent services. The service model specifies the input,output, precondition, and effects (IOPE) of services.The proposed approach also implements a tool for auto-matic translation from WSDL to OWL-S, which enablesthe support of WSDL-based component services. Thedata types are defined by XML-schema and messageexchange between component services relies on the dataflow approach. The composed service are specified usingOWL-S. The interactive composition can be performedby chaining component services in either the forward orthe backward directions. At each step, the compositionscheme adds a new service based on the users’ selection.Existing component service in the orchestration modelcan serve as a criterion to filter candidate services. Onlythe services that match the IOPE properties of existingservices can be selected by the system and presented tothe users.

Planning-based composition The planning-based com-position scheme aims to relieve users from the com-position processes as much as possible. It relies on AIplanning techniques for automatic service composition.In this context, users are allowed to submit a declarativequery specifying the goal he/she wants the compositeservice to achieve together with some of the constraintsand preferences that need to be satisfied. Based onthe user’s query, the composition scheme can derive acorresponding orchestration model with all constraintsand preferences satisfied. The planning scheme regardsservices as actions that are applicable in states. Statetransitions are specified using the preconditions of someactions. A transition will lead to some new states, inwhich the effects of some actions are valid. Based onthis, the composition scheme recursively adds new ser-vices until users’ goals have been achieved. The states ofexisting service in the orchestration will determine theselection of the new services. For example, the precon-ditions of the new services should be satisfied via theeffect of some existing services.

A representative planning-based composition appro-ach is presented in [64]. It is based on situation cal-culus to compose Web services. More specifically, itadopts Golog, which is a logic programming language,and makes some extensions to adapt it to Web ser-vices. The situation calculus enables software agents toreason about Web services. Web services are modeledas actions, which is similar to the classical AI planningproblem. Web services are associated with some pre-conditions and generate some effect under these pre-conditions. Simple Web services are categorized intotwo groups. The Web services in the first group performinformation collection actions. The Web services in thesecond group perform world-altering actions. Compos-ite Web services perform complex actions by composingsimple Web services from both groups. Users can specifytheir requests and constraints, which can be transformedusing situation calculus. Users’ constraints can be usedto customize the predefined generic composition tem-plates. This helps generate the specific composition plansthat fulfill users’ requirements.

Web service processes involve complex interactionsamong different Web services across organization bound-aries. Automating complex Web service processes helpachieve the seamless interoperation between applica-tions on the Internet. Several major issues need to beaddressed pertaining to the WS processes. For example,WS interactions need to take place in such an envi-ronment that security is ensured and privacy is pre-served. Web services are usuallyautonomous and their

Q. Yu et al.

availability fluctuating. Failures and changes are expectedto occur frequently. New services are continuously emerg-ing on the market. The security, privacy, transactionsupport, change management, monitoring, and QoWScomponents in the proposed WSMS are required func-tionalities to address the above issues. The followingsections give a detailed introduction of each of thesecomponents.

5 Web service security and privacy

Web services use the Internet to perform their function-alities and interact with service users. This calls for secur-ing Web services against various attacks and protectingservice users’ private information. Traditional mecha-nisms ensure data security by fulfilling threerequirements: (1) data confidentiality, which refers toprotecting data against unauthorized disclosure, (2) dataintegrity, which refers to protecting data against unau-thorized or improper modification, and (3) data avail-ability, which refers to protecting and recovering fromdata access denials [15]. Solutions include k-anonymity,data encryption, digital signature, and variousaccess control policies. Web service security and privacyextend these mechanisms and tailor them to the complexfeatures of Web services.

5.1 Security

Web services are accessed by receiving SOAP messagesas inputs, performing requested actions, and sendingSOAP messages as outputs. Therefore, the main objec-tive of securing Web services is to provide mechanismsfor ensuring that services act only on the authorized re-quests and for ensuring SOAP messageconfidentiality and integrity. Web service securityfocuses on authenticating service requests and com-munication infrastructure. Securing XML data in Web-based environment introduces more requirements thanin a traditional data security scenario. First, it is requiredto build up confidential systems between Web servicethat are autonomous and unknown to each other. As aresult, Web service security heavily relies on Public KeyInfrastructure (PKI). Second, it is required to provideflexible, declarative specification on user credentials andprofiles. Besides user login information, other attributes(such as age, location, etc.) might be included in accesscontrol policies [59].

Traditional security techniques can be used to buildup a secure transport channel for exchanging messages.Typical examples include Secure Sockets Layer (SSL)and Transport Layer Security (TLS). SSL has been widely

used in securing Web documents [71]. It works betweenHTTP and TCP network layers. SSL relies on pub-lic- and private-key encryption mechanism. It is alsocombined with digital certificates, which depend on third-party authority to authenticate users. TLS provides con-nection security based on encryption. The SSL and TLSenable point-to-point (server-to-server) secure sessions.However, they cannot deal with the scenario where aSOAP message is routed via more than one server. Inthis case, the credential of the sender needs to be deliv-ered in the SOAP message, which would cause scalabil-ity problems.

A few industry standards are already emerging forsecuring Web services, including Security AssertionMarkup Language (SAML) and Web Services Secu-rity protocol (WSS) [42]. SAML includes security infor-mation, such as user identity and access right, into itsdefined schema for document structure. It enablesinteractions between systems with different securityarchitectures. SAML works with SOAP to exchangeauthentication, attribute, and authorization assertionsfor securing Web services. WSS is a newly ratified stan-dard by Oasis [75]. It enables Web services to carry secu-rity data in the headers of SOAP messages. The WSSrelies on two security technologies – XML Digital Sig-nature and XML Encryption – to include both encrypteddata and digital signatures in XML documents [107,108].In addition, it uses security tokens, such as SAML asser-tion and Kerberos authentication tickets, to validate dig-ital signatures [42].

5.2 Privacy

Web services offer a more convenient and efficient envi-ronment for Web users. Users can perform tasks, con-duct business, and access high-quality information withgreat ease. However, to interact with Web services, Webusers generally need to divulge sensitive information,such as Social Security Number (SSN), income, occu-pation, and home address. The user–service interactionmay cause violation of Web users’ privacy due to thereleasing of their personal information. Privacy, in gen-eral, refers to “the control an individual has over infor-mation about himself or herself” [116]. Web serviceprivacy concentrate on privacy enforcement when Webuser’s privacy is to be released to third parties. In thiscase, the user’s privacy is no longer under the control ofthe Web service. More specifically, Web privacy refers to“the right of Web users to conceal their personal infor-mation and have some degree of control over the use ofany personal information disclosed to others” [89].

Standardization efforts have tried to address the Webprivacy protection issue. A typical example is the W3C’s


Platform for Privacy Preference (P3P) [114]. P3P stan-dardizes the way to encode privacy policies in XMLfor Web sites. It also specifies the mechanisms to lo-cate and transport privacy policies. However, the ma-jor focus of P3P is to enable Web sites to convey theirprivacy policies [65]. It is not directly applicable to Webservices. Two promising trends towards developingeffective techniques for privacy preservation are basedon ontologies and reputation, respectively. Ontologiescan add semantics to the specification of privacy modelsand privacy policies [101]. Semantics in privacy modelscan achieve a common understanding of the sensitivedegrees and the context. For example, ontology-basedprivacy model can answer two questions: how sensi-tive the information is; and under what conditions theinformation has that sensitive degree [101]. Defining aprivacy ontology may allow Web services to properlyperform users’ tasks while preserving their privacy [89].Kagal et al. [55] proposes to incorporate privacy poli-cies into OWL-S descriptions and requester profiles. Itdefines algorithms to check policy compliance and inte-grates them in the service selection process of the OWL-S matchmaker. Privacy policies are specified in Rei, alogic-based language that allows rules and constraintsto be defined over domain specific ontologies [54]. Thereputation-based approach enables interacting Web ser-vices to have a better understanding of their mutualbehavior. This information can guide Web services topreserve users’ privacy when interacting with other Webservices [90].

6 Quality of web services

The concept of quality of service (QoS) has been widelyused in middleware and networking communities [11,60]. Research efforts in these communities mainlyfocus on the performance of network and devices. Therehas been a surge in adapting the QoS concept to Web ser-vices in line with their fast growth. Quality ofService or Quality of Web Service (QoWS) could encom-pass a number of quantitative and qualitative parame-ters (non-functional properties) that measure the Webservice performance in delivering its functionalities. Wepresent a taxonomy of QoWS parameters to clearlyidentify the different quality aspects of Web services.The definition of this taxonomy is based on a summa-rization of different QoWS parameters from existingliteratures [26,121,62]. Figure 7 shows the QoWS tax-onomy including the different QoWS types and theirrelationships. The root type QoWS has two subtypes,including runtime quality and business quality. These

quality parameters can be evaluated using quantitativeor qualitative measurements.Runtime quality represents the measurement ofproperties that are related to the execution of an oper-ation. We identify five runtime quality classes: responsetime, reliability, availability, accessibility, and integrity.

– Response time Response time measures the ex-pected delay between the moment when a serviceoperation is initiated and the time the operationsends the results. This parameter can be quantita-tively measured.

– Reliability Reliability measures the ability of a ser-vice operation to be executed within the maximumexpected time frame. This parameter can be quanti-tatively measured.

– Availability Availability measures the probabilitythat the service operation is operating at any givenmoment and is available to perform its function onbehalf of its users. In another word, a high avail-able service operation is one that will most likely beworking at a given instant time. This parameter canbe quantitatively measured.

– Accessibility Accessibility measures the degreethat a service operation is capable of serving a Webservice request. It may be expressed as a probabilitymeasure denoting the success rate or chance of a suc-cessful service instantiation at a point in time. Therecould be situations when a Web service is availablebut not accessible. High accessibility of Web servicescan be achieved by building highly scalable systems.Scalability refers to the ability to consistently servethe requests despite variations in the volume of re-quests. This parameter can be quantitatively mea-sured.

– Integrity Integrity measures how a service oper-ation maintains the correctness of the interactionin respect to the source. Proper execution of Webservice transactions will provide the correctness ofinteraction. A transaction refers to a sequence ofactivities to be treated as a single unit of work.All the activities have to be completed to make thetransaction successful. When a transaction does notcomplete, all the changes made are rolled back. Thisparameter can be qualitatively measured.

Business quality allows the assessment of a serviceoperation from a business perspective. We identify threebusiness attributes: cost, reputation, and regulatory.

– Cost Cost measures the units of money that a ser-vice requestor needs to pay to invoke service

Q. Yu et al.

QoWS

Business

subTypeOf subTypeOf

Runtime

Cost

Reputation

Regulatory

ResponseTime

Reliability

Availability

Accessibility

QuantitativeMeasurement

QualitativeMeasurement

Integrity

subTypeOf subTypeOf

subTypeOf

subT

ypeO

f

subTypeOf

QoWSMeasurement

subT

ypeO

f

Fig. 7 A taxonomy of QoWS parameters

operation. This parameter can be quantitativelymeasured.

– Reputation Reputation measures the trustworthi-ness of a service operation based on user feedbacks.Users are prompted to rate service operations on ascale after using them. The reputation correspondsto the average of collected ratings. This parametercan be quantitatively measured.

– Regulatory Regulatory measures whether a Webservice in conformance with the rules, the law, com-pliance with standards, and the established servicelevel agreement. Web services use a lot of standardssuch as SOAP, UDDI, and WSDL. Strict adherenceto correct versions of standards (for example, SOAPversion 1.2) by service providers is necessary forproper invocation of Web services by service reques-tors. This parameter can be qualitatively measured.

The QoWS taxonomy is not meant to be exhaustiveby addressing all aspects of QoWS. Other quality param-eters can be included to fulfill the requirements of differ-ent application domains. The taxonomy generalizes a setof important QoWS parameters, which have been emer-gent in current literatures. The definitions convey themeanings of the each quality parameter in the context ofWeb services. They also give a hint of how these qualityparameters can be quantitatively or qualitatively mea-

sured. A typical WS deployment system would addressonly some quality aspects defined in this QoWS tax-onomy. The business requirements and usage scenariosdecide which quality aspects a system needs to address.

7 Web service management

The WS management offers a set of management capa-bilities to monitor and control service qualities and ser-vice usage. Web service management mechanisms arehighly coupled with QoWS of a Web service. Moni-toring management aims to rate the behavior of Webservices in delivering their functionalities in terms ofeach QoWS parameter. Monitoring Web service behav-ior would be crucial in either assessing QoWS param-eter values or ensuring a Web service to maintain itspromised QoWS. Control management aims to improvethe service quality through a set of control mechanisms.Typical control mechanisms include Web service trans-action and coordination, Web service change manage-ment, and Web service optimization. Transactions helpimprove the reliability and fault-tolerance of Web ser-vices. Change management deals with highly dynamicenvironment of Web services. It takes a series of actionsto identify the changes, notify the coupled entities, andadopt appropriate operations to respond to the changes.


Web service optimization helps users identify Web ser-vices and/or their combinations to best fulfill theirrequirements.

Control management and monitoring managementmight sometimes work cooperatively. For instance, theWeb service optimization would need the monitoringprocess to get the QoWS parameter values of differ-ent Web services and/or their combinations. These val-ues will guide the optimization process to return theoptimized solutions that best fulfill users’ requirements.Similarly, change management also needs the monitor-ing process to report changes so that it can make thecorresponding reactions.

7.1 Monitoring web services

Web services are dynamic and autonomous entities.They rely on communication protocols (e.g., HTTP,SMTP) and a messaging model to offer miscellaneousfunctionalities on the Web. However, the underlyingcommunication protocols could be unreliable and inca-pable of meeting the function delivery requirement. Forexample, HTTP is a stateless protocol that does notguarantee the order of the arriving packets and the suc-cessful delivery of these packets to the destination. Inaddition, the messaging model requires parsing inten-sive XML data with a lot of type information, whichis rather time consuming. These could both introducefailures for Web services in the delivery of their func-tionalities. Complex WS processes involve multiple Webservices and require more complex interactions, wherefailures could occur frequently. Monitoring offers a“fault detection” mechanism that checks the health of aservice in real time and tries to reduce application down-times by detecting signs of failure. It ensures that theservice is available, accessible, and capable of meetingthe throughput and latency requirements. In addition, asmore Web services are expected to emerge on the Web,several Web services may compete in their offerings fora given functionality. The key difference would be onhow these functionalities are to be delivered in termsof QoWS. However, getting the right value for a givenQoWS parameter is neither an easy nor a trivial task. Inthat context, monitoring Web services behavior wouldbe crucial in either calculating QoWS parameters valuesor assessing a Web service’s claim in term of promisedQoWS.

Monitoring may take different forms, depending onthe QoWS parameter. These include message intercep-tion, probing, value collection, and user feedback. Toallow probing, Web services need to support some “free”operations that can be invoked without any effect for theinvoker. Ideally, Web services should support a “ping”

operation. To avoid a high overhead on the system, mon-itoring could be conducted periodically. Some QoWSparameters are not measurable through the Web servicecomputational behavior and need the feedback fromusers. For example, reputation may be obtained fromthird party based on the Web service business behavior.Table 1 summarizes how monitoring is conducted foreach QoWS parameter.

A frequent monitoring strategy helps precisely reflectthe execution performance and behavior of a Web ser-vice. However, this may put a significant burden on theresources. A fair approach would be to have a config-urable monitoring approach. In this case, the differentparameters are adjusted depending on the requirements,in terms of rating precision, of the application beingused.

7.2 Transactional support

Cross-enterprise business processes involve autono-mous Web services from different business entities.Transaction support is required to provide reliable anddependable execution of WS processes. Transaction sup-port is highly coupled with the process level. However, amajor difference between transaction support and otherprocess-level technologies (e.g., coordination and com-position) is that it is not used to construct a WS pro-cess. Instead, it improves the quality of a WS process interms of reliability and fault-tolerance, etc. In traditionaltransactions, the transaction monitors are in charge ofall the resources that are involved in the transactions.They adopt a 2PC (i.e., two phase commit) transactionmodel to maintain Atomicity, Consistency, Durability,and Isolation (ACID) of transactions. Since the 2PCrequires locking resources for the duration of the en-tire transaction, typical ACID transactions are tightlycoupled and span over short periods of time. In con-trast, interactions between Web services take place in aloosely coupled manner. No participating Web serviceis in full control of others. Business transactions overWeb services may be long-lived, which include multiplecomplex tasks, such as negotiation, commitment, bill-ing, shipping, and tracking. Resource locking strategies(e.g., 2PC) could hinder Web services and users fromjoining other business processes, hence contradicting thebusiness requirements.

The atomicity of Web services and the long-lived busi-ness processes require transactional support for Webservices that is less strict than the traditional ACID prop-erties. A current proposal that provides such support isWS-Transaction. WS-Transaction extends WS-Coordi-nation by defining a set of protocols for transaction pro-cessing. It relies on the WS-Coordination framework to

Q. Yu et al.

Table 1 WS monitoring

Quality type Parameter Monitoring type Monitored information

Runtime Response time Messages interception Average of actual response timeReliability Probing through pinging Ratio of successful pings over a period of timeAvailability Probing through pinging Ratio of successful pings over total number of pingsAccessibility Messages interception Ratio of successful invocations over total number of invocations

Business Cost Values collection Difference between advertised and requested feesReputation User feedback Average rating from a group of usersRegulatory Not applicable Not applicable

manage the transactions across multiple Web servicesbased on the transaction protocols. Specifically, a cen-tralized coordinator or a set of distributed coordinatorscoordinates Web services that participate in a transac-tion. WS-Transaction defines two coordination types:atomic transaction and business activity. The former sup-ports short-lived transactions involving participants thatreside in a trust domain. It adopts the 2PC protocol tocoordinate participating Web services, which is similarto traditional transactions. The latter supports long-livedtransactions involving loosely coupled participants. Itadopts compensations to deal with transaction failures.If one of the transaction steps fails, the completed stepsare compensated to ensure consistency. In contrast tothe immediate consistency achieved by 2PC, compen-sations allow intermediate inconsistency of transactionsbefore all compensation steps are finished [81].

The challenge for automating WS transactions is thatthey have no precisely defined transaction concepts suchas commit, abort, resource, and lock [9]. In traditionaltransactions, these concepts are defined upon a fixedset of operations, which consist of creation, inserting,update, and deletion. However, WS representation (e.g.,WSDL) could encode various operations. For differentoperations, the transaction concepts can be interpretedin different ways. Therefore, it is difficult to define auniform set of transaction concepts that can be appliedto all WS operations. For example, when a WS transac-tion is aborted, the completed WS operations need tobe compensated. However, the compensation strategieswould vary based on the functionalities of the opera-tions, the business requirements of the service providers,and other context (e.g., users’ profile). This would resultin different abort results. In our travel scenario, assumethat Joan’s travel plan has to be canceled after the airticket has been purchased. Based on the functionality ofticket purchase, the corresponding compensation is toreturn the ticket and get the money back to Joan’s creditcard. However, AirCompany requires that customersshould notify them 3 days prior to the departure date toget a full refund. Otherwise, a late fee will be chargedbased on the notification date. In addition, for frequent

fliers of AirCompany, they only need to send their can-cellation notification 2 days prior to the departure dateto get the full refund. As we can see, compensation of asimple business operation could be associated with com-plex conditions. The abort result will be different underdifferent conditions. Therefore, it is important to extendthe description of services by unambiguously describ-ing transactional semantics of Web service operations.This would be the prime step for automating transactionprocessing of Web services.

7.3 Change management

The Web service life cycle is characterized by its highlydynamic features: (1) New services may come into playwithout notification of existing services. For instance,A new hotel service might begin its business and pub-lish the service description on the UDDI repositorywithout releasing any information to TravelAgencyin advance; (2) operating services might stop function-ing without any indication. For instance, Hotel mightonly operate in summers but close in winters because ofthe little volume of clients; (3) functionalities of servicesmight change overtime. For instance, AirCompanycould suspend the scheduled flights to a health resortdue to the propagation of an infectious disease in itsarea.

One of the fundamental challenges in enabling WSprocesses is to manage changes in their lifecycle. We ex-pect that WS processes would only thrive if they are ableto quickly and automatically adapt to changes. Changescould happen in any stage of the WS lifecycle, includingdevelopment, deployment, and maintenance. We dis-cuss change management as part of the maintenancestage of the WS lifecycle. Current methods of changemanagement are usually ad hoc and require significanthuman involvement (e.g., business process re-engineer-ing, continuous process improvement). Workflows havetraditionally been used to model and enact organiza-tional business logic. In this approach, tasks are mappedto business units for enactment. These units are usuallypart of one single enterprise. The enterprise’s internal


structure is fairly static and the rate of organizationalchange is usually very slow. Therefore, changes in work-flows have usually been modeled as exceptions. In con-trast, the WS processes consider changes as the rule, andany solution to change management would need to treatthem as such.

A prerequisite for change management is to derivea uniform specification of changes that may occur ina WS process. There are two approaches to specify-ing changes: top-down and bottom-up. A top-down ap-proach focuses on changes that are usually voluntary andbusiness mandated [7]. For example, the WS processesmay add a new service to its composition to take advan-tage of a business opportunity. Hence, top-down changesare motivated by the WS process’s business goal. Unliketop-down changes, bottom-up changes are initiated bythe member services [8]. For instance, a member ser-vice operation may become unavailable during execu-tion and as a result, would trigger the WS process toreplace the service. Hence, bottom-up changes are man-dated by the member services, and are usually moredisruptive than top-down changes.

Changes have been modeled using various tools andtechnologies [35]. For example, the Z language has beenused to reflect changes in database schema [36]. How-ever, changes to Web services are fundamentally differ-ent from changes in databases. Web services consist ofbehavioral aspects that are not relevant to data. In [79],the author defines a strategy for extending the serviceoriented architecture to enable change management.This work proposes the management of functional andnon-functional changes to Web services. However, theresearch is at an early stage, and it does not yet providea core set of specification for modeling and managingchanges. In [76], Web service attributes are defined in ataxonomy of non-functional properties and representedby a series of Object-Role Models (ORM). An exampleis the attribute of service availability. The authors havedefined service availability and its temporal characteris-tic from two perspectives: service provisioning and ser-vice request. Finally, workflows provide the ability toexecute business processes that span multiple organiza-tions [99]. Traditional workflows provide little supportfor dynamic change management. Workflows are gearedtowards static integration of components. Furthermore,workflows do not cater for the behavioral aspects of Webservices. For example, they do not distinguish betweenthe internal and external processes of a Web service [21].

The use of visual modeling techniques, such as Petrinets in the design of complex service oriented enter-prises, seems justified because of several reasons [49].Petri nets provide attractive properties for modeling,including formal semantics, graphical representation,

powerful expressiveness, and abundant analysismethods [45]. In that respect, the Petri nets are based onwell-grounded mathematical foundation. They can rep-resent system models graphically as net diagrams. There-fore, they provide an easy communication betweendifferent parties. Petri nets have the ability to also dealwith asynchronous concurrent systems. Finally, they pro-vide multiple analysis methods, such as coverability tree,incidence matrix, and state equation. These methodshelp identify system properties readily. Because of thecomplexity of changes in WS processes, formal modelingis a useful method to improve the understanding of theproblem and the solution. An essential step in changemodeling is to validate the model. Petri net theory pro-vides algorithms and methods, which can be applieddirectly to the model and its analysis to validate themodel. Other modeling and specification techniqueshave been proposed, but lack easy formalization fea-tures required by change management in WS processes[35,36].

In [6], a taxonomy of changes in service orientedenterprises has been identified using a bottom-upapproach. It first describes triggering changes that mayoccur in Web services. These changes are then mappedto reactive changes in Web service processes. The speci-fication of changes is a prerequisite to successfully man-aging changes in a Web service process. It uses Petrinets as a change specification tool because they providea visual representation of changes. Furthermore, a Petrinet model is used readily for verifying changes in Webservice processes.

7.4 Optimization

The proliferation of Web services will introduce com-petition between large numbers of Web services thatoffer similar functionalities. Selecting the best servicefrom a large space of options would be a big challengeto service consumers. Some services might offer certainbenefit in several aspects, less attractive in other aspects.For example, in our travel scenario, the client can choosea hotel that provides the most convenience. The hotelcould be close to many local attractions. However, therate of this hotel could be very expensive, which exceedsthe client’s budget. In this case, the client may have tolook for other hotels, which might be far away from thelocal attractions but with a lower rate. In this case, theclient might need to rent a car or take taxis. In this case,she would have to choose among competing taxi or carrental services. Typically, the available options for eachof these services would be many more than what wementioned earlier.

Q. Yu et al.

Web service optimization offers strategies for find-ing the “best” Web services or their composition withrespect to the expected user-supplied quality. Due tothe large space of competing Web services, a servicerequest could be potentially resolved by multiple ser-vices. Thus, it is necessary for WS optimization to setappropriate criteria to select the “best” among possiblechoices. Recent research literature shows that QoWSof individual Web services is crucial for their compet-itiveness [26]. The challenge for WS optimization is todefine appropriate metrics to characterize QoWS anddevise techniques to use it in optimizing service-basedqueries. However, only selecting individual services isstill not enough since some services may be related toeach other. Services need to be composed and consid-ered collectively. Therefore, how properties of multipleservices can be combined will be an important issue.This usually depends on how the composed process usesthese constituent services (e.g., sequential, parallel, etc).In [121], a quality model is presented to integrate prop-erties from multiple Web services. The quality modelcan then be used to evaluate the quality of the com-posed Web service processes.

Optimization techniques have been widely adoptedin different types of DBMS (e.g., central, distributed,and multidatabases) for optimizing data queries. Theultimate goal of any database system is to allow effi-cient querying. A fundamental difference between data-base query optimization and WS optimization lies inthe manipulated objects. The first class objects in WSoptimization are services or their compositions whiledata is the first class object in databases. In WS optimi-zation, optimization focuses on QoWS parameters re-lated to the behavior of the Web services while in mostexisting techniques, optimization concerns only the re-sponse time of the query execution plan. QoWS optimi-zation can be achieved through a three-phase process:candidate service selection, negotiation, and enactmentmonitoring in [18].

8 Evaluation of Web service deployment systems

We present a representative set of WS deployment sys-tems in this section. These systems adopt different tech-nologies to provide the functionalities identified by theWSMS framework. These include interoperation, secu-rity/privacy, QoWS, and management. The evaluationonly covers the most representative systems for the sakeof space.

There are some other standardization efforts under-way to fully support for semantic Web services. Forexample, the Semantic Web Services Initiative Architec-

ture (SWSA) committee focuses on providing architec-ture support for deploying semantic Web services [18]. Ithas identified a set of requirements for building a seman-tic Web service architecture. The architecture supportsa three-phase interaction with semantic Web services:discovery, engagement, and enactment. Architecturalrequirements are identified for each interaction phase.Instead of building concrete software components,SWSA aims to generalize the protocols and functionaldescriptions of capacities across a variety of semanticWeb service architectures. This enables specific com-ponents that are consistent with the proposed generalmodel to interoperate with one another.

8.1 Research prototypes

In this section, we present a set of WS deploymentsystems: CMI, Meteor, SELF-SERV, WebDG, AgFlow,WSXM, and IRS.

8.1.1 Collaboration Management Infrastructure

Collaboration Management Infrastructure (CMI) [12,43] provides architectural support to manage collabo-ration processes. The kernel component of CMM is aCore Model (CORE). The CORE provides a commonset of primitives shared by all of its extensions. Theseprimitives fall into two categories – activity states andresources. Activity states can be either generic or appli-cation-specific. Generic activity states follow the conven-tion of the Workflow Management Coalition[117]. They capture activity behaviors that are indepen-dent of applications. Application-specific activity statesenable the precise modeling of the peculiar applications.The CORE identifies several primary resource types forthe activity execution. For example, data resources referto the workflow internal data. Helper resources referto auxiliary programs that help implement the basicactivities.

The CORE extensions include the CoordinationModel (CM), the Service Model (SM), and the Aware-ness Model (AM). The CM coordinates participants andautomates process enactment. The CM provides twotypes of advanced primitives: activity placeholders andrepeated optional dependencies. Activity placeholdersenable the run-time service selection. They representservices in a process as activity types at specificationtime. At run time, a concrete activity replaces the activ-ity placeholder to construct an executable process. Aresolution policy helps ensure the syntactic and seman-tic compatibility when replacing the placeholder by anactual activity. Repeated optional dependencies specifythe invocation place of an activity in a control flow path


of a process. They also specify the number of invoca-tions of the given activity to accomplish the application’sobjective. The SM provides rich semantics to describeservices. It introduces the notion of service ontologiesto capture the semantics of services. In addition, the SMuses Quality of Service (QoS) as an important non-func-tional parameter to characterize services and their pro-viders. The resolution policy can choose the service withthe best QoS to optimize the execution of a process. TheAwareness Model monitors the process-related events.It allows authorized composition and delivery of suchevents only to closely related process participants.

8.1.2 METEOR

METEOR [23] is a workflow management platform thatsupports QoS management and service composition. Itsets up a QoS model to describe the non-functionalissues of the workflow. The QoS model consists of fourparameters, including time, cost, reliability, and fidelity.For each parameter, the description of the operationalruntime behavior of a task is composed of two clas-ses of information: basic and distributional. The basicclass specifies the minimum value, average value, andmaximum value the parameter can take in a given task.The distributional class specifies a constant or of a dis-tribution function (such as Exponential, Normal, andUniform) which statistically describes a task’s behaviorat runtime. The values in the basic class are used bymathematical methods to calculate workflow QoS met-rics. The distributional class information is used by sim-ulation systems to compute workflow QoS. METEORforms a mathematical model that collectively uses allQoS parameters. The mathematical model computes theoverall QoS of workflow. It can serve as a guide to pre-dict, estimate, and analyze the QoS of production ofworkflow.

METEOR extends DAML-S to describe Webservices. The enriched service description includes threeparts of information: syntactic description, semanticdescription, and operational metrics, such as QoSparameters. All of this information help match the ser-vice object with a corresponding service template. ME-TEOR also provides registry services to enable the adver-tisement and discovery of Web services. The workflowmanagement system executes the composite servicesand also handles runtime exceptions using acase-based reasoning mechanism.

8.1.3 SELF-SERV

SELF-SERV is a platform for Web services composi-tion [14]. It aims to provide a declarative mechanism to

compose Web services. It defines a peer-to-peer modeto support scalable execution of composite Web ser-vices. SELF-SERV uses a state chart to model the flow ofcomponent service operations. It integrates service con-tainers into its service composition platform. A servicecontainer consists of a set of Web services with commonfunctionalities. The container determines which serviceis selected to execute. It carries out the selection dynam-ically and puts off the selection until the invocation time.The service selection is based on a set of QoWS metricsand their relative weights. The service container alsohandles change management. It provides operations tomonitor services, notify the changes, and make reactionsto the changes. SELF-SERF relies on a set of state coor-dinators to enable the scalable execution of compositeservices. It generates a state coordinator for each state inthe state chart. The state coordinator determines whento enter its associated state depending on the notificationof other coordinators. Once a state has been entered,the coordinator invokes the services and retrieves theresults. The coordinator then notifies other coordinatorswhen it completes the execution of the service. Routingtables maintain the information required by a coordi-nator. The information may include preconditions forentering a state and postactions that notify successivecoordinators.

8.1.4 WebDG

Digital government has turned to be a major applica-tion area of Web services. WebDG is proposed based onthe available Web service technologies [68]. It aims toprovide high quality e-government services by improv-ing the interacting mechanism between government andcitizens. Two major contributions make WebDG distin-guish itself from other e-government service suppliers.The first one is that it introduces the privacy-preserv-ing scheme into Web services. This is among the leadingefforts to combine privacy protection with Web services.While the second contribution is that it realizes the auto-matic service composition based on the semantic featureof Web services.

WebDG enforces privacy from the technology pointof view but not merely depends on the trust of involvedentities. It constructs a three-layered privacy model,including user privacy, service privacy, anddata privacy. Each layer defines its own privacy pol-icy respectively. Obeying these privacy policies, Web-DG implements two privacy preserving schemes, includ-ing DFilter and PPM. These two schemes guaranteethat necessary credentials are the keys to access therequested operation. Service composition is a necessityfor most Web service systems because a single service

Q. Yu et al.

could hardly fulfill all requirements from a user. WebDGachieves its automatic service compositionresorting to the ontology notion. According to thesemantic features of the services, WebDG defines twoontologies for service operations, namely, the Categoryand Type. The semantic composability rule isderived based on these ontologies. It states that twooperations can be composed with each other seman-tically if their Categories and Types are compatible,respectively. WebDG also implements a compositiontemplate to evaluate the soundness of the service com-position.

8.1.5 AgFlow

AgFlow is a QoS-aware middleware for Web servicecomposition [121]. It uses ontologies to model the com-ponent services. The data types follow the XML specifi-cation and the message exchange relies on the data flowapproach. The orchestration model is specified usingstatecharts and generated by the programming-basedcomposition scheme. AgFlow defines a QoS model toevaluate Web services from five quality aspects: price,duration, reputation, success execution rate, and avail-ability. Users can specify their preferences by assigningweights to each of these quality parameters. AgFlowproposes two planning strategies, local and global, toselect the proper component services. The candidatecomposition plans are evaluated against an objectivefunction, whereby the optimal plan with the highestobjective value can be selected. Users’ constraints arealso considered during the planning. The global strat-egy can adapt to the dynamic changes in the serviceenvironment. When some component service becomesunavailable or significant changes occurs to its QoS, are-planning process will be triggered. The re-planningis to enable the composite service to remain optimal ina dynamic environment. The performance of AgFlowis efficient when there is a small number of tasks tobe accomplished by the composition. However, as thenumber of tasks increases, the response time of AgFlowexhibits an exponential growth. This situation becomeseven more severe when re-planning is required by thecomposition.

8.1.6 WSMX and IRS-III

Web Service Modeling eXecution environment (WSMX)[105] is the reference implementation of WSMO. It pro-vides an event-based service oriented framework fordynamic service discovery, selection, mediation, andinvocation. The core of WSMX architecture is theWSMX manager. It has several major components,

including resource manager, discovery, selector, andmediator. The resource manager is used to manage therepositories that store WSMO entities and other sys-tem-specific information. WSMO entities include Webservices, goals, ontologies, and mediators. WSMX dis-covery provides a three-step solution for service loca-tion. First, goal discovery is to map a user request to apredefined, formalized goal in the goal repository. Sec-ond, Web service discovery is to map the formalizedgoal to the formalized service description in the servicerepository. During this process, a Web service with thecapability that matches the goal would be returned. Fi-nally, service discovery is to map the formalized servicedescription to the concrete service. The WSMX selectorhelps choose the “best” Web service returned from aset of matching Web services. Various selection criteriaas well as users’ preference can be applied to select theoptimal Web service. The WSMX mediator is used tomediate heterogeneous entities. WSMX provides twokinds of mediators: data mediators and Process media-tor. Data mediators are used to address semantic dis-similarity between data from different sources. Processmediators provide a runtime analysis and adjustmentof mismatching between communication patterns fromservice requesters and providers. The WSMX managercontrols operational flow to react to incoming requests.WSMX provides an interface to accept user requests.Once a service request is submitted, the WSMX discov-ery and WSMX selector locate the services that matchthe request and return the optimal one on demand. In-ternet Reasoning Service (IRS-III) is another referenceimplementation of WSMO [32]. It is a framework fordescription, location, composition of Web services. IRS-III provides two methods for creating semantic Webservices, including browser-based and Java API. TheIRS-III ontology adopts and extends WSMO. The addi-tional attributes include a new type of mediator, gw-mediator. The gw-mediator is used for service discov-ery. An applicability function is used for selecting Webservices.

8.2 Discussion of Web service deployment platforms

In this section, we evaluate and compare different Webservice deployment systems using the proposed WSMS.We first conduct the evaluation by mapping these sys-tems onto the WS interoperation framework. This helpsreflect how each system achieves the WS interoperabil-ity. We examine the different layers in the interopera-tion framework, including communication, messaging,representation, discovery, and processes. We then eval-uate the deployment systems based on other key com-ponents in the WSMS: security/privacy, management,


and QoWS. This helps reflect the functionalities of eachsystem for dealing with other issues of WS deploymentin addition to WS interoperability.

Table 2 compares the representative Web servicedeployment systems using layers in the WS interopera-tion framework. For instance, WebDG uses HTTP at thecommunication layer. It depends on the three key Webservice standards – SOAP, WSDL, and UDDI – for mes-saging, representation, and discovery. In addition, theWebDG also uses ontologies to describe the semanticfeatures of Web services. At the WS processes layer, theWebDG provides a set of mechanisms to compose Webservices automatically. It uses the composition rules tocheck the semantic and syntactic composability of Webservices. The composition plan is optimized based onthe QoC (Quality of Composition) model. A composi-tion template is used to evaluate the soundness of thecomposition.

Table 3 compares the same set of systems using theother key components in the proposed WSMS. For in-stance, RosettaNet adopts digital certification and dig-ital signatures to ensure security to interact with Webservices. The PIP of RosettaNet contains a transactionlayer to provide transaction support for the businessprocesses. Privacy, change management, optimization,monitoring, and QoWS are not specified in RosettaNet.

9 Discussion and open issues

Current technologies help establish a solid foundationto enable the functionalities of Web services. Commu-nication protocols, XML-based standards, and manage-ment facilities provide a good support for interoperationamong Web services. The expected large number of Webservice to be deployed on the Web would trigger a sig-nificant paradigm shift from the data-centric Web tothe service-centric Web. We identify several researchtrends for the future evolution of Web service tech-nologies. These include efficient access of Web service,automatic service composition, ontology management forWeb services, failure recovery, Web service mining andM-services.Efficient access to Web services As the Web is movingfrom a data Web to a service Web, it is expected thattomorrow’s Web will be the repository of a large num-ber of Web services provided by third-party providers. Inthat context, the ability to efficiently access Web servicesis poised to become of prime importance [77]. In thesimplest scenarios, accessing Web services would con-sist of invoking their operations by sending and receiv-ing messages. However, for complex applications (e.g., atravel package), there would be a need for an integrated

and efficient approach to select and deliver several Webservices’ functionalities. As Web services with similarfunctionality are expected to be provided by compet-ing providers, a major challenge is devising optimizationstrategies for finding the “best” Web services or theircomposition with respect to the expected user-suppliedquality. A query infrastructure that offers complex queryoptimization facilities over Web services can addressthe above issues. Querying Web services could lever-age the research result from database queries. A firststep in enabling such a service query infrastructure isdefining the service scheme. The schema can be used toabstract the common features of all the Web servicesacross an application domain and will provide a fixedvocabulary for the service query languages. In addition,the schema should also depict the relationship betweendifferent service operations. This relationship will be re-ferred when a service query needs to retrieve multipleservice operations. For example, the output of some ser-vice operations might serve as the input of another ser-vice operation. Therefore, the latter service operationwould depend on the execution of the former serviceoperation. Thus, when the latter service operation is re-trieved by a service query, the first one should also beretrieved because of this dependency relationship. Ser-vice query languages (e.g., calculus and algebra) can befurther defined based on the service schema.Automatic service composition Web services aredynamic and autonomous, which pose great challengesto service composition technologies. Since Web servicesare unknown a priori, interactions between componentservices cannot be established at service definition time.Current composition technologies requires low-levelprogramming and domain knowledge of the requiredservices. Users needs to submit their requirements toservice composers. Service composers are in charge ofstatically defining the schemas for the composite ser-vices, which end users can use to invoke the compositeservices. This process hinders common users from com-posing Web services at large. Automatic service compo-sition blurs the distinction between composers and com-mon users. Users can submit a declarative query specify-ing the business goal together with some the constraintsand preferences. The composition process can automati-cally identify related services and derive a correspondingorchestration model with all constraints and preferencessatisfied. Seamless automatic composition is rather chal-lenging. It requires to clearly identify user’s require-ments (e.g., business goals, constraints, and preferences),unambiguously describe the services, precisely and for-mally specify the orchestration model, and adopt intel-ligent composition schemes. In addition, there are stillsome other important issues, such as security, privacy,

Q. Yu et al.

Table 2 WS deployment systems versus layers in the interoperation framework

Systems CommunicationMessaging Representation Discovery Processes

METEOR Java RMI Not specifiedDAML-S, QoS model registry service Workflow engineCMI HTTP, CORBANot specifiedService model, ontologiesService broker, advertisement State machine-based modelSELF-SERVHTTP SOAP WSDL UDDI State chartsWebDG HTTP SOAP WSDL, ontologies UDDI Composition rules, QoC

Model, and compositiontemplate

AgFlow HTTP SOAP WSDL, ontologies UDDI StatechartsWSMX Not specified SOAP WSMO, WSML Ontology repository, WSMX repositoryEvent managerIRS-III HTTP SOAP WSMO, IRS-III ontologyPSM Task specification

Table 3 Deployment systems versus key components in the WSMS

Systems Security/privacy Management QoWS

Security Privacy Transaction Change Optimization Monitoringmanagement

METEOR Not specified Not specified Not specified Not specified Mathematical Not specified Time, cost,model to compute reliability,the overall QoS and fidelityof workflow

CMI Role-based Not specified Coordination Scoped roles Resolution policy Awareness Services attachedaccess model for QoS based Model with a set ofcontrol service selection QoS attributes

SELF-SERV Not specified Not specified Not specified Service Not specified Service containers Weighted QoWScontainers for for notifying parametersmonitoring changes andchanges make reactions.

WebDG Not specified Three-layered Not specified Not specified Quality of Not specified Not specifiedprivacy model Composition

modelAgFlow Not specified Not specified Not specified Re-planning Integer Not specified Price, duration,

programming reputation, successexecution rate,and availability

WSMX Not specified Not specified Not specified Not specified WSMX selector Not specified Accuracy, cost,network-relatedtime, reliability,robustness, scalability,security, trust

IRS-III Not specified Not specified Not specified Not specified Applicability Not specified Accuracy, cost,function network-related

time, reliability,robustness, scalability,security, trust

and legal issues, to name a few. Efforts from the AI plan-ning community could help improve the automaticity ofservice composition. However, how to map Web servicesto the classical representation of AI planning involvinginitial states and goals remains to be a challenging issue.Explicit goals are usually not available from an industryperspective.Ontology management for Web services Ontologiesempower Web services with rich semantics. They helpenrich the service description and ease the service adver-

tisement and discovery process. Ontologies offer aneffective organization mechanism to deal with the largenumber, dynamics, and heterogeneity of Web services[66]. Service ontologies are organized in a distributedmanner to adapt to the large scale of the Web. Serviceontologies are formed based on Web services’ domainsof interest. Typically, a service ontology contains a set ofstandard terms to describe service classes. It also con-tains some inference rules to express complex relationsbetween service classes. One important challenge of


using distributed service ontologies is ontologymappings. Cross-ontology interactions between Webservices may bring terms and rules from one ontology toanother. Interpreting and reasoning information fromother ontologies precisely and efficiently is crucial forcross-ontology service integrations. Existing efforts indata integration mainly rely on a centralized mediationmechanism [41]. However, the centralized approach canhardly fit into the large scale of service ontologies on theWeb. Since ontologies have become a key component forWeb service description and organization, an effectivemechanism to realize mappings of different ontologieswould become increasingly important.Failure recovery A viable and robust Web service solu-tion needs to have the capacity to deal with failures. Fail-ure recovery is a crucial issue for proper and effectivedelivery of Web service functionalities. In traditionaldatabase and distributed computing systems, failuresare treated as exceptions. Since failures rarely happenin such fixed and well-controlled environment, someexpensive mechanisms are often adopted for recoveryfrom failures. For instance, transactions with ACIDproperties are the major tools to deal with failures in tra-ditional database systems. Mobile computing isanother major application area for failure recovery tech-niques [61,72,87]. In a mobile environment, failures aremore prone to happen due to multiple reasons, suchas physical damage, lost of mobile hosts, power limita-tion, and connectivity problems. The mobile computingcommunity would treat failures as rules rather thanexceptions due to their high occurrence probability.Checkpoint-based recovery is a representativetechnique used in mobile environment. Web services areautonomous and loosely coupled. They interactdynamically without a-priori knowledge of each other.Therefore, failures in Web service environment areexpected to happen frequently. Design of an effectivefailure recovery mechanism for Web services can bebased on the ideas from both database systems and mo-bile computing. A key step towards such a mechanismis to define what failures are in Web service interactionenvironment and provide a clear taxonomy for all thesefailures.Web service mining The envisioned service Webhosts a large population of Web services. Many of thesecoexisting Web services may be complimentary witheach other in terms of functionalities. Discovering thehidden complimentary relationships and combiningthese Web services may be an effective means to pro-vide value-added services for users. Web service min-ing aims to detect interesting and useful patterns fromWeb service compositions. It provides a more intelli-gent and transparent way to deliver high-quality Web

services. Web service mining offers two advantages overservice composition. First, since it is not restricted bycomposition conditions, service mining has more flex-ibility than service composition. Second, the discov-ery process is capable of finding unexpected servicecombinations. These combinations are not achievablethrough traditional composition techniques because thecombined Web services may not semantically compati-ble with each other in terms of functionalities. In addi-tion, the combinations would be very useful becausethey are summarized from various previous experiencesthrough a training process. Traditional data mining tech-nology is an automated process of extracting structuredknowledge from large volume of data [37]. It hasachieved great success in various application areas,including medical diagnosis, financial analysis, and stockprice prediction. However, extending data mining tech-niques towards Web service mining needs to deal withseveral important issues. Web services are more complexobjects than data. A service mining technology needs tobe equipped with an effective service processing mech-anism. In contrast to data, Web services are dynamicand may change over time. Therefore, adaptability todynamics would greatly affect the service mining per-formance.M-services The significant advances in wirelesstechnologies open a promising application area for Webservices. As a key extension of Web services, mobile ser-vices (m-services) cater for the increasing populationof mobile users. Specifically, m-services are a specialset of Web services that can be accessible by mobilehosts over wireless networks [86,120,119]. They worktogether with mobile devices to offer anytime/anywhereaccessible services. In contrast to Web services withwired infrastructures, m-services are more suitable fortime and location critical tasks [103]. For instance, astock quote service can help users make quick responseby providing timely quote prices. However, users mayprefer desktops to cell phones or personal digital assis-tants (PDAs) when carefully preparing a travel packagefor vacations. The mobile environment poses great chal-lenges for providing and consuming m-services. Mobiledevices have low CPU and memory capacities, limitedpower supply, small screen size, and restricted inputmechanisms. Wireless networks are limited by theirsmall bandwidth. They also suffer from link outages,which result in temporary unavailability. These limi-tations hinder existing Web service technologies fromdirectly working with m-services. For instance, the lim-ited bandwidth may not be enough to convey SOAPmessages [86]. In addition, SOAP is expensive formobile hosts in terms of both power consumption andwaiting time. In mobile environment, users’ context,

Q. Yu et al.

such as location and activity, may change rapidly.M-services need to track these changes and provide con-text-aware functionalities. However, service descriptiontechniques, such as WSDL, have not provided support tomodel context. UDDI enables service discovery in theWeb service framework. However, the multiple costlyround trips required by UDDI lookup are troublesomefor m-service discovery [86]. The frequent unavailabilityof wireless network may cause failures in service discov-ery processes.

Acknowledgements The authors would like to thank the anon-ymous reviewers for their valuable comments on earlier drafts ofthis paper.

References

1. American National Standards Institute: Study Group onData Base Management Systems. Interim report, FDT, 7:2,ACM (1975)

2. Report of the CODASYL Data Base Task Group: ACM(1971)

3. RosettaNet. http://www.rosettanet.org (2003)4. Web Services Metadata Exchange (WS-MetadataEx-

change): http://xml.coverpages.org/WS-MetadataExchange200409.pdf (2004)

5. Ackerman, M.S.: Privacy in E-commerce: examining userscenarios and privacy preferences. In: Proceedings of theACM Conference on Electronic Commerce (1999)

6. Akram, M.S.: Managing changes to service oriented enter-prises. Master’s Thesis, Virginia Tech (2005)

7. Akram, M.S., Bouguettaya, A.: Managing changes to vir-tual enterprises on the semantic Web. In: 5th InternationalConference on Web Information Systems Engineering,pp. 472–478. Brisbane, Australia (2004)

8. Akram, M.S., Medjahed, B., Bouguettaya, A.: Supportingdynamic changes in Web service environments. In: FirstInternational Conference on Service Oriented Computing,pp. 319–334. Trento, Italy (2003)

9. Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web Services:Concepts, Architecture, and Applications. Springer, BerlinHeidelberg New York (ISBN: 3540440089) (2003)

10. Astrahan, M., Blasgen, M., Chamberlin, D., Eswaran, K.,J. Gray, Griffiths, P., King, W., Lorie, R., McJones, P., Mehl,J., Putzolu, G., Traiger, I., Wade, B., Watson, V.: System R:relational approach to database management. ACM Trans.Database Syst. 1(2), 97–137 (1976)

11. Aurrecoechea, C., Campbell, A., Hauw, L.: A Survey ofQoS Architectures. ACM/Springer Verlag Multimedia Syst.J. 6(3), 138–151 (1998)

12. Baker, D., Georgakopoulos, D., Schuster, H., Cassandra,A.R., Cichocki, A.: Providing customized process andsituation awareness in the collaboration management infra-structure. In: Proceedings of the 4th IFCIS InternationalConference on Cooperative Information Systems, Edin-burgh, Scotland, 2-4, September 1999, pp. 79–91. IEEE Com-puter Society (1999)

13. Benatallah, B., Casati, F., Grigori, D., Nezhad, H.R.M.,Toumani, F.: Developing adapters for Web services integra-tion. In: CAiSE Conference, pp. 415–429. Porto, Portugal(2005)

14. Benatallah, B., Sheng, Q.Z., Dumas, M.: The self-serv envi-ronment for Web services composition. IEEE Internet Com-put. 7(1), 40–48 (2003)

15. Bertino, E., Sandhu, R.: Database security-concepts, ap-proaches, and challenges. IEEE Trans. Depend. Secure Com-put. 2(1), 2–9 (2005)

16. BPMI: Business Process Modeling Language (BPML):http://www.bpmi.org/bpml.esp (2003)

17. Bultan, T., Su, J., Fu, X.: Analyzing conversations of Webservices. IEEE Internet Comput. 10(1), 18–25 (2006)

18. Burstein, M., Bussler, C., Finin, T., Huhns, M., Paolucci, M.,Sheth, A., Williams, S.: A semantic Web services architec-ture. IEEE Internet Comput. 9, 52–61 (2005)

19. Bussler, C.: B2B Protocal Standards and their Role inSemantic B2B Integration Engines. IEEE Data Eng. Bull.24(1), 3–11 (2001)

20. Bussler, C.: B2B Integration: Concepts and Architecture.Sringer, Berlin Heidelberg New York (2003)

21. Bussler, C.: The role of semantic web technology in enter-prise applicatin integration. Data Eng. Bull. 26(4), 62–68(2003)

22. Bussler, C., Fensel, D., Maedche, A.: A conceptual architec-ture for semantic Web enabled Web services. SIGMOD Rec.31(4), 24–29 (2002)

23. Cardoso, J.: Quality of service and semantic composition ofworkflows. Ph.D. Thesis, University of Georgia (2002)

24. Casati, F., Ilnicki, S., Jin, L., Krishnamoorthy, V., Shan., M.C.:Adaptive and dynamic service composition in eFlow. Tech-nical report HPL-2000-39, Hewlett Packard, HP LaboratorisPalo Alto (2000)

25. Codd, E.: A relational model for large shared data banks.Commun. ACM 13(6), 377–387 (1970)

26. Conti, M., Kumar, M., Das, S.K., Shirazi, B.A.: Quality ofService Issues in Internet Web Services. IEEE Trans. Com-put. 51(6), 593–594 (2002)

27. DAML: DAML-S (and OWL-S) 0.9 Draft Release.http://www.daml.org/services/daml-s/0.9/ (2004)

28. Ding, Y., Fensel, D., M. Klein, a.B.O.: The semanticWeb: yet another hip? Data Knowl. Eng. 41(3), 205–227(2002)

29. Dogac, A., Kabak, Y., Laleci, G.: Enriching ebXML Regis-tries with OWL ontologies for efficient service discovery. In:RIDE. Boston, USA (2004)

30. Dogac, A., Kabak, Y., Laleci, G.B., Mattocks, C.,Najmi, F., Pollock, J.: Enhancing ebxml registries to makethem owl aware. Distrib. and Parallel Databases J. 18(1),(2005)

31. Dogac, A., Laleci, G.B., Kabak, Y., Cingil, I.: Exploiting webservice semantics: Taxonomies vs. ontologies. IEEE DataEng. Bull. 25(4), 10–16 (2002)

32. Domingue, J., Galizia, S., Cabral, L.: Choreography in IRS-III - Coping with Heterogeneous Interaction Patterns in WebServices. In: ISWC, pp. 415–429. Galway, Ireland (2005)

33. Dustdar, S., Treiber, M.: A View Based Analysis on WebService Registries. Distributed and Parallel Databases, pp.147–171 (2005)

34. ebXML: http://www.ebxml.org (2003)35. van Eck, P., Engelfriet, J., Fensel, D., van Harmelen, F.,

Venema, Y., Willems, M.: A survey of languages for speci-fying dynamics: a knowledge engineering perspective. IEEETrans. Knowl. Data Eng. 13(3), 462–496 (2001)

36. Edmond, D., Bouguettaya, A., Benatallah, B.: Formal cor-rectness procedures for object-oriented databases. In: Pro-ceedings of the 9th Australasian Database Conference.Perth, Australia (1998)


37. Fayyad, U.: Data mining and knowledge discovery indatabases: implications for scientific databases. In: Pro-ceedings of the Ninth International Conference on Sci-entific and Statistical Database Management, pp. 2–11(1997)

38. Fensel, D.: Ontologies: Silver Bullet for KnowledgeManagement and Electronic Commerce. Springer, BerlinHeidelberg New York (2001)

39. Fensel, D., Bussler, C.: The Web Service Modeling Frame-work WSMF. Electron Commerce Res Appl pp. 113–137(2002)

40. Fensel, D., Harmelen, F., Horrocks, I., McGuinness, D.L.,Patel-Schneider, P.F.: OIL: An ontology infrastructure forthe semantic Web. IEEE Intell. Syst. 16(2), 38–45 (2001)

41. Garcia-Molina, H.: The TSIMMIS Project: Integration ofHeterogeneous Information Sources. J. Intell. Inf. Syst. 8(2),117–132 (1997)

42. Geer, D.: Taking steps to secure web services. IEEE Comput.36(10), 14–16 (2003)

43. Georgakopoulos, D., Schuster, H., Chichocki, A., Baker, D.:Managing process and service fusion in virtual enterprises.Inf. Syst. 24(6), 429–456 (1999). http://dx.doi.org/10.1016/S0306-4379(99)00026-5

44. (GGF), G.G.F.: Web Services Agreement Specification:http://www.omg.org/mda/ (2005)

45. Gou, H., Huang, B., Liu, W., Ren, S., Li, Y.: Petri net basedbusiness process modeling for virtual enterprises. In: IEEEInternational Conference on Systems, Man, and Cybernetics,pp. 3183–3188. Nashville, United States (2000)

46. Gravano, L., Papakonstantinou, Y.: Mediating and meta-searching on the Internet. IEEE Data Eng. Bull. 21(2), 28–36(1998)

47. Group, W.W.: Web Service Modeling Language (WSML).http://www.wsmo.org/wsml (2004)

48. Group, W.W.: Web Service Modeling Ontology (WSMO).http://www.wsmo.org/ (2004)

49. Hamadi, R., Benatallah, B.: A petri net-based model for webservice composition. In: Proceedings of the 14th Australasiandatabase conference on Database technologies, pp. 191–200.Australian Computer Society, Inc. (2003)

50. Heflin, J.: Towards the semantic Web: knowledge represen-tation in a dynamic distributed environment. Ph.D. Thesis,University of Maryland (2001)

51. Hull, R., Su, J.: Tools for composite Web services: a shortoverview. SIGMOD Rec. 34, 86–95 (2005)

52. IBM: Web Services Conceptual Architecture: http://www-306.ibm.com/software/solutions/webservices/pdf/WSCA.pdf

53. IBM: Web Services Flow Language (WSFL): http://xml.coverpages.org/ws.html (2003)

54. Kagal, L., Finin, T., Joshi, A.: A policy based approach tosecurity on the semantic Web. In: International SemanticWeb Conference. Florida, USA (2003)

55. Kagal, L., Paolucci, M., Srinivasan, N., Denker, G., Finin,T.W., Sycara, K.P.: Authorization and privacy for semanticWeb services. IEEE Intell. Syst. 19(4), 50–56 (2004)

56. Langdon, C.S.: The state of Web services. IEEE Comput.36(7), 93–94 (2003)

57. Laymann, F.: Jump onto the bus: a guided tour to the WS-*landscape. In: ICSOC (2003)

58. Maedche, A., Staab, S.: Ontology learning for the semanticWeb. IEEE Intell. Syst. 16(2), 72–79 (2001)

59. Malik, Z., Bouguettaya, A.: Preserving trade secrets betweencompetitors in b2b interactions. Int. J. Cooperative Inf. Syst.14(2-3), 265–297 (2005)

60. Marchetti, C., Pernici, B., Plebani, P.: A quality model formultichannel adaptive information. In: WWW04. New York,USA (2004)

61. Martin, C.P., Ramamritham, K.: Recovery guarantees inmobile systems. In: Proceedings of the 1st ACM inter-national Workshop on Data Engineering for Wirelessand Mobile Access, pp. 22–28. ACM Press (1999). DOIhttp://doi.acm.org/10.1145/313300.313325

62. Maximilien, E.M., Singh, M.P.: A framework and ontologyfor dynamic web services selection. IEEE Internet Comput.8(5), 84–93 (2004)

63. Mcllraith, S.A., Martin, D.L.: Bringing semantics to Web ser-vices. IEEE Intell. Syst. 18(1), 90–93 (2003)

64. Mcllraith, S.A., Son, T., Zeng, H.: Semantic Web services.IEEE Intell. Syst. 16(2), 46–53 (2001)

65. Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, A.H.H.,Elmagarmid, A.K.: Business-to-business interactions: issuesand enabling technologies. VLDB J. 12(1), 59–85 (2003).DOI http://dx.doi.org/10.1007/s00778-003-0087-z

66. Medjahed, B., Bouguettaya, A.: A multilevel composabilitymodel for semantic Web services. IEEE Trans. Knowl. DataEng. (TKDE) 17(7), 954–968 (2005)

67. Medjahed, B., Bouguettaya, A., Elmagarmid, A.K.: Com-posing Web services on the semantic Web. VLDB J. 12(4),333–351 (2003)

68. Medjahed, B., Rezgui, A., Bouguettaya, A., Ouzzani, M.:Infrastructure for E-government Web services. IEEE Inter-net Comput. 7(1), 58–65 (2003)

69. Microsoft: Web Services Routing (WS-Routing): http://msdn.microsoft.com/

70. Microsoft: Web Services for Business Process Design(XLANG). http://xml.coverpages.org/xlang.html (2003)

71. Netscape: Secure Socket Layer (SSL) 3.0 Specification:http://wp.netscape.com/eng/ssl3/

72. Neves, N., Fuchs, W.K.: Adaptive recovery for mobileenvironments. Commun. ACM 40(1), 68–74 (1997). DOIhttp://doi.acm.org/10.1145/242857.242878

73. OASIS: Universal Business Language (UBL): http://www.oasis-open.org/committees/ubl

74. OASIS: SAML: http://www.oasis-open.org/ (2004)75. OASIS: WSS: http://www.oasis-open.org/ (2004)76. O’Sullivan, J., Edmond, D., ter Hofstede, A.H.M.: For-

mal description of non-functional service properties.Technical report, Queensland University of Technology.http://www.servicedescription.com/ (2005)

77. Ouzzani, M., Bouguettaya, A.: Efficient access to web ser-vices. IEEE Internet Comput. 8(2), 34–44 (2004)

78. Paolucci, M., Sycara, K.: Autonomous Semantic Web ser-vices. IEEE Internet Comput. 7(5), 34–41 (2003)

79. Papazoglou, M.: Extending the service oriented architecture.Bus. Integr. J. 65, 18–21 (2005)

80. Papazoglou, M., van den Heuvel, W.J.: Web services manage-ment: a survey. IEEE Internet Comput. 9(6), 58–64 (2005)

81. Papazoglou, M.P.: Web services and business transactions.World Wide Web 6(1), 49–91 (2003)

82. Papazoglou, M.P., Dubray, J.: A Survey of Web service tech-nologies. Technical report DIT-04-058, University of Trento(2004)

83. Patel-Schneider, P.F., Siméon, J.: The Yin/Yang Web: A uni-fied model for XML syntax and RDF semantics. IEEE Trans.Knowl. Data Eng. 15(4), 797–812 (2003)

84. Peltz, C.: Web services orchestration and choreography.IEEE Comput. 36(10), 46–52 (2003)

85. Petrie, C., Bussler, C.: Service agents and virtual enterprises:a survey. IEEE Internet Comput. 7(4), 68–78 (2003)

Q. Yu et al.

86. Pilioura, T., Tsalgatidou, A., Hadjiefthymiades,S.: Scenarios of using web services in m-com-merce. SIGecom Exch. 3(4), 28–36 (2003). DOIhttp://doi.acm.org/10.1145/844351.844356

87. Prakash, R., Singhal, M.: Low-cost checkpointing andfailure recovery in mobile computing systems. IEEETrans. Parallel Distrib. Syst. 7(10), 1035–1048 (1996). DOIhttp://dx.doi.org/10.1109/71.539735

88. Ran, S.: A model for Web services discovery with QoS. ACMSIGecom Exchanges 4(1), 1–10 (2003)

89. Rezgui, A., Bouguettaya, A., Eltoweissy, M.Y.: Privacy onthe Web: facts, challenges, and solutions. IEEE Sec. Privacy1(6), 40–49 (2003)

90. Rezgui, A., Bouguettaya, A., Malik, Z.: A Reputation-basedapproach to preserving privacy in Web services. In: VLDBWorkshop on Technologies for E-Services (TES). Berlin,Germany (2003)

91. Rezgui, A., Ouzzani, M., Bouguettaya, A., Medjahed, B.:Preserving privacy in Web services. In: Proceedings of the4th ACM Workshop on Information and Data Management(WIDM’02). McLean, VA (2003)

92. Singh, M.P.: Physics of service composition. IEEE InternetComput. 5(3), 6 (2001)

93. Singh, M.P., Huhns, M.N.: Service-Oriented ComputingSemantics, Processes, Agents. Wiley, New York (2005)

94. Sirin, E., Hendler, J., Parsia, B.: Semi-automatic composi-tion of web services using semantic descriptions. In: WebServices: Modeling, Architecture and Infrastructure Work-shop in Conjunction with ICEIS2003 (2003)

95. Sirin, E., Parsia, B., Hendler, J.: Filtering and select-ing semantic web services with interactive compositiontechniques. IEEE Intell. Syst. 19(4), 42–49 (2004). URLhttp://www.mindswap.org/papers/IEEE-IS-04.html

96. Skonnard, A.: Understanding WS-Policy. Technical report,Skonnard Consulting: http://www.microsoft.com/webservic-es/ (2003)

97. Stonebraker, M., Wong, E., Kreps, P., Held, G.: The designand implementation of ingres. TODS 1(3), 189–222 (1976)

98. SUN: Web Services Reliability (WS-Reliability). http://developers.sun.com/sw/platform/technologies/ws-reliability.html

99. Tagg, R.: Workflow in different styles of virtual enterprise.In: Workshop on Information technology for Virtual Enter-prises, pp. 21–28. Queensland, Australia (2001)

100. Tsalgatidou, A., Pilioura, T.: An overview of standards andrelated technology in Web services. Distrib. Parallel Data-bases 12(2), 135–162 (2002)

101. Tumer, A., Dosac, A., Toroslu, H.: A semantic based pri-vacy framework for web services. In: WWW’03 Workshopon E-Services and the Semantic Web (ESSW ’03). Budapest,Hungary (2003)

102. Vaughan-Nichols, S.J.: Web services: beyond the hype. IEEEComput. 35(2), 18–21 (2002)

103. Venkatesh, V., Ramesh, V., Massey, A.P.: Understandingusability in mobile commerce. Commun. ACM 46(12), 53–56(2003). DOI http://doi.acm.org/10.1145/953460.953488

104. Vinoski, S.: Web services interaction models, part 1: currentpractice. IEEE Internet Comput. 6(3), 89–91 (2002)

105. W3C: Web Service Execution Environment (WSMX):http://www.w3.org/Submission/WSMX/

106. W3C: Web Services Addressing (WS-Addressing):http://www.w3.org/Submission/ws-addressing/

107. W3C: XML Encryption. http://www.w3.org/Encryption/(2001)

108. W3C: XML Signature. http://www.w3.org/Signature/ (2001)109. W3C: Simple Object Access Protocol (SOAP).

http://www.w3.org/TR/SOAP/ (2003)110. W3C: Universal Description, Discovery, and Integration

(UDDI). http://www.uddi.org (2003)111. W3C: Web Service Choreography Interface (WSCI).

http://www.w3.org/TR/wsci/ (2003)112. W3C: Web Services Architecture. http://www.w3.org/TR/ws-

arch/ (2003)113. W3C: Web Services Description Language (WSDL).

http://www.w3.org/TR/wsdl (2003)114. W3C: The Platform for Privacy Preference Specification

(P3P). http://www.w3.org/TR/P3P11/ (2004)115. W3C: Web Services Choreography Description Language

(WS-CDL). http://www.w3.org/TR/ws-cdl-10/ (2004)116. Westin, F.D.: Philosophical Dimensions of Privacy: An

Anthology. Cambridge University Press, Cambridge (1984)117. Workflow Management Coalition: workflow management

application programming interface (interface 2&3) specifi-cation. Document number WFMC-TC-1009 (1998), Version2.0

118. WS-I: Web Services Interoperability Organization. http://www.ws-i.org/

119. Yang, X., Bouguettaya, A.: Adaptive data access in broad-cast-based wireless environments. IEEE Trans. Knowl. DataEng. 17(3), 326–338 (2005)

120. Yang, X., Bouguettaya, A., Medjahed, B., Long, H., He., W.:Organizing and accessing web services on air. IEEE Trans.Syst. Man Cybern. Part A Syst. Hum. 33(6), 742–757 (2003)

121. Zeng, L., Benatallah, B., Ngu, A., Dumas, M.,Kalagnanam, J., Chang, H.: Qos-aware middleware forweb services composition. IEEE Trans. Softw. Eng. 30(5),311–327 (2004)

Deploying and managing Web services: issues, solutions, and

Documents

Transcript of Deploying and managing Web services: issues, solutions, and