You are on page 1of 11

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/3419769

A Semantic Web Services Architecture

Article  in  IEEE Internet Computing · October 2005


DOI: 10.1109/MIC.2005.96 · Source: IEEE Xplore

CITATIONS READS

215 111

8 authors, including:

Mark H. Burstein Christoph Bussler


Smart Information Flow Technologies Oracle Corporation, Redwood Shores, CA, USA
90 PUBLICATIONS   5,204 CITATIONS    186 PUBLICATIONS   5,546 CITATIONS   

SEE PROFILE SEE PROFILE

Tim Finin Michael N Huhns


University of Maryland, Baltimore County University of South Carolina
508 PUBLICATIONS   22,847 CITATIONS    319 PUBLICATIONS   5,989 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

1R01 DA039454, Daniulaityte & Sheth (MPI), TRENDING: SOCIAL MEDIA ANALYSIS TO MONITOR CANNABIS AND SYNTHETIC CANNABINOID USE View project

Ontology repositories View project

All content following this page was uploaded by Michael N Huhns on 30 August 2013.

The user has requested enhancement of the downloaded file.


Service-Oriented Computing Track
Editors: Michael Huhns • huhns@sc .edu
Munindar P. Singh • singh@ncsu.edu

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.

F
Mark Burstein ormed in February 2003, the Seman- of Semantic Web services. We focus specif-
BBN Technologies tic Web Services Initiative Architecture ically on those capabilities that extend the
(SWSA) committee’s mission is to potential range of Web services; we also
Christoph Bussler develop the necessary abstractions for an discuss security, reliability, and a flexible
and Michal Zaremba architecture that supports Semantic Web means of recovery from the problems that
Digital Enterprise Research Institute services. The resultant framework builds can occur in open and evolving environ-
on the W3C Web Services Architecture ments. The SWSA architectural framework
Tim Finin working group report (and is motivated in attempts to address five classes of Seman-
University of Maryland, Baltimore part by Tim Berners-Lee’s vision for the tic Web agent requirements — dynamic
County Semantic Web1). Other groups developing service discovery, service engagement, ser-
Semantic Web services frameworks con- vice process enactment and management,
Michael Huhns tributed to the discussions, including the community support services, and quality
University of South Carolina Web Ontology Language for Services of service (QoS) — which we cover in detail
(OWL-S) consortium, the Web Service here as well.
Massimo Paolucci Modeling Ontology (WSMO; www.wsmo.
DoCoMo Communications org) group at the Digital Enterprise Multiple Distributed
Laboratories Europe GmbH Research Institute (DERI), and the Manag- Environments
ing End-to-End Operations-Semantics Systems developed via Web service tech-
Amit Sheth (METEOR-S; http://lsdis.cs.uga.edu/pro- nologies are often limited by their need to
University of Georgia jects/meteor-s/) group at the University of agree in advance on the syntax and
Georgia.2,3 semantics of various communications.
Stuart Williams In this article, we describe the protocols Whereas the World Wide Web is success-
Hewlett-Packard Laboratories exchanged between the interacting entities ful in part because it makes it easy to
or agents that interpret and reason with interact with and gather information from
semantic descriptions in the deployment sites 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
A Semantic Web Services Architecture

