Object Services and Consulting, Inc.

Agent Systems Comparison

- In Progress -

Paul Pazandak
October 1998

An initial comparison of agent system software and related technologies.

Linking: The major categories are linked to descriptions below.
Feature / System Voyager Jini IBM  Aglets GM Odyssey JATLite D'Agent OAA2 JavaSeal KAoS Concordia Mole
Type
- Mobile Agent (MA) 
- Stationary Agent (SA) 
- Simulation S/W (Sim) 
- Aux. S/W (Aux)		 MA Low-level 
Infra- 
structure		 MA MA Aux (msg router infrastructure) MA MA MA MA MA
Language Java Java Java Java Java Tcl+ da2 7 oa1
[ICL]		 Java Java Java Java
System Purpose
- Component (e.g. JATLite) 
- Enabler 
- Basic Agent Development 
- Advanced Development 
- Specialized		 BAD Enabler BAD BAD Communications BAD AD BAD AD BAD BAD
Components      
=Agent   N/A    
----Remote Creation Yes N/A Yesag1 Yes No Yes No Yes
----Composite Agents No N/A No No No Yes da3 No Yes js1 Yes No No
----Agent IDs N/A unique per host global IDs unique globally unique IDs, badges
----Interface_Exposed? Yes N/A Yes Yes No No No
=Substrate "Subspace" / 
"Voyager Server"		 "Federation" "Context" "Place" -- "Server" "Server" "Server" and 
Lightweight Transporterco3		 "Place"
----Substrate Mgmt per servervo3 per federation per contextag7 place/system od5 per router per server per server Yes - per server 
No - per appl. co1		 per place
----Agent-biosphere Yes No Yes Yes No Yes Yes Yes Yes
----Loosely/Tightly-coupled 
      sub-systems		 Loosely Loosely Loosely Tightly od5 unsure how/if they connect Loosely Loosely Loosely Loosely
----Interface_Exposed? No likely unclearag8 Yes Yes No Yes
----Logical/Physical_Collective Physical Logical Physical Physical Logical Physical Physical Physical Physical
----Federation_Structure 
        (e.g. hierarchic/flat)		 hierarchic hierarchic flat flat flat flat flat flat flat
=Security extension of 
java.lang. 
SecurityMgr		 Distributed 
Security 
Model		 extension of java.lang. 
SecurityMgr		 Not Addressed Basic Host_list da1 Advanced Basic
----Credentials/Certification No(?) ACL No N/A No No Credentials
----Authentication No ? No N/A Name/Password No Yes Name/Passwd 
Third party poss.
----Meeting Secrecy No No No N/A No No No No
----AccessRights_Assignable No Yes Yes N/A No Yes - server Yes
----Resource control 
     and protection		 Some based on ACL Some N/A No some, see da7 Yes Yes
----Method-Invocation Security No No Yes N/A No No Yes Publish/Subscribe
----Security Levels 2 (Un/trusted) " 2 (Un/trusted) N/A No Unix Yes 2 (Un/Auth)
----Interface_Exposed? Yes likely, little info Yes N/A No No No
=Agent_Communications Not Addressed
----Location_Transparency Yes N/A Yesag2 No No No N/A No No
----via Proxies Yes N/A Yes No No No No No
----Proxy auto-updated on 
        agent migration?		 Yes N/A No N/A N/A No No N/A
----Direct or via Substrate 
      (Unmanaged/Managed)		 Substrate Direct Substrate N/A Substrate (Router) Substrate Substrate Substrate
----ORB/RMI/Other ORB Any RMI N/A Other Other Other, 
RMI(?)		 RMI/Other
----Methods or Messages Methods Any Messages N/A Messages (KQML) Messages Messages Messages Both. Msgs, RMI
----Dynamic Messaging Yes - added class support Yes Yes Yes - for Worker Agents od4 No No No No
----Centralized/Distributed 
       Lookup Directory		 Hierarchic, 
