Chapter 11 DatabaseOriented Middleware - PowerPoint PPT Presentation

1 / 19

About This Presentation

Title:

Chapter 11 DatabaseOriented Middleware

Description:

Database oriented middleware is not just a mechanism to 'get at' data, it has ... For example if data contained in a ... Fig. 11.5 The ODBC Driver Manger ... – PowerPoint PPT presentation

Number of Views:83

Avg rating:3.0/5.0

Slides: 20

Provided by: roberts74

Category:

more less

Transcript and Presenter's Notes

Title: Chapter 11 DatabaseOriented Middleware

1
Chapter 11 Database-Oriented Middleware EAI

Database access is the key element to EAI,
especially data-level EAI.
Database oriented middleware is not just a
mechanism to get at data, it has also become a
layer for placing data within the context of a
particular common database model or format, known
as virtual database.
For example if data contained in a relational
database is to be viewed as objects, the database
oriented middleware can map the information
stored in the relational database so it appears
as objects to a source or target application.
The same thing can be done the other way
around-mixing and matching models such as
hierarchical, flat files, multidimensional,
relational, and object-oriented (See Fig. 11.1)

Fig. 11.1 Database Oriented
Middleware

Database-oriented middleware also provides access
to any number of databases, regardless of the
model employed or the platform upon which they
exist.
This is generally accomplished through a single,
common interface such as Open Database
Connectivity (ODBC) or Java Database Connectivity
(JDBC). As a result the information stored for
example in a Oracle, Sybase, etc databases, can
be accessed at the same time through a single
interface as shown in Fig. 11.2
By taking advantage of these mechanisms, it is
possible to map the difference in the source and
target databases to a common model, making them
much easier to integrate.
This process also supports the notion of a common
enterprise metadata model presented in previous
lectures.
If a message broker or an application server
requires information contained in a database,
then database-oriented middleware becomes the
logical solution for accessing that information.

Fig. 11.2 Database Oriented Middleware
Provides Access to a Number of
Databases at the Same Time.

What is Database-Oriented Middleware?
DOM provides a number of important benefits
An interface to an application
The ability to convert the application language
into something understandable by the target
database (for example SQL)
The ability to send a query to a database over a
network
The ability to process a query on the target
database
The ability to move a response set (result of a
query) back over the network to the requesting
application
The ability to convert a response set into a
format understandable by the requesting
application
In addition to these processes, database-oriented
middleware must also provide the ability to
process many simultaneous requests, as well as
provide scaling features, such thread pooling and
load balancing.

Fig. 11.3 Functions of
Database-Oriented Middleware

Types of Database-Oriented Middleware
Database-oriented middleware can be defined as
all the software that connects some application
to some database.
Like primitive middleware layers, database
oriented middleware allows developers to access
the resources of another computer, in this case,
a database server, using a single, well defined
API.
Although there are several types of database
middleware, they are all basically native
middleware-call-level interfaces (CLIs) and
database gateways. In other words, native
middleware is middleware that was created for a
specific database.
Native database-oriented middleware provides the
best performance and access to native database
features because the middleware has been created
for a particular database. However, once the
links to a database have been created using
native middleware, major renovations will be
required in order to change databases.

CLIs (ODBC, JDBC) provide a single interface to
several databases.
CLIs are able to translate common interface calls
into any number of databases dialects, as well as
translate the response sets into a common
response representation (See Fig. 11.4)
understandable by the application making the
request to the database.
Fig. 11.4 CLIs Use a Single
Common Interface

