Agent Discovery and Registration Service - Notes

Craig Thompson
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 WG.

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:  components (IDL, Java, applets, Javascript, UML, OMG services, dlls, ...), 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 then).

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 functionality is.

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 spec):

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): 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 of failure.

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 component.

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:

Open Issues

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.

Author:  Craig Thompson
Last Revised:  13 January 2000.