Distributed, 
Homogen.		 Hierarchic, 
Distributed, 
Heterogen.		 No No od3 Centralized No No Hierarchic, 
Distributed, 
Heterogen.		 Local Only
----Broadcast/Multicast B, M No+ No No No No No No
----Broadcast Object Logical Group 
("subspace")		 N/A No No No No No No
----Broadcast Control any parent node 
& all children		 N/A No No No No No No
----Channels Yes No+ No No No No da8 No No
----Modes (s,ow,f,r,b) s,ow,f b s,ow,f No ow r da4 s,ow,f,boa2 r
----Queue Mgmt No (unless in ORB) N/A Yes, priorities too  ag5 No Yes No No No
----Message Buffering 
     (if agent unreachable)		 No N/A No No Yes, timed-delivery msgs too Yes, see also da8 No No
----Shared Memory/State No N/A No No No No No! No
----Interface_Exposed? No N/A Yes No Yes No No No
=Event Mgmt Implementation Framework 
(very flex.)		 Impementation 
(Java lang.)		 Not Addressed Not Addressed Imple- 
mentation		 Not Addressed Implementation 
(proprietary-RMI)		 Add-on
----Centralized/Distributed/ 
      Object-based		 Object 
[agent, 
system, 
subspace]		 Object Object 
[aglet, context]		 N/A N/A C or D 
(unknown)		 Object Centralized and 
Object-basedco4		 Distributed
----Pre-defined Events Yes (many)vo2 No Yes (8) ag6 N/A N/A No Yes oa6 No No
----Vetoable Events Yes N/A No N/A N/A No No No No
----Before/After Events Both N/A No N/A N/A No No No No
----Extensible Event List? Yes, JavaBeans Yes Likely N/A N/A Yes Yes oa6 Yes Yes
----Handback-Object on Notify No Yes (1) No N/A N/A No No oa4 No No
----Publish/Subscribe Yes Yes Yes N/A N/A No No oa4 Yes Yes
----P/S Security? No No No N/A N/A N/A No Yes - user Yes
----Local/Global Subscription Global Global ? N/A N/A Local? Local Local/Evt Mgrco7 Global
----Location-Transparent 
       Notification		 Yes No No N/A N/A N/A No Yes Yes
----Group Notification No No No N/A N/A No No Yesco6 -flat Yes-hier.
----Specialized_Event_Listeners Yes No. notify() No. N/A N/A No da8 No Yes (4)
----Persistent / Temporary 
        Subscriptions?		 Persistent or 
Process-life		 Leased Process life(?) 
(Java Listeners)		 N/A N/A N/A Temporary
----Listeners are interfaces Yes Yes Yes N/A N/A No No Yes
----All-Event Listener  Object-level Yes Yes N/A N/A No No Yes
----Rules_Support No No No N/A N/A No Yes*oa4 No Yes
----Event Caching / Mailbox No No No N/A N/A Yes da8 Yes Yes - during agent transit Yesmo2
----Interface Exposed? No Yes Yes N/A N/A No No Yes
=Mobility Weak Migration Code On Demand Weak Migration Weak Migration Not Addressed Strong Migration Not 
Addressed		 Weak Migration Weak Migration Weak Migration
----Autonomous Yes No Yes Yes N/A Yes N/A Yes Yes Yes
----System-Managed Yes Yes Yes Yes N/A Yes N/A Yes Yes (Queue Mgr)co2 Yes
----Agent-Managed Yes (partial)vo4 No No No N/A No N/A No No No
----Unique Method_on_Arrival  Yes No No Yes N/A Yes da5 N/A No Yes No
----Method Parameter List? Yes(1-local obj) on arrival No No No N/A Yes da5 N/A No No No
----Secure Transfer ? No N/A No N/A Yes Yes
----Cloning Yes No Yesag3. Proxy returned. No N/A Yes N/A No Yes Yes
----Serialization_Method Unspecified Java Any 
(def. is Java)		 Unspecified N/A Unspecified N/A Java Java Java
----Object_Mobility 
        (migrates with Agent)		 Yes, specified objects Noji1
