Agent Approach for Service Discovery and Utilization

Transcription

1 Agent Approach for Service Discovery and Utilization Paul Palathingal Advanced Software Engineering Research Group, ORNL Abstract There is an extensive set of published and usable services on the Internet. Human based approaches to discover and utilize these services is not only time consuming, but also requires continuous user interaction. This paper describes an Agent Approach for Service Discovery and Utilization (AASDU), which focuses on using light weight autonomous agents built into a multi-agent referral community, and Web Service standards (namely UDDI, SOAP, WSDL and XML). The AASDU approach proposes to use agents that interact with end users by accepting their queries to discover services, and efficiently manage service invocation. AASDU uses intrinsic multiagent properties to allow agents to communicate and cooperate with one another. Each agent conforms to a communication protocol that allows it to send and receive messages from another agent, without needing to know the address of the receiving agent. There is a need for effective and efficient communication among components in a multi-disciplinary, cross-organizational architecture. This has resulted in a proliferation of communication building blocks, or middleware, for distributed scientific computing. The most recent, and quite promising, option is the availability of Sandeep Chandra Advanced Software Engineering Research Group, ORNL schandr@unity.ncsu.edu network-based services, referred to as Web Services. This paper also discusses the interoperability that can be achieved between software components through the use of Web Service standards and protocols in the context of AASDU. 1. Introduction Consider the following scenario. A Geographical Information System (GIS) analyst is analyzing an environmental project for a particular geographical region. The analyst might need the following data and tools: 1) Orthographic images of the region 2) Articles or documents on any activity or construction in the region and 3) A visualization tool for this data. For these data and tools to be found and used, they need to be registered or publicized as services with public registries (e.g. UDDI or any XML based registry) [1] on the Internet. Current approaches require the user to search for these services manually. Soon, the number of services and registries is expected to grow exponentially, with the possibility of manual search becoming extremely time consuming and laborious. To address these issues we propose an approach in which agents act on behalf of the user and search for services based on the user query. Agents are able to, interactively, /04 $17.00 (C) 2004 IEEE 1

2 search, negotiate, compose and execute services and provide results to the user. The multi agent referral system component helps handle the issue of growing number of registries and the time consumed in manually locating and searching through them. The referral system provides for the agents to talk to their immediate neighbor agents to determine agents capable of locating and searching required services. We propose to use an indexing scheme to break down the user query into a form that is understood by the agents. The indexing scheme also provides a way of relating the query to individual agents and coming up with a set of agents that would most likely return the required service details. In the GIS analyst scenario, the individual agents in the multi agent system talk to service registries, and locate services that provide data sets and tools 1, 2 and 3. The services are then negotiated, composed and invoked by a composing agent. The composing agents utilize the Web Service protocols and standards to invoke services and return results to the end user. Section 2 presents an introduction to agent technology and Web Service standards and discusses current state of work. Section 3 describes AASDU and discusses each of its components. In section 4 we discuss AASDU against some related work in progress and section 5 gives a summary of the approach described in the paper 2. Background Current architectures for Web information processing require substantial human intervention. Software agent technology can be used to alleviate the problem by automating processes as much as possible. This paper discusses the use of such software agents and the interoperability of Web Services across heterogeneous environments. Agents will not only describe operations and messages, but also, flexibly and dynamically, compose services by utilizing the best options available through public registries. The following sub sections describe the technologies most relevant to AASDU. We discuss agent technology and Web Service standards Agent technology Software agents have been subject to research in many inter-related fields. They are long-lived, persistent computations that can perceive, reason, act, and communicate [2]. They have the ability to make decisions independently without human intervention and without influence from other agents. Agent architectures provide several advantages over existing object-oriented technologies. In object-oriented systems, objects communicate through messages. The sender object must know the address of the receiver object, and the public methods of the receiver object. On the other hand, agents conform to a communication protocol and language (FIPA ACL, etc) that allow an agent to send a message to agent(s)without needing to know the address of the agent(s) or the specific methods available to the agent. This way agents move around yet maintain contact with other agents. Current agent research, as it relates to the web, focuses on building exemplar agent systems, defining theory of agent behavior and inter-agent communication. Most resulting systems are closed systems, which work well within an enterprise or in a homogeneous environment. There has been less emphasis on the interoperation of agents in a heterogeneous and ever changing environment like the web. Also, agent systems that work across enterprise boundaries need to overcome several challenges in service discovery, communication and utilization Web service Web Services are software components that are self-contained, self-describing applications that can be published, located, /04 $17.00 (C) 2004 IEEE 2