ditional Web services are designed to function more to mediate interactions with classes of function-
like distributed object-oriented computing systems. ally similar providers, even when their detailed
In contrast, semantically transparent services will interfaces differ. These software clients must
make it possible for clients to successfully use ser- translate user requests into suitable forms for
vices that are dynamically discovered without prior each potential provider, and then use the interac-
negotiations between client and service developers. tion methods specified by those providers by rea-
Such goals are important for commercial Web soning from the published semantic descriptions
service environments, including business-to- of those methods.
business and business-to-consumer applications, As the technology matures, we anticipate that
grid computing, ubiquitous computing, and methods now being explored will support more
information management. For commercial Web widespread use of mechanisms for automated ser-
services, it will be increasingly important for ser- vice discovery and matchmaking. A key element of
vice providers to be able to adapt their interfaces this phase will be the development of shared,
in order to support new products and service extensible, community-wide ontologies for describ-
options without interrupting or requiring ing capabilities, services, and goods, and — equal-
changes to the software that clients use to access ly critically — for making these ontologies publicly
those services. Likewise, clients that wish to com- accessible for use by Web applications. Open-
parison shop or use alternate services when the source ontologies for different kinds of services and
ones they traditionally use are unavailable will products will enable broad-based, automated, ser-
need to adapt flexibly to the differences between vice discovery in the same way search engines now
the interfaces those alternative services present. make it easy to discover new Web sites.
Similar issues arise with grid computing services,
in which computational resources are often over- Underlying Assumptions
subscribed and different sites that can perform Our architectural framework builds on two emerg-
the same functions often have different interac- ing technological concepts: Web services and the
tion requirements. Semantic Web. Web service providers can publish
These environments often have two barriers to descriptions of service interfaces on the Web using
interoperability: incompatible information models the XML-based Web Services Description Lan-
and mismatches in different service providers’ inter- guage (WSDL). These descriptions include infor-
action protocols. Dynamically accessible semantic mation about the message forms used to invoke
descriptions of service capabilities and utilization the services, which can be serialized using HTTP
protocols, based on shared semantic models pub- and SOAP protocols, among others. WSDL does
lished on the Semantic Web, are seen as a way to not, however, have a systematic way to associate
overcome these barriers, but they will require addi- meanings with the messages and message argu-
tional infrastructure so that individual software ments that appear in those descriptions. The
agents can directly interpret published service Semantic Web vision takes Web-publishing of
descriptions (which sometimes use unfamiliar descriptions to the next level by introducing
ontologies). Given the open-ended nature of Web- semantic description languages built on XML,
oriented distributed environments, this architecture which enables people to publish and share ontolo-
must also handle semantically interpretable securi- gies — set of conceptual terms labeled by URLs —
ty authorizations and ensure the privacy of trans- that can be used in describing other published
mitted information. materials. Semantic Web services are Web services
Some aspects of our proposed architecture will in which semantic Web ontologies ascribe mean-
be more central to particular applications than ings to published service descriptions so that soft-
others, and some will take longer to be widely ware systems representing prospective service
adopted. Our near-term emphasis is on semantics clients can interpret and invoke them.
for user-directed service interactions: users spec- This is a good time to talk about how clients
ify what they want from a service, rather than the and services can act as software agents with goals.
details of how to ask for it. For this family of In the discussions that follow, we assume the fol-
uses, a service client will need to avoid hard- lowing general capabilities of agents in Semantic
coded knowledge of the syntax for interacting Web service environments (in this context,
with particular providers, instead using informa- “agents” include requesters [clients], service
tion from published semantic service descriptions providers, and middle agents).

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


Service-Oriented Computing Track

Service
Client's provider's
Published
internal goal internal goal
advertisement and
service model
Client goal
description reformulation Client Service
achievement process provision process

Candidate Candidate Service selection Selected service Service


service discovery services and engagement provider and enactment
agreement

Interactions Monitoring
with service and execution
registries of service
Abstract Service Termination
Negotiation with Service Service
characterizations of discovery and
candidate services, initiation monitoring
candidate service query protocol compensation
commitment to
service agreement

Characterization Service contract Service


of desired service negotiation agreement
as a request

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

• All agents can access and interpret Web-pub- Phases of Semantic


lished ontologies, and can communicate Web Service Interaction
using messages whose content is represented, The overall process of discovering and interacting
or can be interpreted, in terms of published with a Semantic Web service will, in general,
ontologies. include three phases:
• Service providers publish semantic descriptions
of their service capabilities and interaction pro- • Candidate service discovery is the distributed
tocols, which prospective consumers can then search for available services that can (poten-
interpret when selecting appropriate services tially) accomplish some set of a client’s inter-
and when formulating their interactions with nal goals or objectives. One architectural
those services. approach to this phase is interaction with a
• Requestor agents wishing to delegate internal semantic matchmaker, a registry agent, or a
objectives to external agents can reformulate peer agent serving either function.
those objectives as well-formed requests to ser- • Service engagement includes the process of
vice providers by using those providers’ seman- interpreting candidate Web service enactment
tically described service interfaces as guides. constraints (partly or fully described in each
service’s published self-description), and then
For dynamic Web services to function, clients must negotiating with prospective services until
be able to interpret the published semantic descrip- reaching an agreement. This phase concludes
tions of unfamiliar services to help them decide when both service and client agree to the ser-
which services to use and how to interact with vice-provision terms in an explicit or implicit
them. As a result of this style of interaction, clients service contract. Negotiations can include ser-
will be able to adjust smoothly as service interfaces vice price, product attributes, and the quality
evolve. Such interaction also lets clients discover and timeliness of service, security and privacy,
and substitute new services for ones that are no and so on.
longer available, even if those new services use • Service enactment is the process that finally
different protocols or message types. completes the mutually agreed objectives of

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