(service APIs)		 Yes No N/A Tcl variables N/A Yes Yes, member vars 
& specified classes		 No
----Interface_Exposed? Yes Yes No Yes N/A N/A N/A No No
=Persistence Not Addressedod6 Not Addressed as service Not Addressed Not Addressed
----Agent_persistence Yes N/A Yes No No Not addr. No Yes No
----Object_persistence Yes Yes (APIs) Yes No No No Data persistence Yes No
----Timed_Sleep No No Yes ag4 No No Yes No No No
----Proprietary/xDBC Db API JavaSpaces ? N/A N/A N/A No Proprietary/Java N/A
----Agent Checkpointing No N/A No No No No No Yes No
----Interface_Exposed? Yes Yes Likely N/A N/A N/A No Yes N/A
=Itineraries Mobility Not Addressed Mobility Not Addressed Not Addressed Not Supported
----Specify method per host No N/A No Yes N/A N/A Yes No
----Itinerary Structure java.util.vector N/A N/A Yes (Task) N/A N/A Yes (proprietary) N/A
----Interface_Exposed? N/A N/A N/A No N/A N/A No No
----
=High_Level_Comm
----ACL Support No N/A No No KQML No ICL No No No
----Task Coordination No N/A No No No No Yes No No No
----Meetings N/A N/A No Yes od1 No Yes da6 da8 No No No Yesmo1
----Conversation_policies N/A N/A No No No No Yes No Yes. No No
----Extensible N/A N/A No No Yes No Yes No Yes. No
----Secrecy N/A N/A No No No No No No No No
=Lifecycle [Leasing] Not Addressed Not Addressed Not Addressed Not Addressed
----Modes 5 vo1 1-duration 1 ag4 N/A N/A 4 da7 N/A N/A
----Interface_Exposed? Yes Yes N/A N/A N/A No N/A N/A
=Scalability
----Naming / Locating Yes Yes No No No No Yes oa6 No
----Message Caching No No No No No ja1 ? No
----Communication Yes No No No No No No
----Events No No No No No No No
=Applet_Support Yes Yes Yes Yes Yes No ? No Yes
=ORB_Support Yes No No Yes No No No No No (RMI)
----Proprietary Yes No (RMI) No No (RMI default) No No No No
----CORBA/DCOM Both No No Both No No No No No
=Other Components
----Trader  No - basic name 
lookup only		 Service Locator No No No No Yes No No
----Transaction Yes Yes No No No No No No No
----Other Timing, 
Stopwatch		 - - - - Timing - Remote GUI Server Admin Tools
=Advanced_Features
----Goal-oriented No No No No No No Yes oa3
(via facilitators)		 No
----Collaboration No No No No No No Yes No Basic class supportco5
=Source Code Closed Open/PL Closed Closed NDA Free Nothing Available Licensing? Open/PL

 

General comments:
This table identifies functionality provided by several agent systems. In most cases, if some specific functionality is not implemented directly by a system it can be added -- some more easily than others. The categories included are not complete nor does each category comprehensively describe all possible implementations, rather the categories highlight the current set of important agent system features and provides a suitable means to distinguish between agent systems. Additional comments in red.

Agent

Remote Creation - Some systems, such as Voyager, talk about the ability to create agents at remote sites. This capability boils down to the ability to communicate with a remote site and invoke an operation which causes the instantiation of a new agent directly at that site. Alternatively, one would have to create an agent at a local site then migrate the agent to the desired site. This also requires, or at least benefits from, the ability to locate other servers, so some lookup service should be provided.
Composite Agents - Are agents simple objects or composite objects (possibly where only a portion of an agent migrates -- see KAoS).  The idea of composite agents is interesting and isn't addressed by other systems.
Agent IDs - Forms of Agent IDs, how they are generated (mechanism, locally/globally unique).

Substrate

An agent system is composed of one or more sub-systems, each of which provides a core set of functionality to the agents within its membership. Generally, the membership is tied to a physical location in which the sub-system is running, such as a server, or even a process within a server. We call this sub-system the substrate upon which agents execute. The substrate provides the necessary functionality for agents to operate, e.g. to be secure, to communicate, to migrate, to coordinate, to persist, etc.

