Ask a question?
  • Contact Us
  • Support Case System
  • Support Forum

Enterprise Edition (Multi-Tier) Drivers for ODBC, JDBC, and ADO.NET

Architecture Diagram

OpenLink UDA Multi Tier Architecture Diagram

Description

Our Multi-Tier architecture is designed for enterprise use, where components are typically to be installed on both the client machine (where user applications run) and the database server.

The advantages are:

  • a thin client - no need to install an RDBMS provider's networking layer components on all the client machines;
  • Control: access-control lists can be configured centrally on the server;
  • Management: the server's resource usage can be controlled to optimize performance.
  • Network-enabling access to obscure or legacy databases and operating-systems

Components

Request Broker

The Request Broker ("oplrqb") forms a central hub, handling incoming connection requests and handing them off to agents.

Each connection provides certain attributes - for example the hostname (IP address) of the calling client, the name of the user application, the name and type of database requested, etc.

The Request Broker takes these parameters and compares them against a matrix of possible combinations to determine which agent should handle the connection, if permitted.

Typical rules that can be implemented include:

  • if the request is from outside our network, deny it completely;
  • if the request is from another partially permitted network, force their access to be read-only (regardless of client DSN settings);
  • if the client DSN had a domain of a particular version of a database but the server has been upgraded, ignore the version number and connect them appropriately;
  • if the client application is Microsoft Access or Excel, enable fixes for the JET Engine (certain data-type mappings against certain databases).
  • Whatever username you requested, you're getting a connection as "guest" instead.

Database Agents

Database Agents come in two kinds: simple database connection, and protcol or proxy implementations.

Being the only database-specific component in the Multi-Tier architecture, an agent could be specifically for Oracle, Microsoft SQL Server, CA OpenIngres, Informix, MySQL or PostgreSQL, etc.

Protocol and Proxy agents are slightly different, in that they connect back to a request broker, in order to request a different kind of connection. For example, the Proxy agent is used to straddle network firewalls; the JDBC agent acts as a bridge between a native database agent and a JDBC client; the ODBC agent expects its "server" to be an ODBC Driver Manager, through which it will connect to a further ODBC DSN.

The mapping of client requests to database agent processes is controlled by the Request Broker in its Rulebook; through the Reuse directives, you can construct rules such as:

  • requests from the same client machine go through the same agent
  • at most up to 5 concurrent connections go through the same agent
  • requests from the same application and username go through the same agent
  • Never reuse agents for a particular database.

The server administrator can specify these and other parameters in order to control the resource usage of the server - for example, if there is no agent-reuse active, then every connection requires a new agent to be loaded off disk, to make its connection to the database, and occupy some memory. Alternatively, if all connections went through the same agent, you would lose control of agent commandline options (such as +jetfix mentioned above).

Generic Clients

Our Generic Clients implement a particular data-access protocol for the user's client application. Whether the application uses ODBC, JDBC, OleDB or ADO.NET, the appropriate generic client for that access mechanism implements OpenLink's database-independent Remote Procedure Call (RPC) network layer to talk to the server-side components; this makes it thin, requiring few resources on the client computer as all the driver's computation is performed in the database agent instead.

Network

With the exception that the Request Broker and Database Agent(s) it spawns must be located on the same machine, there is otherwise no requirement that the other components be so located.

For example, database agents can use either shared-memory or the network in order to establish a connection to the database, so the database server could be on a remote machine from the agent. Alternatively, the client and request-broker could be on the same computer.

Scenarios

Many Clients

Multi-Tier is ideally suited if you have many users connecting via a one or a handful of data-access protocols (ODBC, JDBC etc) to a central database server, and want to implement centralized access-control and reuse rules.

Many Clients, Legacy Database Server

A classic example of this is having a database running on a mainframe, that requires an obscure network protocol to connect to it (eg something not using TCP/IP). However, if you have a server that can connect, running an operating system OpenLink supports, then you can put the Request Broker and Database Agent on that intermediate server and have the agent make its connection via the obscure protocol. This allows many client computers to connect through that gateway machine, to the database, without having to install and configure strange networking protocols on all of them.

Enforcing Requirements

This one can work in two ways:

  • Making life easier: if you have many workstations, to save having to enter DSN parameters precisely the same on all of them, you can use the Rulebook to make a rule such as "whatever user you asked for, because the application is Microsoft Access talking to the Sales database, the user is now scott/tiger". Thus the username/password fields in client applications become irrelevant, and one identity is implemented for the application.
  • Implementing security policy: you can create access-control lists such as:
    • If the connection is coming in from the LAN, use their credentials
    • If the connection is remote, and the database is "support", permit them
    • If the connection is remote and the database is "sales", permit them but set the user to a low-privilege account
    • Otherwise, for all remote connections, deny access (regardless of whether they specified a valid username+password in their DSN or not)

Central Gatekeeper

A logical continuation of the above: if you have several databases on different servers around your network infrastructure, you can stipulate one server to be a gateway on which the request broker and agents run, and only on that server do you need to install RDBMS-specific network layers (eg Oracle SQL*net, or similar for Informix, Ingres, etc). Then all workstations connect to the central server running the request broker, and it distributes the connections based on the domain (RDBMS) and database requested.