A Semantic Web Services Architecture

client and service, by following the service’s gent Physical Agents’ communication language
published protocols. If the contract’s primary (FIPA; www.fipa.org/specs/fipa00037/). FIPA per-
objectives aren’t accomplished, then the client formatives represent different speech acts and
and service can use a compensation protocol to abstractly identify a sender’s intent (such as
restore financial equity or a stable operating INFORM, QUERY, REQUEST, and AGREE). Due to
state. If the underlying message transport space limitations, we show only one abstract pro-
mechanisms allow for asynchronous interac- tocol in detail.
tions, then clients can use protocols to monitor
the service process’s status during execution. Service Discovery
Service discovery is the process by which a client
Figure 1 gives an overview of the workflow with- (service requestor) identifies candidate services to
in and relationships among these three phases. A achieve its objectives. It involves three types of
client (a user plus a software agent) starts with an stakeholders:
internal goal that it intends to accomplish via an
external service request. Correspondingly, service • service providers indicate that they will perform
providers have the general goal of providing the services,
services they were designed to provide — often in • service requestors seek services that can accom-
exchange for some form of compensation. Dur- plish an internal objective, and
ing the three interaction phases, client goals are • matchmakers accept descriptions of available
represented in different forms by the semantic services from providers and match them
descriptions created to query semantic service against requirements from requestors.
registries and in the semantic descriptions of
requests to potential service providers; service Service providers use publish protocols to adver-
provider goals are explicitly represented in the set tise their services with matchmakers; service
of effects produced by those services in published requestors use query protocols to ask the match-
service descriptions. makers which services most closely satisfy their
In the overall service-utilization process, ser- needs. For today’s Web services, this process is
vice requests (messages from clients to prospective manual: service client developers, rather than
services) are part of the engagement stage. A requestors, query registries such as Universal
provider can simply honor these requests (in which Description, Discovery, and Integration (UDDI). In
case we move directly to the enactment stage) or contrast, Semantic Web matchmakers process
these requests can serve as preludes to multistep queries to find appropriate services from among
negotiations, in which case engagement culmi- those advertised using Semantic Web language
nates in a “handshake” that indicates mutual descriptions.4
acknowledgement of a joint contract. Interactions Selecting the abstraction level of the terms in a
during the service-enactment stage can use one of capability description query to be handed to a
several alternative protocols for each subphase: matchmaker involves several trade-offs. Typical-
initiating service activity, monitoring service ly, a requestor has a specific goal to be achieved
processes, and confirming service completion. If at a particular time, whereas service providers
the service terminates abnormally after a contract publish generalized descriptions of their capabili-
is formed, a final set of protocol interactions can ties that will enable clients to find them. For effec-
address compensation issues. tive matches to occur, capability queries should be
The rest of this article summarizes require- more abstract than the specific goals of the agent
ments for each phase, and its architecture in at the moment, but they should include informa-
terms of abstract protocols for accomplishing tion about how the goal should be achieved, and
phase-specific requirements. By “abstract proto- under what constraints, to avoid receiving too
cols,” we mean a set of message exchanges char- many extraneous candidates. This use of abstract
acterized in terms of abstract semantic concepts capability descriptions in matchmaker queries is
and roles. The protocols also identify the agents’ one of the reasons for the architectural distinction
state changes that result from such messages. An between discovery and negotiation. Discovery
ontology represents abstractions of the various involves cached service-capability advertisements,
message types used in these protocols, in terms of and clients can afford to do more detailed filter-
the performatives of the Foundation for Intelli- ing of and negotiation with potential providers

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


Service-Oriented Computing Track

