Extending JADE for Agent Grid Applications

Transcription

1 Extending JADE for Agent Grid Applications Agostino Poggi, Michele Tomaiuolo and Paola Turci Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Abstract This paper presents an extension of the JADE agent development framework that may be the basis for the realization of flexible agent-based grid systems. In particular, JADE framework has been enriched with two new types of agents that, on the one hand simplify the distribution of tasks inside a grid of agent platforms, and, on the other hand, facilitate the composition of tasks through the use of production rules. Moreover, the paper describes how such kinds of operations are executed through the proper authentication and authorization mechanisms. 1. Introduction The grid and agent concepts have begun to be used in connection to indicate with the term of agent grid a new generation of grid systems where agents serve as both enablers and customers of the grid capabilities. Since the term is the union of two words for which a unique and commonly accepted definition does not exist, even more so the agent grid concept is generally used to refer to different things, and seen from different perspectives, although these perspectives are quite related. Our view is that an agent grid refers to an infrastructure that can facilitate and enable information and knowledge sharing at the semantic level in order to support knowledge integration and services composition. To realize an agent grid system, two different lines are possible: i) to extend grid middleware to support agent features and ii) to extend agent-based middleware to support grid features. Following the second lines, an important question arises: is there at present any implemented agentbased middleware which can be suitable to realize a grid? Probably, at this time no agent-based middleware may be used for the realization of a true grid system. Considering JADE [1], which is the leading open source framework for the development of multi-agent systems, it provides lifecycle services, communication and ontology support, security and intra-platform mobility support, persistence facilities, and system management. Without a doubt these features represent an important part of realizing the Grid vision, but we believe that more is needed in order to have a true grid. Our aim is to enhance the JADE framework adding mechanisms for code distribution, reconfiguration, goal delegation, load balancing optimization and QoS definition. In this paper we present a short review of the research conducted on the field of agent grid, and then the results achieved in the first phase of our multiphase effort. In particular we ll describe the advantages provided by the integration of a rule-based framework, Drools, and a scripting engine, BeanShell, inside JADE. 2. State of the art Web services, grid services and agent-based grid services defined a path towards a unifying technologies for the integration of distributed applications and components to provide different kinds of services via Web. In the following, we present a short introduction of the state of art on these three topics Web services Web services [2] are emerging as an interesting abstraction to build distributed systems. Its strength relies above all on the possibility to link together heterogeneous components, developed using various

2 programming languages and paradigms and deployed in different computing environments. Web services publish their interfaces and invocation methods on intranet or internet repositories, where they can be dynamically discovered by clients. Eventually an XML based protocol can be used to invoke the services and obtain their results. The most important standards which web services are built on are the SOAP protocol [3], to transfer messages between distributed applications, or services, and the XML language to encode exchanged data. Essentially, SOAP is a one-way stateless message transfer protocol. More complex interactions can be built by sending multiple one-way messages and exploiting features of the underlying protocols. The SOAP protocol can lay on different message-oriented technologies, like HTTP or SMTP. Even if the HTTP protocol is widely adopted as a de-facto founding technology, this is not a strict requirement of the SOAP standard. No assumptions are made on the semantic of the exchanged messages. SOAP only deals with the routing of messages on reliable transport mechanisms, possibly even across internet firewalls. Conversely, the XML extensibility features are used to convey whatever structured information among distributed components. Web services can be advertised and discovered on UDDI registries [4], available either as intranet accessible services or as internet public directories. Conceptually, the information provided in a UDDI registry is threefold: a white pages service contains a description of the registered businesses, contact information and a simple categorization; a yellow pages service lists all the services provided by each business, some categories and other short information that describe the services; a green pages service provides the technical details of each service, for example its type and the URL where it can be contacted. In facts, each service can be associated with a service type, where interface definitions, message formats, message protocols, and security protocols can be defined. WSDL [5], an XML based language, can be used to describe the interfaces, together with their invocation methods, exposed by web services. These descriptions can be advertised and discovered using UDDI registries. WSDL describes a Web service at two different levels. A first, more abstract, level allows the description of the messages that a service can send and receive, typically using an XML schema. Message exchange patterns can be described as operations, and operations can be grouped in interfaces. Another, more concrete, level allows to specify the bindings between interfaces and transport protocols. Here services are associated with concrete endpoints, i.e., network addresses where they can be contacted Grid services The Open Grid Services Architecture (OGSA) [6] is an effort towards the standardization of a grid architecture. The proposed standard is based on web services concepts and technologies. The founding concept is the grid service, that is a web service exposing a well defined set of interfaces and behaviors. The complete interface of a Grid service is described in a WSDL document and advertised through public registries. Mechanisms are provided for discovering the characteristics of available services. A standard representation of service data is defined as a structure of XML elements and a standard method is exposed by grid services for pulling their individual service data. Registry services can be used to register information about grid services instances and handle map services can translate handles into concrete references to access grid service instances. A standard factory interface is defined, together with its semantics, to allow the dynamic creation and management of new service instances. Two interfaces are defined for freeing the resources associated with grid service instances. Either services can be destroyed explicitly, or their lifetime can be managed by defining a termination time (soft lifetime management). The termination time can be refreshed by keep-alive requests. Abstractions are provided to allow the asynchronous notification of interesting state changes in grid services. Services can expose notification source or notification sink interfaces, to subscribe and push service data in an event-driven fashion FIPA Agents A different, but somewhat parallel, effort to standardize a framework for the integration of remote services and applications is instead founded on autonomous software agents. The FIPA standards [8] describe at various levels how two autonomous agents can locate each other by registering themselves on public directories and communicate by exchanging messages. FIPA agents are situated into a specific environment, which should provide the resources and services they need. In particular, FIPA defines