3 and invoked across the Web. Web Services allow applications to interoperate in a loosely coupled environment, discovering, and connecting dynamically to services without any previous agreements having been established between them. More importantly, a Web Service may combine several applications that a user needs. For the end-user, the entire infrastructure will appear as a single application. Web Services encompass just about any application available over or delivered via the web using standard protocols like Simple Object Access Protocol (SOAP) [4], Universal Description, Discovery, and Integration (UDDI), Web Services Description Language (WSDL) [5] and Extensible Markup Language (XML) [6]. The Web Services architecture encapsulates pre-existing code in a platform and language-independent manner. These technologies and protocols provide a standard means of communication and interaction among different software applications involved in presenting dynamic context-driven information to the end user. Current state-of-the-art-technology in the area of Web Services comprises vendors and service providers developing and publishing specialized services with private or public registries (e.g. IBM, Microsoft) depending on metrics such as usage [7, 8]. Some tools and standards that are available are built on top of current standards to enable various distributed, cross-organizational architectures (OGSA [14]). In some cases agent technology has been used in collaboration with Web Service standards, where semantic markup of Web services, DARPA Agent Mark-Up Language for Services (DAMLS) [2] for example, enable a wide variety of agent technologies to discover and utilize such services [9]. system through the user interface (GUI). A query analyzer agent (QAA) (3) interprets the user query and does the following. First, QAA stems the query to determine relevant keywords. Second, QAA ranks the agents in the multi agent system based on the agent s ability to look up services in the query. The stemmed query is then passed on to the agents selected by the query analyzer agent. The selected agents do a lookup for services (1) in the query and makes use of the referral feature built in to expedite the lookup process (4). This information is then sent to the service composition agent (5). The service composition agent will negotiate (6) with the user to select a particular service from the available services based on the user requirements. These requirements would involve quality of service parameters about the service rather than the service. Once the user decides on the service, the composition agent invokes (7) the service and returns the result to the user (8). The following subsections describe details about each individual module. It consists of four core components: 1. Client Graphical User Interface (GUI) 2. Query Analyzer Agent (QAA) 3. Multi-Agent Referral System for Service Lookup 4. Service Registry, Negotiation and Composition 3.1. Graphical user interface (GUI) The GUI is integral to AASDU as it allows the user to interact with the system. The GUI plays the role of a middleman between the end-user and the agents. A java based prototype interface demonstrating all the components is shown in Figure AASDU AASDU is described in Figure 1. AASDU consists of a user submitting a query to the /04 $17.00 (C) 2004 IEEE 3

4 Service Providers SOAP Server X SOAP Server Y D E P L O Y Vipar Service Astro Service Image Service R E G I S T E R Registry A 1 Invoke 7 Service Composition Agent 5 Registry C Invoke Service Return Result 6 Registry B 8 Negotiations Stemmed Query 4 Query GUI 3 2 Query Analyzer Agent Module Multi- Agent Referral Figure 1. AASDU framework There are five different components in the GUI. (1) A text field for users to submit their query. The query is a string of characters, or plain text. (2) A drop down list of available service domains. This list is useful to the multi agent referral community, because it narrows down the search spectrum for a service. For example, in the GIS scenario the scientist enters a query in the geographical analysis domain. (3) A popup menu with a list of available services. When a service in the list is selected, it will highlight a set of negotiable parameters for that service. (4) The composition agent might return multiple services in response to a user query. For each of the different services to be composed, the popup menu is presented to the user. A button is located at the bottom of the menu to enable the user to go through all the individual services needed to compose the result. (5) A result text box that display s the result of the service composition and execution. The agents use the graphical interface to communicate with the end user and vice versa /04 $17.00 (C) 2004 IEEE 4

