How OpenLink's Component Objects Work Together
Open Database Connectivity Without Compromise !

Data Source Session Establishment

When an ODBC compliant application logs on to an ODBC data source, it does so through the ODBC driver manger. The end result of this process being, a data source connection request being passed on to the Generic OpenLink (MT) ODBC Driver.

Figure 0-1

The Generic OpenLink ODBC (MT) Driver, then assembles an OpenLink message, by appending additional information, such as the database type, destination host name, source machine name, source application name, to the ODBC message generated by the ODBC Driver Manager.

Figure 0-2

The OpenLink Request Agent, translates this message into, an OpenLink Database Agent session request, and then conveys it over your network to the OpenLink Request Broker, residing on the host, already identified, by the original message packaged by the Generic OpenLink ODBC (MT) Driver.

Figure 0-3

The OpenLink Request Broker resolves this OpenLink Request Agent generated message, and determines if it needs to create an association, between the Request Agent and an existing instance of an OpenLink Database Agent (session rules book permitting, see section on server components), Replicates an existing Database Agent instance, or Spawns a new instance of an OpenLink Database Agent for the database type, identified by the message received from the OpenLink Request Agent. This process also associates an OpenLink Database Agent with the actual database, that your ODBC compliant application is seeking to initiate an ODBC session with.

Figure 0-4

Message Relaying

Once a connection, has been established between the OpenLink Request Agent, and an OpenLink Database Agent, all subsequent ODBC messages, are relayed from you desktop ODBC compliant application, through the Generic OpenLink ODBC Driver, via the OpenLink Request Agent, directly on to the relevant Database Agent instance. Replies from the Database Agents, are relayed via Request Agent, back to the Generic ODBC Driver, and finally back into your ODBC compliant desktop application.

Figure 0-5

During this stage of an ODBC based, Client-Server session, the ODBC Driver Manager and the OpenLink Request Broker become passive, playing the roles of enforcement agents (the OpenLink Request Broker does this through its session rules book), until either, another ODBC compliant desktop application seeks to initiate an ODBC connection, or additional data sources connection requests, are made from existing ODBC sessions.

The OpenLink Session Rules Book

As explained earlier within this document, your OpenLink ODBC based Client-Server infrastructure can be managed from a central point using a "Rule Book" approach. The OpenLink Request Broker uses a Session Rules Book to manage the way Database Agents are spawned, replicated and re-associated with the OpenLink Request Agent. The OpenLink Session Rules Book also provides you with Multi dimensional , and flexible control over Domains, Databases, Users, ODBC Compliant Applications, Client Operating Systems, and Network Addresses.

The flexibility provided by the OpenLink Session Rules Book results in OpenLink ODBC based Client-Server infrastructure being able to handle ODBC killer issues such as default database isolation levels, server operating system security, and ODBC compliant application generated network traffic.

Table Of Contents | Next | Previous