Agent Discovery and Registration Service - Notes
Object Services and Consulting, Inc.
for presentation at OMG Agent WG meeting on
Jan 10-11, 2000
The OMG Agent Working Group is considering whether to issue a set of RFPs
that together would be useful in the agent technology area. Different
people were assigned to think about the requirements for each RFP and expand
on each to scope and bound the component capability. This was my
assignment, to determine if an Agent Discovery and Registration Service
was needed and if so then what it would look like. This was done
in the context of both the OMG trader service and the proposed OMG ECDTF
Discovery and Registration Service. This is an internal document,
quickly written for discussion purposes. Please send commentary to
the author who will raise significant issues at future meetings of Agent
The basic problem is to define some sort of registry and trader service
that allows one party to list something and another party to find things
that match its query requests. Really there are two separable problems,
one is how to represent things and the other how to describe a service
for recording descriptions and finding descriptions.
Descriptions of things
In web world, these are called Resource Descriptions. In a
trader world they might be called advertisements (ads). They typically
have identity but after that may have many other aspects. One may
start assuming there are only certain kinds of things being described (e.g.,
components or even components described in IDL or agents or agent systems)
but really on futher thought anything might be described including cars
and comic books.
Some of the kinds of things that might be registered include:
agents or agent systems or agent services, information sources like RDBMSs,
search engines, other traders, or classified ads, or even want ads (advertisements
for things you want, which are like trader queries reified into ads, which
might be viewed as persistent queries). So generally, the ontology
problem is closely related to the resource description problem, just to
map a web concept to an agent concept.
These resource descriptions might be represented in many native
representation styles, xml, idl, etc. Or you might use XML and something
like MIME types to wrap them so native descriptions are either encoded
in XML or are embedded as strings that could be encoded in xml. So
agent messages might appear as FIPA parens and strings or as XML encodings
of these along with a FIPA-ACL mimish type. XML schema seems like
a good language for creating ad wrappers. One would need to standardize
the this wrapper language and then separately provide a growing and extensible
list of types of encodings that are supported in standard forms though
anyone can add new types by simply embedding some xml describing their
thing inside the wrapper (but it might be harder to interpret their thing
These ads might have various properties or aspects that become
standardized. They might include location of the resource, language
its encoded in, ownership, licensing and terms and conditions of use, versioning,
activation constraints, marketing specs, etc. These can certainly
be encoded in xml. But if the trader is to have machinery that knows
how to interpret these then it either must expect standard formats or be
open wrt aspect managers that can be plugged in.
There is an interplay between the representation of the ad and the
power of the query and ranking in the trader. If ads are text
then the query might be keywords as in search engines. If ads can
be xml then some sort of xql might be needed. If ads can involve
inference then queries might look like Prolog or SL. One more interesting
thought is that queries or want ads can be considered first class objects
in a trader. That is, they can be reified and stored as other ads.
So their represententation should be consident with other trader ads (they
might be an ad mime type). Maybe we need a name for these - something
like queries, client ads, or resource description patterns.
A bit more on inference - if ads can be rules as in prolog for
instance, then the trader is suddenly much more powerful if it can
match the query to rules that eventually might return a plan or configuration.
It might be like providing a query (like the right side of a prolog rule
so that there are multiple predicates that can act as constraints on the
answer) and using the rules in the trader rule base to find a solution.
The result might not be to actually return the item that is the result
of executing the rules but rather to return the plan or configuration to
be examined by the requestor. Or it might be to actually return the
executed plan result. Well, this little addition actually ads a lot
of functionality to a trader, so much so that it makes it into an almost
different beast, an inference engine. So maybe it is best to treat
this as a very different design pattern that can be composed with the simpler
trader design pattern.
At any rate, that takes us into the next topic of what the trader's
Discovery and Registration Service
Viewing the trader as an object service (or agent service), we can try
to characterize traders by the roles and interfaces of those that come
in contact with the trader.
Critical roles/interfaces are (in the language of the OMG trader
Rebinding Service: Leaving other interfaces aside for a moment
(we will come right back to look at other interfaces a trader can have),
it is worth pointing out that higher level services might use a discovery
service. The OMG Electronic Commerce task force is thinking about
a Brokerage service. An even simpler family of higher level services
has to do with ReBinding. Here are three configurations where the
trader might take part in a Rebinding Service (which OMG does not
have one of separately specified):
/Exporter role - the placer of ads, the one who makes requests of
the trader to have ads placed in its repository. One way to do this
is to support operations like insert, delete, modify ads that return
ad receipts and ad identities. Variations on this are
ad insertion and retention policies. Maybe ads are only inserted
in batch at midnight
provide bots whose job it is to sweep through other environments
and automatically manufacture ads then store them in the trader.
That is, the bots are playing the exporter role.
security agreements (trust, non-repudation, ...) and guarantees
the trader makes with respect to ads or things it advertises and the responsiblity
if things go wrong.
licensing terms and conditions.
open ended other aspects possible.
/Importer role - the basic operation for the importer's interface
is to send the trader a query and to get back a possibly ranked
list of matching ads. Variations
persistent queries - these are queries that are run periodically
on a schedule or triggered by addition of new ads that may supply a channel
or stream of responses to an importer.
the trader might respond with a list of other traders that might
be useful to look in
The second and third variants can be made type safe. The first variant
is kind of a poor man's rebinding service where the work is left to each
application. One wants to avoid making the trader the single point
Importer A calls the Trader explicitly and gets back a list of components
B, C, D and chooses to bind to C (for its own reasons)
Importer A calls a service with an interface C (or a component query ad
type C). But an interceptor calls the Trader to locate an implementation
of C and binds it in dynamically.
A variation on this theme is to extend the trader to monitor the binding
and rebind if the binding goes down.
Importer A calls the trader with a component query ad type C and the trader
locates a matching service and manages the binding to it and any rebinding
if needed. In a way, the trader masquerades as other services.
This is kind of like the interceptor and rebinding in effect but uses different
Also, this points out the aspect of the trader as a kind of dynamic
dispatch mechanism, so in this guise it could be arguably a core CORBA
Other interfaces: It might be that a standard for Discovery
and Registration Services does not specify other aspects (representations
and interfaces) than those above to be useful to calling programs that
just want to make use of it. But there are several other interfaces
that such a service would likely support, even if these are not exposed
to others. Here is a list:
this could tell you how a trader is composed of intefaces and allow you
to replace parts. It could be part of a general extension to a Components
spec that permitted reflection on a thing, locating its parts, and
allowing for replacement.
another variation is if a reflective interface returns trader properties
like My retention policy is delete ads after one week", "I only register
ads in the Texas area", etc.
internal componentry - the trader is somehow composed of the following
functions but they may be intermingled in implementation
repository - there may be just one or might be many repositories
or kinds of repositories with different kinds of properties. For
instance, a search engine used as a repository on the open web might have
different properties about guaranteeing ads or ad retention than an internal
DBMS used just for ad storage.
An operation repositories might support is export of import to dump or
batch insert ads. This could be useful for repository management
or for sharing ad caches across multiple repositories.
matching/filtering algorithm - the matching capability seems intimately
linked to both the representation of ads and the content types of ads.
So you might match differently in XML car ads than in IDL component ads.
This raises the idea of plugins for different matching algorithms for differnt
types and perhaps is a case for making this an explicit interface.
ranking algorithm - similar for ranking
policies or aspects - if this trader knows about logging, security,
replication, enclaves, licensing, or any other kinds of aspects of
the things it trades, then there might be some behavioral differences associated
with these aspects. As mentioned above under representation, these
might show up via standard xml schema representations (at least standardized
for a given trader). There might be extensibility mechanisms
associated with these aspects so they affect the query and ranking algorithms.
What interfaces are mandatory and what are optional?
For instance, it seems that mandatory interfaces include importer
of queries (but not necessarily persistent queries) and exporter insert
and delete. Optional interfaces might be persistent query,
federation, reflection, repository export or replacement, marching algorithm
and ranking add-ins, policy management and new policy add-ins, licensing.
But mandatory and optional are might be different for different purposes.
How do we represent ads and queries?
Lots of dimensions here. Always use XML Schema but provide a foreign
mime-type to permit other representations? Seems reasonable.
But the actual representation of ads for given kinds of things gets us
into the ontology problem so we could permit specialized rankers for car
ads that might be different than for software ads. Or maybe we can
use XQL and XML schema everywhere and push the problem into matching the
xml schemas. Still need a way to represent queries uniformily as
Is agent registration and discovery a special case of registration and
yes. it does not seem there are any special requirements except
some way to represent and advertise agents in an externalized form, but
this is the same problem as with other resources
if we add in inference or expect the trader to understand acl messages
then we need to add something else to trader but it might not be trader
Is trader an agent or agent service in an agent system? how is
that different than being an object service?
It seems like this is a service, whether agent or object, a kind of passive
thing that is acted upon. One could always give a trader an agent
interface so it talks ACL for uniformity but if one added active negotiation
of some kind, it might be done the same way any other piece of code is
agentized, by wrapping. So this question might not be a very interesting
deep one about agent technology except in raising the issue about agent-object
What do agent resource descriptions look like?
There are many sorts of agents in many sorts of agent systems. For
instance SRI Open Agent Architecture encodes "agents" as prolog solvables
so then agent resource descriptions might look like those. FIPA might
provide ACL interfaces for an agent so these might need to be encoded (in
a FIPA standard way).
How do ontologies fit?
What other agent or non-agent aspects might affect the design or functionality
of a trader?
how other services like security fit - potentially lots of ways
should the trader bundle any economic model like how to charge for
things being traded? Seems like this is at least a different spec
even if it is to be composed with the trader.
if agents are mobile, then we'd expect specialized traders that
really are extensions of the dispatch mechanism and are very fast at dynamic
should the space of ads be structured - perhaps something like a
if you store ads that contain code or inferences, what about viruses?
new issues go here
This research is sponsored by the Defense Advanced
Research Projects Agency and managed by the U.S. Air Force Research Laboratory
under contract F30602-98-C-0159. The views and conclusions contained
in this document are those of the authors and should not be interpreted
as representing the official policies, either expressed or implied, of
the Defense Advanced Research Projects Agency, U.S. Air Force Research
Laboratory, or the United States Government.
© Copyright 2000 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 in this survey.
Last Revised: 13 January 2000.