ARTICLE IN PRESS

0306-4379/$ - se

doi:10.1016/j.is.

�Correspondifax: +1613 520

E-mail addre

bernie@sce.carl

(K. Patel), baba

weima@sce.car

URL: http:/

tions.htm.

Information Systems 30 (2005) 564–586

www.elsevier.com/locate/infosys

Management applications of the Web ServiceOfferings Language (WSOL)

Vladimir Tosic�, Bernard Pagurek, Kruti Patel, Babak Esfandiari, Wei Ma

Department of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa, Ont., Canada K1S 5B6

Abstract

We discuss Web Service Management (WSM) and Web Service Composition Management (WSCM) applications of

the Web Service Offerings Language (WSOL) and how the language supports these applications. WSOL is a language

for the formal specification of classes of service, various constraints (functional constraints, Quality of Service—QoS,

and access rights), and management statements (prices, monetary penalties, and management responsibilities) for Web

Services. Describing a Web Service in WSOL, in addition to the Web Services Description Language, enables

monitoring, metering, accounting, and management of Web Services. Metering of QoS metrics and evaluation of

constraints can be the responsibility of the provider Web Service, the consumer, and/or one or more mutually trusted

third parties (SOAP intermediaries or probes). Further, manipulation (switching, deactivation, reactivation, deletion, or

creation) of classes of service can be used for dynamic (run-time) adaptation and management of Web Service

compositions. To demonstrate the usefulness of WSOL for WSM and WSCM, we have developed a corresponding

management infrastructure, the Web Service Offerings Infrastructure (WSOI). WSOI enables monitoring of WSOL-

enabled Web Services and dynamic manipulation of their classes of service.

r 2004 Elsevier B.V. All rights reserved.

Keywords: Web Service; Description language; Class of service; Web Service Management; Web Service Composition Management

e front matter r 2004 Elsevier B.V. All rights reserve

2004.11.005

ng author. Tel.: +1519 858 1828;

5727.

sses: vladat@computer.org (V. Tosic),

eton.ca (B. Pagurek), kruts.patel@lycos.com

k@sce.carleton.ca (B. Esfandiari),

leton.ca (W. Ma).

/www.sce.carleton.ca/�vladimir/WSOLpublica-

1. Introduction and motivation

The World Wide Web Consortium defines aWeb Service as ‘a software application identifiedby a Uniform Resource Identifier (URI), whoseinterfaces and bindings are capable of beingdefined, described and discovered by ExtensibleMarkup Language (XML) artifacts and [which]supports direct interactions with other softwareapplications using XML-based messages via

d.

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 565

Internet-based protocols’ [1]. The term ‘XMLWebService’ is sometimes used instead of the term‘Web Service’. A Web Service can provide severalports (URI endpoints). Each port implements aparticular port type (interface), which is a collec-tion of one or more operations. The main WebService technologies are XML, the SOAP protocolfor XML messaging, the Web Services DescriptionLanguage (WSDL) language, and the UniversalDescription, Discovery, and Integration (UDDI)directory.

Web Service technologies are intended forapplication-to-application integration. They canbe used for business-to-business (B2B) integrationand/or for Enterprise Application Integrationwithin companies. Consequently, their true poweris leveraged through compositions (choreographiesand orchestrations [2]) of Web Services. In a WebService composition, a Web Service can play theroles of a consumer (client, requester) and aprovider (supplier). For example, when a financialanalysis Web Service FA1 uses operations of astock notification Web Service SN1, then FA1 isthe consumer and SN1 is the provider. A WebService can at the same time be a consumer ofmany Web Services and a provider of many otherWeb Services. Hereafter, we assume that aconsumer is a Web Service, not a human enduser. The composed Web Services can be dis-tributed over the Internet, run on different plat-forms, implemented in different programminglanguages, and provided by different businesses.Communication between Web Services can besynchronous or asynchronous; based on RemoteProcedure Calls XML or on the exchange of XMLdocuments.

Management of Web Services and their compo-sitions is needed to ensure regular operation, toattain or surpass the guaranteed service andquality of service (QoS), to accommodate change,and to keep track of the consumed resources. Forexample, management has to be performed if aused Web Service becomes unavailable.

Web Service Management (WSM) is the man-agement of a particular Web Service or a group ofWeb Services within the same domain of respon-sibility, such as the same business. It consists of themonitoring of the operation of the Web Service

and the control of the Web Service to meet theguaranteed service and QoS. Monitoring of a WebService includes measurement and calculation ofrelevant QoS metrics, evaluation of various con-ditions (requirements and guarantees), calculationof prices and monetary penalties, and accountingof executed operations, measured/calculated QoSmetrics, evaluated constraints, and monetaryamounts to be paid. The monitoring of a WebService can be performed by the provider, theconsumer, and/or one or more management third

parties [3]—entities (e.g., Web Services) indepen-dent from the provider and the consumer.Management third parties can be used to performmonitoring and management actions that theprovider and the consumer cannot execute. Theycan also be used when the consumer and theprovider do not trust each other. For example,when a consumer does not trust that its providerwould accurately measure achieved QoS, thesemeasurements can be outsourced to one or severalmanagement third parties trusted by both theprovider and the consumer. While the use ofmanagement third parties reduces processing over-head placed on the provider and the consumer,their number should not be high because theyintroduce additional compositional complexityand communication overhead.On the other hand, we define the Web Service

Composition Management (WSCM) as the man-agement of which Web Services are composed andhow they interact. Interaction between the com-posed Web Services can be explicitly and formallydescribed in various contracts. A contract is anyformal agreement between the provider, theconsumer, and, potentially, management thirdparties. For example, a contract can containdescriptions of provided operations, guaranteesof maximum response time, prices, and/or legalresponsibilities. Consequently, WSCM consists ofthe selection of Web Services to be composed, theselection and possibly negotiation of contractsbetween these Web Services, the monitoring ofcontract fulfillment, the modification of contractsthat are no longer appropriate, and possibly the re-selection of Web Services to adapt to changes. Themonitoring of contract fulfillment combines themonitoring of the composed Web Services.

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586566

To completely describe interactions betweenWeb Services for WSM and WSCM, differentinformation about service and QoS has to bespecified. WSDL version 1.1 [4] is used forspecification of port types, operations, messages,access methods (messaging protocols used), andlocation of ports of the Web Service. The newWSDL version 2.0 [5] brings several improve-ments, but not pertinent to contributions of thispaper. While this WSDL information is manda-tory for using Web Services, it is not enough formanagement applications. For example, it is alsoimportant to prescribe the flow of information andcontrol between the composed Web Services.Several languages for such description of WebService compositions were developed, the mostpopular of which is the Business Process ExecutionLanguage for Web Services (BPEL4WS). How-ever, neither WSDL nor Web Service compositionlanguages provide specification of what QoSmetrics to measure or calculate, which require-ments and guarantees to evaluate, when toperform measurement of QoS metrics and evalua-tion of conditions, what are the prices andpotential monetary penalties to be paid, and whatparties perform particular management activities.Explicit, precise, and unambiguous specification ofsuch management information is essential formonitoring and management activities [3,6]. Forexample, QoS metrics and QoS guarantees arevaluable for performance management, whileprices and penalties are important for accountingmanagement. In addition to the management ofWeb Services and their compositions, the formalspecification of such information is beneficial forselection of most appropriate Web Services be-cause QoS, price, and manageability can beimportant competitive advantages on a globalmarket of Web Services implementing the sameWSDL port types.

When a provider Web Service collaborates witha large number of different consumers in parallel,it often has to provide different levels of QoS toaccommodate different characteristics and needsof the consumers. Measured QoS metrics, prices,and management parties and the other manage-ment information can also differ between theconsumers.

A considerable body of work on formalspecification of technical contracts and variousmanagement information, as well as customizationof service and QoS exists in telecommunicationsand software engineering. Service-level agreements(SLAs), classes of service, profiles, and policies areoften used in telecommunications and distributedsystems for this purpose. In addition, severaltelecommunication architectures, including Diff-Serv (Differentiated Services), also provide custo-mization of service and QoS. In softwareengineering, particular conditions (requirementsand guarantees) that have to be evaluated arespecified in the form of constraints. For example,several languages for the formal specification ofQoS metrics and constraints for CORBA (Com-mon Object Request Broker Architecture), such asQML (Quality Modeling Language) [7], weredeveloped. Often, a distinction is made betweenfunctional (behavioral) constraints and QoS (ex-tra-functional, non-functional) constraints. Func-tional constraints define conditions that afunctionally correct operation invocation mustsatisfy, while QoS constraints describe propertiessuch as performance, reliability, and availability.The need for the unified formal specification ofvarious constraints and comprehensive technicalcontracts for software components was elaboratedin [8]. As discussed in [9], the results of these priorworks could not have been applied to WebServices directly. Some of the characteristics ofWeb Services are Internet-wide and B2B dynamiccomposition, heterogeneity of implementationsand execution platforms, and the use of XMLand WSDL.To enable explicit and formal specification of

classes of service, various categories of constraints,and management statements for Web Services, wehave developed the Web Service Offerings Lan-

guage (WSOL) [9–12]. Our goal for WSOL was tosupport both WSM and WSCM activities. Whilemanagement is a critical business activity, it canincur significant overhead. Since we wanted toprovide management even for simple Web Ser-vices, we have studied management solutions withrelatively low run-time overhead. The mostimportant of them is the concept of a class of

service, which is a discrete variation of the

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 567