Substrate Mgmt - The agent system's name for the domain of control for an agent subsystem. This can also be thought of as a unit of management.
Agent-Biosphere - Is an agent physically tied to the substrate so that it cannot exist independently (the substrate provides the underlying execution environment for the agent)? Conversely, a substrate may provide management functionality without providing an execution environment. Most systems implement agent biospheres, but Jini and JATLite are exceptions.  This is a key design decision when architecting a system. The idea that there is an underlying substrate which restricts and protects the agent as well as the host resources is well-founded. But the issue of interoperability between heterogeneous systems is ever-present. Further, is it the case that all agents require a biosphere, or only those which migrate or operate in a foreign host? This suggests the need for an architecture which supports both as required.
Loosely/Tightly-coupled Collectives - The formation of the entire agent system or collective is achieved through loosely or tightly coupled subsystems. Tightly-coupled systems will be less resilient to network/server problems.
Logical/Physical Collective - An agent system provides some organization of agents into physical or logical groupings as a means to manage, locate, and communicate with agents. Are these groupings tied to or defined by an agent's physical location, or are the groupings logical?  Logical collectives are more adaptive. They could be layered on physical collectives.
Federation_Structure - Is the structure of a collective flat or hierarchical?  This will likely have some effect on the scalability of the system, e.g. communications, although other logical structures could be layered on top of a flat structure.

Security

Security is critical to the success of agent technology, but it has a long way to go. Most systems simply use Java's built-in mechanisms which are insufficient and cannot protect against certain types of attacks, e.g. denial of service.  Further there should be controls in place throughout the system to restrict what can be done without authorization (e.g. directory lookups, communication, migration, event subscribing/publishing, joining groups, joining transactions, etc.).

Credentials/Certification - Does an agent carry something with it to prove its identity?
Authentication - Is some other form of authentication used? e.g. name & password requested
Meeting Secrecy - Can organized communications (meetings) between agents be kept secret?
AccessRights - Does the agent system's security implementation support being able to assign access rights to specific functionality?
Resource control and protection - Is there an ability to restrict access to resources? E.g. how much process time an agent has.
Method-Invocation Security - Is method-level invocation control possible?
Security Levels - How many security levels are provided in the security model?

Agent_Communications

Location_Transparency - Can communication with an agent be maintained through migration? Once communication is established with an agent must it be re-established if the agent migrates?  Since some agents migrate at will it is important that communications (including event notification)  is unaffected by it.
via Proxies - Is location transparent communication enabled throught he use of proxies?
Proxy auto-updated on agent migration - If proxies are used, are they automatically updated when an agent migrates?
Direct or via Substrate - Is agent communication managed by substrate, or is it direct?
ORB/RMI/Other - What protocol/mechanism is used to implement agent communication?
Methods or Messages - Is communication message or method based?
Dynamic Messaging - Is dynamic messaging supported? Can a method invocation be formulated on the fly? (In truth, reflection should allow this).
Centralized/Distributed Lookup Directory - What service is provided to locate agents? Is it centralized, distributed, or simply local?  The ability to locate an agent or service will be critical to many agent applications.
Broadcast/Multicast - Is broadcast/multicast communication supported? Important -- so that large groups or the entire membership can be communicated with easily, and at reduced cost. While not addressed in any system, there should be security controls in place so that the entire collective isn't flooded with messages from an unauthorized source.
Broadcast Object - Is a broadcast to all agents, or some subset -- what is the object of the broadcast?
Broadcast Control - Is any further control provided when broadcasting a message?
Channels - Are broadcast channels supported?
Modes - s - synchronous/blocking, ow - one-way, f - future, r - rendez-vous, b - bulletinboard/anonymous
Queue Mgmt - As many communications could be pending for an agent, is queue management provided?  This is necessary if different priorities of messages will be used
Message Buffering - Is message buffering / caching provided, e.g. in case an agent is unavailable for some duration? Without buffering communications may be lost. Such capabilities may be added of course by using agent proxies.
Shared Memory/State - Can agents share/access/refer to some shared data/state?

Event Mgmt

