Object Services Architectures

A Short Description of the WebTrader

Tom Bannon Object Services and Consulting Inc. September 30, 1998

Introduction

A trader is a software system which matches clients with services dynamically, so that hardcoded bindings in the client can be avoided, thus making them much more flexible and open to change in themselves or their operating environments. One of the goals of the Trader project at OBJS was to create a lightweight trader similar to an OMG CORBA Trader but using web mechanisms instead of CORBA ones, and WebTrader was the result. The Trader Service Project Summary document provides an overview of the OBJS Trader project as a whole, and this document describes the basic operation of the WebTrader system as it is currently implemented.

The Trading Advertisement

The primary data object of the WebTrader system is an XML document called the "Trading Advertisement". A trading ad encapsulates the data necessary for the WebTrader server to decide matches between clients and services, and well as information for the client to be able to operate the service. Both the client and service have trading ads, the client to advertise needs, and the service to advertise abilities. Below are examples of a client and a service trading ad, and a short explanation of them.

An Example Client Ad

<?xml version="1.0" ?>
<!DOCTYPE TradingAdvertisement SYSTEM "http://dante/Trader/TradingAdvert.dtd">

<TradingAdvertisement adType="client">

    <searchKeywords>
        TradingClientAd, c-interface JavaRMI, c-interfaceName
        RMITimeService, c-derivedFrom Remote, c-clockResolution
        seconds, c-serviceCost free,
    </searchKeywords>

    <metadata>
        <mustHave>
            <mdata name="clockResolution" value="seconds"/>
        </mustHave>
        <reallyWant>
            <mdata name="serviceCost" value="free"/>
        </reallyWant>
    </metadata>

    <interface>
        <JavaRMI name="RMITimeService">
            <derivedFrom interfaceName="Remote"/>
            <method name="getTime" returnType="String">
                <parameter name="timeZone" type="String" direction="in"/>
                <exception name="RemoteException"/>
            </method>
        </JavaRMI>
    </interface>

</TradingAdvertisement>
</xml>

An Example Service Ad

<?xml version="1.0" ?>
<!DOCTYPE TradingAdvertisement SYSTEM "http://dante/Trader/TradingAdvert.dtd">

<TradingAdvertisement adType="service">

    <searchKeywords>
        TradingServiceAd, s-interface JavaRMI, s-interfaceName
        RMITimeService, s-derivedFrom Remote, s-clockResolution
        seconds, s-serviceCost free,
    </searchKeywords>

    <metadata>
        <mdata name="clockResolution" value="seconds"/>
        <mdata name="serviceCost" value="free"/>
    </metadata>

</TradingAdvertisement>

As you can see from the DOCTYPE tag, the trading ads are governed by a DTD, which specifies the grammar of the ad, its tags and attributes. An ad has three main sections, the searchKeywords, the metadata, and the interface. The searchKeywords are a mechanism for exposing information about the ad to a web search engine crawler when the ad is embedded in an HTML document. The way the ad grammar is defined by the DTD embeds the data of the ad inside various ad-specific XML tags, except in the case of the searchKeywords. Since none of the ad-specific tags are part of the official HTML grammar they are ignored by HTML and its crawlers, and only the searchKeywords are picked up. (These keywords could perhaps be replicated in meta tags in the head section of an HTML page, but some web crawlers specifically avoid indexing pages using this information due to page spamming concerns). The metadata section allows arbitrary lists of name-value pairs, as well as some expression of the need or value of particular pieces of metadata. The interface section is where an operational interface is described, both in terms of its type and its location (via connectPoint tags - multiple locations are allowed). Currently only HTTP CGI and Java RMI type interfaces are supported by the trading ad DTD. CORBA IDL would be a natural addition. Also, the DTD in general is not set in stone, and may be modified to improve or add capability. How to handle DTD evolution for compatibility with fielded systems and ads is an open issue.

Trading Advertisement Construction

Currently trading ads are produced by hand in a text editor, in the same way one can write HTML source by hand if so desired. The structure and content of the ads lend themselves to at least semi-automated construction; one can imagine for instance a tool that parses java source code and spits out RMI interfaces in the XML format required in the interface section.

