= uda.jdbc.mt %TOC% = Multi-Tier (Enterprise Edition) %TOC% Multi-Tier (Enterprise Edition) The Multi-Tier Drivers comprise client and server components, being uniquely equipped with an in-built high-performance database-independent networking layer and a session rules-book. These drivers are network-ready out of the box, and capable of dynamically discovering matching server components anywhere in a LAN/subnet using the Rendezvous service-discovery protocol. These drivers are described as "Multi-Tier" due to the fact that they include interface implementations at both the client and the server levels. In today''s world of client/server and web/application server based programming paradigms, with remote clients attempting to access your company''s corporate data from any number of unknown locations, security becomes a major concern of any organization in terms of controlling the access to this information. The [[OpenLink]] Multi-Tier architecture utilizes a server-side sessions Rule Book on the to enforce access- controls to the Database server from incoming client requests based on multiple-access criteria across the Domain, Database, User, Application, OS or hostname being presented by the client. This gives the company Network/Database Administrator ultimate control of who or what groups of users are allowed access to the database. [[/images/udajdbcmt.gif|]] / Image scaled down; Click to enlarge./ The Multi-Tier Drivers include the following components: *Generic Client(the entry for service consumption) this is component that provides the high level implementation of the relevant data-access mechanism (ODBC, JDBC, OLE DB, or .NET Provider) within the multi-tier component stack. *[[OpenLink]] RPC Clientthis is the client side of the database-independent networking layer, and it is inextricably associated with the generic client at runtime (so you do not physically see this component as a separate library or class file etc). *[[OpenLink]] Request Brokerone of the server-side components that implements server-side [[OpenLink]] RPC functionality. This is the part of the Multi-Tier architecture that is responsible for session instantiation, configuration management, and overall system security. It is the heart and soul of the Multi-Tier component stack. *Database Agentanother server-side component that implements both the server-side [[OpenLink]] RPC functionality and the actual [[OpenLink]] Data Access functionality. This is the only database-specific component in the Multi-Tier component stack, it is also the set of interfaces implemented via the database vendor-provided CLI. The architectures of the Multi-Tier and Single-Tier drivers are different, but not as different as instinctively assumed. This is because the Single-Tier database specific driver and the Multi-Tier Database Agent share a common core. What does not change is they both implement the call-level interfaces albeit at different places. The call-level interfaces take the following forms: *Type A - C-based dynamic SQL interface that inextricably includes client and server networking components *Type B - C-based remote procedure calls (RPC) interface to the wire-protocol of the underlying database. This is a client-only interface that communicates directly with the remote database server. These interfaces are not typically available to third-party developers. To date the Open Source projects such as [[FreeTDS]] , [[MySQL]] , [[PostgreSQL]] , and Interbase are the only publicly accessible and freely available versions of such interfaces. *Type C - Generic bridges, these are ODBC, JDBC, OLE DB, and .NET providers that act as implementation proxies, such that bridging can be achieved in the manner depicted in the matrix below: [[OpenLink]] provides Multi-Tier Drivers built using the Type A, B, and C call-level interfaces formats, depending on what is publicly available to third-party developers by the vendors of the respective database engines. Please view your respective Data Access Mechanism for more information. The [[OpenLink]] Multi-Tier data-access layer uses pure Java and JDBC technology to communicate with the [[OpenLink]] Server components. This method of data-access also employs the different data-access mechanisms which are outlined below. These drivers are built using the Type-A call level interfaces of the relevant back-end database engine, and the [[OpenLink]] database independent networking layer. Thus, this driver format implements the generic interfaces of [[OpenLink]] Data Access interface using a database vendor provided CLI. Being Type A, this CLI includes data access and database vendor provided networking middleware which is optionally usable by the database agent (it is still simply a database client as far as the back-end database is concerned). Database Agents are typically installed on the same machine as the database engines that they will be accessing. This is the norm in a typical client-server scenario in which the [[OpenLink]] Client components are installed on a desktop machine or workstation. In reality, there are political, infrastructural, and application format (application server configuration) barriers that may impede your ability, or desire, to install the Database Agent on the database server machine. In situations such as these the Database Agents ability to use the database vendor provided networking middleware comes into vital use, and will enable you to setup 3-Tier or N-Tier topologies (sometimes referred to as gateway architectures). [[/images/ajdbcmt.gif|]] /Type A Architectural Diagram for JDBC Image scaled down; Click to enlarge./ [[/images/ajdbcmt.gif|]] /Type A Architectural Diagram for Progress JDBC Image scaled down; Click to enlarge./ This Database Agent format is similar to Type A with the only difference being the format of CLI used to implement the [[OpenLink]] Data Access Interface. In this case the CLI is a database vendor-provided RPC-client that talks directly to remote database servers. This also means no database vendor-provided networking is required in 3-Tier or N-Tier topologies. [[/images/bjdbcmt.gif|]] /Type B Architectural Diagram for JDBC Image scaled down; Click to enlarge./ (also known as Proxies or Bridges). These drivers are proxies that sit atop third-party implementations of the relevant data-access mechanisms. Their prime purpose is to integrate third-party data-access drivers into the [[OpenLink]] Multi-Tier architecture. Proxies are currently available in the following forms: *ODBC Agent - an implementation of the [[OpenLink]] Data Access Interface using ODBC/JDBC databases [[/images/cjdbcmt.gif|]] /Type C Architectural Diagram for JDBC Image scaled down; Click to enlarge./ | Standards Compliance | | JDBC 3.0 Datatype Enhancements support | The DATALINK and BOOLEAN datatypes are additions to java.sql.Types. the DATALINK type provides access to external resources (URLs) from within a resultset using the new getURL() methods. While the BOOLEAN type is the logical equivalent of the BIT type with additional semantics, and is retrieved from a resultset using the getBoolean() method. | JDBC Metadata Enhancements support | The JDBC metadata APIs have been enhanced in JDBC 3.0, with the [[DatabaseMetaData]] interface now able to retrieve SQL type hierarchies. There is also a new [[ParameterMetaData]] interface to describe the types and properties of the parameters in [[PreparedStatement]] objects. | | Platform Support | Support for client, server, and application server operating systems | | 32- and 64-bit components | Enables the development and utilization of 32- or 64-Bit DBMS independent applications. | Database Engine Support | Backend database engine support | | Broad backend Database Support | Enables DBMS independent application utilization and deployment across a vast array of industry leading DBMS engines that includes; Oracle (7.x - 10.x), SQL Server (6.x - 2005), DB2 (6.x - 8.x), Sybase (10.x - 12.x), Progress (7.x - 10.x), Ingres (6.4 - II family), Informix (5.x - 9.x & IDS 2000), [[MySQL]] , and [[PostgreSQL]] . | Performance | | Blistering Performance | Delivery of data access performance levels across ODBC, JDBC, ADO.NET and OLE DB that don't compromise viability of DBMS independent application development and deployment. | Network Aware Record Retrieval | Enabling the retrieval and insertion of multiple DBMS records in batches over the network with a minimal number of network hops. | | Security | | Rules Engine Based Security | Alignment and enforcement of data access policies across facets of enterprise IS infrastructure. This includes any combination of; users, user roles, applications, operating systems, databases, machine aliases, and networks. | Secure Data Transmission | Enables development and utlization of encrypted data transmission between DBMS independent applications and backend databases. | | Administration | Configuration and Management | | Zero Configuration for ODBC DSNs | Provides a Cross Platform implementation of the Rendezvous service discovery protocol. This enables the configuration of ODBC Data Sources Names (DSNs) to be completely server based with no client side configuration whatsoever. You simply pick a DSN configuration associated with your [[OpenLink]] Request Broker from combo-box hosted list of [[OpenLink]] Services. | Packaging | The manner in which product components are packaged | | Miniature Driver Size | Driver size is minimal with the smallest variant (Megathin) under 60K in size. | Usability | | Network Ready | Enables usage of DBMS independent applications on any platform without installation of additional DBMS specific networking products. | Generic Drivers | Install one, as opposed to several, client components per data access standard and driver combination for your database independent applications. | | Administration | Configuration and Management | | Centralized Configuration & Management | A single point of focus when administering the data sources that serve the data access standards compliant applications. | Standards Compliance | | International character support | Enables the development and deployment of international applications that are independent of underlying database engine. | Performance | | Multithreaded | Enables exploitation of scalability benefits arising from the use of multiple CPUs or Clusters while developing or using DBMS independent applications. | Array Bound [[RowSets]] | As part of the new [[RowSet]] class. It is now possible to bind data arrays to the columns of the [[OpenLink]] [[RowSet]] object, and retrieve the data directly into the arrays with a single invocation of the RowSet.next() method. | | Standards Compliance | | Supports Advanced Data Access API functionality | Enables the development and utilization of DBMS application with DBMS independent granularity that extends to challenging areas such as scalar function calls, dates and timestamps manipulation, outer join handling, and SQL stored procedure invocation etc. | ODBC and JDBC Scrollable Cursor Support | Enables the development of JDBC based DBMS independent applications that are capable of exploiting the ODBC style (Attached [[RowSet]] extension to JDBC by [[OpenLink]] ) and JDBC style (Detached [[RowSet]] ) scrollable cursor models from a single driver. This approach provides the application developer with maximum flexibiity and control over the degree of database change sensitivity expressed by a JDBC based application. | | JDBC 3.0 Connection Pooling support | JDBC 3.0 standardizes connection pooling configuration properties thereby alleviating complexity from the myriad vendor-specific properties in JDBC 2.0. This enables higher interchangeability across JDBC Drivers for JDBC compliant application and service developers. Additionally, the properties allow administrators to fine tune the connection pool to maximize performance characteristics of the application or service. The following properties are implemented by our drivers; maxStatements, initialPoolSize, minPoolSize, maxPoolSize, maxIdleTime, and propertyCycle | | Named Parameters in Callable Statements | Prior to JDBC 3.0, the way to set a parameter in a SQL Stored Procedure was by specifying the parameter's index, not its name. The [[CallableStatement]] interface has been enhanced in JDBC 3.0 so that you can now specify parameters by their names. | | Resultset Holdability | A holdable cursor, or result, is one that does not automatically close when the transaction that contains the cursor is committed. JDBC 3.0 adds support for specifying cursor holdability. To specify the holdability of your [[ResultSet]] , you must do so when preparing a statement using the createStatement(), prepareStatement(), or prepareCall() methods. The holdability may be one of the following constants: HOLD **CURSORS_OVER_COMMIT or CLOSE_CURSORS_AT_COMMIT. Note it is more efficient to close CURSOR at the end of transactions (after the COMMIT). JDBC doesn't specifiy a default HOLD_CURSOR behavour but for resource expediency we have chosen CLOSE_CURSORS_AT_COMMIT as the default. ** | | Prepared Statement Pooling support | A prepared statement allows you to take a commonly used SQL statement and pre-compile it, thereby dramatically improving performance if the statement is executed multiple times. If your applications has many queries that are reused with only parametic changes occuring, then it is beneficial to pool this statements and retain control over their life span. JDBC 3.0 delivers as solution to this need via Prepared Statement Pooling, which enables the life span of a prepared statement to be handled at the driver level thereby alleviating the JDBC application or service developer of this responsibility. | | Transaction Savepoints support | JDBC 3.0 provides the ability to have increased granularity over the control of database transactions. The new Savepoint interface allows you to partition a transaction into logical breakpoints, providing control over how much of the transaction gets rolled back. | ----