Centralized/Distributed/Object-based - How are events managed -- by a centralized or distributed mechanism (event managers), or by the event publisher (e.g. object-based, e.g. using java listeners)? A distributed mechanism is the most sophisticated because events are communicated to all event managers in the agent system. In a centralized (or localized) model, subscribers are notified only about events generated by publishers registered to that event manager.  Distributed event management is significantly more complex, but still very useful to a small subset of applications.
Pre-defined Events - Are any default events defined? Although not required, some of these events might be difficult to define if the interfaces are not extensible for some core system events.
Vetoable Events - When (before-type) events occur is there a capability to cancel them? This feature is  not required by any means, but it is an interesting idea.
Before/After Events - Do the pre-defined events include before/after events? E.g. before migration, after migration, etc.  Again, not required, but core events are probably easier implemented by the vendor.
Extensible Event List - Can new events be added? [In most all cases this should be "yes"]
Handback-Object on Notify - When registering as a subscriber, is it possible to specify an object that should be passed back on notification? A very interesting idea, but it may not scale well.
Publish/Subscribe - Is a publish/subscribe mechanism used?
P/S Security - Does a publish or subscribe request have to have authorization before it is processed?
Local/Global Subscriptions - Does subscription to events include ALL system-wide events, or only events which occur locally  This can only be true if the system implements a distributed event management system
Location-Transparent Notification - Once registered can an agent move (without re-registering) and still receive notifications? Alternatively, an agent should be able to disconnect before moving, and reconnect/re-register after the move is complete. All events occurring while disconnectd should be cached.
Group Notification - Can groups of agents be registered to receive event notifications? One use is for group communication.
Specialized Event Listeners - Event listeners may be generic and able to listen for any event, or they may be specialized and only listen for a subset of all events. If specialized, they could contain event-specific methods to enhance their usefulness. If listeners are supported, this could also be implemented by the programmer.
Persistent / Temporary Subscriptions - How long do subscriptions last -- are they persistent or temporary?  Jini's leasing is a very interesting idea because the agent must renew before a subscription expires. A subscription should last as long as the agent is alive and is interested in the event.
Listeners are interfaces - If listeners are used, are they extensible? It doesn't matter so much if they are actually interfaces as long as the classes are not defined as "FINAL" so that the listeners can be extended.
All-Event Listener  - Are all-event listeners available - this enables a subscriber to receive all events without having to subscribe to each one.
Rules_Support - Is a rules mechanism provided so that notification is guided by specified rules?
Event Caching / Mailbox - Are events cached, are mailboxes used? This is important as it supports agents that migrate and disconnect from the collective.

Mobility

Mobility - Using Mole's categorizations: Remote Execution (code sent to remote host), Code On Demand (Code requested by remote host), Weak Migration (autonoumous, data & code moves), Strong Migration (weak + execution state moves)
Autonomous - Can agents move by themselves or are they moved by other objects? In general they should all be able to do this. It simply requires access to an agent or host method, e.g. migrate(this).
System-Managed - Does the system manage the migration? This is most likely true when agent biospheres are used.
Agent-Managed Mobility - An agent, or its proxy, may monitor and participate in the migration of an agent. This capability may be built-in to the system ("Yes"), or perhaps may be added by defining monitoring events and special listeners (see Voyager which defines these). Since the agent is serialized during migration it cannot react to events. The idea of having a proxy watch out for the agent during migration by monitoring and reacting to events is a good idea.
Unique Method Invocation on Arrival - A system may allow a unique (arbitrary) method be specified to be invoked once the agent has arrived to the new location (otherwise it executes a default "activation" method). Further, the system may allow specification of one or more parameters to include when calling the specified method (or when calling a generic arrival method -- so, "invocation on arrival" may not be supported while "Method Parameters List" is supported). This could be easily implemented by adding an extending the default activation method.
Method Parameter List - When an arrival method is invoked on an agent (by the substrate) can a parameter list be specified/provided -- generally the specification of a method and/or parameters is defined within an itinerary which is examined by the substrate when the agent arrives at its destination.  Again, this could be implemented by extending the activation method.
Secure Transfer - Does the substrate provide secure transfer from one subsystem to another?
Cloning - Is agent cloning support built-in? This provides code that duplicates the object and assigns it a unique ID.
Serialization_Method - What method is used to serialize an agent? e.g. Java serialization, proprietary, etc.
Object_Mobility - Can associated objects be identified and transferred automatically when an agent migrates? In some cases this is supported; in others, only a set of classes can be identified for migration. At least one system defines an agent attribute which can be assigned the names of the classes that should be migrated when the agent migrates.  Special care must be taken when objects are shared -- that is, if an agent migrates and takes some set of objects with it, any remaining agents at that site may end up with invalid references.

Persistence

Agent_persistence - Does the system support persisting agents?
Object_persistence - Can data associated with an agent also be made persistent?
Timed_Sleep - Can an agent be put to sleep for some duration? This is really part of lifecycle management.
Proprietary/xDBC - What persistence mechanism is used?
Agent Checkpointing - Can agent state be saved at any time (for recovery)?

