Multiagent systems deployed in open. Dynamic Discovery and Coordination of Agent-Based Semantic Web Services. Agents Track

Transcription

1 Agents Track Editors: Michael N. Huhns Dynamic Discovery and Coordination of Agent-Based Semantic Web Services Matchmaking and brokering are multiagent coordination mechanisms for Web services. Both have performance trade-offs, but the Web Ontology Language for Semantic Web Services (OWL-S) can handle extensions that address some of the shortcomings. In this article, the authors focus on the broker, analyzing both its interaction protocol and reasoning tasks. The authors also describe OWL-S s exec extensions, detail their implementation s basic features, and explain how these features address the broker s reasoning problems. Katia Sycara, Massimo Paolucci, Julien Soudry, and Naveen Srinivasan Carnegie Mellon University Multiagent systems deployed in open network environments in which agents and communication links can appear or disappear dynamically need assistance to maintain coherent activity coordination and overall system robustness. Multiagent systems use a category of agents called middle agents 1 for such purposes. Like middlemen in physical commerce, these agents assist servicerequester agents in discovering and connecting with one or more relevant service providers in the electronic world. Different types of middle agents exhibit different performance characteristics in terms of privacy, robustness, adaptivity, system load balance, and so on, 2 but the most common types of middle agents are matchmakers and brokers. Matchmakers increasingly appear in standards for Web services infrastructure: the Universal Description, Discovery, and Integration ( html) registry, for example, is essentially a semimanually operated matchmaker. Matchmakers value as service discovery facilitators has even spilled over into the Semantic Web services infrastructure. The Web Ontology Language for Semantic Web Services (OWL-S) supports dynamic service discovery via matchmakers through its service profile language construct. Brokers are some of the main discovery and synchronization mechanisms among autonomous agents. 1,2 The Open Agent Architecture (OAA) Facilitator, 3 for example, brokers between OAA agents that collaborate to solve a problem. Brokers play key roles in many agent applications, including e-commerce, pervasive computing, integrating heterogeneous information sources and databases. Because of its 66 MAY JUNE 2004 Published by the IEEE Computer Society /04/$ IEEE IEEE INTERNET COMPUTING

2 Dynamic Discovery and Coordination properties and wide applicability, a broker component is a natural candidate for the Web services infrastructure. Unfortunately, the current Web services architecture 4 does not include brokers with the rich functionalities of discovery and mediation. In this article, we analyze the requirements for a broker that performs discovery and mediation between agents and Web services; we also describe our implementation of a broker that uses OWL-S. 5 Such a broker performs very complex reasoning tasks, including interpreting service provider capabilities and requester queries; finding the best provider based on a requester s query; invoking the selected provider on the requester s behalf; interacting with the provider as necessary to fulfill the query; and returning query results to the requester. Accomplishing these tasks requires ontologies to describe Web-service capabilities, interaction patterns, and domains along with a logic that allows reasoning on the information specified in those ontologies. We propose a new OWL-S language construct to support broker functionality more explicitly. The Benefits of Brokering In an open organization, service providers advertise their capabilities with a matchmaker, which stores all advertisements in a local knowledge base. If capabilities change or the provider exits the open system, the provider deletes the advertisement. To query a provider for a service, a requester first formulates a metaquery, called a request, to ask the matchmaker for agents that could respond to it. Upon receiving a set of relevant providers, the requester chooses one or more with which to interact and queries them directly. In other words, after the initial discovery of potentially useful providers, requesters and providers interact directly without any further involvement on the matchmaker s part. From an agent-coordinating mechanism s viewpoint, matchmakers provide many useful functions in open environments, including fault tolerance for the overall distributed system and an abstraction for finding service providers by capability or functionality rather than by name. They also provide multiagent interaction robustness: if a provider fails, for example, a requester can find another provider with similar capabilities through the matchmaker. Finally, matchmakers address privacy concerns: a requester doesn t have to reveal preferences for particular service characteristics such as cost, availability, or security. Instead, the requester selects the provider it prefers from a list of candidates. Brokers work slightly differently. Service providers still advertise with them, but requesters can send queries directly to the broker instead of going through a matchmaker. The broker must find one or more appropriate providers, send the chosen provider the information contained in the query, receive the provider s reply, and then send it to the requester. In this way, the broker stays involved throughout the provider requester interaction. Brokered coordination is very centralized; brokers thus represent a single point of failure (because every query and response goes through them). Nevertheless, brokers provide several useful functions for a multiagent system: they provide good system load balancing and can enable agent interoperability, for example. 2 If two parties want to communicate but don t share a common language, brokers can provide translation services. They can also provide nonrepudiation facilities by acting as a trusted intermediary for two parties that don t trust each other, for instance. Finally, brokers provide anonymization to one or both parties by mediating the transaction. In fact, they re the preferred mechanism for e-commerce business models systems such as online auctions are essentially brokered systems. How OWL-S Plays into Brokering OWL-S 5 is a description language that lets providers enrich Web service descriptions with semantic information. 6,7 OWL-S is organized into three modules: a profile describes Web service capabilities, as well as any additional features that help describe the service; a process model describes the Web service provider s activity, which is how the requester can derive information about service invocation; and a grounding describes how the abstract information exchanges explained in the process model are mapped to the actual messages that providers and requesters exchange. A Web service capability essentially describes what the service does: the capability of Barnes and Noble, for example, is to sell books. We can think IEEE INTERNET COMPUTING MAY JUNE

