Even the best-designed database cannot overcome the limitations of poorly designed or underpowered business applications. Database-oriented applications often suffer when you place too much load on the client, or at the other end of the spectrum, when you put too much demand on the database server.
The trick to implementing a robust database application, then, is to balance the resources of the clients against the resources of the servers. Two popular approaches to obtaining this balance are multitiered business applications and Open Database Connectivity (ODBC) servers.
Desktop applications gain power by moving some processing to a server, or "partitioning" the application. Application partitioning uses middleware to distribute logic across processes on multiple computers. In the database world, the transition from a file server architecture to a client/server architecture was an early example of moving logic to the server. A file server has no intelligence beyond the ability to read and write files, so applications using file servers execute query logic at the client level.
SQL Database Management Systems (DBMSs), in contrast, often use a client/server architecture that executes query logic at the server. Many SQL products have additional partitioning capability because they can execute stored procedures at the server. Stored procedures (or persistent stored modules in SQL3 terms) are business rules or other logic stored at the server. For SQL databases, stored procedures are typically optimized,
precompiled SQL scripts. Stored procedures are also a useful tool for version control because changing an application's logic requires only one change at the server instead of changes to multiple client PCs.
Traditional client/server SQL applications follow a two-tier architecture: A server hosts the databases and SQL engine, and clients host application and presentation logic. As the number of users increases, that architecture can exhibit performance problems.
To overcome these problems, some developers balance workloads by partitioning logic and adding tiers. A three-tier architecture augments the database server with a separate application server that handles business rules and related logic. For example, in a desktop accounting application, the sales tax calculations are accessible only to code on the PC running the application. Moving the logic to an application server lets multiple client computers access the procedure or object that does sales tax calculations.
To implement multitier architectures, some developers use formal application partitioning products. These products include Dynasty Technologies's Dynasty, and Oracle's Developer/2000. But other developers want to continue using familiar programming tools such as Visual Basic (VB) and PowerBuilder.
One way to scale up with traditional two-tier programming languages is to build application servers and layer in remote procedure calls (RPCs). You can use tools such as Greenbrier & Russel's RPCpainter or NobleNet's EZ-RPC. RPCpainter lets you call RPCs from PowerBuilder, and EZ-RPC works with VB, SQLWindows, PowerBuilder, Delphi, C++, and other languages.
Microsoft sees Object Linking and Embedding (OLE) as an important tool for building applications from components. This approach inherently provides application partitioning and logic redistribution capabilities. OLE is based on the Component Object Model (COM), which uses RPCs to access local or remote objects.
The version of COM that supports remote objects is Distributed COM (DCOM), formerly Network OLE. DCOM was not available when Microsoft shipped VB 4.0, but the VB developers included support for Remote Automation Servers so that VB Enterprise Edition users can develop three-tier applications by means of remote OLE automation. The release of VB 4.0 means that developers can use VB and Visual C++ to develop OLE-automation servers that can service multiple clients, although servers developed with VB are single-threaded.
ODBC is a widely used programming interface with SQL databases. ODBC installs an infrastructure that includes a driver manager Dynamic Link Library (DLL), loadable database drivers, translation libraries, and other supporting files.
You typically configure an ODBC client machine for each database product that the client accesses. As a result, a given ODBC client sometimes has to run multiple protocol stacks and maintain separate configuration files for each database product that the client accesses. The consequence is a client-side application environment that can consume a significant amount of client resources and administrative overhead.
Software companies have recognized that administering ODBC in organizations with dozens, hundreds, or thousands of PCs is a problem in need of a solution. The term ODBC server describes a genre of products that simplifies ODBC administration by implementing a generic ODBC server to manage the interactions between the ODBC clients and the database servers. The ODBC server products let an organization create a thin client architecture by moving drivers, network libraries, client libraries, and protocol stacks off the client and onto the ODBC server. Figure 1 illustrates the classic fat ODBC client architecture. Figure 2 shows the thin ODBC server architecture.
ODBC servers produce a thin client by offloading components such as client libraries, network libraries, protocol stacks, and the ODBC Cursor Library. The resulting client has a single ODBC driver and network transport.
In future issues, Windows NT Magazine will look at ODBC servers that provide connectivity to multiple databases. Some ODBC servers are targeted at Web developers and use a multithreaded architecture to support multiple simultaneous users. Other ODBC servers emphasize the development of robust applications. These ODBC servers integrate with Distributed Computing Environment (DCE) or use RSA Data Security public key encryption to provide secure processing for the Internet and other applications that require security.
A Multiple Choice Question?
Both multitiered application architectures and ODBC servers streamline the overall operation of client/server database applications, but in different ways. Multitiered applications provide relief by distributing the application processing over a broad set of hardware resources, so you can easily scale multitiered applications. ODBC servers, in contrast, streamline the operation of database applications by adding a protective component (i.e., the ODBC server system) between the clients and servers.
The ODBC server reduces both the client and server resource requirements by managing the bulk of the end-to-end client/server communications. Best of all, you don't have to make a choice between these approaches. You can leverage both in the same environment if the need arises.
Dynasty Technologies * 708-769-8500 |
Greenbrier & Russel * 800-453-0347 or 708-706-4000
Microsoft * 206-882-8080
NobleNet * 508-460-8222
Oracle * 800-633-0596
RSA Data Security * 415-595-8782