complete functionality and QoS provided by oneWeb Service. Since we wanted to extend existingWeb Service technologies, WSOL is an XML-based language compatible with and complemen-tary to WSDL version 1.1, but separate from it. AWSOL file references one or more WSDL files anddescribes additional management information thatis not present in WSDL files. Consequently,dynamic (run-time) creation, deletion, deactiva-tion, and reactivation of WSOL specifications canbe performed without any modification of thereferenced WSDL files. Such updates are neededrelatively frequently during the management ofWeb Services and their compositions. As we willexplain, none of the recent related works on thespecification of custom-made SLAs, policies, QoS,semantic descriptions, and agreements for WebServices addresses the same WSM and WSCMissues as WSOL. The main examples of suchworks, developed in parallel with WSOL, are WebService Level Agreement (WSLA) [3,13], WebService Management Language (WSML) [6,14],SLAng [15], WS-Policy [16], UX [17], DAML-Services (DAML-S) [18], and WS-Agreement [19].While WSOL has limitations, it also has a set ofimportant unique characteristics and advantages.

To demonstrate and further explore the use ofWSOL for the management of Web Services andtheir compositions, we have developed the corre-sponding management infrastructure—the Web

Service Offerings Infrastructure (WSOI) [20,21].WSOI enables monitoring of Web Services anddynamic manipulation of classes of service de-scribed in WSOL.

In this paper, we discuss and illustrate WSMand WSCM applications of WSOL and how thelanguage supports these applications. In thissection, we introduced the general area of ourresearch and motivated our work. In the nextsection, we describe the main concepts andconstructs in WSOL. In Section 3, we discussapplications of WSOL for WSM. In Section 4, weexamine how manipulation of classes of servicedescribed in WSOL can be used for WSCM. Abrief overview of the most important recent relatedworks is presented in Section 5. In Section 6, wesummarize how WSOL supports managementapplications, recap other conclusions, and outline

directions for future work. Throughout the paper,we use bolded text to emphasize definitions ofimportant concepts and summaries of maincharacteristics of our work. Names of XMLelements in the WSOL grammar and values ofdata tuples are written between / and S char-acters, while names of attributes in the WSOLgrammar, values of constants, and terminologicalphrases are written between ‘ and ’ characters.

2. The Web Service Offerings Language (WSOL)

The main categories of constructs in WSOL are:

1.

service offering (SO), 2. constraint, 3. management statement, 4. reusability element, and 5. service offerings dynamic relationship (SODR).

We summarize the main characteristics of thesecategories of constructs in the following fivesubsections. Further information can be found inour other publications about WSOL. In particular,precise syntax defined using XML Schema, illus-trative examples, and discussion of the WSOLlanguage constructs for an older version of WSOLare given in [10], while some recent improvementsand additions in the new WSOL version 1.1 arepresented in [12]. Other WSOL and WSOIpublications [9,11,20–22] elaborate several addi-tional aspects of our work.Fig. 1 is a Unified Modeling Language (UML)

class diagram illustrating the main WSOL con-structs and their relationships. To avoid over-crowding, we have not depicted that constraints,statements, and reusability elements can also bespecified inside WSOL files, but outside particularSOs. In addition, we have not listed all supportedtypes of constraint, statement, reusability element,and expression.To verify the WSOL syntax, we have developed

a WSOL parser called Premier [10]. Its implemen-tation is based on the Apache Xerces XML Javaparser. This parser produces a Document ObjectModel (DOM) tree representation of WSOL filesand reports syntax errors and some semantic

ARTICLE IN PRESS

WSOL File

SO SODR

11.. *

0.. * 0.. *2 0.. *

ConstraintManagement

StatementReusability

Element

11 1

0.. * 0.. *0.. *

1.. *

1.. *

Boolean

Expression

0.. * 1

Expression

0.. *

1

0.. *

0.. 1Extends ^

…

… … …

Fig. 1. Partial UML class diagram for WSOL concepts.

V. Tosic et al. / Information Systems 30 (2005) 564–586568

errors, if any. We have also designed Java classesthat will be the results of the compilation ofWSOL files. As will be explained in Section 3.2,the majority of these classes are WSOI-specifichandlers—WSOI modules that perform WSOL-related measurement and/or calculation of QoSmetrics, evaluation of constraints, and accountingactivities. We have not yet finished a codegenerator that creates the designed Java classesfrom DOM trees produced by our WSOL parser.A prototype WSOL compiler would then be acombination of the Premier WSOL parser and thiscode generator.

2.1. Service offerings

The central concept in WSOL is a class ofservice. Classes of service of one Web Service referto the same WSDL description, but differ inconstraints and management statements. Thepractice of telecommunication service provisioningshowed that classes of service have relatively lowoverhead and complexity of management com-pared to the more powerful alternatives, such ascustom-made SLAs and profiles. Even in situa-tions when classes of service are not the best choicefor customization of service and QoS, they can bea useful addition and complement.

In WSOL, we use the term ‘service offering’(SO) to refer to the formal representation of a

single class of service of one Web Service.Consequently, a WSOL SO contains formalrepresentations of various constraints and man-agement statements that determine the corre-sponding class of service. It can also containappropriate reusability elements. The specificationof contractual legal aspects is currently notaddressed by WSOL. Hereafter, we will almostexclusively use the term ‘service offering’, althoughin some cases we could have also used the term‘class of service of a Web Service’.When a consumer invokes a provider’s opera-

tion, it is necessary to determine which SO is usedfor this invocation. Further, for the measurementor calculation of periodic QoS metrics, theevaluation of QoS constraints, the accounting ofsubscription periods, and some other monitoringactivities, it is necessary to perform grouping ofmanagement information from several consumer’sinvocations of the provider. Several mechanismscan be used for association between operationinvocations and SOs and/or for grouping ofmanagement information. For simplicity, we havechosen that in our work consumers open sessionswith providers. A provider can suggest multipleSOs to its consumer, but the consumer can useonly one of them at a time in one session. On theother hand, a provider Web Service can have inparallel many open sessions, in some cases evenseveral sessions with the same consumer. Inside a

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 569

session, the consumer can choose a SO to be used,as will be discussed in Section 4.1. Further, theconsumer or the provider can initiate a change ofSOs, called switching, and other dynamic adapta-tion mechanisms discussed in Section 4.2.

Let us now illustrate the benefits of SOs with ane-business example. A financial analysis WebService consumes one or several stock notificationWeb Services and supplies results of its analyses,such as recommendations, to different consumers.It can provide its results on request from aconsumer, but a consumer can also subscribe forperiodic reports from the financial analysis WebService. The former is an example of the pay-per-use business model, while the latter is an exampleof the subscription model. SOs could accommo-date different classes of consumer, e.g., consumersthat require a slightly different emphasis or depthof the financial analysis. Also, the SOs could differin verbosity of results, the rate of unsolicitednotification to consumers, in priority of notifica-tion of significant market disturbances, in theguaranteed response time, etc. SOs would differ inprice and play an important role in balancing ofthe resources used by the Web Service when itprocesses requests from a large number ofdifferent consumers. Examples of these resourcesare processing power, threads, consumed memory,and used stock notification Web Services. Theresources are limited and their use incurs somecosts. For example, the used stock notificationWeb Services from other businesses have to bepaid for, probably according to the received levelof service and QoS. To summarize, a Web Servicewith multiple SOs can be used in differentcircumstances and by a wider range of consumers.Providing multiple SOs also enables the WebService to better balance limited underlyingresources and the price/performance ratio.

Fig. 2 shows an example WSOL SO. Descrip-tions of SOs are usually long and complex, soFig. 2 contains only example parts that will bereferenced in this section.

Important management information is conveyedin the attributes of the WSOL /serviceOfferingSelement. The ‘service’ applicability domain attri-bute specifies for which Web Service the SO shouldbe used. The value of this attribute is a qualified

name whose namespace part refers to a WSDL file,while local part refers to the name of a WebService defined in this WSDL file. In Fig. 2, theservice offering SO2 is defined for the buyStock-Service Web Service. This Web Service is describedin the WSDL file http://www.buyStockProvider.ca/buyStockFile.wsdl. For the majority of con-straints, statements, reusability constructs, andQoS metrics inside a SO, the applicability domainis determined with three attributes: ‘service’,‘portOrPortType’, and ‘operation’, according tothe rules presented in [11].The ‘extends’ attribute specifies the name of the

SO the given SO extends through single inheri-tance. In Fig. 2, the service offering SO2 extendssome service offering SO1 defined in the sameWSOL file.The ‘accountingParty’ attribute determines the

accounting party—a special management partyresponsible for keeping track of the use of theprovider Web Service and management thirdparties, as well as what constraints were satisfiedand what were not. Further, it calculates pricesand penalties to be paid. In addition, the account-ing party is responsible for evaluation of allconstraints for which management responsibilityis not specified explicitly through managementresponsibility statements. Every SO has exactlyone accounting party. The provider, a manage-ment third party, or, in rare cases, the consumercan play the role of the accounting party. In Fig. 2,the accounting party for SO2 is the provider(supplier) Web Service.There are several other optional attributes of the

/serviceOfferingS element [12], not illustrated inFig. 2. These attributes are used to specifyduration of the validity period or expiration timeof the SO, subscription duration and price, andwhether the provider should ask for consumerconfirmation before switching from this WSOLSO.

2.2. Constraints and expressions

