a semantic web services architecture
TRANSCRIPT
University of South CarolinaScholar Commons
Faculty Publications Computer Science and Engineering, Department of
1-1-2005
A Semantic Web Services ArchitectureMark Burstein
Christoph Bussler
Michal Zaremba
Tim Finn
Michael N. HuhnsUniversity of South Carolina - Columbia, [email protected]
See next page for additional authors
Follow this and additional works at: http://scholarcommons.sc.edu/csce_facpubPart of the Computer Engineering Commons
This Article is brought to you for free and open access by the Computer Science and Engineering, Department of at Scholar Commons. It has beenaccepted for inclusion in Faculty Publications by an authorized administrator of Scholar Commons. For more information, please [email protected].
Publication InfoPublished in IEEE Internet Computing, ed. Michael N. Huhns and Munindar P. Singh, Volume 9, Issue 5, 2005, pages 72-81.http://ieeexplore.ieee.org/servlet/opac?punumber=4236© 2005 by the Institute of Electrical and Electronics Engineers (IEEE)
Author(s)Mark Burstein, Christoph Bussler, Michal Zaremba, Tim Finn, Michael N. Huhns, Massimo Paolucci, Amit P.Sheth, and Stuart Williams
This article is available at Scholar Commons: http://scholarcommons.sc.edu/csce_facpub/34
Mark BursteinBBN Technologies
Christoph Bussler and Michal ZarembaDigital Enterprise Research Institute
Tim FininUniversity of Maryland,Baltimore County
Michael N. HuhnsUniversity of South Carolina
Massimo PaolucciDoCoMo CommunicationsLaboratories Europe GmbH
Amit P. 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 that serve 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 Architec-ture (SWSA) committee’s mission is
to develop the necessary abstractions foran architecture that supports SemanticWeb services. The resultant frameworkbuilds on the W3C Web Services Archi-tecture working group report (and ismotivated in part by Tim Berners-Lee’svision for the Semantic Web1). Othergroups developing Semantic Web servicesframeworks contributed to the discus-sions, including the Web Ontology Lan-guage for Services (OWL-S) consortium,the Web Service Modeling Ontology(WSMO; www.wsmo.org) group at theDigital Enterprise Research Institute(DERI), and the Managing End-to-EndOperations-Semantics (METEOR-S; http://lsdis.cs.uga.edu/projects/meteor-s/) groupat the University of Georgia.2,3
In this article, we describe the proto-cols exchanged between the interactingentities or agents that interpret and rea-son with semantic descriptions in the
deployment of Semantic Web services.We focus specifically on those capabili-ties that extend the potential range ofWeb services; we also discuss security,reliability, and a flexible means of recov-ery from the problems that can occur inopen and evolving environments. TheSWSA architectural framework attemptsto address five classes of Semantic Webagent requirements — dynamic servicediscovery, service engagement, serviceprocess enactment and management,community support services, and qualityof service (QoS) — which we cover indetail here 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 from
72 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 N. Huhns • huhns@sc .eduMunindar P. Singh • s ingh@ncsu .edu
sites that are discovered dynamically, traditionalWeb services are designed to function more likedistributed object-oriented computing systems. Incontrast, 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-busi-ness and business-to-consumer applications, gridcomputing, ubiquitous computing, and informa-tion management. For commercial Web services, itwill be increasingly important for service providersto be able to adapt their interfaces to support newproducts and service options without interruptingor requiring changes to the software that clientsuse to access those services. Likewise, clients thatwish to comparison shop or use alternate serviceswhen the ones they traditionally use are unavail-able will need to adapt flexibly to the differencesbetween the interfaces those alternative servicespresent. Similar issues arise with grid computingservices, in which computational resources areoften oversubscribed and different sites that canperform the same functions often have differentinteraction requirements.
These environments often have two barriers tointeroperability: incompatible information modelsand mismatches in different service providers’interaction protocols. Dynamically accessiblesemantic descriptions of service capabilities andutilization protocols, based on shared semanticmodels published on the Semantic Web, are seenas a way to overcome these barriers, but they willrequire additional infrastructure so that individualsoftware agents can directly interpret publishedservice descriptions (which sometimes use unfa-miliar ontologies). Given the open-ended nature ofWeb-oriented distributed environments, this archi-tecture must also handle semantically interpretablesecurity authorizations and ensure the privacy oftransmitted information.
Some aspects of our proposed architecture willbe more central to particular applications than oth-ers, and some will take longer to be widely adopt-ed. Our near-term emphasis is on semantics foruser-directed service interactions: users specifywhat they want from a service, rather than thedetails of how to ask for it. For this family of uses,a service client will need to avoid hard-codedknowledge of the syntax for interacting with par-ticular providers, instead using information frompublished semantic service descriptions to mediate
interactions with classes of functionally similarproviders, even when their detailed interfaces dif-fer. These software clients must translate userrequests into suitable forms for each potentialprovider, and then use the interaction methodsspecified by those providers by reasoning from themethods’ published semantic descriptions.
As the technology matures, we anticipate thatmethods now being explored will support morewidespread use of mechanisms for automatedservice discovery and matchmaking. A key ele-ment of this phase will be the development ofshared, extensible, community-wide ontologiesfor describing capabilities, services, and goods,and — equally critically — for making theseontologies publicly accessible for use by Webapplications. Open-source ontologies for differ-ent kinds of services and products will enablebroad-based, automated, service discovery in thesame way search engines now make it easy todiscover new Web sites.
Underlying AssumptionsOur architectural framework builds on twoemerging technological concepts: Web servicesand the Semantic Web. Web service providers canpublish descriptions of service interfaces on theWeb using the XML-based Web Services Descrip-tion Language (WSDL). These descriptions includeinformation about the message forms used toinvoke the services, which can be serialized usingHTTP and SOAP protocols, among others. WSDLdoes not, however, have a systematic way toassociate meanings with the messages and mes-sage arguments that appear in those descriptions.The Semantic Web vision takes Web-publishingof descriptions to the next level by introducingsemantic description languages built on XML,which lets people publish and share ontologies —set of conceptual terms labeled by URLs — thatcan be used in describing other published mate-rials. Semantic Web services are Web services inwhich semantic Web ontologies ascribe meaningsto published service descriptions so that softwaresystems representing prospective service clientscan 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 73
A Semantic Web Services Architecture
• All agents can access and interpret Web-published 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 theservice-provision terms in an explicit or implic-it service contract. Negotiations can includeservice price, product attributes, and the qual-ity and timeliness of service, security and pri-vacy, and so on.
• Service enactment is the process that completesthe mutually agreed upon objectives of client
74 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
and service by following the service’s publishedprotocols. If the contract’s primary objectivesaren’t accomplished, then the client and servicecan use a compensation protocol to restorefinancial equity or a stable operating state. Ifthe underlying message transport mechanismsallow for asynchronous interactions, thenclients can use protocols to monitor the serviceprocess’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 mutualacknowledgment 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 advertisetheir services with matchmakers; service requestorsuse query protocols to ask the matchmakers whichservices most closely satisfy their needs. For today’sWeb services, this process is manual: service clientdevelopers, rather than requestors, query registriessuch as Universal Description, Discovery, and Inte-gration (UDDI). In contrast, Semantic Web match-makers process queries to find appropriate servicesfrom among those advertised using Semantic Weblanguage descriptions.4
Selecting the abstraction level of the terms in acapability description query to be handed to amatchmaker involves several trade-offs. Typically,a requestor has a specific goal to be achieved at aparticular time, whereas service providers publishgeneralized descriptions of their capabilities thatwill enable clients to find them. For effective match-es to occur, capability queries should be moreabstract than the specific goals of the agent at themoment, but they should include information abouthow the goal should be achieved, and under whatconstraints, to avoid receiving too many extrane-ous candidates. This use of abstract capabilitydescriptions in matchmaker queries is one of thereasons for the architectural distinction between dis-covery and negotiation. Discovery involves cachedservice-capability advertisements, and clients canafford to do more detailed filtering of and negotia-tion with potential providers during the engagementprocess, ultimately leading to an agreement between
IEEE INTERNET COMPUTING www.computer.org/internet/ SEPTEMBER • OCTOBER 2005 75
A Semantic Web Services Architecture
the requestor and a valid 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 domains.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 inter-action between a requestor and a potentialprovider. The result of this phase is an agreementbetween requester and provider such that bothparties expect, explicitly or implicitly, that a spe-cific service will be provided by the provider.Although it is during this phase that service con-tract negotiation occurs, negotiation might benecessary during the later enactment phase toensure compliance with prior agreements or toresolve 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 themessages exchanged between providers andrequestors that eventually result in agreements.
76 SEPTEMBER • OCTOBER 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING
Service-Oriented Computing Track
IEEE INTERNET COMPUTING www.computer.org/internet/ SEPTEMBER • OCTOBER 2005 77
A Semantic Web Services Architecture
Three abstract protocols reflect the range ofsophistication among the parties to an agreement.The simplest, equivalent to the FIPA query-replyprotocol, establishes agreement to a service’s pro-vision without any negotiation or formal contract.It’s the equivalent of saying, “please provide yourservice for me” and requires no acknowledgmentor agreement from the provider, which automati-cally attempts to enact its service. The second pro-tocol, which is equivalent to the FIPA requestprotocol, requires the provider to agree to or refusea request and results in a non-negotiated butexplicit commitment to provide a service.
The third protocol, negotiate-commitment,establishes a formal negotiated contract for a ser-vice’s provision. This abstract protocol provides amodel for the temporal flow and semantic under-pinnings of negotiations that can occur betweenrequestors and providers. Each party is required tonotify the other if they abandon the negotiation,and explicit recognition of time-outs ensures thatno party is left hanging when another party mis-behaves or communication fails. The result of asuccessful negotiation is an explicit sharedacknowledgment of a contract, which can then bemodeled as a commitment between the parties, asin this dialogue two people might have:
• Requestor: “Will you provide your service forthree dollars?”
• Provider: “Only if you pay 10 dollars.”• Requestor: “I will pay five dollars if you pro-
vide your service by 5:00 pm.”• Provider: “OK.” | “No.”
The result of this dialogue, if between Web agents,would be an explicit commitment (perhaps cap-tured by a message trace) between the agents by
which the service provider agrees to provide theservice under the negotiated terms and the clientagrees to any negotiated compenstating actions.
Figure 2 (next page) shows the full abstractmodel, with the common subdialogue for clarifi-cation summarized. Table 1 shows the semanticsof the messages used in all the engagement pro-tocols of Figure 2, as well as their respective FIPAperformatives.
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 serviceresponds with either success or failure.6,7 Func-tional 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 hide chore-ography differences when interacting clients andservices use fixed, incompatible protocols,agents can use process mediation services.
• Dynamic service composition. Requestors needsupport, not only to invoke dynamically dis-
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
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 of
recovery 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,and that the transaction is verified as final.Systems must ensure that a party can’t reject atransaction after this point.
78 SEPTEMBER • OCTOBER 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING
Service-Oriented Computing Track
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 requestor’s requirements.
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 provider's identity.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*
Architectural requirements arise when middleagents provide support services. We will requirestandardized protocols and standard ontologies forinteracting with these agents, which could include
• 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 in 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 the service agree-ment; see www.swsi.org/swsa for more informa-tion on these 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, and
confidentiality 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 provide com-munities with authenticated semantic descrip-tions of shared policies and protocols, as well asvalidation and dispute resolution services; 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 use of otherservices, and thus they can impact the complexityof the protocols used in conjunction with thosedomain services. These interactions are topics forfuture 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 processes, 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
IEEE INTERNET COMPUTING www.computer.org/internet/ SEPTEMBER • OCTOBER 2005 79
A Semantic Web Services Architecture
80 SEPTEMBER • OCTOBER 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING
Service-Oriented Computing Track
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 consistent withthe long-term vision of the Semantic Web at theW3C; we anticipate that our architecture will indi-cate requirements for Semantic Web service descrip-tion languages, which are being designed by oursister committee, the Semantic Web Services Initia-tive Language committee (www.swsi.org/swsl/).
AcknowledgmentsWe thank the other members of the committee, past and pre-
sent, and its organizers, who contributed to the ideas present-
ed here: Bob Balzer (Tecknowledge), Fabio Casati (HP Labs, UK),
Mike Dean (BBN Technologies), Andreas Eberhart (AIFB, Uni-
versity 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
in artificial intelligence and computer science from Yale
University. He is a member of the 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 commit-
tee. His research interests include Semantic Web services,
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/
business-to-business integration, and workflow manage-
ment. Bussler has a PhD in computer science from the Uni-
versity of Erlangen, Germany. He is a member of the ACM
and the IEEE Computer Society. Contact him at chbus-
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
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 and cofounder of Semagix. He also
started the WSDL-S initiative for semantic annotation of
Web services. His research interests include the Semantic
Web, Semantic Web services, and semantic applications in
bioinformatics, healthcare, and risk and compliance. Sheth
has a PhD in distributed databases from Ohio State Uni-
versity. 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
University of Bath. Contact him at [email protected].
Michal Zaremba is a postdoctoral researcher at National Univer-
sity of Ireland. His research interests include Semantic Web
services and its architectures, e-business, enterprise applica-
tion integration, B2B integration, and business process man-
agement. Zaremba has a PhD in industrial engineering from
the National University of Ireland and an MSc in computer
science and management from the Wroclaw University of
Technology in Poland. He is a member of OASIS, W3C, and
the ACM. Contact him at [email protected].
IEEE INTERNET COMPUTING www.computer.org/internet/ SEPTEMBER • OCTOBER 2005 81
A Semantic Web Services Architecture