3 Agents Track Seq, (E [return v >>= e], ϕ), (E [(ev)], ϕ) Spawn, (E [spawn e], ϕ), (E [return ()], ϕ), (e, ) Cond True, (E [cond C e 1 e 2 ], ϕ), (E [e 1 ], ϕ),, (E [e 1 ], ϕ), (E[e 1 ], ϕ ), Choice Left, (E [choice e 1 e 2 ], ϕ), (E [e 1 ], ϕ ), Atomic, (E [atomic e], ϕ), (E [return ()], ϕ ), Figure 1. Execution semantics.these rules describe the execution semantics of OWL-S and the control constructs used in OWL-S process models. of a Web service s capability in two ways: as a service category within an ontology of services or as a transformation of a set of inputs to a set of outputs. The OWL-S profile describes a Web service s capabilities by the transformation it produces. The profile also offers the option of describing services in terms of service categories. The OWL-S/UDDI matchmaker 8 middle agent uses part of the OWL-S profile and includes an automated matching engine that matches stored provider advertisements to the service requests expressed in OWL-S. The broker we define later in this article is another example of a middle agent that performs both discovery and mediation. OWL-S s process model has two aims: to show how the provider achieves its goals and to provide the requester provider interaction protocol. It achieves the first goal by letting the provider publicize a description of its computation (to the extent that the provider feels comfortable doing so). OWL- S distinguishes between two types of processes: composite and atomic. Atomic processes correspond to operations that the provider can perform directly; composite processes are collections of processes (either atomic or composite) organized on the basis of some control-flow structure. We define a sequence of processes, for example, as a composite process whose processes are executed one after the other. Other control constructs supported by OWL-S are cond for conditional expressions, choice for nondeterministic choices between alternative control flows, and spawn for spawning a new concurrent thread. OWL-S also includes looping constructs such as while and repeat-until. Process execution produces a state transition in which the agent either exchanges information with a partner or changes the environment. A state is defined as a tuple (ϕ, Π), where Π represents the set of concurrent threads, and ϕ is the state of the thread in which the process is executed. 9 (The execution semantics we use here were originally proposed for the DARPA Agent Modeling Language for Services [DAML-S 0.6]. Although many aspects of the language changed in its evolution to OWL-S 1.0, the execution semantics of the process model s basic constructs remain valid.) Processes modify the state either by changing the state of thread ϕ for instance, an atomic process can read a message from a port or by modifying the set of concurrent threads P by spawning new threads or closing older ones. Figure 1 shows the formal semantics of the OWL-S composite and atomic processes. Looping constructs are implemented as combinations of sequences and conditions. Each rule in Figure 1 specifies how process execution changes overall state. Sequences of processes, expressed here with the temporal constraint return v >> = e, applies e to the previous step s results (v). A spawn operation s execution starts a new thread (e, ), but it returns no value in the current thread (return ()). The other rules specify the results of executing other types of control constructs, with Cond True specifying the results of a conditional statement s execution if the condition is true (we d use a similar rule for a false condition). Choice Left specifies the nondeterministic selection of the next process to be executed. Finally, Atomic describes the results of executing an atomic process, which affects the state of the current thread ϕ but doesn t modify the set of concurrent processes. The last OWL-S module is the grounding, which describes how atomic processes are transformed into concrete messages or remote procedure calls over a network. Atomic processes provide abstract descriptions of information exchanges with requesters. We define the OWL-S grounding as a one-to-one mapping from atomic processes to Web Services Description Language (WSDL) 10 input and output message specifications. According to the Web services philosophy of interaction between requesters and providers, a requester needs to know ahead of time the information that a provider requires during the interaction. In industrial standards, for example, the requester provider interaction is governed by knowledge of the provider s Web service description (WSD), which is given in WSDL; in semantic Web services, the interaction presupposes the requester s knowledge of the provider s process model (plus WSD). Broker Protocol Figure 2 illustrates how any transaction involving a broker requires three parties: the first party 68 MAY JUNE IEEE INTERNET COMPUTING