In WSOL, every constraint contains a Booleanexpression that states some condition to beevaluated. The constraints can be evaluated beforeand/or after invocation of operations or at

ARTICLE IN PRESS

Fig. 2. Parts of an example WSOL service offering.

V. Tosic et al. / Information Systems 30 (2005) 564–586570

particular date/time instances. WSOL enables theformal specification of:

1.

Functional constraints. These constraints defineconditions that a functionally correct operationinvocation must satisfy. They usually checksome characteristics of message parts of theinvoked operation. WSOL enables specificationof pre-, post-, and future-conditions, as well asinvariants. The novel concept of a future-condition is introduced to model conditionsevaluated some time after the provider finishesexecution of the requested operation and sends

results to the consumer. It enables specificationof operation effects that cannot be easilyexpressed with post-conditions. An example isdelivery confirmation for goods bought usingWeb Services.

2.

QoS (non-functional, extra-functional) con-

straints. These constraints check whether themonitored QoS metrics are within specifiedlimits. They can be checked for a particularoperation invocation or periodically, at speci-fied times.

3.

Access rights. An access right specifiesconditions under which any consumer using

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 571

the current SO has the right to invoke aparticular operation. For example, an accessright can limit the time of day when anoperation can be invoked. It can also limit thenumber and/or frequency of invocations. Ac-cess rights are used in WSOL for servicedifferentiation. On the other hand, specificationof conditions under which a particular con-sumer (or a class of consumers) may use a SOand other security issues are outside the scopeof WSOL.

For the specification of QoS constraints, WSOLuses external ontologies of QoS metrics andmeasurement units. Such ontologies contain pre-cise definitions of how the QoS metrics aremeasured and/or calculated and how the QoSmetrics (or the measurement units) relate to eachother. These external ontological definitions can bereused for different Web Services. We havesummarized requirements for such ontologies in[22]. Ideally, appropriate standardization bodieswould develop such ontologies and make themwell known. Such standardization is useful becauseexistence of multiple ontologies for the sameconcepts reduces interoperability. However, sincestandardization process is long and tedious, it ispractical to allow that other interested parties canalso define and publish ontologies to be used untilstandards are completed. Once a QoS metric isdefined in an external ontology, a WSOL filedeclares its use through the ‘metricType’ attributeof QoS constraints.

WSOL constraints are defined using the/constraintS element, which is independent ofparticular types of constraint. The ‘type’ attributeof the /constraintS element refers to an XMLschema defining a particular type of constraint.We have defined XML schemas for theabove-mentioned types of constraint. Usingthe XML Schema mechanisms, additionaltypes of constraint can be defined. An exampleWSOL constraint, the QoS constraint QoScons2,is shown in Fig. 2. This QoS constraint contains acomparison of a measured QoS metric Response-Time and the constant ‘0.3 s’. The valuesfor the applicability domain attributes ‘service’,‘portOrPortType’, and ‘operation’ indicate that

this QoS constraint is evaluated for everyoperation of the ‘buyStockService’ Web Service,because this is the Web Service for which thecontaining service offering SO2 is evaluated.Further explanation of WSOL constantssuch as ‘WSOL-ANY’ and ‘WSOL-EVERY’ canbe found in [10,11]. The value ‘WSOL_INTER-NAL’ for the ‘measuredBy’ attribute of theQoS states that the entity that evaluates thisQoS constraint also measures the response timeQoS metric.Boolean expressions in constraints can contain

standard Boolean operators, references tooperation message parts of type Boolean orother WSOL Boolean expressions, andcomparisons of arithmetic, string, date/time, orduration expressions. WSOL also supportschecking operation message parts that arearrays of any data type using quantifiers ‘ForAll’and ‘Exists’. Arithmetic expressions cancontain standard arithmetic operators, arithmeticconstants, and references to operation messageparts or WSOL expressions of numeric datatypes. WSOL provides only basic built-insupport for string and date/time/durationexpressions.In addition, it is possible to perform operation

calls in any expression. The called operations canbe implemented by the Web Service for which theconstraint is evaluated, by another Web Service, orby the management entity evaluating the givenconstraint. In the latter case, although theseexternal operations are described with WSDL,they are invoked using internal mechanisms,without any SOAP call.Different types of constraints have similar

syntax and require similar monitoring infrastruc-ture. Further, management statements, such asprices/penalties and management responsibilitystatements, relate to all constraints and not aparticular type of constraint, such as QoS. Con-sequently, there is less overhead in supporting onelanguage for various types of constraint, such asWSOL, than several separate languages for QoSconstraints, functional constraints, access rights,and possibly other constraints and managementstatements. This topic was discussed in more detailin [9].

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586572

2.3. Management statements

A WSOL statement is any construct, other thana constraint, that states important managementinformation about the represented class of service.For the formal specification of statements, WSOLcontains the general /statementS element. It isanalogous to the general /constraintS elementdiscussed in the previous subsection. The ‘type’attribute of the /statementS element refers to theXML schema defining a particular type of state-ment. We have defined XML schemas for thefollowing types of management statement:

1.

pay-per-use price statements, 2. monetary penalty statements, and 3. management responsibility statements.

Additional types of statement can be supportedin WSOL by defining XML schemas for them.

A pay-per-use price statement states the mone-tary amount a consumer using the particular SOhas to pay for invoking particular operation.Penalty statements specify the monetary amountthat the provider Web Service has to pay to aconsumer if the consumer invokes some operationand the Web Service does not fulfil all constraintsin the SO. A penalty can be stated for not meetingall constraints for an operation and/or for notmeeting a particular constraint. Currency unitsused in price and penalty statements are defined inexternal ontologies. A management responsibility

statement specifies what entity (the provider, theconsumer, or a management third party) has theresponsibility for checking a particular constraint,a constraint group (CG), or the complete SO. Aswill be discussed in Section 3.1, these managementparties act as SOAP intermediaries. Due to thespecifics of accounting parties, it is not possible touse a management responsibility statement tospecify the accounting party for a SO. Fig. 2shows an example WSOL management responsi-bility statement, MangResp1. In this example, theprovider (supplier) Web Service evaluates theaccess right AccRght1, the consumer evaluatesthe pre-condition Precond3, and the third partyevaluates the QoS constraint QoScons2.

2.4. Reusability elements

When multiple classes of service, SLAs, or othercomprehensive contracts are specified, there isoften a lot of similar information that differs insome details. For example, SLAs that a telecom-munication service provider has with its customersoften have similarities. Analogously, two classes ofservice for the same Web Service can be the samein many elements, but differ only in response timeand price. Expressive reusability constructs inWSOL enable easier specification of new SOsfrom existing SOs of the same Web Service orother Web Services. They can also be helpful indetermining similarities and differences betweenSOs in the process of selection of Web Services andSOs.WSOL files can contain several special reusa-

bility elements:

1.

the definition of constraint groups (CGs), 2. the inclusion of already defined constraints,

statements, or CGs,

3. the definition of constraint group templates

(CGTs),

4. the instantiation of CGTs, and 5. the declaration of operation calls.

A CG is a named set of constraints, statements,and reusability elements (including nested CGs).The inclusion element enables reusing constraints,statements, and CGs that have been previouslydefined. A CGT is a parameterized CG. In adefinition of a CGT, parameters are declared andused within the contained constraints. In aninstantiation of a CGT, concrete values aresupplied for all parameters. A declaration of anoperation call is used to enable referencing resultsof the same operation call in several relatedconstraints.Further, WSOL defines several reusability attri-

butes. Most importantly, the ‘extends’ attributecan be used to specify extension (single inheri-tance) of SOs, CGs, and CGTs. Reusabilityconstructs in WSOL were discussed in detailin [11].

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 573

2.5. Service offerings dynamic relationships

(SODRs)

Dynamic (run time) relationships between SOs

are those that can change during run-time, e.g.,after dynamic creation of a new class of service.For example, one such dynamic relationship canstate what class of service could be an appropriatereplacement if a particular constraint from someother class of service cannot be met. On the otherhand, static (development-time) relationships be-

tween SOs show similarities and differencesbetween SOs that do not change during run time.Two important examples of such relationships areextension (single inheritance) of SOs and instantia-tion of the same CGT with different parametervalues. Both static and dynamic relationshipsbetween SOs are useful for easier selection andnegotiation of SOs. In addition, dynamic relation-ships are crucial for the mechanisms for dynamicadaptation of Web Service compositions discussedin Section 4.2.

In WSOL, static relationships between SOs areexpressed with the reusability elements and attri-butes, such as extension, inclusion, and instantia-tion. They are built into definitions of SOs.Conversely, WSOL defines a special construct,the service offerings dynamic relationship (SODR),for dynamic relationships. SODRs are specifiedoutside definitions of SOs, often in separate files.In this way, a change in a SODR does affectdescriptions of SOs.

A SODR can be specified as a triple /SO1, S,SO2S or as a triple /SO1, E, SO2S [12]. Here:

1.

SO1 is the used SO, 2. (a) S is the set of constraints from SO1 that are

not satisfied;(b) E is a Boolean expression relating unsatis-fied constraints from SO1, and

3.

SO2 is the appropriate replacement SO.

If the format /SO1, S, SO2S is used, then SO2is the appropriate replacement for SO1 if allconstraints from S are unsatisfied. If the format/SO1, E, SO2S is used, then SO2 is theappropriate replacement for SO1 if the expressionE is true. The former format is simpler and easier

to monitor during run time, so it was the onlyformat for SODRs in early versions of WSOL [10].In the new WSOL version 1.1 we have added thelatter format, which is more powerful and can beused instead of the older format.

