Wrappers


Contents

Introduction

Design Space

Systems


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

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