4 Dynamic Discovery and Coordination (requester) initiates the transaction by sending a request to the broker for information or a service. The broker selects the second party (provider) from a pool of options as the best suited to resolve the requester s problem. The third party is the broker itself. We can further divide the protocol in Figure 2 between advertisement and mediation. In the advertisement protocol, the broker first collects a list of Web services advertisements (shown in the figure with straight lines), which it then uses to select the best provider. The mediation protocol (shown in the figure as curved lines) requires the following steps: Requester 1. Requester query 4. Broker relays provider's answer Broker 2. Broker queries provider 3. Provider answer Advertise Advertise Advertise Providers 1. The requester queries the broker and waits for a reply while the broker uses its discovery capabilities to locate an appropriate provider. 2. Once it discovers the provider, the broker reformulates the query for that specific service. 3. Upon receiving the query, the provider relays the reply to the broker. 4. Finally, the broker replies to the requester. This protocol illustrates how the broker must perform several complex reasoning tasks for both discovery and mediation. The discovery process requires two different reasoning tasks: to abstract from the query to the provider s required capabilities and to compare and match these required capabilities with what available providers can do. The mediation task requires the broker to transform the original query into one that it can send to the provider. This process has two aspects: the efficient use of the requester-provided information and the mapping from the requester s messages to the provider s and vice versa. Because the requester doesn t know which is the most relevant provider, the (initial) query it sends to the broker might not correspond exactly with the query input that the (selected) provider might require in order to provide the service. Consider the example of a requester that wants to book the cheapest flight from Pittsburgh to New York. Besides the trip origin and destination, the selected provider might expect departure date and time. In this example, let s say the requester doesn t provide the departure time and that the provider has no use for the cheapest qualifier. It s the broker s task to reconcile the difference between the information provided and expected. It does this by recognizing that the departure time is missing and, therefore, should be requested, and Figure 2. The broker s protocol. The protocol shows the different phases of the interaction between the provider and the requester through the broker. by finding a way to select the cheapest flight from among the ones the provider finds. The broker might also have to map between ontologies and the terms the two parties use. The requester might ask for information about IBM, for example, whereas the provider expects inputs in terms of International Business Machine Corporation. A more complicated mismatch can occur at the level of concepts and their relations in the ontologies used for the provider s inputs and outputs. A requester might ask for the weather in Pittsburgh, for instance, but the provider might only report the weather at major airports. The broker would have to infer which airport was the most appropriate and use it in its query to the provider. Therefore, instead of asking for the weather in Pittsburgh, the broker would ask the provider for the weather at PIT, which is the three-letter code for Pittsburgh International Airport. Finally, the broker has the nontrivial task of translating between different syntactic forms of queries and replies. The examples we just discussed assume semantic mismatches between different messages that the broker must first interpret and then send. These messages will be compiled in an appropriate syntactic form, but despite their semantic similarity, they are likely to be realized in very different ways. The broker must resolve any syntactic differences and formulate messages that all parties can understand. IEEE INTERNET COMPUTING MAY JUNE

