1 / 19

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 .

malha
Download Presentation

Chapter 11 – Database-Oriented Middleware & EAI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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) Chapter 11 – Database-Oriented Middleware & EAI

  2. Fig. 11.1 Database –Oriented Middleware

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

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

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

  6. Fig. 11.3 Functions of Database-Oriented Middleware

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

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

  9. 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 particular database brand.

  10. Fig. 11.5 The ODBC Driver Manger

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

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

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

  14. 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: JDBC-ODBC bridge driver A native-API part-Java driver A net-protocol all-Java driver A native-protocol all-Java driver.

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

  16. Fig. 11.7 OLE DB

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

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

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

More Related