Itineraries

Specify method per host - Can a unique method be specified within an itinerary to be executed on arrival, on a per-host basis? ("Unique Method on Arrival" does not address per host uniqueness). Again, this can be implemented in a fairly straightforward manner.
Itinerary Structure - What structure is used to contain the itinerary?  What should be included at a minimum is a list of host-method-parameters triplets to specify what hosts should be visited, what method should be executed at each host, and what parameters should be passed in at a given host.

High_Level_Comm

ACL Support - Does the agent system support an agent communication language?
Task Coordination - Does the agent system support task coordination?
Meetings - Does the agent system support inter-agent meetings?
Conversation_policies - Does the agent system support other kinds of agent conversation policies?
Extensible - Are any of the above extensible if supported?
Secrecy - Does the agent system support high-level communications secrecy (besides meeting secrecy)?
 

Lifecycle

Modes - What lifecycle modes are supported?

Scalability

An agent system may specifically and directly support scalability of some functionality. This pertains to providing supporting mechanisms or inherent design features for the specified functionality in some way that scales to large numbers of agents or agent systems.

Naming / Locating - Naming and locating agents globally
Message Caching - Caching (and delivery) of messages
Communication - E.g. broadcast communications to all subsystems
Events - Sending events to all subsystems

Applet_Support

Does the agent system provide applet support? In general, if the agent system uses Java I've said "yes", although some systems may provide more advanced support for implementing applet-based agents. Applets provide a limited case ability to implement an agent outside of a biosphere -- however it then generally lacks the ability to migrate or receive communications (it would need to initiate any communications).

ORB_Support

Does the agent system use an ORB or some other underlying implementation mechanism? The categories are self-explanatory.

Proprietary -
CORBA/DCOM -

Other Components

Does an agent system provide any other kinds of components/services? Again, the categories are self-explanatory.

Trader  -
Transaction -
Other -

Advanced_Features

What other advanced features does this agent system provide?

Goal-oriented -
Collaboration -

Source Code

Is the source code available?
 

Interface_Exposed - While systems may not expose interfaces to be extended, if events are generated for primary actions in the system then listeners may be used as a means to extend the behavior of the system.

System-specific Comments

Voyager Comments
vo1 - Lifecycle modes: dieAt(time), dieAfter(long), dieAfterInactivityPeriod(long), LiveForever(), dieWhenNoReference()
vo2 - Events - 30+ Events defined for object (mobility, lifecycle and messaging), system, and subspace
vo3 - Substrate Management - One voyager server per VM, multiple servers per host are possible.
vo4 - Agent-Managed Mobility - This is enabled by Voyager's support for before and after mobility-related events and associated listeners. This enables the agent, or its monitoring listener, to monitor and react to mobility events as the agent is moved.

Jini comments
ji1 - Objects migrate in Jini in the context of service APIs that are delivered to requesting clients. Agents are not defined in Jini.
 

Aglet Comments
ag1 - Since a createAglet is sent to an AgletContext, it would seem that if a handle for any AgletContext can be accessed, then an agent should be able to be remotely instantiated.
ag2 - Migrating proxies can continue to communicate with an agent "as long as the aglet resides in the same location.". This seems to imply that location transparency is not supported. They say it will be supported in a future version.
ag3 - Page 2 of the Aglets 1.0 specification states that a clone() operation returns an AgletProxy object, not an Aglet object.
ag4 - Lifecycle modes: Aglets have one mode - they live until dispose() is called.  Aglets can also be deactivated/reactivated: deactivate(t) - serialize & sleep for time t, activate() - wake up a sleeping agent
ag5 -Queue Management - Aglets provides prioritizable message queues, as well as extended management called Message Synchronization -- methods for an aglet to internally handle pending message queues
ag6 - Events - 9 events for cloning, mobility, deactivation, and deletion. Others may be supported (the specification appears somewhat disorganized).
ag7 - Substrate Management - Multiple contexts per VM are possible
ag7 - Substrate - Exposed Interface - The aglets spec describes the Daemon and AgletRuntime classes but doesn't say whether they have been finalized (meaning they cannot be subclassed). They are not presented as interfaces.