3. Using WSOL in Web Service Management

We concentrate our research of WSM onmonitoring of WSOL SOs. This includes measure-ment and calculation of used QoS metrics,evaluation of WSOL constraints, and accountingof executed operations and evaluated WSOLconstraints. In this section, we illustrate monitor-ing of WSOL SOs with an example configurationof management parties and discuss how our WSOIimplements monitoring activities inside a manage-ment party.

3.1. Web Service monitoring with several

management parties

Management third parties that are specifiedinside WSOL management responsibility state-ments, as well as independent accounting parties,act as SOAP intermediaries. In other words, theyintercept SOAP messages between the consumerand the provider, perform their managementtasks, and piggyback their management resultsinto SOAP headers.Fig. 3 shows an example configuration of

management third parties as SOAP intermediaries.In this example, only QoS constraints are eval-uated and distinction is made between theaccounting party, the QoS metering party, andthe QoS constraint evaluation party. In this figure,the arrows represent passing of information andcontrol between different management parties,achieved through sending of SOAP messages.When a consumer submits a request for executinga provider’s operation, the management thirdparties are organized as SOAP intermediaries forthe request, as well as the response message. Therequest from the consumer to the provider firstgoes through the accounting party, which logs thatthe request has been made. The request is thenforwarded to the QoS metering party, which

ARTICLE IN PRESS

ConsumerWeb

Service Provider

WebService

Accounting party

QoS metering

party

QoS constraintevaluation

party

Fig. 3. An example configuration of management third parties as SOAP intermediaries.

V. Tosic et al. / Information Systems 30 (2005) 564–586574

performs necessary activities. For example, formetering response time the QoS metering partylogs the time that will be considered as thebeginning time of the operation invocation. Next,the request message is forwarded to the providerWeb Service, which performs the requested opera-tion and sends the response message. The responsemessage first goes through the QoS metering party.In the response time measurement example, theQoS metering party logs the time that will beconsidered as the ending time of the operationinvocation and subtracts from it the loggedbeginning time. One way to transport to the QoSconstraint evaluation party the information aboutthe measured QoS metrics is to use special SOAPheaders as additions to the original responsemessage from the provider. The QoS constraintevaluation party receives the response message andthe information about the measured QoS metricsand evaluates appropriate constraints. It forwardsto the accounting party the response messagetogether with the information whether the eval-uated constraints were satisfied or not andappropriate details if some constraints wereviolated. The accounting party logs the receivedmanagement information, calculates prices and/orpenalties to be paid, and forwards the responsemessage and management information to theconsumer. It can also notify the provider withappropriate details, particularly if some QoSconstraints were not satisfied. This can help theprovider to adapt its behavior to meet guaranteesfor future operation requests. The additionalSOAP message from the accounting party to theprovider shown in Fig. 3 is optional. This isbecause there are a couple of other ways totransport management information from theaccounting party back to the provider. One ofthem is piggybacking the next SOAP message from

the consumer to the provider, while another isperiodic sending of reports.The routing of SOAP messages between the

consumer and the provider through SOAP inter-mediaries can be implemented in several ways. Inour WSOI prototype, we have used a simpleapproach in which the route is stored in a SOAPheader and the WSOI code in the consumerinvokes the accounting party instead of theprovider. The accounting party extracts the routefrom the SOAP header and invokes the next SOAPintermediary. The process is repeated until theroute is completed.There are other Web Service monitoring scenar-

ios that can be accommodated with WSOL. Forexample, WSOL has two features that can reducethe run-time overhead of monitoring activities, atthe cost of less management information. First,WSOL constraints checked before and/or afteroperation invocations can be evaluated occasion-

ally, only for some randomly chosen invocations(on average: 1 in n). This is specified with theoptional attribute ‘evalPeriod’ of QoS constraints.For example, when this attribute is set to 5, thismeans that this QoS constraint is checked, onaverage, for one operation invocation out of five.To maximize usefulness of such constraint evalua-tions, the provider must not know in advance forwhich operation invocation the QoS metrics willbe measured and/or the constraint will be eval-uated. This is achieved when an independentaccounting party randomly chooses between op-eration invocations and monitoring is performedonly by third parties. To make up for cases whenunsatisfied constraints are not checked, monetarypenalties for not meeting such constraints shouldbe relatively high.On the other hand, some QoS constraints can be

evaluated periodically at particular date/time

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 575

instances, independently from particular operationinvocations. This is useful for checking QoSmetrics such as average response time andthroughput. The accounting party initiates calcu-lation of periodic QoS metrics and evaluation ofperiodic QoS constraints.

In addition, WSOL supports management thirdparties that act as probes. Some QoS metrics, suchas availability, can be measured using probinginstead of message interception [3]. WSOL sup-ports this by modeling probing entities as separateWeb Services that provide results of their measure-ments through operations of agreed-upon porttypes (interfaces). These operations can be invokedin appropriate QoS constraints in WSOL SOsusing the WSOL operation call mechanism. Alter-natively, the probing entities can send their resultsto other management parties using operations ofthe special notification port type, discussed inSection 4.1.

3.2. Web Service monitoring inside WSOI

A management party performs its Web Servicemonitoring activities using WSOI. WSOI modulescan be classified into modules that are used formonitoring of WSOL SOs, modules used fordynamic manipulation of WSOL SOs, and mod-ules used for both purposes [21]. The part of WSOIthat performs monitoring of WSOL SOs is basedon extensions of Apache Axis (Apache eXtensibleInteraction System) [23,24], a popular open-sourceSOAP engine implemented in Java. A SOAPengine is an application that receives, processes,and sends SOAP messages. We run Axis using thepopular Apache Tomcat open-source applicationserver. Axis has several good features that wefound crucial for WSOI. Here we emphasize thetwo most important. First, Axis has a modular,flexible, and extensible architecture based onconfigurable chains of pluggable SOAP messageprocessing components, called handlers. Sucharchitecture enables implementing monitoring ofWSOL SOs using a set of additional handlers andhandler chains that are plugged into Axis easily.Second, Axis defines a SOAP message processingnode that can be used for provider Web Services,consumer Web Services, and SOAP intermedi-

aries. Consequently, it can be used for all WSOLmanagement parties.An Axis handler [23,24] can process input,

output, and/or fault SOAP messages. For exam-ple, it can perform measurement of QoS metrics. Ahandler can also alter the processed SOAPmessage, e.g., add/remove headers. An Axis chain

is an ordered, pipelined collection of handlers.Every Axis chain can also be treated as a handler.There are tree types of chain in Axis. A transportchain performs processing related to the transportof SOAP messages. A global chain performs otherprocessing applicable to all Web Services. Aservice chain performs processing characteristicfor a particular Web Service. Axis handlersexchange information through an instance of theMessageContext class, which contains informationabout the request message, the response message,and a set of properties. Axis handlers can use theMessageContext properties for decisions related tomessage processing. They can also modify theseproperties.In WSOI, specialized Axis handlers perform

WSOL-related measurement and calculation ofQoS metrics, evaluation of constraints, andaccounting activities. Hereafter, we refer to thesehandlers and their chains as ‘WSOI-specific

handlers and chains’. We have designed thesehandlers so that a WSOL compiler can generatethem automatically from WSOL files. However,since our prototype WSOL compiler is not yetfully implemented, we have manually implementedsome of these handlers in our proof-of-conceptprototype of WSOI. Some design decisions forWSOI-specific handlers were discussed in [20].In different invocation contexts, different

WSOI-specific handlers are used. An invocation

context is determined by the full name of theinvoked operation (containing Web Service, port,and operation names), the name of the SO, thename of the management party in which thishandler is used, and whether the processedmessage is request, response, or fault. In WSOLfiles, constraints and management statements areassociated with different invocation contextsthrough applicability domain attributes, contain-ment of constraints and management statementsinside SOs, management responsibility statement,

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586576

and the ‘accountingParty’ attribute of SOs. Wehave developed a special XML file format, calledthe Web Service Offering Descriptor (WSOD), fordescribing the order of WSOI-specific handlersused in a particular invocation context. WSODfiles can be generated by a WSOL compiler. Inaddition, we allow human Web Service adminis-trators to generate or modify WSOD files. WSOIloads this ordering information from WSOD filesinto internal data structures.

The WSOIChain class is the crucial WSOImodule for the monitoring of WSOL-enabledWeb Services. It contains code that dynamicallyconstructs the chain of appropriate WSOI-specifichandlers for the given invocation context, accord-ing to the contents of the internal data structuresloaded from WSOD files. In this way, differentWSOI-specific handlers are used for differentWSOL SOs and/or different operations. Aninstance of the WSOIChain class is a sub-chainof the Axis’ service chain.

Several WSOI-specific handlers are used by allmanagement parties. For efficiency reasons, theyare implemented outside the WSOIChain chain.One of them is WSOISessionHandler (SH) thatperforms session management activities. Further,the ServiceOfferingInput (SOI) and ServiceOffer-ingOutput (SOO) exchange the management in-formation between MessageContext propertiesand SOAP headers. While MessageContext prop-erties are used to transport WSOL-related man-agement information between WSOI modules,SOAP headers are used to transport this informa-tion between management parties.

MessageContext properties only store monitor-ing information for the latest invocation. There-fore, WSOI additionally stores descriptions ofWSOL constructs and the actual measured orcomputed data into several WSOI-specific data

req.

res.

