a semantic web services architecture

Mark BursteinBBN Technologies

Christoph Bussler and Michal ZarembaDigital Enterprise Research Institute

Tim FininUniversity of Maryland, BaltimoreCounty

Michael HuhnsUniversity of South Carolina

Massimo PaolucciDoCoMo CommunicationsLaboratories Europe GmbH

Amit ShethUniversity of Georgia

Stuart WilliamsHewlett-Packard Laboratories

A Semantic Web Services Architecture

The Semantic Web Services Initiative Architecture (SWSA) committee has

created a set of architectural and protocol abstractions as a foundation for

Semantic Web service technologies.This article summarizes the committee’s

findings, emphasizing its review of requirements gathered from several different

environments.The authors also identify the scope and potential requirements for

a Semantic Web services architecture.

Formed in February 2003, the Seman-tic Web Services Initiative Architecture(SWSA) committee’s mission is to

develop the necessary abstractions for anarchitecture that supports Semantic Webservices. The resultant framework buildson the W3C Web Services Architectureworking group report (and is motivated inpart by Tim Berners-Lee’s vision for theSemantic Web1). Other groups developingSemantic Web services frameworks con-tributed to the discussions, including theWeb Ontology Language for Services(OWL-S) consortium, the Web ServiceModeling Ontology (WSMO; www.wsmo.org) group at the Digital EnterpriseResearch Institute (DERI), and the Manag-ing End-to-End Operations-Semantics(METEOR-S; http://lsdis.cs.uga.edu/pro-jects/meteor-s/) group at the University ofGeorgia.2,3

In this article, we describe the protocolsexchanged between the interacting entitiesor agents that interpret and reason withsemantic descriptions in the deployment

of Semantic Web services. We focus specif-ically on those capabilities that extend thepotential range of Web services; we alsodiscuss security, reliability, and a flexiblemeans of recovery from the problems thatcan occur in open and evolving environ-ments. The SWSA architectural frameworkattempts to address five classes of Seman-tic Web agent requirements — dynamicservice discovery, service engagement, ser-vice process enactment and management,community support services, and qualityof service (QoS) — which we cover in detailhere as well.

Multiple DistributedEnvironmentsSystems developed via Web service tech-nologies are often limited by their need toagree in advance on the syntax andsemantics of various communications.Whereas the World Wide Web is success-ful in part because it makes it easy tointeract with and gather information fromsites that are discovered dynamically, tra-

52 SEPTEMBER • OCTOBER 2005 Published by the IEEE Computer Society 1089-7801/05/$20.00 © 2005 IEEE IEEE INTERNET COMPUTING

Serv

ice-

Ori

ente

dC

ompu

ting

Tra

ck Editors: Michael Huhns • huhns@sc .eduMunindar P. Singh • s ingh@ncsu .edu

ditional Web services are designed to function morelike distributed object-oriented computing systems.In contrast, semantically transparent services willmake it possible for clients to successfully use ser-vices that are dynamically discovered without priornegotiations between client and service developers.

Such goals are important for commercial Webservice environments, including business-to-business and business-to-consumer applications,grid computing, ubiquitous computing, andinformation management. For commercial Webservices, it will be increasingly important for ser-vice providers to be able to adapt their interfacesin order to support new products and serviceoptions without interrupting or requiringchanges to the software that clients use to accessthose services. Likewise, clients that wish to com-parison shop or use alternate services when theones they traditionally use are unavailable willneed to adapt flexibly to the differences betweenthe interfaces those alternative services present.Similar issues arise with grid computing services,in which computational resources are often over-subscribed and different sites that can performthe same functions often have different interac-tion requirements.

These environments often have two barriers tointeroperability: incompatible information modelsand mismatches in different service providers’ inter-action protocols. Dynamically accessible semanticdescriptions of service capabilities and utilizationprotocols, based on shared semantic models pub-lished on the Semantic Web, are seen as a way toovercome these barriers, but they will require addi-tional infrastructure so that individual softwareagents can directly interpret published servicedescriptions (which sometimes use unfamiliarontologies). Given the open-ended nature of Web-oriented distributed environments, this architecturemust also handle semantically interpretable securi-ty authorizations and ensure the privacy of trans-mitted information.

Some aspects of our proposed architecture willbe more central to particular applications thanothers, and some will take longer to be widelyadopted. Our near-term emphasis is on semanticsfor user-directed service interactions: users spec-ify what they want from a service, rather than thedetails of how to ask for it. For this family ofuses, a service client will need to avoid hard-coded knowledge of the syntax for interactingwith particular providers, instead using informa-tion from published semantic service descriptions

to mediate interactions with classes of function-ally similar providers, even when their detailedinterfaces differ. These software clients musttranslate user requests into suitable forms foreach potential provider, and then use the interac-tion methods specified by those providers by rea-soning from the published semantic descriptionsof those methods.

As the technology matures, we anticipate thatmethods now being explored will support morewidespread use of mechanisms for automated ser-vice discovery and matchmaking. A key element ofthis phase will be the development of shared,extensible, community-wide ontologies for describ-ing capabilities, services, and goods, and — equal-ly critically — for making these ontologies publiclyaccessible for use by Web applications. Open-source ontologies for different kinds of services andproducts will enable broad-based, automated, ser-vice discovery in the same way search engines nowmake it easy to discover new Web sites.

Underlying AssumptionsOur architectural framework builds on two emerg-ing technological concepts: Web services and theSemantic Web. Web service providers can publishdescriptions of service interfaces on the Web usingthe XML-based Web Services Description Lan-guage (WSDL). These descriptions include infor-mation about the message forms used to invokethe services, which can be serialized using HTTPand SOAP protocols, among others. WSDL doesnot, however, have a systematic way to associatemeanings with the messages and message argu-ments that appear in those descriptions. TheSemantic Web vision takes Web-publishing ofdescriptions to the next level by introducingsemantic description languages built on XML,which enables people to publish and share ontolo-gies — set of conceptual terms labeled by URLs —that can be used in describing other publishedmaterials. Semantic Web services are Web servicesin which semantic Web ontologies ascribe mean-ings to published service descriptions so that soft-ware systems representing prospective serviceclients can interpret and invoke them.

This is a good time to talk about how clientsand services can act as software agents with goals.In the discussions that follow, we assume the fol-lowing general capabilities of agents in SemanticWeb service environments (in this context,“agents” include requesters [clients], serviceproviders, and middle agents).

IEEE INTERNET COMPUTING www.computer.org/internet/ SEPTEMBER • OCTOBER 2005 53


• All agents can access and interpret Web-pub-lished ontologies, and can communicateusing messages whose content is represented,or can be interpreted, in terms of publishedontologies.

• Service providers publish semantic descriptionsof their service capabilities and interaction pro-tocols, which prospective consumers can theninterpret when selecting appropriate servicesand when formulating their interactions withthose services.

• Requestor agents wishing to delegate internalobjectives to external agents can reformulatethose objectives as well-formed requests to ser-vice providers by using those providers’ seman-tically described service interfaces as guides.

For dynamic Web services to function, clients mustbe able to interpret the published semantic descrip-tions of unfamiliar services to help them decidewhich services to use and how to interact withthem. As a result of this style of interaction, clientswill be able to adjust smoothly as service interfacesevolve. Such interaction also lets clients discoverand substitute new services for ones that are nolonger available, even if those new services usedifferent protocols or message types.

Phases of Semantic Web Service InteractionThe overall process of discovering and interactingwith a Semantic Web service will, in general,include three phases:

• Candidate service discovery is the distributedsearch for available services that can (poten-tially) accomplish some set of a client’s inter-nal goals or objectives. One architecturalapproach to this phase is interaction with asemantic matchmaker, a registry agent, or apeer agent serving either function.

• Service engagement includes the process ofinterpreting candidate Web service enactmentconstraints (partly or fully described in eachservice’s published self-description), and thennegotiating with prospective services untilreaching an agreement. This phase concludeswhen both service and client agree to the ser-vice-provision terms in an explicit or implicitservice contract. Negotiations can include ser-vice price, product attributes, and the qualityand timeliness of service, security and privacy,and so on.

• Service enactment is the process that finallycompletes the mutually agreed objectives of

54 SEPTEMBER • OCTOBER 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING

Service-Oriented Computing Track

Figure 1. Service interaction process. Client (green) and service provider (blue) goal descriptions (hexagons) drive the threemain phases of interaction (discovery, engagement, and enactment).At the lower level, these goals are communicatedduring message exchanges utilizing protocols (green boxes) that follow general, phase-specific patterns.

Abstractcharacterizations ofcandidate service

Publishedadvertisement and

service modelService

provision process

Interactionswith service

registries

Clientachievement process

Candidateservice discovery

Service contractnegotiation

Characterizationof desired service

as a request

Servicediscovery

query protocol

Monitoringand execution

of service

Serviceinitiation

Servicemonitoring

Terminationand

compensation

Serviceagreement

Client'sinternal goal

Serviceprovider's

internal goal

Serviceenactment

Selected serviceprovider andagreement

Service selectionand engagement

Candidateservices

Client goaldescription reformulation

Negotiation withcandidate services,

commitment toservice agreement

client and service, by following the service’spublished protocols. If the contract’s primaryobjectives aren’t accomplished, then the clientand service can use a compensation protocol torestore financial equity or a stable operatingstate. If the underlying message transportmechanisms allow for asynchronous interac-tions, then clients can use protocols to monitorthe service process’s status during execution.

Figure 1 gives an overview of the workflow with-in and relationships among these three phases. Aclient (a user plus a software agent) starts with aninternal goal that it intends to accomplish via anexternal service request. Correspondingly, serviceproviders have the general goal of providing theservices they were designed to provide — often inexchange for some form of compensation. Dur-ing the three interaction phases, client goals arerepresented in different forms by the semanticdescriptions created to query semantic serviceregistries and in the semantic descriptions ofrequests to potential service providers; serviceprovider goals are explicitly represented in the setof effects produced by those services in publishedservice descriptions.

In the overall service-utilization process, ser-vice requests (messages from clients to prospectiveservices) are part of the engagement stage. Aprovider can simply honor these requests (in whichcase we move directly to the enactment stage) orthese requests can serve as preludes to multistepnegotiations, in which case engagement culmi-nates in a “handshake” that indicates mutualacknowledgement of a joint contract. Interactionsduring the service-enactment stage can use one ofseveral alternative protocols for each subphase:initiating service activity, monitoring serviceprocesses, and confirming service completion. Ifthe service terminates abnormally after a contractis formed, a final set of protocol interactions canaddress compensation issues.

The rest of this article summarizes require-ments for each phase, and its architecture interms of abstract protocols for accomplishingphase-specific requirements. By “abstract proto-cols,” we mean a set of message exchanges char-acterized in terms of abstract semantic conceptsand roles. The protocols also identify the agents’state changes that result from such messages. Anontology represents abstractions of the variousmessage types used in these protocols, in terms ofthe performatives of the Foundation for Intelli-

gent Physical Agents’ communication language(FIPA; www.fipa.org/specs/fipa00037/). FIPA per-formatives represent different speech acts andabstractly identify a sender’s intent (such asINFORM, QUERY, REQUEST, and AGREE). Due tospace limitations, we show only one abstract pro-tocol in detail.

Service DiscoveryService discovery is the process by which a client(service requestor) identifies candidate services toachieve its objectives. It involves three types ofstakeholders:

• service providers indicate that they will performservices,

• service requestors seek services that can accom-plish an internal objective, and

• matchmakers accept descriptions of availableservices from providers and match themagainst requirements from requestors.

Service providers use publish protocols to adver-tise their services with matchmakers; servicerequestors use query protocols to ask the match-makers which services most closely satisfy theirneeds. For today’s Web services, this process ismanual: service client developers, rather thanrequestors, query registries such as UniversalDescription, Discovery, and Integration (UDDI). Incontrast, Semantic Web matchmakers processqueries to find appropriate services from amongthose advertised using Semantic Web languagedescriptions.4

Selecting the abstraction level of the terms in acapability description query to be handed to amatchmaker involves several trade-offs. Typical-ly, a requestor has a specific goal to be achievedat a particular time, whereas service providerspublish generalized descriptions of their capabili-ties that will enable clients to find them. For effec-tive matches to occur, capability queries should bemore abstract than the specific goals of the agentat the moment, but they should include informa-tion about how the goal should be achieved, andunder what constraints, to avoid receiving toomany extraneous candidates. This use of abstractcapability descriptions in matchmaker queries isone of the reasons for the architectural distinctionbetween discovery and negotiation. Discoveryinvolves cached service-capability advertisements,and clients can afford to do more detailed filter-ing of and negotiation with potential providers



during the engagement process, ultimately lead-ing to an agreement between the requestor and avalid provider.

We can divide the requirements for service dis-covery into three parts. Language requirementshelp express capabilities and goals, and theyinclude

• available services’ characteristics and con-straints (preconditions and fulfillment limita-tions),

• protocols to be followed during interactions(message semantics), and

• requestor requirements (goals, quality, securi-ty, and privacy).

Functional requirements specify the tasks eachentity will perform:

• Providers must describe the capabilities andconstraints on offered services.

• Requestors must create abstract characteriza-tions of required services to facilitate matchingwith published capabilities.

• Requestors must locate and interact with peersor matchmakers that can respond to queries foradvertised service descriptions.

• Matchmakers must compare descriptions ofqueries and capabilities.

• Requestors must decide if they can satisfy thepreconditions specified in a prospective ser-vice’s self-description in order to use it.

Finally, architectural requirements identify the var-ious classes of agents necessary to produce thefinal result of the phase: clients that know whatservices with which to negotiate. Discovery phaseprotocols include

• advertising protocols used by service providersto announce capability availability (this adver-tising can be largely passive, such as postingson Web pages), and

• candidate service-discovery protocols used byrequestors looking for services that satisfytheir goals.

Matchmakers, like other kinds of registries, canalso be federated and organized by community oractivity domain.5 Matchmakers that both find andinvoke services as proxies for requestors — calledbrokers — play the role of the client in discovery,engagement, and enactment. As such, they use dif-

ferent protocols for interacting with requestors, notcovered here.

Service Engagement:Negotiation and ContractsService engagement is the initial phase of interac-tion between a requestor and a potential provider.The result of this phase is an agreement betweenrequester and provider such that both partiesexpect, explicitly or implicitly, that a specific ser-vice will be provided by the provider. Although itis during this phase that service contract negotia-tion occurs, negotiation might be necessary duringthe later enactment phase to ensure compliancewith prior agreements or to resolve disputes.

Functional requirements for engagement varywith the interaction’s complexity, but we cannonetheless divide them into four basic areas:

• Service request formulation. The requestor mustbe able to acquire the message and protocolinformation required for composing valid ser-vice requests or participating in service nego-tiation and invocation protocols. It must alsobe able to interpret clarification requests andcounterproposals.

• Contract preliminaries. Potential partners needa means to exchange information aboutrespective goals and capabilities.

• Contract negotiation. Potential partners need ameans for reaching agreement regarding a ser-vice’s provisioning.

• Agreement. All partners need a means for iden-tifying the terms of an agreement and when anagreement is reached.

Architectural requirements for engagement canvary with the complexity of the negotiationsappropriate to the domain, but can include

• Negotiation protocols. Protocols that let partiespropose and accept or reject aspects of a ser-vice agreement must be available in a standardform, and at least one must be appropriate forthe particular domain.

• Negotiation services. One or both parties cancontract with a neutral, stand-alone negotiationexpert (similar to an authentication service).

• Auditing services. Compliance with a negotiatedagreement might require tracking commitmentsand auditing the parties’ enactment activities.

Service-engagement protocols describe the





messages exchanged between providers andrequestors that eventually result in agreements.Three abstract protocols reflect the range ofsophistication among the parties to an agree-ment. The simplest, equivalent to the FIPA query-reply protocol establishes agreement to aservice’s provision without any negotiation orformal contract. It’s the equivalent of saying,“please provide your service for me” and requiresno acknowledgement or agreement from theprovider, which automatically attempts to enactits service. The second protocol, which is equiv-alent to the FIPA request protocol, requires theprovider to agree to or refuse a request andresults in a non-negotiated but explicit commit-ment to provide a service.

The third protocol, negotiate-commitment,establishes a formal negotiated contract for aservice’s provision. This abstract protocol pro-vides a model for the temporal flow and seman-tic underpinnings of negotiations that can occurbetween requestors and providers. Each party isrequired to notify the other if they abandon thenegotiation, and explicit recognition of time-outsensures that no party is left hanging whenanother party misbehaves or communicationfails. The result of a successful negotiation is anexplicit shared acknowledgment of a contract,which can then be modeled as a commitmentbetween the parties, as in this dialog two peoplemight have:

• Requestor: “Will you provide your service forthree dollars?”

• Provider: “Only if you pay ten dollars.”• Requestor: “I will pay five dollars if you pro-

vide your service by 5:00 pm.”• Provider: “OK.” | “No.”

The result of this dialog, if between Web agents,would be an explicit commitment (perhaps cap-tured by a message trace) between the agents bywhich the service provider agrees to provide theservice under the negotiated terms and the clientagrees to any negotiated compenstating actions.

Figure 2 shows the full abstract model, with thecommon subdialog for clarification summarized.Table 1 shows the semantics of the messages used inall the engagement protocols of Figure 2, as well astheir respective FIPA performatives.

Service Process Enactment and ManagementOnce the requestor and the provider agree on theservice to be performed, the service is ready to beinitiated. The requester determines what informa-tion is necessary for requesting the performance ofthe service and how to react when the servicerespons with either success or failure.6,7 Function-al requirements for enactment include

• Response interpretation. The client must be ableto interpret responses to its requests (asdescribed in the service description).

• Response translation. A translation must beproduced when a requestor and provider usedifferent ontologies for communication.

• Choreography interpretation and execution. Asemantically grounded language is necessaryto describe the temporal constraints amongprocess elements, so that the requestor agentcan produce the correct sequence of behaviorsfor the chosen service.

• Process mediation and delegation. To hidechoreography differences when interactingclients and services use fixed, incompatibleprotocols, agents can use process mediation

Table 1. Engagement message semantics.

Message type Performative From To CommentRequestService Request Client Server Message content describes desired service, identifies requestor,

provides authorization, and conveys nonfunctional preferences and conditions

AcceptRequest Agree Server Client Acknowledges receipt of request and intention to perform the serviceCancelRequest Cancel Client Server Informs that the client no longer needs the server to perform the

requested serviceOfferService Inform Server Client Provides clients with a service description (typically used to make a

counteroffer)AcceptOffer Inform Client Server Informs server that client agrees to perform the offered serviceRefuseOffer Inform Client Server Informs server that client doesn’t agree to the offered service

services.• Dynamic service composition. Requestors need

support, not only to invoke dynamically dis-covered services but also to compose themwhen no single service meets their needs. Acomposition can use automated planning tech-niques to invoke a collection of services for ajoint purpose.6,8

• Process-status monitoring and event notifica-tion. Tracking an execution’s state can help arequestor determine when and whether it willcomplete.

• Service-failure handling and compensation.Services must provide declarative descriptionsof their failure modes and associated means ofrecovery as well as their types of (and proto-cols for) compensation.

• Dispute resolution and compliance. Clients andservice providers can invoke third-party servicesfor conflict resolution, proof of verification,claim adjudication, and settlement compliance.

• Nonrepudiation, audit tracking, and explana-tion. All parties must be confident that a trans-action is secure, that all parties are authentic,



Figure 2. Negotiate-commitment protocol.The left and right graphs show the state transitions of the requestor andprovider, respectively. Conditions on transitions are in square brackets.The CLARIFY state in both diagrams represents asubdialog, not shown.

Precondition: the requestor has selected a candidate service provider,based on a prior discovery and selection process/protocol.

Input: the identity of the candidate service provider and the requirements of the requestor.

NotationR - a request for a service including QoS requirements and requestor IDR' - a revised request or refusal leading to a new offerO' an offer of a service, including QoS guaranteesCLARIFY* - indicates a possible CLARIFY and/or AUTHORIZATION sub-dialog

Provider

Output: an agreement about the service to be enacted and the identity of the provider.The agreement includes the negotiated QoS

[Receive (R)]

Wait

Evaluate request

[Receive (agree)]

[Receive (R')]

[Receive (cancel)]

[Unacceptable]/Send(Refuse)

Evaluate request

ENACTMENT

Wait for response

[Negotiable? /Send(Offer)

[Timeout]/Send(Cancel)

[Acceptable & reply read] /Send(Agree)

Requestor

[Receive (Offer)}

[Init]/Send(R)

[Negotiable?]/Send (R)

Wait for response

Evaluate request

[No reply required]

[Receive(Refuse)]

[Timeout]/Send)cancel)

[Receive(Agree)

ENACTMENT

Wait for agreement

[Acceptable]/Send(Agree)

[Unacceptable]/Send(Cancel)

[Timeout]/Send(Cancel)

CLARIFY*

CLARIFY*

and that the transaction is verified as final.Systems must ensure that a party can’t reject atransaction after this point.

Architectural requirements arise when middleagents provide support services. We will requirestandardized protocols and standard ontologiesfor interacting with these agents, which couldinclude

• process-mediation services between agents forwhom semantically compatible interactions arepossible, but whose choreographies don’t align(in terms of the number and types of messagesto be exchanged);

• process-scheduling and composition services,which require ontologies for describing tempo-ral and domain constraints, objectives, andpreferences;

• process-execution and status-logging servicesto support execution monitoring, failure recov-ery, and compensation processes; and

• policy-monitoring services to ensure thatinvoked services follow contractually guaran-teed QoS agreements.

In our framework, we’ve developed abstractenactment protocols for three types of enactmentinteraction. One of our three enactment protocolsassumes synchronous communication, in which arequestor sends a message and then waits for areturn message. The other two assume asynchro-nous communication, in which a requestor sendsa message to the provider, but doesn’t expect asynchronous message return.

Each scenario has the same preconditions —namely, the discovery and engagement processeslead to an explicit or implicit service contract. Aservice requestor initiates the enactment phase bysending an invocation message or by simply com-pleting the engagement phase (when the partiesdon’t explicitly acknowledge service agreement;see www.swsi.org/swsa for more information onthese protocols).

Community Support ServicesAnother class of infrastructural services will beneeded to support communally maintainedSemantic Web service activities. In turn, these ser-vices will support requirements, such as

• ontology lookup, mapping, and version controlservices for communities that create shared,

centrally managed ontologies and thereforeneed mechanisms to provide authenticated def-initions and mappings among concepts andtheir derivatives;9

• information and access security, privacy, andconfidentiality management and monitoring,support for those ubiquitous concerns of com-mercial and public-access Web services;

• group membership and trust reasoning servicesthat extend simple ID-based authentication, toenable policy and relationship-based access byautomated reasoning about known trust rela-tionships between parties;

• community-based preference and reliabilityreporting services based on collected feedbackfrom service clients;

• policy and protocol management services, likeontology management services, to providecommunities with authenticated semanticdescriptions of shared policies and protocols,as well as validation and dispute resolution ser-vices; and

• lifecycle management services to control thespawning (factories) and management (moni-toring and allocation) of service resources.

These requirements and service categories werederived from scenarios using semantically rich ser-vice agents, and are not necessarily core parts of thearchitecture for all environments. However, whenpresent, they play roles in the effective utilizationof other services, and thus they can impact the com-plexity of the protocols used in conjunction withthose domain services. These interactions are topicsfor future investigation by the committee.

Quality of ServiceIn Semantic Web service applications, suppliersand customers define binding agreements or con-tracts among themselves in part by specifyingQoS-level agreements, using metrics such as dead-lines, accuracy, and cost.10,11 QoS metrics can affecthow services are advertised, can be the topic ofnegotiation process, and must be monitored dur-ing enactment; thus, when clients’ procedures orworkflows involve multiple services, the underly-ing discovery, coordination, and execution systemsmust be able to monitor QoS measures and controlthe services accordingly. In complex workflows,these monitors must reason about aggregate mea-sures over the life of the workflow. Enforcement ofthese metrics can require complex resource rea-soning, prioritization, and service resource reallo-





cation. These topics are currently being studied,thus weren’t addressed in detail by the committee.

Rather than specific software components, ourarchitectural framework is based on abstract

characterizations of protocols and functionaldescriptions of capabilities. Our objective is todefine an interoperability model that can under-pin a variety of architectures without prescribingspecific implementation decisions. If service devel-opers build concrete components consistent withour proposed abstract protocols, then SemanticWeb service clients will be able to interpret pub-lished descriptions of these components in termsof the abstract message ontologies and protocolswe’ve developed. This sharing of abstract models,rather than syntactic and procedural agreementsamong developers, could give developers maximalfreedom in building components that can adap-tively interoperate.

Our belief is that this approach is consistentwith the long-term vision of the Semantic Web atthe W3C; we anticipate that our architecture willindicate requirements for Semantic Web servicedescription languages, which are being designedby our sister committee, the Semantic Web Ser-vices Initiative Language committee (www.swsi.org/swsl/).

AcknowledgmentsWe also thank the other members of the committee, past and

present, and its organizers, who contributed to the ideas pre-

sented here: Bob Balzer (Tecknowledge), Fabio Casati (HP Labs,

UK), Mike Dean (BBN Technologies), Andreas Eberhart (AIFB,

University of Karlsruhe), Dieter Fensel (DERI, Insbruck), Carole

Goble (University of Manchester), Mark Greaves (DARPA),

Frank McCabe (Fujitsu Laboratories, Sunnyvale, California),

Enrico Motta (Open University, UK), Juan Miguel (DERI, Inns-

bruck, Austria), Chris Priest (HP Labs, UK), Norman Sadeh

(CMU), Katia Sycara (CMU), Michael Uschold (Boeing), and

Kunal Verma (LSDIS Lab, University of Georgia).

References

1. T. Berners-Lee, J. Hendler, and O. Lassila, “The Semantic

Web,” Scientific Am., vol. 284, no. 5, 2001, pp. 34–43.

2. D. Martin et al., “Bringing Semantics to Web Services: The

OWL-S Approach,” Proc. 1st Int’l Workshop Semantic Web

Services and Web Process Composition (SWSWPC 04),

2004; http://www-2.cs.cmu.edu/~softagents/papers/OWL

-S-SWSWPC2004-final.pdf.

3. I. Foster et al., The Physiology of the Grid: An Open Grid

Services Architecture for Distributed Systems Integration,

tech. report, Open Grid Service Infrastructure Working

Group, Global Grid Forum, June 2002; www.globus.org/

alliance/publications/papers/ogsa.pdf.

4. K. Sycara et al., “Dynamic Service Matchmaking among

Agents in Open Information Environments,” J. ACM SIG-

MOD Record, Special Issue on Semantic Interoperability in

Global Information Systems, vol. 28, no. 1, 1999, pp. 47–53;

http://www-2.cs.cmu.edu/~softagents/papers/ACM99-L.ps.

5. K. Sivashanmugam, K. Verma, and A. Sheth, “Discovery of

Web Services in a Federated Registry Environment,” Proc.

IEEE Int’l Conf. Web Services, IEEE CS Press, 2004;

http://lsdis.cs.uga.edu/lib/download/MWSDI-ICWS04-

final.pdf.

6. D. McDermott, M. Burstein, and D. Smith, “Overcoming

Ontology Mismatches in Transactions with Self-Describing

Agents,” The Emerging Semantic Web: Selected Papers

from the First Semantic Web Working Symp., IOS Press,

Amsterdam, 2002, pp. 228–244.

7. A. Eberhart, “Ad-Hoc Invocation of Semantic Web Services,”

Proc. IEEE Int’l Conf. Web Services, IEEE CS Press, 2004;

www.aifb.uni-karlsruhe.de/WBS/aeb/pubs/icws2004.pdf.

8. S. Narayanan and S. McIlraith, “Simulation, Verification

and Automated Composition of Web Services,” Proc. 11th

Int’l World Wide Web Conf. (WWW-11), 2002;

www.daml.org/

services/owl-s/pub-archive/nar-mci-www11.ps.

9. M.H. Burstein, “Dynamic Invocation of Semantic Web Ser-

vices that Use Unfamiliar Ontologies,” IEEE Intelligent Sys-

tems, vol. 19, no. 4, 2004, pp. 67–73.

10. J. Cardoso et al., “Quality of Service for Workflows and

Web Service Processes,” J. Web Semantics, 2004; http://

lsdis.cs.uga.edu/lib/download/CSM+QoS-WebSemantics.pdf.

11. L. Zeng et al., “Quality Driven Web Services Composition,”

Proc. 2003 WWW Conf., 2003, pp. 411–421; http://sky.fit.

qut.edu.au/~dumas/www03.pdf.

Mark Burstein is a division scientist and director of the Human

Centered Computing Group at BBN Technologies, and

cochair of the Semantic Web Service Initiative’s Architec-

ture committee. His research interests include semantic

translation and planning system support for Semantic Web

services, mixed-initiative distributed systems, knowledge

representation, and machine learning. Burstein has a PhD

Further Reading

For the full SWSA report, visit www.swsi.org/swsa/. For additional infor-mation on related approaches, visit these links:

• W3C Web Services Architecture WG: www.w3.org/TR/ws-arch/• OWL-S: www.daml.org/services/owl-s/• WSMO: www.wsmo.org• METEOR-S: http://lsdis.cs.uga.edu/projects/meteor-s/

in artificial intelligence and computer science from Yale

University. He is a member of IEEE and AAAI. Contact him

at [email protected].

Christoph Bussler is executive director of the Digital Enterprise

Research Institute in Galway, Ireland, and cochair of the

Semantic Web Services Initiative’s Architecture committee.

His research interests include Semantic Web services, busi-

ness-to-business integration, and workflow management.

Bussler has a PhD in computer science from the University

of Erlangen, Germany. He is a member of the ACM and the

IEEE Computer Society. Contact him at [email protected].

Tim Finin is a professor of computer science and electrical engi-

neering at the University of Maryland, Baltimore County.

His research interests include applications of artificial intel-

ligence to problems in information systems and intelligent

interfaces; software agents; the Semantic Web; and mobile

computing. Finin has a PhD in computer science from the

University of Illinois. He is a member of AAAI and the

ACM. Contact him at [email protected].

Michael N. Huhns is the NCR professor of computer science and

engineering at the University of South Carolina, where he

also directs the Center for Information Technology. He

recently wrote Service-Oriented Computing: Semantics,

Processes, Agents (John Wiley & Sons, 2005). Contact him

at [email protected].

Massimo Paolucci is a senior researcher at DoCoMo NTT in

Munich, Germany. His research interests include automat-

ic Web service composition and discovery and the applica-

tion of Semantic Web service technology to mobile and

ubiquitous computing. Paolucci is also a member of the

OWL-S coalition, and a former member of the UDDI Tech-

nical Committee.

Amit P. Sheth is a professor of computer science at the Univer-

sity of Georgia, the director of the Large-Scale Distributed

Systems Lab, and CTO/cofounder of Semagix. He also start-

ed the WSDL-S initiative for semantic annotation of Web

services. His research interests include the Semantic Web,

Semantic Web services, and semantic applications in bioin-

formatics, healthcare, and risk and compliance. Sheth has

a PhD in distributed databases from Ohio State University.

He is a senior member of the IEEE and a member of the

ACM. Contact him via http://lsdis.cs.uga.edu/~amit.

Stuart Williams is a group manager at HP Laboratories in Bris-

tol, UK, and an elected member of the W3C Technical Archi-

tecture Group, which is working to document the Web’s

architecture. His research interests include protocol design

and the application of the Semantic Web for solving inter-

operability problems between networked software compo-

nents, such as Web services. Stuart has a PhD from the Uni-

versity of Bath. Contact him at [email protected].

Michal Zaremba is a postdoctoral researcher at National Uni-

versity of Ireland. His research interests include Semantic

Web services and its architectures, eBusiness, enterprise

application integration, B2B integration, and business

process management. Zaremba has a PhD in industrial

engineering from the National University of Ireland and an

MSc in computer science and management from the Wro-

claw University of Technology in Poland. He is a member

of OASIS, W3C, and the ACM. Contact him at michal.

[email protected].



a semantic web services architecture

Documents