The agent platfrom A-globe ver 2.1 is a major feature release. The features listed below are introduced in ver 2.1 since the previous release distribution.
A-globe ver 2.1 uses Java 2 edition 5.0. This version of JAVA or later is required for running A-globe ver 2.1. New components of A-globe platform utilize new JAVA language features, such as generics, enhanced for loop, etc. It also utilizes other runtime improvements, such as garbage collection ergonomics, string builder, opengl, etc.
There is a Library Manager component in each agent container since A-globe ver 2.1. The previous release version of A-globe used only one Library Manager per agent platform (running in one JVM) where one or more agent container could be running.
Every new loaded library in A-globe container internally uses the library name constructed from the original library name and SHA-1 hash of the library content. The loaded library is automatically marked with a unique version label in the form ver{#ver_num_in_the_container}@{container name}. This way, two different libraries with the same filename are used as two libraries by the A-globe platform. The library can be removed until a class loader opens it.
Each agent and service has class loader defined. If an agent/service doesn't use any special library, it uses a bootstrap class loader. The bootstrap JAVA class loader finds classes only in the name space defined in the path specified by the starting CLASSPATH parameter or manifest CLASSPATH parameter in the jar library used by Java Runtime. If an agent/service uses one or more own libraries, it has its own class loader defined which tries to load classes in specified libraries. An agent class loader always prefers classes defined by the bootstrap class loader. So, it has no sense to define your own java.lang.String class because it can never be used. The agent/service class loader defines agent/service class resolving name space. The migration process and the message transport layer always uses respective name space.
In the agent container more agents can run with the same main class but still different class definitions. For example there can be more migrating agents using examples.agent.migrating.MigratingAgent main class, but each agent uses its own library with a different class definition.
The previous release version of A-globe has only a message transport component in the agent container. All messages sent between two agent containers running in one agent platform were sent via TCP/IP stream. In the latest release, there is also a message transport component in the agent platform through which local messages are passed. This enhancement improves message sending speed between agent containers in one Java Virtual Machine.
The message transport layer takes care that all message are serialized/marshaled and deserialized/unmarshaled in the appropriate class name space depending on the sender and receiver agent/service's class loader.
In a scenario, the actor agents and the environment simulation agents can communicate using topic messaging - the container-to-container messaging as shown on figure below. The actor agents play roles in the simulated world. The environment simulation agents are used for the world simulation - the container position in the simulated world, the visibility simulation, the weather simulation, etc. The ES agents are located in the server container.
Topic messaging is managed by GIS Service - a special service that is a part of the A-globe platform and can be started in a container by specifying an appropriate startup parameter (-server or -client). This parameter determines whether the container is a server side container or a normal container with actor agents.
The GIS/server service provides several methods for working with topic messaging by its service shell object: subscribeTopic, unsubscribeTopic, unsubscribeAllTopics, broadcastTopic, sendTopicToLocal, sendTopic. The GIS/client service shell object provides: subscribeTopic, unsubscribeTopic, unsubscribeAllTopics, submitTopicToServer, submitTopicToLocal, submitTopic.
The Class Finder component of A-globe searches for all available agent/service classes in the agent container's library manager when the new agent or service dialog is shown. It provides a list of main classes for easy startup of the new agent/service. When an agent/service is defined in a specific loaded library and that library is required for running it, the library requirement is indicated by the library name and version coming after the character '@' as shown on the picture below.
The Directory Service provides extended yellow pages services supporting inaccessibility controlled by visibility updates. The service is automatically started on every client container. Example use of directory service can be found in examples.agent.directory.DirectoryAgent. The white pages services container/(agent|service)/directory and search service are deprecated since A-globe ver 2.1.
There are several enhancements in the sniffer agent since the previous A-globe release:
The Communication Analyzer provides a view of the intensity of interactions between agents. Communication Analyzer presents selected agents, filtered by a regular expression, in a circle. Messages exchanged between agents influence the color and width of the links between communicating agents. In order to keep the image updated, old messages fade away progressively and only the most recent ones are visible. The communication analyzer agent can run only in the server container like the sniffer.