WSOI (extends A

SOI

SOO

TL

TS

DS …

…Se

W

SH

Fig. 4. An example configuration of handlers and m

structures, often implemented as hashtables. Forexample, these data structures store informationabout which SO is used in a session, the lists ofactive and deactivated SOs, the history of un-satisfied and satisfied constraints, the billingbalance for a particular session, and the historyof prices and monetary penalties incurred in asession. Most of these data structures are also usedfor the mechanisms for manipulation of SOsdescribed in Section 4.2. Further informationabout these data structures and other WSOImodules is given in [21].Let us now illustrate how WSOI-specific hand-

lers are used for the monitoring of WSOL-enabledWeb Services. In Fig. 4, we have shown anexample configuration of handlers inside theprovider-side WSOI. The example is analogousto the example in Fig. 3, but in Fig. 4 all shownmodules are parts of the provider Web Service. Inother words, the provider Web Service measuresresponse time, evaluates a QoS constraint limitingresponse time, and performs accounting. In thisfigure, the arrows represent passing of informationand control between internal modules, achievedthrough local procedure calls. The Transport-Listener (TL) component of Axis receives therequest (input) SOAP message and passes it to thestandard Axis handler called Deserializer (DS),which creates a MessageContext instance used byother handlers. After DS, several other standardAxis handlers used for all Web Services areexecuted [24]. Due to space limits and the factthat these handlers are not crucial for theillustration of WSOI, they are not shown inFig. 4. Instead, their position is indicated with‘y’. For every Web Service that supports WSOL,the WSOI-specific handlers SH, SOI or SOO,and the chain WSOIChain are executed. Forprocessing input messages, SH reads the session

op. call

pache Axis)

Pr

SOIChain

RTB

RTS

AI

AO QCE

essage processing inside provider-side WSOI.

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 577

information from a SOAP header and writes itinto a MessageContext property. Similarly, SOIreads WSOL-related information from SOAPheaders and writes it into appropriate Message-Context properties. The first handler in WSOI-Chain for input message is AccountingInput (AI),which records the request message. Then, theResponseTimeBegin (RTB) handler stores into aMessageContext property the start time formeasuring response time. After this, the standardAxis handler, Provider (Pr), is executed. It isoutside WSOIChain. It dispatches the call to theJava object implementing the requested operationof the Web Service.

This Java object returns its results back to the Prhandler. After Pr, handlers in WSOIChain processthe response (output) message. First, the handlerResponseTimeStop (RTS) stores into a Message-Context property the stop time for measuringresponse time, as well as the difference betweenthis stop time and the start time stored by RTB.Next, the QoS constraint limiting response time isevaluated in the handler QoSConstraintEvalua-tion (QCE). This handler stores its results into aMessageContext property. Finally, the Accounting-Output (AO) handler uses the information fromMessageContext properties to calculate prices and/or penalties to be paid. This information is alsostored into other MessageContext properties.After WSOIChain, SOO and SH read WSOL-related information from MessageContext proper-ties and write them into SOAP headers. Next,several standard Axis handlers used for all WebServices [24] are executed. These handlers are notshown in Fig. 4, but their position is indicated with‘y’. The last of these handlers is Serializer (Se),which packs information from the MessageCon-text instance into SOAP. The TransportSender(TS) component of Axis sends the response SOAPmessage to the consumer. The information aboutthe measured response time, the evaluated con-straint, and, possibly, prices or penalties to be paidare in the SOAP header.

When for another SO and/or for anotheroperation different QoS metrics have to bemeasured, different WSOL constraints evaluated,and/or different prices or penalties calculated, thenonly the contents of the WSOIChain changes

appropriately. The configuration of all otherhandlers remains the same.The measurement or calculation of periodic QoS

metrics and evaluation of periodic constraintsdiffers from the example in Fig. 4. As alreadymentioned, it is initiated by the accounting party.If the provider acts as the accounting party, theperiodic monitoring activities are initiated byTimer, a special active module in WSOI. Timerinvokes WSOIChain, which creates and executes achain of appropriate WSOI-specific handlers. Theresults of such measurement, calculation, and/orevaluation can be stored locally for future proces-sing. They can also be reported to other manage-ment parties in a special notification SOAPmessage.We have performed a number of experiments to

demonstrate that WSOL and WSOI can be usedfor monitoring of Web Services and to estimate theoverhead that such monitoring places on WebServices. The experiments compare average re-sponse time and average Java Virtual Machine(JVM) memory usage when Web Services arehosted with Axis and when they are hosted withWSOI. Tosic et al. [21] describe one such experi-ment in which the use of WSOI increased responsetime 15% and memory usage 4%, compared toresponse time and memory usage when only Axiswas used. In our opinion, this is an acceptableincrease, because it is significantly low for manyconsumers and many circumstances. Further, inthe mentioned experiment the provider and theconsumer Web Services executed on differentcomputers in a local network. When Web Servicesare distributed over the Internet, the networkdelay is higher, so the relative WSOI increase ofthe total response time is lower.

4. Using WSOL in Web Service Composition

Management

4.1. Using WSOL for configuring Web Service

compositions

Let us now explain how a consumer whoalready knows about the appropriate providerWeb Service can choose one of the provider’s SOs.

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586578

This process is part of the configuration of WebService compositions.

For monitoring and manipulation of WSOLSOs, we have defined WSDL signatures of anumber of operations grouped into several Service

Offering Management (SOM) port types [20,21].For example, the SONotification port type definesoperations for notifications and other exchange ofWSOL-related management information betweenmanagement parties during monitoring of WSOL-enabled Web Services. Several characteristics ofthe SOM port types should be noted. First, thedefinition of well-known (ideally: standardized)management operations significantly reduces com-plexity of management activities. Several otherworks, such as WSLA [13], Open Grid ServicesArchitecture (OGSA) [25], and WS Manageability[26] also define management operations for WebServices. Second, the advantages of definingmanagement port types instead of separate man-agement Web Services are easier discovery andeasier support for only some SOM port types andoperations in them. While WSLA defines separatemanagement Web Services, WSOL, WS Manage-ability, and OGSA define management ports. Theconcept of management interfaces (port types) wasalso advocated and explored in several earlierworks on the management of distributed services,e.g., [27]. Third, a management party (e.g., aprovider) might implement only some of thesemanagement port types and/or only some opera-tions within a particular port type. Fourth, onlyselected external entities are allowed access to themajority of operations from SOM port types.These entities are primarily the other managementparties in the composition, but potentially alsospecial management software or human adminis-trators. Fifth, some or all Web Services of thesame vendor (e.g., Web Services using the sameSOAP engine instance) can share the actualimplementation of SOM port-type operations.This is because Web Services do not describeimplementation. In such cases, the overhead ofsupporting the SOM port types is lower.

In the process of setting up a SO to be usedbetween a consumer and a provider, severaloperations from SOM port types are used. Atthe very beginning, the consumer has to open a

session with the provider by invoking the provi-der’s implementation of the openSession() opera-tion from the SessionMgmt port type. Thisoperation creates a new session and returns thesession ID (identifier) to the consumer. When theconsumer invokes the listActiveSOsForMe() op-eration from the SOInfo port type, the providerreturns a WSOL file containing descriptions of allactive SOs that this consumer is allowed to use. Tocompare SOs, the consumer can invoke operationsfrom the SOComparisons port type. These SO-Comparions operations can be implemented by theconsumer, the provider, or some specialized helperWeb Service. When the consumer decides whichSO is most appropriate, it invokes the startWith-SO() operation of the SOM-Prov port type.Note that the negotiation between the consumer

and the provider is very simple—the providersuggests several existing SOs and the consumerchooses one of them. While this is less powerfulthan negotiation of custom-made SLAs, it requiresmuch simpler program code for decision making.In addition, selection of SOs can be done muchfaster than negotiation of custom-made SLAs,primarily because of the smaller number ofexchanged SOAP messages. To conclude, whilethis approach has limitations, it also has advan-tages because of its relative simplicity, speed, and

low overhead. As will be mentioned in the nextsubsection, we also allow dynamic creation of newSOs in exceptional cases.In the next subsection, we will mention SOM

port types used for the manipulation of WSOLSOs, while further information about all SOMport types can be found in [20,21].

4.2. Using WSOL for dynamic adaptation of Web

Service compositions

In the WSCM area, we are investigatingmanagement and dynamic adaptation of WebService compositions without breaking an existingrelationship between a provider Web service andits consumer. For example, the adaptability of therelationship between the stock notification WebService and the financial analysis Web Servicemight be a very valuable feature in a turbulentstock market. To achieve this goal we are

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 579

exploring mechanisms for the manipulation ofWSOL SOs. The crucial WSOL language supportfor these mechanisms is the specification ofdynamic relationships (SODRs) between serviceofferings, discussed in Section 2.5. The main fivedynamic manipulation mechanisms we have studiedare [20]:

1.

switching (initiated by the consumer or theprovider Web Service),

2.

deactivation, 3. reactivation, 4. deletion, and 5. creation of SOs.

These mechanisms can be used between opera-tion invocations inside one session. We illustratethe benefits of these mechanisms by extending thee-business example with provider stock notifica-tion and consumer financial analysis Web Services,introduced in Section 2.1.

