Object Services and Consulting, Inc.
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|
- Mobile Agent (MA)
- Stationary Agent (SA)
- Simulation S/W (Sim)
- Aux. S/W (Aux)
|MA||MA||Aux (msg router infrastructure)||MA||MA||MA||MA||MA|
|Language||Java||Java||Java||Java||Java||Tcl+ da2||7 oa1
- Component (e.g. JATLite)
- Basic Agent Development
- Advanced Development
|----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|
|----Substrate Mgmt||per servervo3||per federation||per contextag7||place/system od5||per router||per server||per server||Yes - per server
No - per appl. co1
|Loosely||Loosely||Loosely||Tightly od5||unsure how/if they connect||Loosely||Loosely||Loosely||Loosely|
|extension of java.lang.
|Not Addressed||Basic||Host_list da1||Advanced||Basic|
Third party poss.
|----AccessRights_Assignable||No||Yes||Yes||N/A||No||Yes - server||Yes|
|Some||based on ACL||Some||N/A||No||some, see da7||Yes||Yes|
|----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|
|----Proxy auto-updated on
|----Direct or via Substrate
|----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|
|----Broadcast Object||Logical Group
|----Broadcast Control||any parent node
& all children
|----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|
(if agent unreachable)
|No||N/A||No||No||Yes, timed-delivery msgs too||Yes, see also da8||No||No|
|Not Addressed||Not Addressed||Imple-
|N/A||N/A||C or D
|----Pre-defined Events||Yes (many)vo2||No||Yes (8) ag6||N/A||N/A||No||Yes oa6||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|
|----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|
|----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
|----Listeners are interfaces||Yes||Yes||Yes||N/A||N/A||No||No||Yes|
|----Event Caching / Mailbox||No||No||No||N/A||N/A||Yes da8||Yes||Yes - during agent transit||Yesmo2|
|=Mobility||Weak Migration||Code On Demand||Weak Migration||Weak Migration||Not Addressed||Strong Migration||Not
|Weak Migration||Weak Migration||Weak Migration|
|----System-Managed||Yes||Yes||Yes||Yes||N/A||Yes||N/A||Yes||Yes (Queue Mgr)co2||Yes|
|----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|
|----Cloning||Yes||No||Yesag3. Proxy returned.||No||N/A||Yes||N/A||No||Yes||Yes|
(def. is Java)
(migrates with Agent)
|Yes, specified objects||Noji1
|Yes||No||N/A||Tcl variables||N/A||Yes||Yes, member vars
& specified classes
|=Persistence||Not Addressedod6||Not Addressed||as service||Not Addressed||Not Addressed|
|----Object_persistence||Yes||Yes (APIs)||Yes||No||No||No||Data persistence||Yes||No|
|=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|
|----Meetings||N/A||N/A||No||Yes od1||No||Yes da6 da8||No||No||No||Yesmo1|
|=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|
|----Naming / Locating||Yes||Yes||No||No||No||No||Yes oa6||No|
|----Message Caching||No||No||No||No||No ja1||?||No|
|----Proprietary||Yes||No (RMI)||No||No (RMI default)||No||No||No||No|
|----Trader||No - basic name
|-||-||-||-||Timing||-||Remote GUI Server Admin Tools|
|----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|
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.
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.
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?
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
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.
ji1 - Objects migrate in Jini in the context of service APIs that are delivered to requesting clients. Agents are not defined in Jini.
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.
js1-Composite Agents - JavaSeal supports the creation of agent hierarchies. But in this case, they must always migrate together.
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
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
Send comments about this report to firstname.lastname@example.org.
Last updated: 10/98 -- Back
to OBJS homepage.