3 directory services for registering and discovering agents and services, and transport services for delivering messages. The agent directory service provides a location where agents can register their descriptions and where they can search for other agents they want to interact with. Basically, the agent directory service stores entries, where each agent name is bound to one or more agent locators, i.e. transport addresses where agents can be contacted. Message-based interfaces are also defined for the creation and lifecycle management of deployed agents. The service directory service, instead, provides a location where agents and other entities can register and discover descriptions for available services. The entries stored in service directory service bind a service, identified by means of a unique name, to a service type, some service locators to concretely access the service, and optional attributes. Compared to web services directories and UDDI, the FIPA service directory service lacks the so-called green pages service, where technical details and interfaces to contact the service could be registered and discovered dynamically. In FIPA agent systems, agents communicate by exchanging messages which represent speech acts. Each message is structured as a tuple of key-value pairs and is written in an agent communication language, such as FIPA ACL. Its content, instead, is expressed in a content language, such as KIF or SL. Ontologies, listed within the ontology slot of the message, can ground the content to a semantic domain. The sender and the receivers of a message are expressed as agent names, i.e. unique identifiers for agents. When a message is sent to a remote platform, it is encoded into the payload of a transport message, using a representation appropriate for the particular transport mechanism, for example an HTTP connection. The transport message can also have an envelope, containing transport addresses of involved agents and all relevant information about how to deliver the message Agent-based grid services Trying to overcome the strong differences among these approaches, a number of research works are being directed toward the identification of a more generic architecture, in particular, to allow the composition of heterogeneous services provided on the web. The DARPA CoABS Grid [7] leverages existing Java network technologies, like RMI and Jini, and FIPA compliant [8] agent platforms for agent messages, to build a grid infrastructure. One of the main aims of the project is to demonstrate the value of grid concepts as a glue to achieve interoperability among different multi-agent systems, including RETSINA [9] and OAA [10]. Interconnectivity among objects and other components is also supported. In the SoFAR project [11,12], agents realize a grid system where they are able to provide services. In particular, grid agents advertise the services they provide through UDDI repositories and WSDL descriptions. In [13], authors deal with the composition of web services to implement business processes. WSDL is used for the operational and behavioral descriptions of services. BPEL4WS [14], WS-Coordination [15] and WS-Transaction [16] are used for composing and choreographing services. Instead, in [17], DAML-S [18] is preferred to other solutions to represent not only properties and capabilities of web services, but even workflows of compound services. In particular, DAML-S is argued to be best fit QoS issues, as these cannot be separated from semantics and context of services. In [19] extended UDDI registries are used for the implementation of a QoS-based service discovery system. Each service provider is associated with two descriptions: a functional interface, for the service invocation, and a management interface, for the QoS attributes and performance characteristics. 3. Towards an agent grid: adding rule and code mobility to JADE In our opinion there could be a significant synergy between agents and grid when the problem to be solved concerns the execution of an application/service composed of a large set of independent or loosely coupled tasks, Particularly when some interactions among tasks and even some of the tasks to be executed may be only defined during the execution of the application. In fact, this kind of problem requires an intelligent movement of tasks (from a node to another one) to reduce the high communication cost for managing the interaction between remote agents (nodes), and requires an intelligent task composition and generation to cope with the management of the new interactions and tasks defined during the execution of the application.

