OS/2 Shareware BBS: 14 Text/14-Text.zip/IDAPI.ZIP/IDAPI.TXT

Text File | 1992-11-25 | 24KB | 526 lines

IDAPI⌐ Architecture
 White Paper
(Integrated Database Application Programming Interface)



November 16, 1992


                        Table of Contents


Executive Summary. . . . . . . . . . . . . . . . . . . . . . .iii

IDAPI Concepts and Objectives. . . . . . . . . . . . . . . . .  1
     What is IDAPI?. . . . . . . . . . . . . . . . . . . . . .  1
     The Need for IDAPI. . . . . . . . . . . . . . . . . . . .  2
          Different Operating Systems. . . . . . . . . . . . .  2
          Different Computing Models . . . . . . . . . . . . .  2
          Different Data Access Models . . . . . . . . . . . .  3
     IDAPI Capabilities. . . . . . . . . . . . . . . . . . . .  4
     IDAPI and Other Interfaces. . . . . . . . . . . . . . . .  4
          IDAPI and SQL/CLI. . . . . . . . . . . . . . . . . .  4
          IDAPI and ODBC . . . . . . . . . . . . . . . . . . .  5
          Summary. . . . . . . . . . . . . . . . . . . . . . .  5
     IDAPI Benefits. . . . . . . . . . . . . . . . . . . . . .  6

IDAPI Architecture . . . . . . . . . . . . . . . . . . . . . .  8
     Architecture. . . . . . . . . . . . . . . . . . . . . . .  8
          Client Applications. . . . . . . . . . . . . . . . .  8
          Application Support Layer. . . . . . . . . . . . . .  8
          Engine Support Layer . . . . . . . . . . . . . . . .  8
          Driver Support Layer . . . . . . . . . . . . . . . .  9
          IDAPI Driver Layer . . . . . . . . . . . . . . . . .  9
     Environment Configuration & Session Management. . . . . .  9
     Database Capabilities . . . . . . . . . . . . . . . . . .  9
     Database Operations and Data Manipulation . . . . . . . .  9
     Relational and Navigational Engines . . . . . . . . . . .  9
     Remote Data Access. . . . . . . . . . . . . . . . . . . . 10

IDAPI Benefits . . . . . . . . . . . . . . . . . . . . . . . . 11

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


                      I. Executive Summary

The Integrated Database Application Programming Interface (IDAPI)
environment is being promoted by a group of computer industry
leaders to advance the state-of-the-art of corporate database
access.  During the rapid growth of computer technology,
corporations have invested billions of dollars in the collection
and maintenance of various databases.  The maximum advantage of
this investment cannot be realized today because data is commonly
stored in many databases and on different computational
architectures, often incompatible with each other.  Full
utilization of these data sources is possible only by a new data
access model that will present the data to users and application
developers in a consistent manner that is congruent with the
desired use of the data.

IDAPI's goal is to enable developers to create database
applications more productively and to allow end users to easily
access data stored in multiple formats on a wide variety of
hardware, operation system platforms, and network environments.
Developers writing to the IDAPI specification will be able to
interconnect to any database driver using IDAPI technology.  This
interconnectivity will be allowed in a heterogeneous computing
environment, allowing an application to access multiple databases
despite the underlying access method or computing architecture.
This includes application access to databases that are
distributed over multiple server architectures.

Applications using IDAPI will provide users with access to a far
broader range of data than previously possible because these
applications will be written to a consistent, platform
independent Application Programming Interface (API).  The user
wins because data is available despite the location or format.
Developers win because their applications are able to access a
wide variety of data at a much lower cost.

                II. IDAPI Concepts and Objectives


A. What is IDAPI?

Driven by competitive business pressures, companies increasingly
need to use corporate, departmental, and personal databases as a
unified corporate resource.  Often, the users' environment
includes a disparate collection of database applications and
servers, in different locations, from different suppliers, and on
different platforms.  In this fragmented and complex environment,
companies need to access data transparently from any location in
order to stay competitive.

Today, the most prevalent answers to this need are customized
software solutions, which are unique to given combinations of
applications or operating environments.  These customized
solutions present an extraordinary challenge to providers of
applications and databases and to their users.  Growing costs for
development, training, support, and maintenance of enterprise
database applications are symptoms of this unmet need.

The Integrated Database Application Programming Interface (IDAPI)
technology simplifies the development environment for database
products to interoperate.  IDAPI permits databases to
interoperate across different operating systems, data models, and
computing architectures, creating a uniform basis for
communications between disparate database applications.  This
benefits developers by simplifying the task of writing and
maintaining multi-platform database applications.  It benefits
end users by enabling them to transparently access the myriad
sources of data within their enterprises.