Concordia Comments - The documentation available on Concordia was quite incomplete.
co1 - Substrate Management - One Concordia server per VM, multiple servers per host are possible. Also, as agents can move to simple Java applications (see co3), in this case there is no centralized management.
co2 - Server Managed Mobility - Concordia has a special Queue Manager which provides some degree of survivability by managing the movement of agents from node to node, as when a destination node disconnects from the system (it continues to retry). It also provides prioritization and basic execution management of agents on entry to nodes.
co3 - Substrate - Concordia supports both a standard agent server and a lightweight "Agent Transporter" class which allows any application to receive, transport, and execute migrating agents.
co4 - Event Management - Concordia supports both registering listeners with agents as well as event managers. However, the specs do not describe any distributed capacity for these mgrs (e.g. that they interoperate). Agents that have registered for events will be notified even if they migrate (agents make and keep connections with the event manager). Event managers support both synchronous and asynchronous notification. Concordia also supports security checks to permit only authorized users to register events and receive notifications.
co5 - Collaboration - Concordia defines CollaboratorAgents and AgentGroups. A Collaborator Agent can belong to one or more Agent Groups. After acquiring some results the agent calls its collaborate() method which sends the information to the Agent Group object. Each agent is blocked after calling collaborate() until all agents in the group have called it. At this point the Agent Group object can operate on the sum of this information and return a result to all of its members. Concordia provides some recoverability using persistent group objects and group proxies which maintain group membership information.
co6 - Group Notification - In Concordia an AgentGroup can register for event notifications, and when received will pass them on to all member Agent objects (with location transparency). Groups are flat.
co7 - Local/Global Subscriptions - Agents are notified of events which are sent to the event manager that the agent has associated with. If multiple event managers exist, the events are not shared between managers.

Odyssey Comments - Information taken from the product's API documentation, and "Introduction of Odyssey API paper."
od1 - Meetings - Odyssey agents request to meet with other agents by submitting petitions to the agent's server. Meeting requests may de denied.
od2 - Substrate Management - One Odyssey server per VM, multiple servers per host are possible. The API mentions "regions" but does not define this term well enough. It is also not well-integrated into the API.
od3 - Agent Lookup  - Odyssey has a Finder to locate Places but not agents.
od4 - Agent Communication - Oddly enough, Odyssey documentation does not address agent inter-communication; nor how to locate agents to talk to; nor how to keep track of migrating agents. It does however support an Invoke() operation of a subclass of agents called workers. Invoke() takes a method name and a list of parameters, so it allows arbitrary methods to be invoked on a worker. This permits one form of communication. But again, there is no mention of how such a method is remotely invoked, nor is this supported on an agent object.
od5 - Loosely/Tighly coupled - Odyssey defines a BootPlace, when shutdown, the entire agent system is terminated. We define this as a tightly-coupled design. Note that other places can register at any time (we believe), providing some looseness of design. Other management is controlled at the level of a "place"
od6 - Persistence - A number of classes implement the java.io.serializable interface, yet Odyssey does not specifically manage persistence.

JATLite Comments -
ja1 - Scalability - The JATLite documentation briefly mentions scalability but it does not describe how, or if, it is really implemented/supported. My guess is that scalability would have to be built in to JATLite.

JavaSeal Comments-
js1-Composite Agents - JavaSeal supports the creation of agent hierarchies. But in this case, they must always migrate together.
js2 -
js3 -
js4 -
js5 -
js6 -