during the engagement process, ultimately lead- ferent protocols for interacting with requestors, not
ing to an agreement between the requestor and a covered here.
valid provider.
We can divide the requirements for service dis- Service Engagement:
covery into three parts. Language requirements Negotiation and Contracts
help express capabilities and goals, and they Service engagement is the initial phase of interac-
include tion between a requestor and a potential provider.
The result of this phase is an agreement between
• available services’ characteristics and con- requester and provider such that both parties
straints (preconditions and fulfillment limita- expect, explicitly or implicitly, that a specific ser-
tions), vice will be provided by the provider. Although it
• protocols to be followed during interactions is during this phase that service contract negotia-
(message semantics), and tion occurs, negotiation might be necessary during
• requestor requirements (goals, quality, securi- the later enactment phase to ensure compliance
ty, and privacy). with prior agreements or to resolve disputes.
Functional requirements for engagement vary
Functional requirements specify the tasks each with the interaction’s complexity, but we can
entity will perform: nonetheless divide them into four basic areas:

• Providers must describe the capabilities and • Service request formulation. The requestor must
constraints on offered services. be able to acquire the message and protocol
• Requestors must create abstract characteriza- information required for composing valid ser-
tions of required services to facilitate matching vice requests or participating in service nego-
with published capabilities. tiation and invocation protocols. It must also
• Requestors must locate and interact with peers be able to interpret clarification requests and
or matchmakers that can respond to queries for counterproposals.
advertised service descriptions. • Contract preliminaries. Potential partners need
• Matchmakers must compare descriptions of a means to exchange information about
queries and capabilities. respective goals and capabilities.
• Requestors must decide if they can satisfy the • Contract negotiation. Potential partners need a
preconditions specified in a prospective ser- means for reaching agreement regarding a ser-
vice’s self-description in order to use it. vice’s provisioning.
• Agreement. All partners need a means for iden-
Finally, architectural requirements identify the var- tifying the terms of an agreement and when an
ious classes of agents necessary to produce the agreement is reached.
final result of the phase: clients that know what
services with which to negotiate. Discovery phase Architectural requirements for engagement can
protocols include vary with the complexity of the negotiations
appropriate to the domain, but can include
• advertising protocols used by service providers
to announce capability availability (this adver- • Negotiation protocols. Protocols that let parties
tising can be largely passive, such as postings propose and accept or reject aspects of a ser-
on Web pages), and vice agreement must be available in a standard
• candidate service-discovery protocols used by form, and at least one must be appropriate for
requestors looking for services that satisfy the particular domain.
their goals. • Negotiation services. One or both parties can
contract with a neutral, stand-alone negotiation
Matchmakers, like other kinds of registries, can expert (similar to an authentication service).
also be federated and organized by community or • Auditing services. Compliance with a negotiated
activity domain.5 Matchmakers that both find and agreement might require tracking commitments
invoke services as proxies for requestors — called and auditing the parties’ enactment activities.
brokers — play the role of the client in discovery,
engagement, and enactment. As such, they use dif- Service-engagement protocols describe the

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


A Semantic Web Services Architecture

Table 1. Engagement message semantics.


Message type Performative From To Comment
RequestService 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 service
CancelRequest Cancel Client Server Informs that the client no longer needs the server to perform the
requested service
OfferService 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 service
RefuseOffer Inform Client Server Informs server that client doesn’t agree to the offered service