4 On the basis of the previous idea, we started to improve the JADE agent developing framework to make it suitable to realize true grid agent systems. Our first steps were the realization of new types of agents that support: i) rule-based creation and composition of tasks and ii) mobility of code at the task level (i.e., JADE behaviors or simply rules are exchanged by agents) BeanShell and Drools BeanShell [20] is an application written by Pat Niemeyer that allows to use Java as a scripting language. Usually, the main difference between a scripting language and a compiled one, lies in the handling and control of types. In this sense, BeanShell is a new type of scripting language: it allows the developer not to renounce to type control. In this way, it is possible to write BeanShell scripts that look like Java applications under every degree. But BeanShell allows to relax the type control to different extents, too, making the code more similar to a traditional scripting language. The advantage of BeanShell is therefore to not impose any sort of syntactic barrier between its scripts and real Java code. All this is allowed by the use of the Java Reflection API. In facts, as BeanShell is executed into the same Virtual Machine where the embedding application is executed, programmers are free to work with true Java objects, inserting and extracting them freely from the scripting environment of BeanShell. Drools [21] is a rule engine that implements the well-known Forgy s Rete algorithm [22]. Drools is open source (LGPL) so it provides important advantages respect to the use of commercial products like JESS [23]. Inside the Drools environment a rule is represented by an instance of the Rule class: it specifies all the data of the rule itself, including the declaration of needed parameters, the extractor code to set local variables, the pre-conditions making the rule valid, the actions to be performed as consequence of the rule. Rule object can be loaded from xml files at engine startup, or even created and added to the working memory dynamically. Rules contain scripts in their condition, consequence and extractor fields. The scripts can be expressed using various languages, fore example Python, Groovy and Java. In this last case, the script is executed by the embedded BeanShell engine. When a rule is scheduled for execution, i.e. all its preconditions are satisfied by asserted facts, Drools creates a new instance of a BeanShell namespace, set the needed variables inside it and invokes the BeanShell interpreter to execute the code contained in the consequence section of the rule BeanShell and Drools agents BeanShell agent integrates the BeanShell scripting engine inside a JADE agent, and provided an API for interacting with it through ACL messages. The FIPA request protocol is used to submit tasks. A specific ontology describes the new AgentAction objects, shown in fig. 1, which can be used to submit tasks and to manipulate variables in the BeanShell environment. Figure 1 - Actions supported by BeanShell agents The code to perform a submitted task is contained into the AgentAction object, in the form of Java statements. If proper permissions are owned, the Java code will be executed by the embedded scripting engine of the BeanShell agent. Drools agent exposes a complete API to allow the manipulation of their internal working memory. Their ontology defines AgentAction objects, shown in fig. 2, to add rules, assert, modify and retract facts. All these actions must be joined with an authorization certificate. Only authorized agents, i.e. the ones that show a certificate listing all needed permissions, can

5 perform requested actions. Moreover, the accepted rules will be confined in a specific protection domain, instantiated according to their own authorization certificate. Figure 2 - Actions supported by Drools agents 3.3 Permissions and protection domains Mobility of rules and code among agents cannot be fully exploited if all the security issues that arise are not properly addressed The approaches to mobile code security are different, depending on the particular threats that should be faced. In the context of our applications, we decided to leave out the problem of threats of hosting environments against received code. These issues are harder to face, and solutions often rely on detection means, more than prevention ones. In our work, we focused on the problem of receiving potentially malicious code, that could harm the hosting agent and its living environment. For this purpose, we leveraged on JadeS [24], the security framework that is already available for JADE, to implement two different layers of protection. When an agent is requested to accept a new rule or task, a first access protection involves authenticating the requester and checking the authorization to perform the action: can the agent really ask to add a new rule, or to perform a given task on its behalf? To perform these tasks, the requester needs particular permissions, i.e. instances of the DroolsPermission and BshPermission classes. A DroolsPermission object can authorize the execution of requests as: add or remove rules; add, remove or manipulate facts. A BshPermission object can authorize the execution of requests as: submit a task; remotely set or cancel a variable. As a consequence, only authenticated and authorized agents can successfully ask another to accept rules and tasks. But till this point, the security measures do not go further what other technologies, like ActiveX, already offer. In facts, once the request to perform a given task is accepted, then no more control on the access to protected resources can be enforced. The agent can choose to trust, or not to trust. But, if the request is accepted, then the power of the received code cannot be limited in any way. Instead, in order to deploy the full power of task delegation and rule mobility the target agent should be able to restrict the set of resources made accessible to the mobile code. The requester agent should be provided with means to delegate not only tasks, but even access rights needed to perform those tasks. This is exactly what is made possible through the security package of JADE, where the distributed security policies can be checked and enforced on the basis of signed authorization certificates. In our system, every requested action can be accompanied with a certificate, signed by a known and trusted authority, listing the permissions granted to the requester. Permissions can be obtained directly from the platform policy, or through a delegation process. Through this process, an agent can further delegate a set of permissions to another agent, given the fact that it can prove the very possession of those permissions. The final set of permissions received through the request message, can finally be used by the target agent to create a new protection domain to wrap the mobile code during its execution, protecting the access

