Wrapper Protocol

The wrapper protocol has been designed to be easily used by most of the existing and future mediator systems. Usually the wrapper protocol exports a schema so that the mediator can query the remote data source.

We have designed a protocol which is able to deal with most of the existing WEB sources. The protocol is also build to be easily integrated in a mediator query processing system. It describes the schema, the capabilities and the meta information of the remote WEB source. The main goal of the wrapper protocol is to give the relationship between an input query bindings with the corresponding output result. It also provides a program able to test the correctness of queries and a cost estimator. All this information are given in a very simple way so that the mediator can use it to optimize queries. The wrapper protocol is decomposed into :

An Output Schema : the protocol describes the schema of the object that can be returned by the wrapper. The object model is a subset of the ODMG standard ODL. It supports lists, sets, bags and complex objects. It does not support methods nor inheritance. The following schema gives the output schema of the Weather Channel WEB source.
```
interface State    {String name;bag(City) cities}
interface City     {String name;bag(Forecast) fiveDayForecast}
interface Forecast {String day;Image forecastImage;String forecast;
                    int lowTemperature;int highTemperature}
```
Input attributes definition : this list of attributes defines the possible bindings that can be used to query the remote source. We then restrict the capabilities of the source input query language to selections. For simplicity and usability, all the other relational operators (like Group-By, Joins, Projections); or object operations (like path and set traversals or method invocation) are not supported by the wrapper protocol query language and have to be performed at the mediator level. For the Weather Channel source the input attributes are :
```
interface input_attributes {String State;String City}
```
The protocol also describes the domain of each attribute. The domain information is separated in the domain nature, the domain type and the domain contents.
- The domain nature can be one of these : Infinite, Enumerated or Unknown.
- The domain type can be all the basic types provided by the Java definition language including the URL type or the Image type.
- The domain contents can be either Undefined, a Range or an Enumeration of values.
These domains are attached to both the output schema and the input attributes so that the mediator can use it to optimize and check the correctness of queries. The domain extraction used the same tools than the usual data extraction of the wrapper.
Capabilities : the capabilities of the source are expressed by relationships between input query bindings with corresponding output result object types. The query bindings is expressed by the list of input attributes that have to be bind to get this result. If there is no binding, all the object of the source corresponding to the output type are returned. The output type is described using a restriction of the OQL projection declaration. It does not supports the struct operator (only set, list bag) and it can only use global variables (for example : State for an object of type State).
The table 1 shows the capabilities of the Weather Channel wrapper. It says that you can get all the State objects from the source or, for a given state name, you can either have a State object or the corresponding City objects. Given a city name, you can have the set of City objects corresponding to that name. Given a state name and a city name you can have the City object corresponding to that name.

Table 1: The Wrapper Capabilities Table
Query Parser. This program can be use by the mediator to check the correctness of queries. It uses the input attributes, the output schema, the domains and the wrapper capabilities to decide if a query qualified or not (it returns true or false). It is helpful with simple mediators. With complex mediator, all the information provided by the wrapper should be used by this mediator to directly produce correct queries.
Cost Estimator. This module uses a Multi Dimension Table (MDT) to learn from past queries. It gives back a cost estimation of an input query. Then, the mediator can incorporate this cost information in its own optimizer.

All these information are given back by the wrapper during the connection process with the mediator. Then, each time the mediator connects to a wrapper, all these information are re-evaluated at the mediator level. This connection process is a way to deal with dynamic sources.

As part of the protocol, we also describe the query interaction between the wrapper and the mediator. The wrapper accepts a submitted query and return an iterator object on the result :

A wrapper query : this operator is used by the mediator to provide both the input bindings and the type of the output result. For example, the following query ask for the all the City objects of the state of Maryland :
```
Select_Submit set(City) 
where (State="Maryland")
```
An iterator object : this object follows the iterator model standard. It has an open, a getNext and a close method. The mediator can use this iterator to get back objects of the query result in a threaded pipeline. When an object is returned by the getNext method all the related objects are also returned so that the coherence of the schema is respected. This is up to the wrapper implementor to set his output schema and the wrapper capabilities to improve the wrapper performances.

The protocol also provides easy methods to get the output schema information, to extract every domains, to scan the capabilities table, to construct submitted queries and to access the contents of the resulting objects.