Trading Advertisement Placement

Since trading ads are ASCII XML documents, they can be embedded in a wide variety of data objects. The most obvious (and perhaps useful) are HTML pages now, but it is probably true that there is no real limit, from .docs to MPEG videostreams, from GIF images to application binaries. Anywhere a format allows a section of text, a trading ad can be inserted. The trick of course is distinguishing what is trading ad and what is not, and that may have to be determined on a type by type if not even a project by project basis unless some standardization emerges. However, at this point, the WebTrader takes a narrow view of where to look for ads.

WebTrader Operation

The WebTrader currently only concerns itself with ads embedded in (HTML and text) webpages acquired as the result of a search engine query. That is, the WebTrader posts a query to a search engine, retrieves the list of page URLs of the response, and retrieves and examines the content of each page in turn, extracting what if any trading ads are embedded in the page (a page may contain 0 to N ads). The scale at which the WebTrader operates, from single host, to LAN, to WAN, to the WWW, is determined then by the scope of the search engine it interrogates, unioned with the closure of all the other traders it may interoperate with in course of satisfying its client. A WebTrader is itself a service and instances of it can show up as the results of queries just like the instances of other services can show up. A WebTrader is any piece of software that implements the TraderService interface, and further it is envisioned that specialized WebTraders could emerge to service various niches, just as search engines are starting to, such as a trader specialized to map words to images, as in "give me pictures of Texas in the 1950s". The current WebTrader implementation, however, does not use other traders to further its search, although one WebTrader demo, a web searching tool called DeepSearch, does use found ads describing local page search engines to further its search reach by applying the original user query to the local search engines that seem good candidates to answer the query.

How does a client actually use the WebTrader? Below is a code snippet from a Java code example supplied with the WebTrader wherein a client uses the WebTrader to find a Internet-based time service that speaks Java RMI.

// Get a handle to the WebTrader

String traderURL = "rmi://dante/TraderJoe";
Trader trader = new Trader (traderURL);
...

// Use the trader to find a service for our needs

String ourURL = "http://dante/Trader/RMITimeClient.html";
TraderMatch matches = trader.getMatches (ourURL, 1); // only get 1 match
....

// Link to the time server we got from the trader and get the time

ConnectPoint connectPoints[] = matches[0].getConnectPoints();
String url = connectPoints[0].getUri();
RMITimeService rmiTime = (RMITimeService) Naming.lookup (url);
String time = rmiTime.getTime (timezone);

First, a link to a WebTrader is established. The WebTrader is implemented as a Java server with an RMI interface, and dante is the hostname where the trader we are after is running. Next, we ask the trader to find matches for the client trading ad embedded in the webpage RMITimeClient.html, also served from dante. Note that the client ad in this webpage is the same client ad used as an example in The Trading Advertisement section. Finally, the client processes the results from the WebTrader to actually connect to the service found and get the time.

How does a service actually use the WebTrader? The service's responsibility, beyond advertising itself via a trading ad in a webpage that gets indexed by the desired search engine or search engines, is merely to fulfill the promise of its ad. In this example we show the the Internet time service companion to the client above.

// The getTime() implementation

public String getTime (String timezone) throws RemoteException
{
TimeZone tz = null;
Calendar cal;

     if (timezone != null) tz = TimeZone.getTimeZone (timezone);
     if (tz == null) tz = TimeZone.getDefault();
     cal = Calendar.getInstance (tz);
     return DateFormat.getDateTimeInstance().format(cal.getTime());
}

// Registering the time service
...
RMITimeServer server = new RMITimeServer();
Naming.rebind ("RMITimeServer", server);
...

So, here we have the implementation of the getTime() method as advertised by the service, and the registering of the service under the name "RMITimeServer" as specified in the connectPoint tag of the service's ad.

Conclusion

This concludes the short description of the OBJS WebTrader. Please send any questions or comments to the author.

This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.

© Copyright 1998 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: September 30, 1998. Send comments to Tom Bannon.