Dynamic switching between SOs means changingwhich SO a consumer uses. Either a consumer or aprovider can initiate it. In the latter case, theconsumer is notified about the change. In addition,if the ‘autoManipulation’ attribute of the old SO isset to ‘False’, the consumer is asked for confirma-tion of the switching before it is executed. Theconsumer can initiate switching to dynamicallyadapt the service and/or QoS it receives withoutsearching for another provider. For example,depending on the analysis of the current situationin a stock market, the financial analysis WebService could want to dynamically switch betweendifferent SOs of the stock notification Web Serviceit consumes. Fig. 5a shows a case when thefinancial analysis Web Service FA1 switches fromservice offering SO1 to service offering SO2 of thesame stock notification Web Service SN1. In this

SO1

SO2

FA1 SN1

(a)

Fig. 5. (a) Switching between SOs; and (b

example Web Service composition, FA1 is theconsumer, while SN1 is the provider. In [20], wediscussed a more detailed example of consumer-initiated switching between SOs and illustrated itwith a UML sequence diagram. The provider caninitiate switching to gracefully upgrade or degradeits service and/or QoS in case of changes. Forexample, after dynamic creation of a new SO, thestock notification Web Service can suggest some ofits consumers to switch to the new SO. Switchingbetween SOs is the basic adaptation mechanism inour research.

Deactivation of SOs is used by a provider Webservice when changes in operational circumstancesaffect what SOs it can provide to consumers. SomeSOs cannot be used in all circumstances. Forexample, it is sometimes impossible to achieve highQoS or it is dangerous to provide SOs with lowsecurity. An example of changed circumstances isunexpected fluctuation in the QoS provided byWeb Services used by the provider. Anotherexample is some temporary disturbance of thecommunication between involved parties, e.g., dueto mobility. When such change of circumstancesoccurs, a Web service can dynamically andautomatically deactivate SOs that cannot besupported in the new circumstances. The affectedconsumers are switched to an appropriate replace-ment SO and notified about the change. Inaddition, if the ‘autoManipulation’ attribute ofthe deactivated SO is set to ‘False’, the consumersare asked for confirmation of the switching to thereplacement SO. If there is no appropriatereplacement SO, the provider can initiate creationof new SOs. When this is also not possible, analternative provider Web Service has to be sought.This dynamic adaptation mechanism supportsboth graceful degradation and seamless serviceupgrades and expansions.

SO1

FA1 SN1

SO2

SN2

(b)

) Switching between Web Services.

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586580

The deactivated SO may be reactivated at a latertime, after another change of circumstances. Afterthe reactivation, the provider suggests the affectedconsumers to switch to their original SOs. This canhelp in achieving, as much as possible, theoriginally intended level of service and QoS.

If the probability of future reactivation is zeroor very low, the provider Web Service can decideto dynamically delete a deactivated SO. Forexample, if implementation of the stock notifica-tion Web Service is dynamically upgraded toimprove performance, some of its SOs with lowerQoS might become redundant and can be deleted.Another example is when a management thirdparty used in some SO goes out of business.Deletion permanently removes support for an SO.Only deactivated SOs can be deleted.

Dynamic creation of new SOs can be used after achange in the implementation of the provider WebService, in the Web Services that the provider uses,in management third parties, in the executionenvironment, or in consumer needs. While thedynamic adaptation mechanisms discussed abovehandle changes that are to some extent antici-pated, the creation of new SOs can be used forunanticipated changes. For example, when theimplementation of the stock notification WebService is dynamically upgraded, then new SOsof this Web Service can be created. To reflect thesechanges, new SOs of the financial analysis WebService can also be created. This propagatesupgrade benefits from the stock notification WebService to consumers of the financial analysis WebService, e.g., decision support systems. Note thatcreation of new SOs is not creation of newfunctionality or new functional interfaces, butcreation of new sets of constraints and manage-ment statements for the existing functionality.However, dynamic creation of new SOs can benon-trivial and incur non-negligible overhead. Itcannot be performed arbitrarily due to variouspossible conflicts. Therefore, we are researchingonly simple and limited creation of new SOs asvariations of existing SOs, based on WSOLreusability elements and attributes. While weconcentrate on provider-initiated creation of SOs,we also leave the possibility of consumer-initiatedcreation in special cases. In the latter cases,

dynamic creation of a new SO can be viewed asa substitute for negotiation of a custom-madetechnical contract or SLA between Web Servicesbecase it involves matching consumer’s preferenceswith provider’s capabilities.Manipulation of SOs can be followed by

appropriate deactivation, reactivation, or creationof SODRs. The mechanisms for dynamic manip-ulation of WSOL SOs were discussed in detail andillustrated with further examples in [20].For the implementation of these dynamic

adaptation mechanisms, we have developed ap-propriate algorithms and protocols. The algo-

rithms for the manipulation of SOs containprogram logic deciding whether, what, how, andwhen the manipulation of SOs should be per-formed. In most cases, these algorithms areexecuted in provider-side WSOI, particularly inthe special SOMgmtDecisions module, when cer-tain conditions are met, without explicit externalintervention. They use the WSOI-specific datastructures that are also used for Web Servicemonitoring. For example, the algorithm fordeactivation of SOs first checks the history ofunsatisfied and satisfied constraints to determinewhether deactivation is appropriate. Then, it usesseveral data structures, including the informationabout the currently used SO and descriptions ofactive SODRs, to determine to which SO toswitch. Next, it invokes the algorithm and proto-col for the provider-initiated switching of SOs foraffected consumers. Further, it handles possiblespecial cases, such as the possibility that someconsumers reject the suggested replacement SO.After all these activities are performed, thisalgorithm invokes the algorithm for deactivationof affected SODRs. On the other hand, theprotocols for the manipulation of SOs govern thecoordination of management parties to achieve themanipulation. The operations that participate inthese protocols are defined in SOM port typesSOM-Prov, SOM-Cons, SOM-AccP, SOM-MgmtP, and SODRMgmt.To conclude, WSOI implements the discussed

mechanisms for manipulation of WSOL SOs withseveral data structures, the SOMgmtDecisionsmodule, and several modules that implement SOMport types. Unlike the Web Service monitoring

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 581

modules discussed in Section 3.2, these modulesare not based on Apache Axis. The details ofthese modules were presented and illustratedin [21].

We have performed a number of analyticalstudies and practical experiments comparing themanipulation of SOs with alternative approachesto dynamic adaptation of Web Service composi-tions. The main alternatives are re-composition ofWeb Services and re-negotiation of SLAs. Fig. 5billustrates switching between Web Services, whichis a special case of re-composition. In this example,the financial analysis consumer Web Service FA1is the consumer. SN1 and SN2 are two stocknotification providers implementing the sameWSDL port types, but providing different serviceofferings SO1 and SO2. To achieve dynamicadaptation, FA1 switches from SN1 with theservice offering SO1 to SN2 with the serviceoffering SO2. Our analytical studies [20] comparedthe number of exchanged SOAP messages indifferent dynamic adaptation approaches. This isbecause internal operations performed by partiesinvolved in dynamic adaptation are relativelysimple and fast compared to the generation,transmission, and processing of SOAP messages.On the other hand, in our experiments [20,21] wemeasured average delay and average JVM memoryusage.

These experiments and analytical studiesshowed that manipulation of SOs is generallysimpler, faster, and incurs less run-time overhead

than the re-composition of Web Services and there-negotiation of SLAs. Further, it providesadditional flexibility and enhances robustness ofthe relationship between a provider Web Serviceand its consumer. This robustness is important,e.g., when the consumer trusts the currentprovider, but does not yet trust alternativeproviders.

However, compared to the re-composition ofWeb Services, manipulation of SOs has limitations.SOs of one Web Service differ only in constraintsand management statements, which might not beenough for adaptation. Further, appropriatealternative SOs cannot always be found or created.Therefore, manipulation of SOs is a complementto, and not a complete replacement for, the re-

composition of Web Services. On the contrary, itcan be either a complement to or a lightweightreplacement for the re-negotiation of SLAs,because they have relatively similar limitations.Consequently, we suggest that a management

system for dynamic adaptation of Web Servicecompositions integrates the manipulation of SOsand the re-composition of Web Services. The firststep in such dynamic adaptation is to try to find areplacement SO from the same Web Service. If thisis not possible, the second step is to try to find areplacement Web Service and perform re-compo-sition. In some cases, the used provider WebService can supply a temporary replacement SOwhile the consumer searches for another, moreappropriate, Web Service. Other approaches todynamic adaptation, such as re-negotiation ofSLAs, could also be integrated into such manage-ment system to address cases when they areappropriate.

5. Related work

The most important related works to WSOL aretwo languages for the formal XML-based specifi-cation of custom-made SLAs for Web Service: theWSLA [3,13] from IBM and HP’s WSML [6,14].These languages do not directly support theconcept of classes of service. SLAs in these twolanguages contain QoS guarantees and manage-ment information such as management responsi-bilities and prices. Since WSOL SOs also specifyQoS constraints (guarantees and requirements),they can be viewed as simple SLAs or othertechnical contracts. Let us outline some of thedifferences between WSOL SOs and SLAs inWSLA and WSML. Custom-made SLAs have toexplicitly specify information about consumers,which is implicitly assumed in WSOL. In addition,SLAs in WSLA and WSML contain more detailfor QoS constraints than WSOL SOs. Forexample, they contain detailed description ofmanagement action guarantees, while WSOL onlydescribes monetary penalties to be made. Simi-larly, their description of schedules that is moredetailed than information provided in WSOLperiodic QoS constraints. In these aspects, WSLA

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586582

