= doc.Index.index.uda.dotnet.mt

%TOC%

   
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. 

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. 

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


----