DAgent/Agent Tcl Comments - taken from the user docs for version 1.1 of Agent Tcl -- no updated docs for D'Agent were available. D'Agent has a C++ kernel with support for different language front-ends. It runs on Unix, NT, Win95.
da1 - Security - Agent Tcl requires a host list (IP addresses) which is used to restrict what other agent hosts may contact a given host and migrate agents.
da2 - Language - Agent Tcl requires an extended version of Tcl which support mobile agents. It is fully compatible with Tcl 7.4.
da3 - Composite Agents - Agent Tcl supports agent hierarchies whereby an agent can have an associated root agent. No further info yet.
da4 - Communication Modes - Apparently, some type of mailbox messaging is used. Senders are asychronous. Receivers may block, not block, or specify a maximum waiting time. Agents don't get messages unless they look for them.
da5 - Mobility - The function is supported in three ways: the agent can migrate -- it resumes execution just after the agent_jump command; cloning (e.g. comparable to a Unix fork()), and creating a child agent -- both allow a script name to invoke and the ability to pass a set of parameters. Also, Agent Tcl supports STRONG migration; however, the Java version is not likely to.
da6 - Meetings - Agent Tcl requires both agents (2) to autonomously be aware of a need to meet & therefore execute meeting commands independently. A receipient may reject a meeting request. Meetings are meant to be a more efficient type of communication between agents than message passing as they allow sending strings directly across an established connection to another agent.
da7 - Lifecycle - Agent Tcl supports 4 types: end now, sleep for t seconds, execute for no more than t seconds (also acts as resource control), execute now with retry on failure.
da8 - Communication/Events/Meetings - Agent Tcl defines a Mask command which hides all messages, events, and meeting requests which are filtered out by the defined masks. A different mask can be defined for each of the 3 types. This doesn't qualify as specialized event listeners or as channels, but is noteworthy. All communications which are filtered out with the current masks are buffered for later retrieval with different (e.g. ALL) masks. There are nine associated commands providing added flexibility.

Mole Comments -
mo1 - Meetings - Mole supports extended (peer-to-peer) communications semantics by allowing agents to asynchronously (PassiveSetUp) or synchronously(ActiveSetUp)  request to meet with other agents. Such meetings are called sessions. Session requests are based upon agent Id or agent-role (badge), and optionally location. When two requests match (complement each other), a session is established by a session manager. A session is either explicitly terminated, or implicitly terminated if one agent moves.
mo2 - Event Caching - Mole has event caching to guarantee agents that disconnect and reconnect receive all registered events. However, at this point, there is no time-out mechanism so all events must be cached indefinitely until the agent reconnects/is reachable.

SRI's OAA Comments - The primary goal of OAA is to provide an infrastructure for integrating distributed heterogeneous applications. The documentation reviewed was for version 2. A commercial "Pro" version is planned, while v2.0 is planned to be freely available under a non-commercial license.
oa1 - Systems can be implemented in various languages (C, C++, Java, Prolog, LISP, Visual Basic, Delphi). Inter-agent communications  use ICL - Inter-agent communications language - to communicate. ICL is used to query, execute actions, exchange information, set triggers, and manipulate data. ICL includes a conversational protocol (like KQML) and a content language (like KIF). In general, agents called facilitators (task coordinators) are used to provide "transparent delegation" and handling of compound goals, however, they are not required -- agents can communicate directly with a loss of the forementioned functionality.
oa2 - OAA supports a blackboard (anonymous) style of communication between agents (via facilitators). Specific invocations can be tailored requesting synchronous, asynchronous or no response from an agent (using the reply parameter).
oa3 - Using ICL, a facilitator accepts requests (goals) which must be satisfied. It matches requests with service descriptions and determines the proper execution strategy (a goal may require more than one service to produce a solution). Service requestors can also specify feedback parameters to ask the facilitator how a goal was handled. Invocations can be further customized using extensible advice parameters (e.g. how many solutions should be returned, setting time limits, local priority of request, etc.). Finally, facilitators accept compound goals (which can be optimized by the requestor -- e.g. to specify if parallelism should be used, and how the results should be returned). The facilitator uses delegation (to determine what agents are required), execution optimization (minimize communication, exploit parallelism), and interpretation (coordination, assembly).
oa4 - Event Rules - OAA supports the use of triggers for autonomous monitoring. Triggers can be installed by an agent on itself, another agent, or a facilitator. A trigger is composed of a conditional and an action. The agent must understand how to evaluate the conditional, but then submits the action to the facilitator for execution. Four types of triggers are supported: Communication, Data, Task, and Time.
oa5 - Pre-defined events - OAA has several predefined events. These events are handled by the agent library which is compiled into each agent. User-defined events, or solvables, are invocations on the agent which arrive as events (aka messages).

 In Progress Notes
1) Check Local/Global subscription again for Voyager, Jini, and Aglets


© Copyright 1998-1999.  Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information on this page.

Send comments about this report to pazandak@objs.com.

Last updated: 10/98 -- Back to OBJS  homepage.