and WSML are more powerful than WSOL.Further, WSLA and WSML define used QoSmetrics within SLAs, while WSOL outsources suchdefinition to external ontologies. It seems that allthis results in higher run-time overhead of WSLAand WSML than the overhead of the simplerWSOL. On the other hand, WSOL SOs cancontain formal specification of functional con-straints and access rights, which are not specifiedin SLAs. Another advantage of WSOL is thebroad set of powerful reusability constructs [11].Both WSLA and WSML are oriented towardsmanagement applications in inter-enterprise sce-narios. It seems that they assume existence of somemeasurement and management infrastructure atboth ends. This is a different assumption from theone that we have adopted for WSOL. Theselanguages are accompanied by appropriate man-agement infrastructures. These infrastructures aremore powerful, but also more complex, than ourWSOI. To conclude, while both WSLA andWSML are very good languages for their domainand purpose, they do not address all the issues thatWSOL does.

Another language that can be used for specifica-tion of SLAs for Web Services is SLAng [15].SLAng enables specification of SLAs on the WebService level and several lower levels, so it hasbroader scope than WSLA, WSML, and WSOL.However, the definitions of QoS metrics are builtinto SLAng schema, so SLAs have predefinedformat. Since the current version of SLAng lacksflexibility and power, it seems less well suited forWeb Services than WSLA, WSML, and WSOL.The work on a management infrastructure forSLAng is in progress.

WS-Policy [16] is a general framework for thespecification of policies for Web Services. A policycan be any property of a Web Service or its parts,so it corresponds to WSOL concepts of aconstraint and a management statement. WS-Policy is only a general framework, while thedetails of the specification of particular categoriesof policies will be defined in specialized languages.The only such specialized language currentlydeveloped is WS-SecurityPolicy. WS-PolicyAsser-tions can be used for the formal specification offunctional constraints, but the contained expres-

sions can be specified in any language. It is notclear whether and when some specialized lan-guages for the specification of QoS policies, prices/penalties, and other management information willbe developed. Another set of issues is where, when,and how are WS-Policy policies monitored andevaluated. WS-Policy has a number of goodfeatures, such as flexibility, extensibility, andreusability. However, some of the advantages ofWSOL are the explicit support for managementapplications, built-in support for various cate-gories of constraints and management statements,unified representation of expressions, wider rangeof reusability constructs, and specification ofclasses of service and relationships between them.Several other resent works also recognize the

importance of the formal specification of variousconstraints, SLAs, and contracts for Web Servicesand special types of Web Service. The DAML-S[18] community works on semantic descriptions ofWeb Services, including specification of somefunctional and some QoS constraints. However,these specifications are not yet precise and detailedenough for the monitoring and managementactivities. While DAML-S has the concept of aservice profile, there is no concept of a class ofservice and no SODRs. The OGSA [25] commu-nity also recognizes the need for formal specifica-tion of contracts, SLAs, and constraints. It hasbeen working on WS-Agreement, previouslyknown as OGSI-Agreement [19]. However, a GridService is a very special Web Service and it is notyet clear how the future results from the OGSAcommunity will relate to general Web Services. Inaddition, several research projects related to thedescription and discovery of QoS for WebServices, such as the UX [17] extension of UDDI,have been started recently. However, these worksare not yet accompanied by research of manage-ment-related issues and appropriate managementinfrastructures. On the other hand, several recentpapers and commercial products focus on parti-cular areas of WSM and WSCM, often perfor-mance or security. However, these managementsolutions cannot be transferred or generalized toother management areas. In addition, they do notaddress comprehensive description of managementinformation for Web Services.

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 583

6. Conclusions and future work

Describing a Web Service in WSOL, in additionto WSDL is useful for both WSM and WSCMapplications.

The crucial WSOL support for WSM applica-tions is the formal and unambiguous specification of

various types of constraint and management state-

ment, in a format that can be used for automaticgeneration of constraint-checking code. WSOLdescribes for Web Services the QoS metrics tomeasure or calculate, the constraints (requirementsand guarantees) to evaluate, when and where and,to some extent, how to perform these monitoringactivities, and what are the monetary conse-quences of meeting or not meeting the constraints.This management information is the basis for bothWeb Service monitoring and control of the WebService to meet its guarantees. Different types ofconstraint and management statement are usefulin different management areas. QoS constraintsare particularly useful in performance manage-ment. Functional constraints are beneficial in faultmanagement, particularly to determine whether aWeb Service behaves correctly. Access rights limitaccess to operations and ports of a Web Service.While WSOL access rights are used primarily forservice differentiation, they could also be a smallpart of a comprehensive security managementsolution for Web Services. Statements about pay-per-use prices and monetary penalties are valuablein accounting management, particularly billing.Management responsibility statements can be usedin configuring Web Services and their composi-tions. While WSOL constraints and statementscan be viewed as two categories of managementpolicies, WSOL SOs formally represent classes ofservice and can be viewed as simple SLAs ortechnical contracts between providers, consumers,and potential management third parties.

Web Service monitoring activities can be per-formed by the provider Web Service, the con-sumer, and/or one or more mutually trusted thirdparties (SOAP intermediaries or probes.) Manage-ment third parties and the specific accountingparty can be explicitly designated in WSOL files.The accounting party is stated in an attribute ofthe XML element for a SO. A management third

party that measures or calculates a QoS metric isindicated in an attribute of the declaration of useof this QoS metric. Management third parties thatact as SOAP intermediaries are specified inmanagement responsibility statements, while aparty that acts as a probe is specified through anattribute of the appropriate operation call.Other attributes of WSOL constructs are also

relevant for management. The subscription andvalidity period attributes of SOs are useful foraccounting management. The applicability domainattributes determine for which Web Service, port,and operation a WSOL construct or a QoS metricshould be monitored. An attribute of QoSconstraints can be used to indicate their occasionalevaluation, while child elements of periodic QoSconstraints are used to specify evaluation times.The crucial WSOL language support for dy-

namic adaptation of Web Service compositionsbased on the manipulation of SOs is the specifica-

tion of relationships between SOs. In particular,WSOL contains the built-in format for thespecification of SODRs. These relationships areessential for switching (particularly provider-in-itiated), deactivation, and reactivation of SOs. Onthe other hand, WSOL reusability elements andattributes determine static relationships betweenSOs. They can be used for dynamic creation ofnew SOs.The work on WSOL is accompanied with the

development of WSOI and the research of themechanisms for the dynamic manipulation of SOs.WSOI demonstrates feasibility and usefulness ofusing WSOL for management applications. Itenables monitoring of WSOL-enabled Web Ser-vices and dynamic manipulation of their SOs. ForWeb Service monitoring, we have extended theApache Axis open-source SOAP engine withWSOI-specific modules, data structures, and man-agement ports. To support dynamic manipulationof SOs, we have developed appropriate algo-rithms, protocols, and management port typesand built into WSOI modules, data structures, andports for their implementation.The use of classes of service for customization of

Web Services has limitations. Similarly, thedynamic adaptation of Web Service compositionsbased on the manipulation of classes of service has

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586584

limitations. However, the main competitive ad-vantages of using classes of service and theirmanipulation for management activities are rela-

tive simplicity, speed, and low run-time overhead. Inmany situations, application of our results can bemore practical than utilization of solutions basedon custom-made SLAs or other alternatives. Oneexample of such a situation is when a providerservers a very large number of consumers (e.g.,hundreds or more) in parallel. Another examplesituation is when the provider executes in resource-constrained environments, such as embedded and/or mobile systems. Both classes of service and themechanisms for their dynamic manipulation canbe used as lightweight complements and additionsto the more powerful alternatives.

WSOL and WSOI address specification, mon-

itoring, and manipulation of classes of service for

Web Services. These issues have not yet beenresearched by related works. Several recent relatedworks—particularly WSLA, WSML, and WS-Policy—address management-related issues thatpartially overlap with WSOL. In some aspects,they are more powerful than WSOL. On the otherhand, some of the unique characteristics andadvantages of WSOL are [9]: support for classesof service and their static and dynamic relation-ships, formal specification of various types ofconstraint and statement, a diverse set of reusa-bility constructs, features reducing run-time over-head, and support for both WSM and WSCMapplications. Further, WSOL can be extendedwith support for additional types of constraint andmanagement statement using XML Schema me-chanisms, without any changes to the currentWSOL grammar. Unfortunately, it seems that wecurrently do not have resources to push WSOLthrough a standardization process. Nevertheless,our results from the work on WSOL, WSOI, andthe mechanisms for manipulation of WSOL SOscan be integrated into future standards and plat-forms for WSM and WSCM. In particular, weadvocate integration of good features fromWSLA, WSML, WS-Policy, and WSOL into afuture standard for description of Web Services.

Our current work is mainly focused on thefurther development of WSOI, its prototypeimplementation, and research of the manipulation

of SOs. While our current WSOI prototypedemonstrates the main concepts, the improvedprototype will demonstrate the complete system.For example, we have not yet implemented theWSOI support for manipulation of SODRs. Like-wise, WSOI currently has only rudimentarysupport for creation of SOs. We plan furtherexperiments comparing WSOL and languagesbased on custom-made SLAs. Integration intoWSOI of the actual control of Web Services tomeet the specified constraints is also left for futurework.While WSOL can be improved in several ways,