5 service keywords by a vocabulary agent. These keywords are sent through a stemmer and stopper that remove words that are too common to search and hence are not indexed. Let the resultant keyword set be called vocabulary V. th i keyword. Let w i be the Term frequency of i w, TF ( w i, agent) is the number of times that agent looks up w i. In other words, it is the number of registries that the particular agent looks up and locates service keyword w i. The document frequency of w i, DF ( wi ) is the number of times w i is looked up by agents in the community. Inverse document frequency of w i, IDF ( wi ) is defined as ( wi ) IDF = log Figure 2. User interface 3.2. Query analyzer agent (QAA) The query that is input to the QAA is a natural language sentence. It has to be filtered and processed to break it down into service keywords that can be input to the multi-agent system. To do this the QAA uses a simple variant of the Term Frequency Inverse Document Frequency (TFIDF) scheme to index the query and rank the results [11]. The TFIDF is an indexing scheme, which relies on the premise that the meaning of a document (in our case the service lookup capability of an agent) can be derived from the documents constituent terms (in our case service keywords located on registries. Hence registries represent the documents in our approach). Here is a look at a brief overview of the TFIDF indexing scheme as applied to AASDU. Let r be one the service registries. The registry WSDL s (web service description language) are scanned for ( agents DF ( wi ) ) where agents is the number of agents in the community. Then the term frequency inverse document frequency of w i with respect to agent agent, TFIDF (, agent) is given by (, agent) w i TF w i * IDF( wi ) The vector representation for an agent is then given by ( TFIDF ( w, agent), 1 TFIDF ( w n, agent ) TFIDF ( w 2, agent),.. ) The query is also modeled similarly. We come up with a query vector ( TFQ (w 1 ), TFQ (w 2 ).. TFQ (w 3 ) ). The ranking of a query with respect to a document (agent) is done by using the cosine similarity below: TFQ( w i ) TFQ( w i ) i TFIDFw ( agent TFQw i i, ) ( i ) * TFIDFw ( i, agent) TFIDFw ( i, agent) i The higher the similarity, more likely are the chances that the agent would be able to lookup a service for that query /04 $17.00 (C) 2004 IEEE 5

6 The QAA module is described in figure 3. The query is input to the stemmer that removes stop words from it. The stemmed query that is filtered down to potential service keywords is passed to the QAA. The agents in the referral system continuously update the Agent vector repository. Each agent is responsible for an agent vector. It does a search on the registry that it is associated to. Based on the keywords found it updates the agent vector according to the TFIDF approach described above. The QAA takes the stemmed query and does a similarity check (TFIDF search) to look for agents that are most likely to find services outlined in the query. The query is then forwarded to these selected agents from the multi-agent system. Query Registries Stemmer Keywords in Registry Keywords in query Forward query to agents returned from the TFIDF search Referral System Stemmed Update Figure 3. QAA module QAA TFIDF search Agent vector 3.3. Multi-agent referral system for service lookup We believe that the core component of the AASDU framework is the service lookup and discovery. There is a fair possibility, that there are numerous registries available on the Internet and to have agents search through all of them would be very inefficient. In this section, we propose the use of a multi agent referral system to make the search faster. The referral system allows agents in the community the need to know only a subset of agents and registries and still be able to find any service it is looking for. We propose to set the system so that every time a new registry for a web service is created, it associates itself with an agent that plugs into the referral community. This way an agent entering the community does not need to keep track of all the registries available and the ones to look up. A general overview of the multi-agent referral system is shown in figure 4. The stemmed query from the QAA is input to the selected agents. Each agent parses the query to look for service keywords that it has expertise in. If it finds a match in the agent profile, it looks up the service registry with which it is associated and returns the service parameters. For all the other keywords in the stemmed query, the agent looks for answers or referrals from its neighbor model. The components in the referral system include: 1. Agent Profile Each agent in the referral system has an agent profile that models its interests and expertise. The profile contains (a) Agent ID, which is a unique identifier for each agent in the community. (b) An expertise vector, which contains expertise values for each service keyword lookup. For example the expertise vector could look like the following: /04 $17.00 (C) 2004 IEEE 6