IDAPI is being produced by a group of computer industry leaders
that include Borland International, IBM, Novell, Inc., and
WordPerfect Corporation.  IDAPI will be implemented on the
industry's leading computing platforms, beginning with DOS, OS/2,
NetWare, and Windows.  Derived from Borland's database
connectivity technology, IDAPI will eliminate fundamental
obstacles that have traditionally prevented developers and users
from integrating dissimilar databases.


B. The Need for IDAPI

The most fundamental obstacles to transparent data access occur
when enterprises try to integrate databases that are based on
different operating systems, data models, or computing
architectures.  As the installed base of technology has grown and
evolved, there has been increasing diversity along three
dimensions.

1. Different Operating Systems
The computing environment in most modern business enterprises
today includes a variety of host, desktop, and network operating
system platforms.  Although there is an increasing level of
connectivity between these platforms, application
interoperability requires a good deal more than connected
platforms.  For independent applications to be integrated,
operating systems need to support the APIs that applications use
for interoperability.  Structured Query Language (SQL) has been
established as a standard database access language for relational
databases.  Apple's Data Access Language (DAL) addresses this
need for database interoperability in the Macintosh operating
system environment.  Microsoft's Open Data Base Connectivity
(ODBC) also begins to address this need in Windows by providing a
consistent way for developers to build the required system
services into their Windows applications.  Apart from these
beginnings, no APIs exists today to integrate database
applications.

To justify building database products that interoperate,
developers need the operating systems that their customers use to
support database interoperable APIs.  Developers also want the
APIs and system services to be consistent between operating
systems, so that code developed for one operating system can be
easily modified to run elsewhere.  To date, no API has emerged
that promises to meet the need for a consistent database API that
spans today's leading operating systems.

2. Different Computing Models
For many applications, customers and developers are choosing
client-server computing over traditional desktop or host-centric
models because of it's economy, scalability, and flexibility.
Database products were among the first to implement client-server
architectures, and the installed base of databases today contain
a rich mixture of all three models.  Each architecture has unique
strengths and weakness dictating it's use, and the mixture
reflects the diversity of users' database requirements.

To be effective at integrating databases in different computing
environment, database interoperabilty solutions need to be
flexible to take advantage of the strengths of each environment.
To date, no database interoperability standard has emerged that
provides this flexibility.

3. Different Data Access Models
Databases can be classified into two groups according to the
underlying model used for data access.

In the navigational model, data is stored as though it were
contained in a collection of records.  Individual data elements
are accessed by "navigating" through the collection until the
desired record is reached.  Databases running on personal
computers and networks (such as Btrieve, Paradox, dBASE, and
DataPerfect) have traditionally used the navigational model and
represent an enormous installed base of applications and data.

Data stored according to the relational model can be thought of
as residing in tables.  In this model, each data element can be
described in terms of rows and columns in tables and the
relationship between them.  Access to relational model data is
accomplished through set-oriented languages such as SQL.  The
relational model, in which SQL is the predominant access
language, has prevailed among host-based databases and has been
gaining as the prominent database access model.

The differences between these two classes of databases may not be
apparent to the end user.  In fact, end users employ very similar
types of queries and interfaces with both models, when using
today's state-of-the-art database products.  Regardless of how
data is presented to the user, these two types of databases
provide very different APIs to developers.  The divergence
between these two sets of APIs resulted from their having
originated on unrelated platforms, and does not indicate any
fundamental incompatibility between the two models.

The difference between the APIs used for relational and
navigational databases has made it difficult for developers to
access both kinds of data from a single application.  The
difficulty for developers has translated into a limited set of
choices for users who need their dissimilar databases to
interoperate.

C. IDAPI Capabilities

⌐    IDAPI will integrate applications that require both
     relational (SQL) and record oriented access to data.
     Developers will be able to freely mix both types of access
     methods as needed.

⌐    IDAPI is based on existing standards for database access and
     connectivity.

⌐    IDAPI integrates access between databases on different
     computing platforms.

D. IDAPI and Other Interfaces

1. IDAPI and SQL/CLI
The SQL Access Group (SAG) is a consortium of database vendors
and applications developers working together to define an
interface for SQL database interoperability (called the Call
Level Interface or CLI).  The goal of CLI is to provide a
standard means of accessing databases supporting the SQL query
language.  A CLI compliant application can access different SQL
databases without code change, provided the application does not
take advantage of any extensions offered by specific SQL database
systems.  The specification for CLI is now being standardized by
X/Open.

