Download Enterprise Application Ingetration

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 databaseoriented 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:
1. An interface to an application
2. The ability to convert the application language into
something understandable by the target database (for
example SQL)
3. The ability to send a query to a database over a network
4. The ability to process a query on the target database
5. The ability to move a response set (result of a query) back
over the network to the requesting application
6. 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. It’s 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 don’t 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 it’s bound to a
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 it’s 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:
1. The JDBC API provides application-to-JDBC Manager
communications
2. 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.registerDrive 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:
1.
2.
3.
4.
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, multidimensional, 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.
It’s not so much in use anymore because it doesn’t 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).