7 Satellite Images Table 1. Expertise vector Weapons Foot- Ball News Docs Weather Neighbor Model In addition to its own profile, each agent also maintains a model of its immediate neighbors. The neighbor model is a list of known neighbors to the agent. Each agent in the neighbor model also has an accompanying expertise vector and a sociability value. The expertise vector as seen earlier is a reference to the expertise values for each service keyword lookup. The sociability value, which is a scalar, is a measure of the neighbor s sociability level or in other words how well the neighbor knows other expert neighbors. When an agent joins the community, it is randomly assigned a set of neighbors from the neighbors list. The neighbor s list is maintained as a registry. An example neighbor model is depicted in Table Multi Agent Learning The information stored in the user profile and neighbor models, change dynamically through interactions between the various agents. If an agent sends a query to a neighbor and receives a good answer (the validity of which is confirmed on user interaction with the final results) the expertise value for that particular keyword in the neighbor model is increased. If on the other hand the answer to a query is a bad one, the expertise value for that particular keyword in the neighbor model is decreased. Similarly if a neighbor agent is able to provide a good referral for a particular query, the sociability value of the neighbor agent is increased and vice versa Service module Service registry. Every Organization exposes and registers its services with a registry (e.g. UDDI, WSIL). The service provider publishes specifications, and the messages it can exchange, about the service namely access point (where it s been hosted and deployed), methods implemented, input/output parameters, negotiable quality of service parameters and other service related information. Table 2. Neighbor model Neighbor 1 Neighbor 2 SatelliteImages 0.33 Weapons 0 Football 0.54 NewsDocuments 0.87 Weather 0 SatelliteImages 0.21 Weapons 0.47 Football 0 NewsDocuments 0.19 Weather Each organization can access and use a template to create an agent that can easily join the multi agent community. The created agent will take the registry information with itself and join the multi agent community. This will help in evolving and growing the agent community with information on multiple registries. In essence, we will have an agent for every organization that would plug itself into the multi agent community. To find services AASDU uses the Java API for XML Registries (JAXR), which provides a uniform and standard Java API for accessing different kinds of XML registries including the UDDI registries. JAXR /04 $17.00 (C) 2004 IEEE 7

8 extracts relevant service information from the registry. The service details are sent to the client. Upon approval the service is composed and invoked. The client need not know the implementation details of a service. The agent gathers service parameters, from the service description file, namely service name, method name, input method parameters and SOAP URL, and creates a SOAP call that is sent to the SOAP router. The SOAP router calls the appropriate service based on the parameters it receives in the SOAP message. Finally, it returns the result to the agent who passes it to the end user Service negotiation. Consider a case where we have two web services that perform a clustering operation on documents. One service uses the genetic algorithm and the other uses a hierarchical approach model in the background. Both these web services are registered with the UDDI registry and deployed to a SOAP router. Once the client inputs a query to look for services that perform clustering, the query agent distributes this to the agents in the multi-agent referral system. The agents in the multi-agent system interpret the query and search for the required service in their profile or their neighbor s profile. Once the services are found, the agents retrieve service information published in the WSDL and supply it to the service composition agent. The service composition agent carries out the negotiation with the client. Parameters that are part of the negotiation could be quality of service, response time, maximum load, etc. In our example two services will be retrieved. Their service details and negotiation parameters are passed to the service composition agent. The service composition agent would pass these parameters to the end user and negotiate on a particular service to be selected for invocation. Once the end user selects a service out of the available services, the composing agent invokes the service Service composition. Service composition consists of using service parameters to create service calls that are directed to appropriate servers where the service is hosted. Service composition component also handles invoking alternative services incase of failure of the selected service. In the existing framework we are working on invoking individual services. As part of future work we will try to incorporate creation and invocation of service workflows. Users can specify the services and the order in which they would want to invoke them [15]. The agent will negotiate the services to invoke; it would validate the input and output parameters; check for data type matching and pipeline the services in the order. Once the workflow is created from the selected services the agent would invoke the services. Some of the service workflow languages used are WSFL, BPEL4WS, etc. 4. Discussion There are a number of architectures that are trying to address the same problem of service discovery and utilization. One such work is the markup of web services in the DAML family of semantic web markup languages. The markup proposed enables agent technologies for web service discovery and execution [9]. Our approach is similar in the use of agents and service descriptions to support interaction with the services. We focus on quicker and more efficient lookup of web services. With the markup of web services approach laying much emphasis on markup, we concentrated our attention more towards the agents being associated with individual registries and the agent maintaining information of individual services in the registry. The referral system module provides easier lookup of services and greater scalability. Every time a new registry is created all it needs to do is create an agent in the referral community for itself. The agent gets plugged into the community with a default set of neighboring agents and /04 $17.00 (C) 2004 IEEE 8

