Agent Technology White Paper and RFP Roadmap
Draft .02
29 November 1999
internet/99-11-01
Executive Summary
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.
Candidate RFPs
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
important
(b) the list takes into account other relevant OMG work and avoids
duplication, and
(c) we are not duplicating work done on agent standards elsewhere (e.g.,
FIPA)
Agent identity
-
Persistent identity over time
-
Identity belongs to authority
-
Identify authority
-
Insuring identity
-
Authentication
-
Retiring identity (and shunning, time-bound)
-
GC issues
-
One unique id—orposibly many under various circumstances (see FIPA work)
-
How does this play in existing agent platforms?
Message transport
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
Agent discovery
-
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
-
Representational issues
-
gateways
-
Any agent that …
-
Query richness – LDAP Vs much more capable
-
Ontology issues
-
Can Trader services be extended?
-
Content-based, parameterized search by ACL & ontology
-
Ontology for common attribute or properties
-
Content languages
-
Wider community than OMG: properties more abstract- OMG prop, JINI, ….
-
Rich property service extension to UML
ACL
-
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.
Ontology
-
Could provide a technical basis for defining OMG domains
-
There are a lot of ontologies out there; should we support any or all of
them?
-
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
Content Language
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
-
Issues:
-
Sender Identification
-
Tampering
-
Encryption
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
-
Team Formation
-
Agent Information Management Framework
-
Multi modal agent-based user interface framework
-
Dialog Management
-
Content Filtering
-
Configurating and Version Control (triaged - consider requirements
sooner so as not to preclude but RFP later)
-
RT Upgrade management is relevant
-
Constraint langauge
-
Planning service
-
Scheduling service
-
list others here ...
Criteria for Sequencing RFPs
There is more material here than can be considered in one RFP so the RFPs
must be sequenced according to some adoption roadmap.
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.
Initial Roadmap
We recommend that the first two bundles of RFPs be:
-
Agent Interoperability RFP - covering agent identity, agent transport,
and agent registration and discovery
-
Agent Communication RFP - covering agent communication language,
ontology, and content language
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.
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.
Timetable
-
Agent Interoperability RFP - issue RFP by Denver, Oslo or San Jose
meeting
-
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
rarified market)
-
should the interoperability and communication bundles be overlapped or
sequenced?
-
add other issue here ...