Agent Technology White Paper and RFP Roadmap
29 November 1999
The purpose of this white paper is to provide OMG with a rationale (policy,
motivation) for a proposed series of Agent Technology RFPs. The list
of RFPs is culled from material covered in the Agent
Technology Green Paper and discussed at OMG Agent Working Group meetings.
The rationale provides reasons to order RFPs the way we recommend below.
Nevertheless, we recognize that experience with initial RFPs may lead to
later revision of this document including revising the list of RFPs or
their ordering so we have not spent much time ordering later RFPs, rather
providing criteria to select the initial core.
All of these RFP candidates need more work. Here they are only sketched
at the level we talked about them during the Boston meeting. Some
additional work is needed to insure that
(a) this is the right list of RFPs and we are not missing something
(b) the list takes into account other relevant OMG work and avoids
(c) we are not duplicating work done on agent standards elsewhere (e.g.,
Persistent identity over time
Identity belongs to authority
Retiring identity (and shunning, time-bound)
One unique id—orposibly many under various circumstances (see FIPA work)
How does this play in existing agent platforms?
Durable, reliable; send/receive
Might need to build a transport gateway
current OMG architecture handles this.
Concrete realization of FIPA transport
Use event or messaging style?
IIOP, events, CORBA, msg, Java msg, com/OLE
Message source and value types
FIPA role, OMG role, gateways
Registry/directory service - as such how is this related to trader and
to EC brokerage registry and directory services
Feature -> identity or name/address -> agent properties
Any agent that …
Query richness – LDAP Vs much more capable
Can Trader services be extended?
Content-based, parameterized search by ACL & ontology
Ontology for common attribute or properties
Wider community than OMG: properties more abstract- OMG prop, JINI, ….
Rich property service extension to UML
encoding of ACL
Important issues: support multiple ACLs and extensible ACLs
Also support XML/XMI usage, reflection, dynamic IDL
What is value-added by ACL? Need to make this clear for all OMG
At least be able ascertain structure and methods, but what else?
Ontology issues here also
Frank McCabe will write a piece on the value-added to current OMG technologies.
Could provide a technical basis for defining OMG domains
There are a lot of ontologies out there; should we support any or all of
While the relationship to XML is to an implementation, XML will be used
to define many poor-man ontologies so what does ontology add.
What is the best way to express ontology. Can UML help?
How does this relate to EC Brokerage RFP on resource description using
xml-based and XML schema value types
Agent security ("Trust")
Orthgonalized; similar to OO security but with some twists
Interop Security RFP
FIPA- systematically secure…across transports
In a touchy-feely sort of way, some agent-only issues are:
Who agents tell what to
Whether they are trustworthy or not
Who do you trust and who don’t you trust
Kate Stout will champion for now
Agent/object mobility (triaged - consider requirements sooner so as not
to preclude but RFP later)
Orthoganalized; similar to OO mobility plus msg forwarding
UML profile for agents & ACL & agent platforms
What UML extensions are needed to support agents?
How many of these extensions will the OO UML 2.0 decide to support anyway?
For those agents requiements outside of UML 2.0, perhaps separate agent,
ACL, and agent platform profiles will be useful.
How does UML relate to ACL and ontologies.
Other possible RFP areas that are out of scope for the near term
Listed below are a number of valid RFP topics but doing the work to refine
them into RFPs awaits champions for each. If someone is interested,
please come to OMG Agent WG meetings and participate.
Logging service - including services for visualization of the log
Negotiation - but see ECDTF Negotiation RFP
Agent Information Management Framework
Multi modal agent-based user interface framework
Configurating and Version Control (triaged - consider requirements
sooner so as not to preclude but RFP later)
RT Upgrade management is relevant
list others here ...
There is more material here than can be considered in one RFP so the RFPs
must be sequenced according to some adoption roadmap.
Criteria for Sequencing RFPs
The center of interest in the Agent Working Group is in multi agent
systems that are used in application development in robust ways
in distributed environments that operate in LANS, WANs and over
the web. For the present, we are less focused on: individual
agents, desktop agents, collaborative filtering, and agent-user interfaces.
Criteria that can affect the ordering of RFPs are as follows:
interoperability - agent systems will come in various forms and
technology that allows agent and agent systems to interoperate will be
immediately useful. RFP areas that provide direct help in interoperability
are: agent identity, agent registry/discovery, and agent transport
ACL communication - we need standard ways that agents can communicate
with each other and standard ways for them to talk about domain entities
in different domains. RFP areas that directly provide help here are
ACL, Ontology, and Content Language.
security - if agent technology becomes widely popular it will need
security models before people trust agent-based applications. So
we need to ask what extensions to the OMG security service are needed and
must not be precluded in agent system development
mobility - if agents are to realize the claim of mobility, then
mobility services should be in place. We view mobility to be largely
orthogonal to agents (or objects) and again only need to insure that earlier
RFPs do not preclude adding mobility later in a consistent way.
distributed, robust, large-scale - we believe these are general
desirable criteria for agent systems as well as object systems. RFPs
should not preclude deployment of agents in such industrial strength environments.
We recommend that the first two bundles of RFPs be:
The first bundle is in several ways orthogonal to the second, at least
insofar as different ACLs could be accommodated by the same Agent Interoperability
services. Also, within these bundles, the services should be separately
specified as they are separable but they must work closely together so
they are included in the same bundle. We currently seem to be on
the vector to work on the first bundle first and then the second but we
can decide about overlap at the Mesa meeting.
Agent Interoperability RFP - covering agent identity, agent transport,
and agent registration and discovery
Agent Communication RFP - covering agent communication language,
ontology, and content language
Next on the list should be Agent Security RFP when we decide
what aspects of security are special to agents and go beyond object security.
Other RFPs will be considered at a later date: these will include
some from the deferred list.
IDL (if any) and UML extensions needed by agents will be requested as
part of every agent RFP.
Agent Interoperability RFP - issue RFP by Denver, Oslo or San Jose
Agent Communication RFP - issue RFP by TBD - issue:
overlap or sequential
others - issue later
Issues with current document
is there a good reason why this initial list of RFPs is not architecturally
derived from the FIPA architecture? should it cover things like agent
management, agent wrappers for objects, ...
agent persistence - should this be broken out
should the focus be on agent systems and provide gateways that show how
at least OMG solutions like IIOP can help but permitting other kinds of
implementations -or- are these just going to be OMG agents (a much more
should the interoperability and communication bundles be overlapped or
add other issue here ...