Agent Discovery and Registration Service - Notes

• Prolog
• Description of things
• Discovery and Registration Service
• Open Issues

Prolog

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

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

Critical roles/interfaces are (in the language of the OMG trader spec):

• /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

• 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 mechanisms.

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:

• reflection inteface
• 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.

Open Issues

• 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 ads.
• Is agent registration and discovery a special case of registration and discovery?
• 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 unique.
• 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 interoperability.
• 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?
• See the section above on
• 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 binding
• should the space of ads be structured - perhaps something like a directory tree?
• if you store ads that contain code or inferences, what about viruses?
• new issues go here

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