ODBC
ODBC is more a standard than a product, that
Microsoft created a few years ago. Its a CLI
that simplifies database access from Windows (as
well as a few other OS) by allowing a developer
to make a single API call that works with most
relational databases, along with a few that dont
follow the relational model.
It can be said that ODBC is a translation layer.
Like all the middleware layers, ODBC provides a
well-defined and database-independent API. When
using the API, ODBC utilizes a driver manager to
determine which database the application would
like to communicate with and load (unload) the
appropriate ODBC driver (See Fig. 11.5)
As a result, an application using ODBC is
database independent.
But, if there are any database-specific calls
(such as passing SQL directly through to the
database or invoking a number of stored
procedures and triggers, the application is no
longer database independent because its bound to
a particular database brand.

Fig. 11.5 The ODBC Driver
Manger

In conclusion we can say that ODBC is good enough
for most EAI projects, especially for those
using a Microsoft platform. ODBC should be
considered when operating in a multi-database
platform that requires access to several
different databases from the same application or
integration server.
ODBC is also good fit is a database is likely to
change during the life cycle of the application
However, ODBC must be avoided if only one
particular database is used or if the solution
requires a large number of proprietary database
functions.
JDBC
JDBC was designed by JavaSoft and it was the
first standard Java-enabled database.
Function-wise its equivalent to ODBC, but it
also provides Java developers with a uniform
interface to most popular relational databases
from most Java-enabled development or
application-processing environments.

The JDBC API defines a set of Java classes that
allow an applet, servlet, JavaBean, or Java
application to connect to a database.
In most cases, such an applet is the one that
links back through the network to remote
relational database servers, such as Sybase,
Oracle or Informix.
The native Java JDBC classes, sold by the
database vendors, exist with the custom
application classes and provide pure Java and
portable mechanism for database access.
These allow you to link to any database from any
platform that supports Java.
JDBC Java classes allow developers to use native
Java to issue common SQL statements to request
information from a remote database, as well as
process the result set.
Because JDBC is also a translation layer (like
ODBC), Java applications that employ JDBC are
database independent and can access any number of
databases through a single JDBC interface.

There are two major layers in JDBC
The JDBC API ?provides application-to-JDBC
Manager communications
The JDBC Driver API
Fig. 11.6 JDBC
Layers

In order for the Driver Manager to locate the
correct driver, each driver has to register with
the Driver Manager using the DriverManager.registe
rDrive method, invoked from the applet.
JDBCs limited security is only able to use
drivers coming from the local file system or from
the same class loader.
JDBC Drivers fit in the following categories
JDBC-ODBC bridge driver
A native-API part-Java driver
A net-protocol all-Java driver
A native-protocol all-Java driver.

OLE DB
OLE DB is a specification that defines a set of
data access servers capable of facilitating links
to any number of data sources.
As a result, developers have the ability to
manage different data sources as a single virtual
database.
OLE DB allows access to data using a standard COM
interface and it gives developers the means to
access data that resides in relational databases,
documents, spreadsheets, files, emails, etc.
When using OLE DB, the database simply becomes a
component known as data provider. Any component
that uses a native data format and exposes
methods through an OLE DB interface is considered
a data provider, including relational databases
(using ODBC), a text file, an email, or a data
stream (See Fig. 11.7)

Fig.
11.7 OLE DB

The idea is to create an individual OLE DB
component object to deploy additional features
that are layered on top of the data providers.
These individual OLE DB components are called
service providers.
Service providers are like query processors in
that they allow applications to take advantage of
providers that interconnect different
combinations of data. The data, regardless of
model (object-oriented, relational,
multi-dimensional, etc), exists as single view.
This solves the relational-bound limitations when
using ODBC.
The other side of data providers are OLE DB data
consumers, applications written to a single data
provider or generic consumers that work with any
number of data providers.
Why using native database-oriented middleware? ?
the advantage is using it compared to ODBC, JDBC,
OLE DB, is the ability to provide
high-performance database access, along with the
ability to access features native to a specific
database but that binds the user to the
middleware vendor.

Database Gateways
AKA SQL gateways ? are APIs that use a single
interface to provide access to most databases
residing on many different types of platforms.
They are like virtual database middleware
products providing developers with access to any
number of databases, residing in environments
typically not easily accessible, such as a
mainframe.
Database gateways translate the SQL calls into a
standard format known as the Format and Protocol
(FAP), the common connection between the client
and the server. It is also the common link
between very different databases and platforms.
The gateway can translate the API call directly
into FAP, moving the request to the target
database and translating the request so that the
target database and platform can react.

Some major Database gateways on the market are
1. EDA/SQL ?is a general purpose database gateway
that works with most database servers and
platforms. It uses ODBC as the interface rather
than a proprietary API.
2. RDA ? standard for developers to access data.
RDA uses OSI and supports dynamic SQL. It allows
the client to be connected to more than 1
database server at the same time. Its not so
much in use anymore because it doesnt support
typical transaction-related services.
3. DRDA ? IBM database connectivity standard that
has the support of companies like Sybase, Oracle,
IBI, etc. it attempts to provide easy database
connectivity between any number of databases
operating in multiplatform environments. DRDA
defines database transactions as remote requests
(one SQL statement is sent to one database),
remote units of work (many SQL statements sent to
one database), distributed units of work and
distributed requests (many SQL statements sent to
many databases).