we consider the language relatively complete andstable. We have recently completed several im-provements, described in [12], of the WSOLgrammar and parser. For example, we have addedspecification of complex expressions into SOsdynamic relations, naming and inclusion ofexpressions, as well as definition of CGs andCGTs in which only some (‘at least one’ or ‘exactlyone’) constraint have to be satisfied. We have alsoadded additional management-related attributes toSOs and QoS constraints, improved specificationof periodic QoS constraints and future-conditions,and made specification of statements more flexibleand more consistent. The Premier WSOL parserwas improved according to these WSOL grammarchanges. We plan full compatibility with the newWSDL version 2.0. In addition, we are consideringextending WSOL to achieve compatibility withBPEL4WS. The major WSOL issue related toWSOI is the full implementation of a WSOLcompiler to enable automatic generation of WSOI-specific handlers from WSOL files. A Java API forthe generation of WSOL files would also bebeneficial.We have left several important areas for future

research. One of them is use of WSOL for selectionof Web Services and their SOs. The process ofcomparison, negotiation, and selection of WebServices, their functionality, and particularly QoSis a very complex issue, without a simple andstraightforward solution. QoS often cannot beeasily compared as it can have many dimensions ofdifference. For example, when one SO constrainsavailability and does not limit response time, whileanother SO does the opposite, it is very difficult to

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586 585

say which one is ‘better’. On the other hand, as thenumber of Web Services that offer similarfunctionality increases, the offered QoS, price,and manageability will become important compe-titive advantages. Consequently, the comprehen-sive description of Web Services in WSOL,particularly the explicit representation of staticand dynamic relationships between WSOL SOs,can assist in selecting appropriate Web Servicesand SOs. Therefore, the development of appro-priate WSOL-based comparison and selectionalgorithms and heuristics and their implementa-tion in specialized Web Service brokers seem likepromising research topics. A related open issue isintegration of WSOL with the existing WebService discovery and selection technologies, suchas UDDI.

In addition, WSOL could be used with securitytechnologies for Web Services. For example,different keys could be used for encryption ofSOAP message body and various QoS measure-ments and constraint evaluation results, so thatonly relevant management parties would see them.Further research in this area is needed.

References

[1] J.C. Schlimmer (Ed.), Web services description require-

ments, World Wide Web Consortium (W3C) working

draft, on-line at: http://www.w3.org/TR/2002/WD-ws-

desc-reqs-20021028/, October 28, 2002.

[2] C. Peltz, Web services orchestration and choreography,

Computer, IEEE-CS 36 (10) (2003) 46–52.

[3] A. Keller, H. Ludwig, The WSLA framework: specifying

and monitoring service level agreements for Web Services,

J. Network Systems Manag. 11 (1) (2003).

[4] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana,

Web services description language (WSDL) 1.1, World

Wide Web Consortium (W3C) note, on-line at: http://

www.w3.org/TR/wsdl, March 15, 2001.

[5] R. Chinnici, M. Gudgin, J.-J. Moreau, J. Schlimmer, S.

Weerawarana (Eds.), Web services description language

(WSDL), version 2.0, Part 1: core language, World Wide

Web Consortium (W3C) working draft, on-line at: http://

www.w3.org/TR/2003/WD-wsdl20-20031110, November

10, 2003.

[6] A. Sahai, A. Durante, V. Machiraju, Towards automated

SLA management for web services, Research Report HPL-

2001-310 (R.1), Hewlett-Packard (HP) Laboratories, Palo

Alto, on-line at: http://www.hpl.hp.com/techreports/2001/

HPL-2001-310R1.pdf, July 26, 2002.

[7] S. Frolund, J. Koistinen, Quality of service specification in

distributed object systems design, in: Proceedings of the

Fourth USENIX Conference on Object-Oriented Tech-

nologies and Systems—COOTS ’98, Santa Fe, USA, April

1998, USENIX.

[8] A. Beugnard, J.-M. Jezequel, N. Plouzeau, D. Watkins,

Making components contract aware, Computer, IEEE-CS

32 (7) (1999) 38–45.

[9] V. Tosic, K. Patel, B. Pagurek, WSOL—a language for the

formal specification of classes of service for web services,

in: Proceedings of the 2003 International Conference on

Web Services—ICWS’03, Las Vegas, USA, June 2003,

CSREA Press, pp. 375–381.

[10] K. Patel, XML Grammar and parser for the web service

offerings language, M.A.Sc. Thesis, Carleton University,

Ottawa, Canada, on-line at: http://www.sce.carleton.ca/

netmanage/papers/KrutiPatelThesisFinal.pdf, January 30,

2003.

[11] V. Tosic, K. Patel, B. Pagurek, Reusability constructs in

the web service offerings language (WSOL), in: Proceed-

ings of the Workshop on Web Services, e-Business, and the

Semantic Web (WES) at CAiSE’03, Velden, Austria, June

2003, LNCS, No. 2681, Springer, Berlin, pp. 468–484.

[12] K. Patel, B. Pagurek, V. Tosic, Improvements in WSOL

grammar and ‘‘premier’’ WSOL Parser, Res. Rep. SCE-03-

25, Department of Systems and Computer Engineering,

Carleton University, Ottawa, Canada, on-line at: http://

www.sce.carleton.ca/netmanage/papers/PatelEtAlResRep

Oct2003.pdf, October 2003.

[13] H. Ludwig, A. Keller, A. Dan, R.P. King, R. Franck, Web

service level agreement (WSLA) language specification,

version 1.0, Revision wsla-2003/01/28, International Busi-

ness Machines Corporation (IBM), on-line at: http://

www.research.ibm.com/wsla/WSLASpecV1-20030128.pdf,

2003.

[14] A. Sahai, V. Machiraju, M. Sayal, A. van Moorsel, F.

Casati, Automated SLA monitoring for web services, in:

Proceedings of the 13th IFIP/IEEE International Work-

shop on Distributed Systems: Operations and Manage-

ment—DSOM 2002, Montreal, Canada, October, Lecture

Notes in Computer Science (LNCS), No. 2506, Springer,

Berlin, 2002, pp. 28–41.

[15] D.D. Lamanna, J. Skene, W. Emmerich, SLAng:

a language for defining service level agreements, in:

Proceedings of the Ninth IEEE Workshop on Future

Trends in Distributed Computing Systems—FTDCS

2003, Puerto Rico, May 2003, IEEE-CS Press, pp.

100–106.

[16] M. Hondo, C. Kaler (Eds.), Web services policy frame-

work (WS-Policy), version 1.0, BEA/IBM/Microsoft/SAP,

on-line at: ftp://www6.software.ibm.com/software/develo-

per/library/ws-policy.pdf, December 18, 2002.

[17] Z. Chen, C. Lianf-Tien, B. Silverajan, L. Bu-Sung, UX—

an architecture providing QoS-aware and federated sup-

port for UDDI, in: Proceedings of the 2003 International

Conference on Web Services—ICWS’03, Las Vegas, USA,

June 2003, CSREA Press, pp. 171–176.

ARTICLE IN PRESS

V. Tosic et al. / Information Systems 30 (2005) 564–586586

[18] The DAML Services Coalition, DAML-S: semantic

markup for web services, WWW page for DAML-S

version 0.9, on-line at: http://www.daml.org/services/

daml-s/0.9/daml-s.html, May 5, 2003.

[19] K. Czajkowski, A. Dan, J. Rofrano, S. Tuecke, M. Xu,

Agreement-based grid service management (OGSI-Agree-

ment), Version 0, Global Grid Forum, June 2003.

[20] V. Tosic, W. Ma, B. Pagurek, B. Esfandiari, On the

dynamic manipulation of classes of service for XML web

services, in: Proceedings of the 10th Hewlett-Packard Open

View University Association (HP-OVUA) Workshop,

Geneva, Switzerland, July 2003, Hewlett-Packard.

[21] V. Tosic, W. Ma, B. Pagurek, B. Esfandiari, Web service

offerings infrastructure (WSOI)—a management infra-

structure for XML web services, in: Proceedings of the

NOMS—The IEEE/IFIP Network Operations and Man-

agement Symposium 2004, Seoul, South Korea, April

2004, IEEE, pp. 817–830.

[22] V. Tosic, B. Esfandiari, B. Pagurek, K. Patel, On

requirements for ontologies in management of web

services, in: Proceedings of the Workshop on Web

Services, e-Business, and the Semantic Web at CAiSE’02,

Toronto, Canada, May 2002, Lecture Notes in Computer

Science (LNCS), No. 2512, Springer, Berlin, pp. 237–247.

[23] The Axis Development Team, Axis architecture guide, 1.0

Version, The Apache Software Foundation, on-line at:

http://archive.apache.org/dist/ws/axis/1_0/xml-axis-10.zip,

October 7, 2002.

[24] WebServices.Org, Introduction to axis, WWW resource,

WebServices.Org, on-line at: http://www.webservices.org/

index.php/article/articleview/415/1/24/, May 28, 2002.

[25] I. Foster, C. Keselman, J.M. Nick, S. Tuecke, Grid

services for distributed systems integration, Computer,

IEEE-CS 35 (6) (2002) 37–46.

[26] M. Potts, I. Sedukhin, H. Kreger, E. Stokes, Web service

manageability—specification (WS-Manageability), version

1.0, IBM/CA/Talking Blocks submission to the OASIS

Web Services Distributed Management TC, September

2003.

[27] M. Sloman, Management issues for distributed services, in:

Proceedings of the IEEE Second International Workshop

on Services in Distributed and Networked Environ-

ments—SDNE ‘95 Whistler, Canada, June 1995, IEEE-

CS Press, New York, pp. 52–59.