IDAPI will comply with the X/Open CLI (SQL/CLI) standard.  In
addition, IDAPI will allow heterogeneous access and joins to
navigational record-oriented databases and set-oriented SQL
databases.  IDAPI will propose navigational extensions to SQL/CLI
(called NAV/CLI within the IDAPI context) for consideration by
various interoperability and standards committees.  Thus, IDAPI
encompasses both the set-oriented model of SQL/CLI and the
navigational record-oriented model databases commonly used in
desktop applications.

IDAPI application interfaces will be initially defined for use by
C, C++, Pascal, and COBOL with the goal of providing a standard
API to access diverse formats across varying database, operating
system, and computing architectures.  The environment of
corporate computing systems continually presents MIS personnel
and users with this mix of diverse formats.  The goal of IDAPI is
to provide an API providing a single view of data throughout the
corporate environment.

2. IDAPI and ODBC
ODBC is the name given to an interface supported by Microsoft to
provide interoperability between Microsoft Windows applications
and different database products.  Initially this interface will
support function calls based on SQL/CLI, with the intent of
defining the functional areas common to many database products.
Applications will be required to contain code to take advantage
of specific database product features as required by the
applications developer.  Navigational database access is
supported by ODBC as individual drivers support it.

IDAPI supports SQL/CLI and includes navigational record-oriented
environments as an integral part of IDAPI technology.  X/Open
SQL/CLI will be supported by IDAPI, as well as full-function
access to navigational record oriented database products
(NAV/CLI). These navigational extensions will greatly simplify
the task of developing applications.  Operating systems support
is initially planned for OS/2 2.0, NetWare, DOS, and Windows.

Whereas ODBC provides for remote database access as a function of
the driver, IDAPI provides remote database access at both the
driver and IDAPI server level (Requester/Responder).  With the
Requester/Responder installed in a IDAPI environment, database
access may be directed to a remote database via an existing
electronic transport independent of driver functionality.

3. Summary

In summary, IDAPI will offer the following advantages over other
interfaces for database interoperability to both users and
developers:

⌐    Access to more data from within the same application.
⌐    Wider selection of applications to access a given source of
     data.
⌐    Freer choice of computing model.
⌐    Greater scalability.
⌐    Less code redesign from platform to platform, reducing code
     testing and maintenance.
⌐    More thorough investment protection and value added in more
     operating systems, across more data models, and through more
     computing architectures.
⌐    Integrate ODBC drivers into IDAPI thereby making all IDAPI
     functionality available to ODBC drivers.

E. IDAPI Benefits

IDAPI offers the following benefits for the full range of users
and software vendors for desktop and distributed systems:

End users:
⌐    Provides transparent access to data from a broad range of
     sources.
⌐    Requires little to no time delay in accessing heterogeneous
     data sources.
⌐    Supports multiple sessions in one application.

SQL users:
⌐    Provides X/Open SQL/CLI functionality plus extensions.
⌐    Permits data access to most widely used PC database
     products.
⌐    Provides SQL/CLI access to record-oriented databases.
⌐    Provides remote data access.

Record-oriented database users:
⌐    Permits access to SQL data with minimal application change.
⌐    Provides remote data access.

In-house and independent software developers:
⌐    Assures access to multiple database products without
     application code redesign.
⌐    Gives ISVs a broader market for their applications because
     of the greater number of database products that can be
     accessed.
⌐    Provides greater data processing capability through
     implementation of query processing and cross-table mapping
     and joins across different database products.

Database vendors:
⌐    Creates a broader market for their products because
     applications written for other data environments will be
     usable with their products.
⌐    Permits easy implementation of database drivers for the
     IDAPI environment.
⌐    Enables multiple client platforms to access DBMS products.
⌐    Provides a database/platform independent API aimed at
     maximum interoperability.
⌐    Supports concurrent connection to multiple databases while
     preserving uniform database access semantics across
     databases, platforms, and operating systems.
⌐    Supports queries spanning multiple databases.
⌐    Supports SQL/CLI and tolerates SQL dialect idiosyncracies.

Users, database vendors, application developers, and systems
integrators will all benefit from an open API that enables
support in many existing databases and platforms.


                     III. IDAPI Architecture


A. Architecture

The IDAPI architecture is depicted
in Figure 1.
The architecture allows
implementation extensions via
three methods:
⌐  Adding new drivers
⌐  Adding new relational and
navigational engines
⌐  Distributing the data model via
the requester/responder (this
extensibility is available even if
the native data model of the
database does not support it).

1. Client Applications
IDAPI conforming applications can
access any set of databases for which engines or drivers are
available.  IDAPI provides access to all the capabilities of the
underlying engine/driver.  The client application can choose to
be database independent or it can have special code for specific
databases.

2. Application Support Layer
The application support layer is an object-oriented
implementation of the data-model access method.  It is a set of
functions that manages the state and environment of a client
application.