9 their agent profiles. Another module that impacts the service composition in particular is the query analyzer agent. Using a vector space model in the QAA guarantees quicker breakdown of a query into possible service lookup and in composing resultant services. The system is fail safe in that the service composition agent will temporarily keep the details of the backup services and automatically invokes them incase the main service fails. 5. Conclusion We have introduced a novel idea for a multiagent based system for automatic service discovery and utilization. It is flexible, scalable allowing new services and agents to be inserted into the system. The proposal to integrate a referral system to our approach gives the system greater power in the discovery of services. The approach also discusses the interoperability achieved between software components through the use of Web Service standards and protocols. The agent architecture used in the approach will be an extension to the Oak Ridge Mobile Agent Community (ORMAC) framework. References [1] Universal Description, Discovery and Integration, Executive White Paper, 14 Nov aper.pdf [2] Michael N. Huhns and Munindar P. Singh. Agents and multiagent systems: Themes, approaches, and challenges. In [9], chapter 1, pages Morgan Kaufmann, [3] Thomas E. Potok, Mark Elmore, Joel Reed, and Frederick T. Sheldon, "VIPAR: Advanced Information Agents discovering knowledge in an open and changing environment", Proceedings of the IIIS Agent Based Computing, Orlando, July 27-30, [4] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Satish Thatte, Dave Winer and Henrik Nielsen. Simple Object Access Protocol (SOAP) 08-May [5] Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weerawarana Web Services Description Language (WSDL), 15-Mar-2001, [6] Tim Bray, Jen Paoli, C. M. Sperberg-McQueen, Eve Malor Extensible Markup Language (XML) 1.0, 6-Oct-2000, [7] Huhns M. N, Agents as Web services, Dept. of Computer Science, South Carolina Univ., Columbia, SC. Internet Computing, IEEE On page(s): Volume: 6, Issue: 4, Jul/Aug 2002 [8] Sheng-Tzong Cheng; Jian-Pei Liu; Jian-Lun Kao; Chia-Mei Chen, A new framework for mobile Web services Applications and the Internet (SAINT) Workshops, Proceedings Symposium on, 28 Jan.-1 Feb [9] Mcllraith S. A, Son T. C., Honglei Zeng, Semantic Web services Knowledge Systems Lab., Stanford Univ., CA; Intelligent Systems, IEEE On page(s): Volume: 16, Issue: 2, Mar/Apr 2001 [10] Tak W. Yan and Hector Garcia-Molina, Index structures for information filtering under the vector space model, Technical report, Department of Computer Science, Stanford University, Stanford CA [11] Todd A. Letsche and Michael W. Berry, Largescale information retrieval with latent semantic indexing, Information Sciences, 100: , 1997 [12] Bin Yu and Munindar P. Singh, "Emergence of Agent-based Referral Networks." in Proceedings of AAMAS-2002 [13] DAML Services, [14] Ian Foster, Carl Kesselman, Jefferey Nick, Steven Tuecke. The Physiology of the Grid, An Open Grid Services Architecture for Distributed Systems Integration. [15] "A Modeling and Execution Environment for Distributed Scientific Workflows", The Scientific Data Management Center project sponsored by the US Department of Energy (DOE) to enable Scientific Discovery through Advanced Computing [SDM02,Sci] /04 $17.00 (C) 2004 IEEE 9