5 Agents Track How OWL-S Supports the Broker As we ve just seen, the broker performs many complex reasoning tasks that range from service discovery to message interpretation, translation, and compilation. To accomplish these tasks, the broker needs the support of a formal framework that allows complex reasoning about agents, what they do, and how to interact with them. The OWL-S language and ontology provide constructs that support the broker in both discovery and mediation: the OWL-S profile supports the discovery process by providing a representation of Web service and agent capabilities; the process model and grounding support the interaction between the broker and the service requester and provider. The grounding maps the semantic form of the messages exchanged (as defined in the process model) to the syntactic form as defined in the WSDL input and output specifications. The grounding provides the broker with the mapping from the abstract semantic representation of the messages to the syntactic form that these messages adopt when they become concrete information exchanges. The broker then uses this mapping to interpret its received messages and compile its sent messages. Several researchers have proposed capabilitymatching algorithms for OWL-S-based Web services. 8,11 These algorithms exploit OWL ontologies and their related logics to infer which advertisements satisfy requests for certain capabilities. These algorithms also can be used to solve the problem of matching a query s required capabilities to available providers capabilities. The abstraction from the requester s query to the required capabilities is more complicated. First, there is no explicit support in OWL-S for queries; nevertheless, it s easy to use the OWL Query Language (OWL QL), 12 which relies on the same logics OWL-S requires. This transformation is still an open problem, though, and to the best of our knowledge, it has yet to be addressed. Later in this article, we propose an abstraction algorithm that transforms queries into capabilities. Once the broker selects a provider, it has access to that provider s process model; from there, it can derive the provider s interaction protocol by extracting what information the provider will need, in what order, and what information it will return. For the rest of the interaction, the broker will act as the provider s direct requester, but this relationship is not straightforward. Because the broker acts on the requester s behalf, it must somehow transform the initial query (and all subsequent messages) into a query (or a sequence of queries) for the provider. This transformation is necessary because the requester cannot see the provider s process model; it interacts with the provider only through the broker. Furthermore, because the requester initiated its query without having access to the provider s process model (the provider was unknown at the time of the initial query), the broker must infer what additional information it needs from the requester. Once it does so, it uses this knowledge to construct a new process model, which it presents to the requester not as the provider s process model but as the broker s. The new process model indicates to the requester what information is needed and in what order. Because, from the requester s viewpoint, the broker represents the provider, the new process model should contain crucial elements of the provider s process model. Given, however, that the broker is unaware of the provider until it discovers and selects it based on the requester s query, the broker is faced with a challenge: it must publish a process model that depends on the provider s process model, but it doesn t know the provider until the requester reveals its query. On the other hand, the requester cannot query (or interact with) the broker until the broker publishes its process model. The result is a paradoxical situation in which the broker cannot reveal its process model until it receives a query, but it can t receive a query until it publishes its process model. Essentially, this broker s paradox results from inflexibility in OWL-S s service-invocation specification, which requires the process model s specification before interaction. (Current industry-proposed standards have the same inflexibility, because the WSD must be specified with no provisions for on-the-fly loading or modification.) Extending OWL-S Our solution to the broker s paradox extends the OWL-S process model s specification to allow flexibility: The broker can provide an initial, providerneutral process model to the requester, and then modify it consistently with the provider s process model requirements, thus creating a new process model that the requester can use in its interactions with the broker. To implement this solution, we extend the OWL-S Model Processing Language by adding a new statement that we call exec. The exec statement takes a process model as input and then executes it. The broker compiles a new process model, 70 MAY JUNE IEEE INTERNET COMPUTING

