Browse Prior Art Database

Trusted versus Fenced Wrapper Execution Model

IP.com Disclosure Number: IPCOM000015974D
Original Publication Date: 2002-Oct-03
Included in the Prior Art Database: 2003-Jun-21
Document File: 2 page(s) / 53K

Publishing Venue

IBM

Abstract

Trusted and Fenced Wrapper Execution Model Disclosed is the model for running wrapper module trusted versus fenced in federated database server. Bacground: By using C++ derived class and virtual funtion technologies, DB2 ® federated database server provides a generic framework for

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 2

Trusted versus Fenced Wrapper Execution Model

Trusted and Fenced Wrapper Execution Model

Disclosed is the model for running wrapper module trusted versus fenced in federated database server.

Bacground:

By using C++ derived class and virtual funtion technologies, DB2 ® federated database server provides a generic framework for

quickly developing wrappers internally or externally. Here a wrapper is a module of code that enables DB2 federated database

server to interact with a certain kind of data sources. Typically, A data source can be relational databases such as DB2 database,

INFORMIX database, ORACLE database and Microsoft SQL Server database, etc, or non-relational sources such as flat file source

and Microsoft Excel spreadsheets. In order to support a federated application which can join or union data from different kinds of data

sources, DB2 federated database server needs to interact with multiple kinds of data sources using multiple wrappers at the same time.

Among these wrappers, typically there are the following types:

1) A wrapper is developed by IBM and it will be statically or dynamically linked with IBM owned application libraries. For example, DRDA wrapper which is for interacting with all DB2 family data sources and will be linked with DB2 application libraries;

2) A wrapper is developed by IBM and it will be statically or dynamically linked with IBM acquired/owned application libraries. For example, INFORMIX wrapper which is for interacting with INFORMIX data sources and recently IBM has acquired INFORMIX.

3) A wrapper is developed by IBM but it will be statically or dynamically linked with non IBM applicatoin libraries. For example, ORACLE wrapper which is for interacting with ORACLE data sources and will be linked with ORACLE application libraries on the customer site.

4) A wrapper is developed by IBM's partners or contractors and it will be statically or dynamically linked with non IBM application libraries. For example, IBM's has started partnership with other vendors to develop any specific kind of data sources based on business requirements such as in life sciences.

Letting wrappers of type 3) or 4) running directly in DB2 engine is a potential danger. For an example, if a wrapper of type 3) or 4) is running in DB2 engine, it can further implicitly or explicitly load other vendor's code into DB2 engine, all these codes potentially can cause DB2 engine to crash if they have faulty logic or are malicious. For another example, when a DB2 federated server uses a wrapper of type 3) or 4) to interact with a data source, it becomes an application of the data source. if the data source shuts down without giving proper signals, it might kill our DB2 server without any notice.

On the other hand, for wrappers of type 1) and 2), since all the libraries involved are products owned and developed by IBM, they should be integrated with DB2 engine in the most efficient way if possible. For example all the libraries involved c...