(1) Bridge
app <-> bridge <-> DB driver <-> database
Use to bridge between an existing database connectivity standard and a new one. For example, a JDBC/ODBC bridge driver presents Java call interface to the program but translate the call to ODBC standard. These are also called JDBC type 1 drivers which are often not desirable because they often constrain by the existing driver (ODBC) and thus cannot implement the new standard (JDBC) fully. These driver also possess security risk and performance constrain under high load.
(2) Database Client-Based
app <-> DB driver <-> client software <-> database
The driver communicate through the database client software (e.g. Oracle NETx, Sybase OpenClient). Many ODBC drivers and ADO.NET data providers uses this architecture. In JDBC, this is classified as type 2 driver and is generally not desirable. The disadvantages are:
(a) Management overhead to maintain client software in all client platforms
(b) Functional and quality constrain of the client software to the driver
(c) For ADO.NET, the need to transit to unmanaged code in client software
(3) Database Wire-Protocol
app <-> DB driver <-> database
JDBC drivers using this architecture are called type 4 driver. The driver generates the required wire protocol calls (e.g. DB2 uses DRDA) to communicate directly with the database. Performance is optimal. For Java and .NET, because the driver does not need to call the client software, the DB calls are executed in fully managed code.
(4) Independent Protocol
app <-> DB driver client <-> DB Driver Server <-> database
These drivers translate the standard based API calls into a database independent protocol, which is then translated to the database wire protocol by a server. In JDBC, this is known as type 3. This architecture can provide advanced feature (e.g. security or encryption), connect to varies set of database source (e.g. VSAM) and central management and monitoring capability.
No comments:
Post a Comment