6 Dynamic Discovery and Coordination returns it as an output of one of its processes, and then uses exec to turn the new process model into executable code that specifies the broker s new interaction protocol. Figure 3 shows the broker s provider-neutral process model, in which the broker performs a sequence of three operations: GetQuery the broker gets the query from the requester. Discover the broker uses its discovery capabilities to find the best provider. Exec the broker passes control to a new process model. The exec operation allows the separation of service discovery from service invocation and interaction. The broker first completes the discovery; it then initiates the interaction, which depends on the discovered provider, through exec. One important question is whether we can use OWL and OWL-S without adding an extension. Unfortunately, neither language provides a way to transform a term into a predicate of the logic, which is the essential step exec performs. Intuitively, the exec operation s semantics are to execute the processes that it contains as arguments. In other words, the state transformation that exec(p) produces is equivalent to the state transformation that the direct execution of P produces. The following execution semantics capture this intuition via exec s axiomatic semantics: Π,( EP [ ], ϕ) Π',( EP [ '], ϕ') exec( P) Π, E([ exec( P) ], ϕ) Π',( EP [ '], ϕ'). This rule specifies that the execution of exec(p) in state (, ϕ) should produce the same results as produced by the execution of P in the same state (, ϕ). This definition allows us to transform the specification of process P into the process s execution, which is exactly what we re seeking with the definition of exec. Sequence GetQuery Discover Exec Figure 3. The broker s process model. The exec operation is depicted by the three small rectangles that display processes to be run as a consequence of the exec statement. Our Broker Implementation Our prototype of a broker uses OWL-S with the exec extension to mediate between agents and Web services. We based our implementation on the OWL-S virtual machine (OWL-S VM) 13 a generic OWL-S processor that lets Web services and agents interact on the basis of the service s OWL-S description and OWL ontologies. We extended the OWL-S VM to include exec s semantics and developed the reasoning that lets the broker perform discovery and mediate provider requester interaction. Discovery The broker expects a query in OWL-QL format from the requester. 12 In this format, the predicate corresponds to a property in the ontology, and the terms in the query are either variables or instances that are consistent with the predicate s semantic type requirements. The discovery process takes the query as input and generates an appropriate provider s advertisement as output (if any providers are known to the broker). The discovery process has three steps; the broker abstracts from the query to the required capabilities, thus constructing a service request; finds appropriate providers by matching the capabilities required to solve the query (the service request) with provider advertisements; and selects the most appropriate provider. 8 Automatic abstraction from the original query to a service request is, to our knowledge, an unexplored problem. The abstraction process must respect the OWL-S discovery process s constraints namely, generating a service profile with the appropriate required service inputs and outputs that reflect both the query s semantic content and the generated service request s requirements. The instantiation algorithm follows the six steps listed in Figure 4 (next page). Steps 1 and 2 extract and separate terms from the query into variables and instantiated terms. In step 3, abstracting the instantiated terms to their immediate class derives the service request s set of inputs. If one term were Pittsburgh, for example, it would be abstracted to City (assuming the presence of a location ontology). Step 4 handles the variables. In OWL-QL, variables are of class Variable, but there is no constraint on the type IEEE INTERNET COMPUTING MAY JUNE

7 Agents Track 1. set V = set of variables in the query 2. set T = set of instantiated terms in the query 3. set I = abstraction of each term in T to its immediate class 4. use predicate definition in the ontology to abstract variables in V to their class 5. set O = abstraction of each variable in V to its class 6. generate a service request with input I and outputs O Figure 4. The abstraction algorithm. This algorithm transforms the query the broker receives from the requester into a description of the capabilities required to answer that query. The broker then uses this description of capabilities to locate the best provider to answer the query. 1. KB = knowledge from query 2. I = input of process 3. for i 1 4. select k from KB with the same semantic type of I 5. if k exists 6. remove i from I Figure 5.Algorithm for pruning redundant information.the provider s process model might request information that the requester has already provided to the broker.to ask the requester again would be redundant, therefore the broker removes it from the process model. that they have to assume. We use the predicate s definition in the ontology to constrain the variable values to the most restrictive class of values to which they can be assigned. In step 5, we use the abstraction in step 4 to generate the set of outputs O. Finally, in step 6, the broker generates the service request by specifying the inputs and outputs. Mediation After the broker selects a provider, it must mediate between the provider and the requester. The mediation process depends on the provider s process model, which specifies what information is required and when. In theory, the broker might present the provider s process model to the requester and limit mediation to message forwarding, but this solution is very inefficient because it ignores any information already provided to the broker. The requester might ask the broker to book a trip to Pittsburgh, for example, and the broker might find a travel Web service that asks for departure and arrival location. The broker s task is to recognize that the arrival location is already specified, and that it needs to ask only for the departure location. Figure 5 shows the algorithm for pruning redundant information. First, the broker records the information provided by the query in a knowledge base (KB) (step 1) and also records the process s inputs (step 2). Next, for each input i, the broker looks in the KB for information that it can use in place of it. If any is found, it removes i from the process s inputs. Interaction Figure 6 shows the broker s architecture. To interact with the provider and the requester, the broker instantiates two ports: a server and client. We use OWL-S to describe the server port s functionalities. Specifically, the broker exposes to the requester its process model, grounding, and WSDL specification. The client (requester) uses these descriptions to instantiate an OWL-S VM to interact with the broker. Given that the provider-neutral process model exposed by the broker uses the exec extension, the OWL-S VM the requester uses also includes an implementation of exec s axioms. The client port is also implemented as an OWL-S VM that uses the provider s process model, grounding, and WSDL description to interact with it. Broker reasoning occurs in the query processor section of the architecture, which is responsible for translating messages between the two parties and for implementing the algorithms in Figures 4 and 5. Specifically, the query processor stores information received from the query in a knowledge base to be used as needed during execution. Furthermore, the query processor interacts with the discovery engine, which stores and matches capabilities upon receiving a capability advertisement or when it needs to find a provider that can answer the query. Conclusions In this article, we highlighted some far-reaching, important questions about mediation in Semantic Web services; these issues also arise in the automatic interaction between agents and in Web service composition. An agent might decide to subcontract the solution of one of its goals, for example. To achieve this task, it must find a provider that can solve that goal, and then interact with this provider. The problems the agent will face in such an arrangement are equivalent to the problems we discussed in the context of the broker. Our current research extends our work on brokering toward automatic multiagent interaction and automatic Web service composition. 72 MAY JUNE IEEE INTERNET COMPUTING

8 Dynamic Discovery and Coordination Acknowledgments We thank Khalid El-Arini for his contribution to early development of this work. This work was funded in part by the US Defense Advanced Research Projects Agency as part of the DARPA Agent Markup Language (DAML) program under US Air Force Research Laboratory contract F , and in part by US Office of National Research under grant N References 1. H.C. Wong and K. Sycara, A Taxonomy of Middle-Agents for the Internet, Proc. 5th Int l Conf. Multi-Agent Systems (ICMAS 2000), AAAI Press, 2000, pp K. Decker, K. Sycara, and M. Williamson, Matchmaking and Brokering, Proc. 2nd Int l Conf. Multi-Agent Systems (ICMAS 96), AAAI Press, 1996, pp D.L. Martin, A.J. Cheyer, and D.B. Moran, The Open Agent Architecture: A Framework for Building Distributed Software Systems, Applied Artificial Intelligence, vol. 13, nos. 1 and 2, 1999, pp D. Booth et al., Web Services Architecture, W3C Working Draft, 8 Aug. 2003; -arch /. 5. Semantic Markup for Web Services (OWL-S), OWL Services Coalition, 2004; 6. M. Dean et al., OWL Web Ontology Language Reference, W3C Candidate Recommendation, 18 Aug. 2003; org/tr/owl-ref/. 7. T. Berners-Lee, J. Hendler, and O. Lassila, The Semantic Web, Scientific Am., vol. 284, no. 5, 2001, pp M. Paolucci et al., Semantic Matching of Web Services Capabilities, Proc. Int l Semantic Web Conf. (ISWC 02), LNCS 2342, Springer Verlag, 2002, pp A. Ankolekar, F. Huch, and K. Sycara, Concurrent Execution Semantics for DAML-S with Subtypes, Proc. 1st Int l Semantic Web Conf., LNCS 2342, Springer Verlag, 2002, pp E. Christensen et al., Web Services Description Language, W3C Note, 15 Mar. 2001; -wsdl B. Benatallah et al., Towards Semantic Reasoning for Web Services Discovery, Proc. Int l Semantic Web Conf. (ISWC 03), LNCS 2870, Springer Verlag, 2003, pp R. Fikes, P. Hayes, and I. Horrocks, OWL-QL: A Language for Deductive Query Answering on the Semantic Web, tech. report KSL-03-14, Knowledge Systems Lab., Stanford Univ., K. Sycara et al., Automated Discovery, Interaction and Composition of Semantic Web Services, J. Web Semantics, vol. 1, no. 1, 2003, pp Katia Sycara is a professor in the School of Computer Science at Carnegie Mellon University and director of the Advanced Information Technology Laboratory. Her research interests Requester OWL S VM Client port Broker Server port Process model, grounding, WSDL Discovery engine Matching engine Knowledge base Query processor Advertisement database OWL S VM Client port Figure 6. The broker architecture. The broker receives queries from its server port; the queries are then passed to the query processor, which implements the algorithms in Figures 4 and 5. Requests of capabilities are sent to the matching engine module that selects the best provider, while queries are sent to the client port to be forwarded to the provider. include autonomous agents, planning, learning and coordination of multiple agents in dynamic environments, Web services, and case-based reasoning. Sycara received a PhD in computer science at Georgia Institute of Technology. She is a member of the OWL-S coalition and the UDDI technical committee, US chair of the SWSI executive committee, and a fellow of the AAAI. Contact her at katia@cs.cmu.edu. Massimo Paolucci is a principal research programmer at Carnegie Mellon University. His research interests include Semantic Web services and their relation to multiagent systems and planning. Paolucci received an MS in computational linguistics at Carnegie Mellon University and an MS in intelligent systems from the University of Pittsburgh. He is a member of the OWL-S coalition, the UDDI Technical Committee, and the architecture committee of the SWSI initiative. Contact him at paolucci@cs.cmu.edu. Julien Soudry was a visiting student scholar at the Robotics Institute at Carnegie Mellon University when the work in this article was conducted. His interests include Web services and the Semantic Web. Contact him at julien.soudry@wanadoo.fr. Naveen Srinivasan is a research programmer at Carnegie Mellon University. His research interest includes the Semantic Web, Web services, automatic interaction and discovery of Web services, and tools for Semantic Web services and multiagent systems. Srinivasan received an MS in computer science from the University of Maryland, Baltimore County. Contact him at naveen@cs.cmu.edu. Provider Server port Process model, grounding, WSDL IEEE INTERNET COMPUTING MAY JUNE