This layer initializes the environment and configuration of the
client application and requests the loading of the appropriate
engine/driver dynamically as demanded by the Client Application.
It hides all semantics of the underlying engine/driver.  IDAPI
will allow ODBC drivers to be used without modification.  Because
the ODBC drivers are integrated into the IDAPI technology, all
IDAPI functions and benefits are realized by ODBC drivers.

3. Engine Support Layer
The core of the IDAPI environment is the engine support layer
comprised of  relational and navigational engines and
requester/responders.

4. Driver Support Layer
The driver support layer provides a consistent API for
interaction between IDAPI drivers and the engine support layer.

5. IDAPI Driver Layer
Drivers for many databases will be available from various
manufacturers.  New drivers may be created using an IDAPI
Software Development Kit (SDK) available from participating
vendors.  This toolkit provides services for isolating operating
system dependencies such as file I/O and memory management.  It
also provides services for internationalizing and localization.

B. Environment Configuration & Session Management

IDAPI provides extensive control of both data model and session
access.  Functions to configure new IDAPI drivers and access
methods, configure remote data models via the
requester/responder, and add additional relational and
navigational engines are provided.

Session Management allows applications to interact with the
session level functions required by some database environments.
Functions to initiate and terminate sessions as well as data
access "login" are provided.

C. Database Capabilities

The heterogeneous nature of IDAPI allows application developers
to use a single API to access data in a variety of data models.
Functions within IDAPI allow the application developer to declare
data types, index types, access models, referential integrity,
etc.  Each function is designed to provide all information
necessary for full heterogeneous interaction.

D. Database Operations and Data Manipulation

Functions for the manipulation of tables, indexes, locks, search
criteria, cursor management, database information access, etc.
are fully supported by IDAPI.

E. Relational and Navigational Engines

IDAPI allows special drivers to be configured that will provide
specialized relational and navigational query language handling.
If a database model has a query method other than SQL/CLI, the
method may be integrated into IDAPI by adding a relational or
navigational engine to handle the query syntax and semantics.
The relational or navigational engine will then use the database
driver to access the information.

F. Remote Data Access

The architecture of IDAPI naturally supports remote database
access.  Remote data requests are routed via the IDAPI requestor
to a corresponding IDAPI responder.  The responder acts as an
application by resolving the request and then returning the
response set to the requestor.  The Requestor then acts as a
driver returning the response set as a reply from a driver.

Several remote database architectures can be supported by IDAPI,
including Distributed Relational Database Architectures (DRDA)
and NetWare.

                       IV. IDAPI Benefits

⌐    IDAPI will support an integrated method allowing data access
     to both applications that require SQL/CLI based and record
     oriented navigational access.  Developers will be able to
     freely mix both types of access methods in a single
     applications with a consistent API.

⌐    IDAPI will allow developers to preserve the investment they
     have made in database technologies such as dBASE, Paradox,
     Btrieve, and DataPerfect.  It also allows developers to
     access additional sources of data using existing SQL
     databases.

⌐    IDAPI is based on standards for database access and
     connectivity.  For example, it provides the ability to use
     standard SQL calls based on the SQL/CLI.  The IDAPI work
     group is committed to working with interoperability and
     standard bodies such as ANSI, X/Open, and SAG to broaden the
     scope of existing database connectivity interface standards.

⌐    IDAPI will allow integrated access between databases on
     different computing platforms, a critical user requirement
     in today's heterogeneous computing environment.

⌐    IDAPI will provide support for cross database operations,
     such as joins between tables and environments maintained in
     two or more disparate database servers.  Because of this
     support, developers will not need to write special code to
     manage these types of operations.

⌐    IDAPI is designed for network or stand-alone
     implementations.  The functionality that IDAPI provides can
     be implemented on the workstation client or on the network
     server or enterprise server, depending on the application
     and configuration.  IDAPI addresses critical network issues
     such as establishing and managing connectivity between
     databases.
                           V. Summary

IDAPI will propel database applications to a new level of
usability.  Diverse data models will be integrated into a single
model by IDAPI, thus enhancing the value of existing data stores
by providing access to a wide variety of applications.  The
following list details the distinct advantages of using IDAPI:

⌐    IDAPI is an open database API embracing set- and record-
     oriented data models.
⌐    IDAPI will initially have C, C++, Pascal, and COBOL APIs for
     maximum portability.
⌐    IDAPI communicates with different database engines, drivers,
     and servers via a single API.
⌐    IDAPI supports both client-based and client-server
     environments.
⌐    IDAPI supports SQL/CLI and record-oriented query methods.
⌐    IDAPI is supported by multiple database and computing
     environment vendors.