Today, Grasshopper is the agent platform of choice in multiple international research projects within the European CLIMATE (Cluster for Intelligent Mobile Agents for Telecommunication Environments) . A common aspect of most of these projects is to explore the usage of agent-based middleware in particular application domains, such as service control in fixed and mobile networks, telecommunications management, electronic commerce, multimedia applications, etc.
In the following section a detailed overview of the concepts and capabilities of the Grasshopper agent platform is given. In section 3, we provide an overview of the projects, which are based on Grasshopper.Grasshopper , which has been developed by GMD FOKUS and IKV++ GmbH, is a mobile agent development and runtime platform which is built on top of a distributed processing environment. This achieves an integration of the traditional client/server paradigm and mobile agent technology. Grasshopper is implemented in Java, based on the Java 2 specification. Most importantly, Grasshopper has been designed in conformance with the first mobile agent industry standard, namely the Object Management Group's Mobile Agent System Interoperability Facility (MASIF) . In addition, the latest Grasshopper version is also compliant with the specifications of the Foundation for Intelligent Physical Agents (FIPA) .
Figure 1: The Grasshopper Distributed Agent Environment
Two types of agents are distinguished in Grasshopper: mobile agents and stationary agents. The actual runtime environment for both mobile and stationary agents is an agency ; on each host at least one agency has to run to support the execution of agents. A Grasshopper agency consists of two parts: the core agency and one or more places. Core Agencies represent the minimal functionality required by an agency in order to support the execution of agents. The following services are provided by a Grasshopper core agency:
Communication Service: This service is responsible for all remote interactions that take place between the distributed components of Grasshopper, such as location-transparent inter-agent communication, agent transport, and the localisation of agents by means of the region registry. All interactions can be performed via CORBA IIOP, Java RMI, or plain socket connections. Optionally, RMI and plain socket connections can be protected by means of the Secure Socket Layer (SSL) which is the de-facto standard Internet security protocol. The communication service supports synchronous and asynchronous communication, multicast communication, as well as dynamic method invocation. As an alternative to the communication service, Grasshopper can use its OMG MASIF-compliant CORBA interfaces for remote interactions. For this purpose, each agency provides the interface MAFAgentSystem , and the region registries provide the interface MAFFinder .
Registration Service: Each agency must be able to know about all agents and places currently hosted, on the one hand for external management purposes and on the other hand in order to deliver information about registered entities to hosted agents. Furthermore, the registration service of each agency is connected to the region registry which maintains information of agents, agencies and places in the scope of a whole region.
Management Service: The management services allow the monitoring and control of agents and places of an agency by (human) users. It is possible, amongst other things, to create, remove, suspend and resume agents, services, and places, in order to get information about specific agents and services, to list all agents residing in a specific place, and to list all places of an agency.
Security Service: Grasshopper supports two security mechanisms: external and internal security.
Persistence Service: The Grasshopper persistence service enables the storage of agents and places (the internal information maintained inside these components) on a persistent medium. In this way, it is possible to recover agents or places when needed, e.g. when an agency is restarted after a system crash.
As an alternative to the communication service, Grasshopper can use its OMG MASIF-compliant CORBA interfaces for remote interactions. For this purpose, each agency provides the interface MAFAgentSystem , and the region registries provide the interface MAFFinder . Those interfaces are defined in the MASIF standard. Note that the following sections only describe the Grasshopper communication service. Detailed information about MASIF can be found in the standard itself.
Figure 2: Multi-Protocol Support in Grasshopper
To achieve secure communications, RMI and the plain socket connection can optionally be protected with the Secure Socket Layer (SSL).
Within a region, Grasshopper is able to determine dynamically the protocols supported by a desired communication peer and to select the most suitable protocol for the remote interactions.
Since the supported communication protocols are realised via a plug-in interface, developers can easily integrate new communication protocols by writing their own protocol plug-ins. In this way Grasshopper is open for future requirements that may come up in the changing communication world. Whilst this is advantageous for the Grasshopper developers, what is the benefit for potential end users? Consider a network of a large company. Usually, such a network is connected to the Internet via a router and protected by a firewall running on the router. Thus, only a fixed number of ports is visible to users outside of the company's intranet. Grasshopper can use this intranet strategy to protect users from malicious agents by providing a single agency as an access point to the intranet, permitting only secure interactions to the outer world. Inside of the intranet, agencies may interact by taking advantage of fast but insecure connections.
Regarding access control, Grasshopper is strongly oriented towards the security mechanisms of Java2. It makes use of an access control policy based on identity and group membership that is initialised at start-up. In Grasshopper, an access control policy consists of an access control list comprising several entries, one for each subject treated in this policy, where a subject can be a single identity or a group consisting of 1..n members. A set of permissions is associated with each subject, granting access to all-important parts of the Grasshopper agency. Each permission consists of a type, a target and optionally one or more actions.
When an agent tries to make a system access, an access controller is consulted to make the access decision. In fact, the access controller is invoked each time a system access occurs, but it is capable of distinguishing whether the access was made by an agent or by trusted system code, e.g. the Grasshopper core. If the access came from an agent, the access controller extracts the agent's owner from the agent itself. With this information, it contacts the Policy object, a runtime representation of the Grasshopper access control policy, to extract the set of permissions valid for this subject. If the subject is a member in one or more groups, the group permissions are added to the individual permissions. It is then checked if the permission to perform the access is contained in the set of permissions granted to the subject. If not, an access control exception is thrown.
While the first scenario can be avoided by buffering the agent until its arrival has been confirmed, the remaining two need other approaches. A copy of the agent object has to be maintained on a persistent medium, e.g. a hard disk. If the agency crashes, persistent agents can be reloaded from this medium after the agency has been restarted. Besides, idle agents (i.e. agents just waiting for an event without executing any task), do not need to remain instantiated, but could be stored permanently and then removed from the agency's memory in order to save resources. If a request for such a flushed agent arrives, it can be re-instantiated in order to handle the request.
Grasshopper provides mechanisms to handle all the topics mentioned above if the persistence service is enabled.Due to the increasing acceptance of the FIPA standards  and the resulting demand for FIPA conformant agent platforms, Grasshopper has been extended by a corresponding package, referred to as 'FIPA Add On' which was motivated by the similarity of OMG MASIF and FIPA Agent Management System concepts.
The FIPA Agent Management System specification proposes the concept of an Agent Platform (AP) consisting of three basic services. These services are namely the Agent Management System (AMS), the Directory Facilitator (DF) and the Agent Communication Channel (ACC). Agents are considered residing on a home agent platform (HAP) if they are registered at the HAP's AMS. Agents may offer their services to other agents and make their services searchable in a yellow pages manner by the DF if they register at the DF. Registration at a DF is voluntary, whereas registering at the AMS is mandatory for being in an AP. Finally the ACC enables agent communication (AC) between agents on a platform and between platforms by offering a message forwarding service called forward . Reachability between platforms is gained by making the forward service available by IIOP.
Grasshopper provides the main components of a FIPA compliant platform in the form of corresponding stationary Grasshopper agents (see Figure 3).
To support platform interoperability as required by FIPA, the ACC has to support IIOP. Grasshopper supports this protocol since the Java JDK contains a complete ORB including IIOP.
The class FIPAAgent, which forms the basis for the FIPA platform components, extends Grasshopper's class StationaryAgent . Agent developers have also to use this class as the basis for their agent application. The class FIPAAgent offers two methods: send() and message() . With them, the ACL-message exchange over the ACC is realised. The method send() requires a parameter of the type ACLMessage and server for dispatching of messages, whereas the message method serves for retrieval of messages.
Figure 3: Realisation of the FIPA Agent Platform Components on Top of Grasshopper
According to the FIPA standard, the AMS is responsible for the management of operation of the agent platform. This encloses the management of the agent and the agent state. All these features are already provided by Grasshopper. Thus, the AMSAgent provides a FIPA compliant interface to the Grasshopper agent management facilities.
The DF realises a 'yellow page' in a FIPA compliant platform. In Grasshopper this functionality is already realised by the Region Registry . Thus, the DF is realised as a wrapper of these features. In detail, the functions of the DF are as follows:
The ACC component is also implemented as a Grasshopper agent. Inheriting from the class FIPAAgent, it provides the message and send methods. The ACC agent is responsible for the communication of FIPA agents residing on different agent systems. For this, the ACC agent has to be available on each agent system belonging to a FIPA conformant environment. To support IIOP, which is necessary for interoperability, the ACC agent has to be provided with a CORBA interface. The ACC agent inherits from a corresponding super class according to the particular CORBA implementation. Then, as a CORBA object, the ACC agent's methods can be invoked via IIOP.
The Grasshopper FIPA Add-On implementation supports the new standard language for the World Wide Web, i.e., the eXtensible Markup Language (XML) as well as the FIPA ACL described by the FIPA 97 Specification (part 2). An appropriate parser for FIPA ACL has been implemented and is provided to the FIPA agents, i.e., the FIPA platform components ACC, DF, AMS as well as to the applications. Using the publicly available XML engine from IBM makes it easy to parse the incoming XML message. With XML, appropriate ontologies can be specified for different application domains. The communication between the FIPA agents takes place with the default communication language, either FIPA ACL or XML ACL, which is selectable when starting the FIPA platform. The real message content (i.e. message payload) can be encoded in FIPA SL1 or XML without any extra user intervention. It is left to the users to develop their specific own parser implementation to support any other, perhaps proprietary, content language.Grasshopper can be used in many different application contexts. Historically, the telecommunications domain is probably one of the most prominent application areas. Grasshopper is used today in several European projects. Most of these projects belong to CLIMATE , the Cluster for Intelligent Mobile Agents in Telecommunication Environments, which is part of the European Research Programme on Advanced Communication Technologies and Services (ACTS). It should be emphasised that most of these projects concentrate on application-specific enhancements of Grasshopper. The objective of the ESPRIT ANIMA project  has been to develop and validate agent-based solutions to support the dynamic deployment of commercial applications on easy-to-use terminals such as Windows CE based screen phones. Therefore, ANIMA applications need to be able to run on deeply embedded systems which have extremely tight memory space, a low-bandwidth network connection and a limited physical user interface (screen area and input medium). Therefore, the ANIMA core has to be adapted and shrunk to a small memory footprint, and the network bandwidth will need to be reduced to a minimum.
Grasshopper is used as the basis of the ANIMA platform extended with various facilities as required by deployment in a commercially-oriented end user environment. In the main, these extensions support Windows CE based devices as well as areas of security, platform and service management.The CAMELEON project  aims for an agent-based implementation of the Virtual Home Environment concept, considered key for 3 rd generation mobile communication systems (e.g. UMTS). Universal adapted service access for roaming users in mobile environments is also a key feature. In this project, Grasshopper forms the basis for the realisation of enhanced customer service control applications, as well as agent-based service access, delivery, customisation and mobility management. An important aspect has been to make Grasshopper also available for Windows CE based terminals, which are considered to be important devices in the UMTS context. The main goal of the EURESCOM P815 project  has been to analyse, design and develop a prototype of an agent-based workflow management system that can be deployed for the automation of inter-domain telecommunication business processes. Additionally, the project has developed, tested and validated a set of appropriate inter-domain business process scenarios. The selected scenarios were International Leased Line Provision (ILLP) and Intelligent Networks, for each of which a set of intelligent agents providing the individual functional steps of the business processes will be developed and tested.
The FIPA-compliant version of the Grasshopper Agent Platform is the underlying platform for the development of the workflow management system, as well as the development of the business process intelligent agents. In addition, the agent-based workflow management system and the inter-operation of the Grasshopper platform with other FIPA compliant agent platforms have been integrated.The goal of the FACTS (FIPA Agent Communication Technologies and Services) project  has been to validate the work of FIPA and other standards groups by constructing a number of demonstrator systems based on proposed standards. Note that the project focuses on the interaction between differently implemented agents, and not on agent technologies or on the application domains that will be used as a vehicle for the project.
GMD FOKUS and Alcatel Belgium used Grasshopper as the development and test platform for an Agent-based VPN application. The developments (done in parallel by the two partners) makes use of the FIPA ACL extensions and XML/RDF support on top of Grasshopper.MARINE  introduces agent platforms into a broadband IN architecture, enabling the provision of agent-based IN services directly at the distributed IN switches, which by the introduction of agent platforms become IN Service Nodes. This enables decentralised service provision and decreasing signaling network load.
Grasshopper forms the technical basis for this project. In addition to the development of Grasshopper based broadband IN services and making use of wrapped signaling interfaces (B-INAP), an important aspect is the development of a Grasshopper-based service management system for Grasshopper-based service environments.MARINER  introduces agent technology for traffic control in existing Intelligent Networks, where agents located at IN switches (SSPs) and central service control nodes interact for strategic decision-making. The focus is on Agent Communication based on the FIPA specifications.
For this project, Grasshopper is enhanced with a FIPA Add On (providing FIPA conformant ACL-Interfaces) and used for the implementation of appropriate load balancing agents which exchange Signaling System No. 7 load and node load information.MIAMI  has developed mobile agent solutions for the management of the Open European Information Infrastructure and created a unified mobile intelligent agent framework that supports those solutions in an adequate way. The MIAMI project on the one hand uses Grasshopper as a basis to develop new or enhance existing features of the Grasshopper platform. The main areas are security, resource management, logging services, agent communication transport services, and high level agent communication services. On the other hand, the MIAMI project uses Grasshopper for the deployment of mobile intelligent agents developed in the project. Those agents are used for purposes like the automated establishing and managing of virtual enterprise together with workflow management supporting agents. They are also used for a variety of network management purposes such as fault, performance, and configuration management. The Grasshopper agent platform is the enabling technology for many European agent projects. A comparison of Grasshopper with other MA platforms, such as IBM Aglets Workbench, Concordia, Odyssey, and Voyager is given in .
The first Grasshopper version was released in summer 1998. In February 1999, Grasshopper Release 1.2 has become available, which offers a simplified user interface for the security configuration. Besides, the communication protocols are realised via a defined plug-in mechanism that enables the easy integration of additional communication protocols. Release 2.0 of Grasshopper (available autumn 1999) offers the following new features:
The Grasshopper FIPA Add On (available autumn 1999) works with both versions 1.2 and 2.0.
Future application domains for Grasshopper will be the ongoing integration of voice and data networks, unified messaging, and active networking. Furthermore, major emphasis will be placed on using Grasshopper for electronic commerce applications, e.g., financial services, and the implementation of distributed internet search engines, where the integration of existing web information is of pivotal importance.
For more papers related to this subject please look at the download/paper section of the IKV web site . Furthermore, you can obtain a free demo version of Grasshopper, in order to experiment with this new technology.
The next section of this document: Interviews