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:
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:
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:
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).
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.
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.
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.
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.
This one can work in two ways:
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.
This document is empty and basically useless. It is generated by a web service that can make some statements in HTML Microdata format. This time the service made zero such statements, sorry.