messages exchanged between providers and The result of this dialog, if between Web agents,
requestors that eventually result in agreements. would be an explicit commitment (perhaps cap-
Three abstract protocols reflect the range of tured by a message trace) between the agents by
sophistication among the parties to an agree- which the service provider agrees to provide the
ment. The simplest, equivalent to the FIPA query- service under the negotiated terms and the client
reply protocol establishes agreement to a agrees to any negotiated compenstating actions.
service’s provision without any negotiation or Figure 2 shows the full abstract model, with the
formal contract. It’s the equivalent of saying, common subdialog for clarification summarized.
“please provide your service for me” and requires Table 1 shows the semantics of the messages used in
no acknowledgement or agreement from the all the engagement protocols of Figure 2, as well as
provider, which automatically attempts to enact their respective FIPA performatives.
its service. The second protocol, which is equiv-
alent to the FIPA request protocol, requires the Service Process
provider to agree to or refuse a request and Enactment and Management
results in a non-negotiated but explicit commit- Once the requestor and the provider agree on the
ment to provide a service. service to be performed, the service is ready to be
The third protocol, negotiate-commitment, initiated. The requester determines what informa-
establishes a formal negotiated contract for a tion is necessary for requesting the performance of
service’s provision. This abstract protocol pro- the service and how to react when the service
vides a model for the temporal flow and seman- respons with either success or failure.6,7 Function-
tic underpinnings of negotiations that can occur al requirements for enactment include
between requestors and providers. Each party is
required to notify the other if they abandon the • Response interpretation. The client must be able
negotiation, and explicit recognition of time-outs to interpret responses to its requests (as
ensures that no party is left hanging when described in the service description).
another party misbehaves or communication • Response translation. A translation must be
fails. The result of a successful negotiation is an produced when a requestor and provider use
explicit shared acknowledgment of a contract, different ontologies for communication.
which can then be modeled as a commitment • Choreography interpretation and execution. A
between the parties, as in this dialog two people semantically grounded language is necessary
might have: to describe the temporal constraints among
process elements, so that the requestor agent
• Requestor: “Will you provide your service for can produce the correct sequence of behaviors
three dollars?” for the chosen service.
• Provider: “Only if you pay ten dollars.” • Process mediation and delegation. To hide
• Requestor: “I will pay five dollars if you pro- choreography differences when interacting
vide your service by 5:00 pm.” clients and services use fixed, incompatible
• Provider: “OK.” | “No.” protocols, agents can use process mediation

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


Service-Oriented Computing Track

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.

Notation
R - a request for a service including QoS
Requestor Provider
requirements and requestor ID
R' - a revised request or refusal leading to
a new offer
[Init]/Send(R) O' an offer of a service, including
QoS guarantees Wait
CLARIFY* - indicates a possible CLARIFY
and/or AUTHORIZATION sub-dialog
[Receive (R)] CLARIFY*
Wait for response

[Receive (Offer)} CLARIFY*


