Wrappers

Introduction

Wrappers are a type of software "glueware" that is used to attach together other software components. A wrapper encapsulates a single data source to make it usable in a more convenient fashion than the original unwrapped source; this distinguishes wrappers from another kind of glue-ware, mediators, that combine data from different data sources. Wrappers are assumed to be "simple", although there is no clear demarcation between what belongs in a "simple" wrapper and a "complex" higher level component.

Wrappers can be used to present a simplified interface, to encapsulate diverse sources so that they all present a common interface, to add functionality to the data source, or to expose some of the data source's internal interfaces.

Design Space

The following describe important functionality or design variants for wrappers. Some of the material for this report comes from a session on wrapper technology in the ARPA Intelligent Integration of Information (I3) program at the I3 PI meeting. A session report prepared by Jennifer Widom should be available on the ARPA server soon.

Model

All wrappers have the same basic logical model. The wrapped data source natively is operated upon in a language Z and responds with results expressed in a model W. The application wants to operate in language X and get responses in model Y. The wrapper converts language X commands to language Z and model W results to model Y. Wrappers differ in the languages and models they support (e.g., relational. objects, knowledge models) and in the sophistication of the functionality they provide.

Levels of Functionality

Four Levels of "wrapperness" were defined; each level probably subsumes the previous, but not necessarily. These are:

Level 1: Queries in; Answers out
Level 2: Updates in; Yes/No out
Level 3: Subscriptions in; Notifications out
Level 4: Queries about capabilities in; Capability lists out

In addition, wrappers often expose internal interfaces of the data source or alter its behavior in some way, including the control flow. Since wrappers are presumed to do "simple" translations, it is tempting to try to draw a line of complexity above which a component is something other than a wrapper. However, there is wide difference of opinion as to where this line should be. In general, it appears that once something is well understood, it becomes "simple". Since different groups have different skill sets, different things seem simple, and hence includable. For example, it is not clear whether the use of an ontology engine to map models is inside or outside the scope of a wrapper.

Classes of Functionality

The functionality of a wrapper can be further subdivided into a number of categories. This subdivision hints at either an internal architecture for wrapper construction or at a composition algebra for "micro-wrappers". While several of the kinds of wrappers surveyed later on have a consistent internal architecture, there is no general agreement between wrapper families as to what that architecture should be. The classes of functionality are:

Generic functionality. This refers to operations that take place because of the type of the data source rather than its contents. For example, conversions of SQL3 queries to SQL queries against an Oracle DBMS will be done the same regardless of the database schema. It is possible to further differentiate between conversions necessary for a family of data sources (e.g., RDBs or file systems) and those necessary for a particular instantiation of a data manager in the family (e.g., Oracle or SyBase RDBMSs, or Unix or DOS file systems).
Source-specific functionality. This refers to the operations that take place because of the contents of the data source, i.e., its schema. Assuming that the schema remained unchanged, these conversions would take place regardless of which engine is actually managing the data (e.g., unless the schema changes, the source-specific conversions would be the same whether the data was stored in Oracle or SyBase.
Control structure. A wrapper can change the way in which requests and responses are passed. For example, a synchronous data source may be wrapped by an asynchronous wrapper that buffers responses until they are requested by the caller. This seems to be a relatively minor area of interest for wrapper builders, so this may be more properly the domain of some other software component.
Error reporting. Wrappers can report errors back to the caller. These may be error messages generated by the data source, perhaps converted to a desired format, or they can be the results of an error recovery operation within the wrapper.
Caller model. Most wrappers assume that they are wrapping the source for use by a particular kind of caller. However, the TSIMMIS project recognizes that by supporting a variety of conversions from the caller before the wrapper converts to the data source, much of the wrapper's implementation can be reused.
Calls to external services. Wrappers could conceivably call out to services to perform more complex services than the wrapper itself can perform. An example would be the use of an external ontology engine to semantically transform a query before submission to the wrapped data source. We are unaware of any wrappers that support this.

Internal Architecture

There are a number of implementation styles of wrappers as can be seen from the review of systems below. While most wrapper families have a consistent internal architecture, there is no general agreement about this organization that would allow. This precludes the sharing of any internal components between wrapper families.

Systems

Currently, we have only reviewed research systems; commercial systems will be reviewed at a later date. Anecdotal evidence from a number of presentations indicates that the majority of commercial wrappers are for relational database management systems and their architecture tends to be proprietary and closed. The research prototypes offer more kinds of functionality and tend to have more interesting and flexible internal architectures.

Research Systems

The following systems were presented at the ARPA I3 meeting in January 1996. All wrappers were built in the context of a larger project to integrate information sources and applications. Discussion concerns only the wrapper aspects of the projects.

A list of questions about wrappers was developed and several projects present at the ARPA I3 meeting in 1/96 meeting presented what they have done in the context of those questions.

Which sources were wrapped? Aids in selection of a particular wrapper.
What documentation exists and what is the style of the external interfaces? Aids in selection of a particular wrapper.
What are the wrapper functions? Aids in selection of a particular wrapper.
What I/O languages and models are supported? Aids in selection of a particular wrapper.
Why were the sources wrapped? This gives some indication of the load placed on the wrapper and its probably robustness.
How was the wrapper constructed? Are they easy to build; does the construction paradigm help to build other wrappers?
What is the internal architecture? Can sub-components be reused elsewhere; how easy is it to build?

The answers to these questions for the systems identified above can be found in the following table.

	SHADE	TSIMMIS	Harvest/Agile	IWSB	GFP	InfoBroker	PolySpin
_{Sources wrapped}	_now: _{design appls} _later: _RDBs _COTS _SDRC-IDS _MATLAB	_RBDs _{Stanford library data}	_??	_{RBDs for:} _{intelligence (very complex)} _{manufacturing}	_LOOM _Theo _OntoLingua _{biology Kbs}	_KQML _{semi-structured} _{San Jose Mercury News classifieds}	_{OpenOODB CLOS & C++}
_{Why wrapped?}	_{Satellite design} _{Wrapped COTS tools}	_{Access to semi-structured data in common object model}	_{Information discovery} _{Add heterogeneity to Harvest}	_{To simplify complex DB structures in the intelligence DBs and make them usable}	_{To develop KBs} _{Support generic KB editor}	_??	_{Inter-lingual sharing between C++ & CLOS}
_{Wrapper Functionality}	_{Querying data} _{Meta data advertised but not queriable}	_{Querying data}	_{Querying data} _{Updating soon} _{Levels 3 & 4 eventually}	_{MQL to SQL conversion} _{Objects to/from Tables conversion} _{Calculated fields} _Joins _Subtyping	_{Querying data} _Updates _{Querying wrapper capabilities}	_{Querying data} _{Querying meta data} _{"enhancer" adds ontology}	_Transparency _Query _Update _OQL
_{How Built}	_now: _{Hand coded} _later: _{Semi-automated}	_now: _{Hand coded} _later: _{Generator w/ "wrapper by example" templates}	_??	_{Hand coded}	_{Completely generic (uses CLOS generic functions)}	_??	_{Tool to build wrappers} _{Type Definition Mgr.} _{Auto-generate wrappers}
_{I/O Langauges & Models}	_KQML	_{OEM (a Datalog-like query language using (label/value) pairs}	_DIOM _IDL	_{MQL to SQL} _{Has a model lang & query lang}	_CLOS	_NGFP _ACL	_{CLOS & C++}
_{Documentation & Interfaces}	_{GUI wrapper builder} _{No specific manual} _{KQML so easy to learn}	_{Just papers} _{Templates are easy to understand}	_??	_{Some doc.} _{See IWSB}	_Yes _{35 fcts that must be defined by methods}	_??	_{None needed} _{Does not cause I/F to be modified}
_{Internal Architecture}	_{Unknown internal structure} _{About 50% reusable}	_{Uniform internal structure} _{Divided between Call & Return converters}	_{Uniform connections to external world}	_{Upper & Lower wrappers} _{Common language in mediation layer (MQL)} _{Internal organization}	_{Everything is a CLOS generic function}	_??	_{Open OODB sentries} _{Piccolo language independent naming}
_Presenter	_{Larry Harada}	_??	_{Calton Pu}	_{Nancy Lehrer}	_??	_??	_{Jack Wileden}

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 1996 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 on this page.

This page was written by David Wells. Send questions and comments about it to wells@objs.com.

Last updated: 04/22/96 8:01 PM

Back to Internet Tool Survey -- Back to OBJS