What are Multi-Tier Drivers?

The Multi-Tier Drivers comprise client and server components, being uniquely equipped with a built-in high-performance database-independent networking layer and a session rules-book for governing and securing connections. These drivers are network-ready out of the box, and capable of dynamically discovering matching server components anywhere in a LAN/subnet using the "Bonjour" service-discovery protocol (previously known as "Rendezvous", an implementation of ZeroConfig).

Being Multi-Tier, these drivers include interface implementations at both the client and the server levels.

Why Multi-Tier?

In today''s world of client/server and web/application-server-based deployment architectures, 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.

Server-side security features are implemented in the session Rule Book; access-controls take the form of a matrix of incoming connection criteria such as the IP#, Database, User, Application, OS and RDBMS type, so the administrator has maximum flexibility and fine granularity in defining what connections are permitted.

Driver Architecture

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. By installing this on client machines, they can connect to any Request Broker component elsewhere

• OpenLink RPC Client

  this 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 Broker

  one 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 Agent

  another 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 (so one generic client and one request broker, many agents for each different kind of database to which you wish to connect); 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: 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 ADO.NET-based Database Agents open-up database avenues for .NET developers looking to embrace different technologies, be it different databases or operating systems, where the .NET architecture is not available. With a client, built using the C# language, direct access to the OpenLink Server is achieved, in the process bypassing the native ODBC driver manager for speedier response and manageability.

At the OpenLink Server level, we show the different data-access architectures provided. The server database agents are built using the native Database CLI.

Type A CLI-based Database Agents

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 these situations 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).

Type A Architectural Diagram for ADO.NET Image scaled down; Click to enlarge.

Type A Architectural Diagram for Progress ADO.NET Image scaled down; Click to enlarge.

Type B CLI-based Database Agents

This Database Agent format is similar to Type A, 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.

Type B Architectural Diagram for ADO.NET Image scaled down; Click to enlarge.

Type C CLI-based Database Agents

(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

Type C Architectural Diagram for ADO.NET Image scaled down; Click to enlarge.