Evaluate request
[Negotiable?]/Send (R)
Evaluate request [Timeout]
/Send(Cancel) [Receive (R')]
[Negotiable? /Send(Offer)

[Unacceptable] Wait for response


/Send(Cancel)
[Acceptable]
/Send(Agree) [Receive (agree)] [Timeout]
/Send(Cancel)
[No reply required]
[Receive (cancel)]
Wait for agreement Evaluate request

[Receive(Agree) [Receive(Refuse)] [Unacceptable]/Send(Refuse)

[Acceptable & reply read] /Send(Agree)


[Timeout]/Send)cancel)

ENACTMENT
ENACTMENT

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

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

services. • Service-failure handling and compensation.


• Dynamic service composition. Requestors need Services must provide declarative descriptions
support, not only to invoke dynamically dis- of their failure modes and associated means of
covered services but also to compose them recovery as well as their types of (and proto-
when no single service meets their needs. A cols for) compensation.
composition can use automated planning tech- • Dispute resolution and compliance. Clients and
niques to invoke a collection of services for a service providers can invoke third-party services
joint purpose.6,8 for conflict resolution, proof of verification,
• Process-status monitoring and event notifica- claim adjudication, and settlement compliance.
tion. Tracking an execution’s state can help a • Nonrepudiation, audit tracking, and explana-
requestor determine when and whether it will tion. All parties must be confident that a trans-
complete. action is secure, that all parties are authentic,

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


A Semantic Web Services Architecture

and that the transaction is verified as final. centrally managed ontologies and therefore
Systems must ensure that a party can’t reject a need mechanisms to provide authenticated def-
transaction after this point. initions and mappings among concepts and
their derivatives;9
Architectural requirements arise when middle • information and access security, privacy, and
agents provide support services. We will require confidentiality management and monitoring,
standardized protocols and standard ontologies support for those ubiquitous concerns of com-
for interacting with these agents, which could mercial and public-access Web services;
include • group membership and trust reasoning services
that extend simple ID-based authentication, to
• process-mediation services between agents for enable policy and relationship-based access by
whom semantically compatible interactions are automated reasoning about known trust rela-
possible, but whose choreographies don’t align tionships between parties;
(in terms of the number and types of messages • community-based preference and reliability
to be exchanged); reporting services based on collected feedback
• process-scheduling and composition services, from service clients;
which require ontologies for describing tempo- • policy and protocol management services, like
ral and domain constraints, objectives, and ontology management services, to provide
preferences; communities with authenticated semantic
• process-execution and status-logging services descriptions of shared policies and protocols,
to support execution monitoring, failure recov- as well as validation and dispute resolution ser-
ery, and compensation processes; and vices; and
• policy-monitoring services to ensure that • lifecycle management services to control the
invoked services follow contractually guaran- spawning (factories) and management (moni-
teed QoS agreements. toring and allocation) of service resources.

In our framework, we’ve developed abstract These requirements and service categories were
enactment protocols for three types of enactment derived from scenarios using semantically rich ser-
interaction. One of our three enactment protocols vice agents, and are not necessarily core parts of the
assumes synchronous communication, in which a architecture for all environments. However, when
requestor sends a message and then waits for a present, they play roles in the effective utilization
return message. The other two assume asynchro- of other services, and thus they can impact the com-
nous communication, in which a requestor sends plexity of the protocols used in conjunction with
a message to the provider, but doesn’t expect a those domain services. These interactions are topics
synchronous message return. for future investigation by the committee.
Each scenario has the same preconditions —
namely, the discovery and engagement processes Quality of Service
lead to an explicit or implicit service contract. A In Semantic Web service applications, suppliers
service requestor initiates the enactment phase by and customers define binding agreements or con-
sending an invocation message or by simply com- tracts among themselves in part by specifying
pleting the engagement phase (when the parties QoS-level agreements, using metrics such as dead-
don’t explicitly acknowledge service agreement; lines, accuracy, and cost.10,11 QoS metrics can affect
see www.swsi.org/swsa for more information on how services are advertised, can be the topic of
these protocols). negotiation process, and must be monitored dur-
ing enactment; thus, when clients’ procedures or
Community Support Services workflows involve multiple services, the underly-
Another class of infrastructural services will be ing discovery, coordination, and execution systems
needed to support communally maintained must be able to monitor QoS measures and control
Semantic Web service activities. In turn, these ser- the services accordingly. In complex workflows,
vices will support requirements, such as these monitors must reason about aggregate mea-
sures over the life of the workflow. Enforcement of
• ontology lookup, mapping, and version control these metrics can require complex resource rea-
services for communities that create shared, soning, prioritization, and service resource reallo-

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


Service-Oriented Computing Track

Further Reading References


or the full SWSA report, visit www.swsi.org/swsa/. For additional infor-
F mation on related approaches, visit these links:
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
• W3C Web Services Architecture WG: www.w3.org/TR/ws-arch/ OWL-S Approach,” Proc. 1st Int’l Workshop Semantic Web
• OWL-S: www.daml.org/services/owl-s/ Services and Web Process Composition (SWSWPC 04),
• WSMO: www.wsmo.org 2004; http://www-2.cs.cmu.edu/~softagents/papers/OWL
• METEOR-S: http://lsdis.cs.uga.edu/projects/meteor-s/ -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
cation. These topics are currently being studied, Group, Global Grid Forum, June 2002; www.globus.org/
thus weren’t addressed in detail by the committee. alliance/publications/papers/ogsa.pdf.
4. K. Sycara et al., “Dynamic Service Matchmaking among
Agents in Open Information Environments,” J. ACM SIG-

R ather than specific software components, our


architectural framework is based on abstract
characterizations of protocols and functional
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.
descriptions of capabilities. Our objective is to 5. K. Sivashanmugam, K. Verma, and A. Sheth, “Discovery of
define an interoperability model that can under- Web Services in a Federated Registry Environment,” Proc.
pin a variety of architectures without prescribing IEEE Int’l Conf. Web Services, IEEE CS Press, 2004;
specific implementation decisions. If service devel- http://lsdis.cs.uga.edu/lib/download/MWSDI-ICWS04-
opers build concrete components consistent with final.pdf.
our proposed abstract protocols, then Semantic 6. D. McDermott, M. Burstein, and D. Smith, “Overcoming
Web service clients will be able to interpret pub- Ontology Mismatches in Transactions with Self-Describing
lished descriptions of these components in terms Agents,” The Emerging Semantic Web: Selected Papers
of the abstract message ontologies and protocols from the First Semantic Web Working Symp., IOS Press,
we’ve developed. This sharing of abstract models, Amsterdam, 2002, pp. 228–244.
rather than syntactic and procedural agreements 7. A. Eberhart, “Ad-Hoc Invocation of Semantic Web Services,”
among developers, could give developers maximal Proc. IEEE Int’l Conf. Web Services, IEEE CS Press, 2004;
freedom in building components that can adap- www.aifb.uni-karlsruhe.de/WBS/aeb/pubs/icws2004.pdf.
tively interoperate. 8. S. Narayanan and S. McIlraith, “Simulation, Verification
Our belief is that this approach is consistent and Automated Composition of Web Services,” Proc. 11th
with the long-term vision of the Semantic Web at Int’l World Wide Web Conf. (WWW-11), 2002;
the W3C; we anticipate that our architecture will www.daml.org/
indicate requirements for Semantic Web service services/owl-s/pub-archive/nar-mci-www11.ps.
description languages, which are being designed 9. M.H. Burstein, “Dynamic Invocation of Semantic Web Ser-
by our sister committee, the Semantic Web Ser- vices that Use Unfamiliar Ontologies,” IEEE Intelligent Sys-
vices Initiative Language committee (www.swsi. tems, vol. 19, no. 4, 2004, pp. 67–73.
org/swsl/). 10. J. Cardoso et al., “Quality of Service for Workflows and
Web Service Processes,” J. Web Semantics, 2004; http://
Acknowledgments lsdis.cs.uga.edu/lib/download/CSM+QoS-WebSemantics.pdf.
We also thank the other members of the committee, past and 11. L. Zeng et al., “Quality Driven Web Services Composition,”
present, and its organizers, who contributed to the ideas pre- Proc. 2003 WWW Conf., 2003, pp. 411–421; http://sky.fit.
sented here: Bob Balzer (Tecknowledge), Fabio Casati (HP Labs, qut.edu.au/~dumas/www03.pdf.
UK), Mike Dean (BBN Technologies), Andreas Eberhart (AIFB,
University of Karlsruhe), Dieter Fensel (DERI, Insbruck), Carole Mark Burstein is a division scientist and director of the Human
Goble (University of Manchester), Mark Greaves (DARPA), Centered Computing Group at BBN Technologies, and
Frank McCabe (Fujitsu Laboratories, Sunnyvale, California), cochair of the Semantic Web Service Initiative’s Architec-
Enrico Motta (Open University, UK), Juan Miguel (DERI, Inns- ture committee. His research interests include semantic
bruck, Austria), Chris Priest (HP Labs, UK), Norman Sadeh translation and planning system support for Semantic Web
(CMU), Katia Sycara (CMU), Michael Uschold (Boeing), and services, mixed-initiative distributed systems, knowledge
Kunal Verma (LSDIS Lab, University of Georgia). representation, and machine learning. Burstein has a PhD

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


A Semantic Web Services Architecture

in artificial intelligence and computer science from Yale nents, such as Web services. Stuart has a PhD from the Uni-
University. He is a member of IEEE and AAAI. Contact him versity of Bath. Contact him at skw@hp.com.
at burstein@bbn.com.
Michal Zaremba is a postdoctoral researcher at National Uni-
Christoph Bussler is executive director of the Digital Enterprise versity of Ireland. His research interests include Semantic
Research Institute in Galway, Ireland, and cochair of the Web services and its architectures, eBusiness, enterprise
Semantic Web Services Initiative’s Architecture committee. application integration, B2B integration, and business
His research interests include Semantic Web services, busi- process management. Zaremba has a PhD in industrial
ness-to-business integration, and workflow management. engineering from the National University of Ireland and an
Bussler has a PhD in computer science from the University MSc in computer science and management from the Wro-
of Erlangen, Germany. He is a member of the ACM and the claw University of Technology in Poland. He is a member
IEEE Computer Society. Contact him at chbussler@aol.com. of OASIS, W3C, and the ACM. Contact him at michal.
zaremba@deri.org.
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 finin@umbc.edu.

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 huhns@sc.edu.

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-

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

View publication stats