Here's a list of best-of-class features taken from evaluated agent systems. If the feature is unique, the proper system with be attributed. After (or before) this should be a list of other parts, and perhaps their sources. Another issue is where these parts will come from. I don't think it is necessarily a good idea to grab an entire system to get a specific feature -- for example, use Voyager for it's location transparency functionality. That would be like using a whole car just to get one of its parts. So if we cannot get what we want without unbundling it, I think we need to look for another source or build it ourselves.

We also need to categorize at what level the functionality needs to be plugged into the architecture. For example, NLMenu should be high-level and probably not affect the core architecture. A first suggestion (and some examples) might be:

• Core - security, communication, object-based events, mobility
• Service - persistence, events, lifecycle, communication, naming, location
• Application - NLMenu

Best of Class Agent System Functionality

• System-level mgmt - Jini provides a biosphere-less, logical collective based-environment
• Lightweight Host-level mgmt - Concordia has a lightweight "agent transporter" which allows any application to receive, transport and execute mobile agents.
• Host-level mgmt - most

• ACLs / Credentials - scalability issues.- Jini, Concordia
• Meeting Secrecy - none
• Resource Control/Protection - Better - Mole; Some - Voyager, Jini, Aglets
• Method Invocation Security - Aglets, Concordia

• Location Transparency (proxy or directory) - Voyager, Aglets
• Methods and Messages
• Modes - synch, asynch, future (Voyager/Aglets)
• Lookup  - Hierarchic, Distributed, Heterogeneous (Jini)
• Broadcast, Multicast (Voyager) hierarchically organized groups, with ability to send to any node & all children
• Channels -  Voyager
• Queue Mgmt - Aglets
• Message Buffering - JATLite, timed delivery too
• Shared State - Jini via JavaSpaces

• Architecture
• Distributed - Mole - location transparency for subscribers
• Centralized - Concordia (less tolerant / scalable) - location transparency for subscribers
• Object-based - Voyager/Jini/Aglets - Scalability issues. Voyager is object-based, but supports location transparency for subscribers. Jini could support something similar.
• System-events - Voyager/Aglets/Concordia emits system-related events
• Vetoability - Voyager
• Handback Object on Notify  - Jini - unsure of actual value, but noteworthy
• Publish/Subscribe - most
• P/S Security - Concordia/Mole
• All-event Subscription - several
• Persistent Subscriptions - Voyager / Concordia
• Location-Transparent Notification  - Voyager/Concordia/Mole
• Leased Subscriptions - Jini
• Rules - Mole
• Caching - Concordia - using Proxies

• Agent-Managed - Voyager - An agent's proxy can supervise the migration by monitoring system-events
• Specifiable Arrival Methods - several
• Parameter Lists - Voyager (limited to 1 param)
• Secure Transfer - Concordia
• Cloning - a few (e.g. clone agent & migrate clone)
• Object Mobility - several

• Agent Persistence - several
• Object Persistence - several - (I believe none provide transparent persistence)
• Timed Sleep  - Aglets

• Unique method per host - Odyssey/Concordia

• Conversation Policies - KAoS

• Modes - Voyager (5 modes,but more possible -- see feature matrix)

• Service Lookup -  Jini
• Transactions - Jini, Voyager
• Collaboration - Concordia (limited)

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

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