6 to the resources of the system, as well as those of the application. Finally, masquerading and alteration threats are prevented by establishing authenticated, signed and encrypted channels between the remote components of the system. 4. Conclusion In this paper, we have presented an extension of the JADE agent development framework that may be the basis for a development framework for flexible agent grid systems. In particular, we have introduced two new types of agents: i) the BeanShell agent able to receive and execute behaviours coming from other agents, and ii) the Drools agent able to receive and execute rules coming from other agents; both the agents are able to perform their duties through the proper authentication and authorization mechanisms. Our current work is about the second step of the path towards a development framework for flexible agent grid systems, that is, the development of some intelligent mechanisms to provide agents able to perform both task composition and generation. References [1] JADE Home Page, Available from [2] Web Services Description Working Group Home Page, Available from [3] SOAP Specifications Home Page, Available from [4] UDDI Home Page, Available from [5] WSDL Specifications Home Page, Available from [6] Open Grid Services Architecture Home Page, Available from [7] CoABS Home Page, Available from [8] FIPA Home Page, Available from [9] K. Sycara, J.A. Giampapa, B.K. Langley, M. Paolucci. The RETSINA MAS, a Case Study. In: Software Engineering for Large-Scale Multi-Agent Systems: Research Issues and Practical Applications, A. Garcia, C. Lucena, F. Zambonelli, A. Omici, J. Castro, eds. Vol. LNCS 2603, pp , 2003, Springer-Verlag, Berlin, Germany. [10] D.L. Martin, A.J. Cheyer and D.B. Moran. The Open Agent Architecture: A Framework for Building Distributed Software Systems. Applied Artificial Intelligence 13: [11] L. Moreau. Agents for the Grid: A Comparison for Web Services (Part 1: the transport layer). In Proc. IEEE International Symposium on Cluster Computing and the Grid, Berlin, Germany, [12] A. Avila-Rosas, L. Moreau, V. Dialani, S. Miles, X. Liu. Agents for the Grid: a Comparison with Web Services (part II: Service Discovery). In Proceedings of Workshop on Challenges in Open Agent Systems (AAMAS02), pp , 2002, Bologna, Italy. [13] F. Curbera, R. Khalaf, N. Mukhi, S. Tai, S. Weerawarana. The next step in Web services. Communication of ACM, 46(1):29-34, [14] Business Process Execution Language for Web Services 1.1, Available from [15] Web Services Coordination 1.0, Available from [16] Web Services Transaction 1.0; Available from [17] C. Patel, K. Supekar, Y. Lee: A QoS Oriented Framework for Adaptive Management of Web Service Based Workflows. Proc DEXA 2003, pp , [18] DALM-S Home Page, Available from [19] R. Al-Ali, O. Rana, D. Walker, S. Jha, S. Sohail. G- QoSM: Grid Service Discovery Using QoS Properties. Computing and Informatics Journal, 21 (4), [20] BeanShell Home Page, Available from [21] Drools Home Page, Available from [22] C.L. Forgy. Rete: A Fast Algorithm for the Many Pattern / Many Object Pattern Match Problem. Artificial Intelligence 19(1), pp , [23] E.J. Friedman-Hill. Jess, the Java Expert System Shell. Sandia National Laboratories, Available from [24] A. Poggi, G. Rimassa, M. Tomaiuolo. Multi-user and security support for multi-agent systems. In proc. Of WOA 2001: Modena, Italy