The rise of client-server applications allowed application designers to improve usability and decrease training costs by providing applications with graphical user interfaces on platforms such as Windows and OS/2. At the same time, it allowed the flexibility of delegating database management function to robust database servers on a variety of operating systems and hardware platforms.
The client-server model, where application logic is distributed to client workstations, is commonly referred to as 2-tier client server. In the 2-tier model, the application is deployed on the client tier and database server implements the server or the back-end tier. As seen in Direct Database Access, DB2 Connect provides complete support for 2-tier client-server applications, where database servers are DB2 for OS/390, DB2 for MVS/ESA, DB2/400, or DB2 for VM and VSE.
With the increase in the size of the client-server applications, it became apparent that the 2-tier client-server model had significant limitations. Distributing large amounts of business logic to hundreds or even thousands of client workstations made change management a complex and costly undertaking. Any change in business rules required replacement of the client portion of the application. Often these application rollouts had to be on all client workstations in the enterprise at the same time to ensure that business rules are being applied consistently.
Another shortcoming of the 2-tier client-server model became apparent with scale is the amount of resources that are consumed by such applications. Deploying hundreds or thousands of fat clients, as 2-tier clients are often called, increased demands on processing power and capacity of each client workstation. Moreover, the demands on the database server are also greatly increased as each client required a dedicated database connection and the resources associated with maintaining such a connection. While the 2-tier client-server dependency of distributing business logic can be somewhat reduced by extensive use of stored procedures, the other shortcomings are not easily addressed without changes to the model.
As the cost and complexity of 2-tier client-server applications escalated, most of the largest applications embarked on the path to multi-tier client-server. Under the multi-tier model, the role of the database tier remains unchanged. However, the client tier is supplemented by a one or more middle tiers; typically one, therefore the name 3-tier.
In the 3-tier model, the client is relegated to handling user interactions and does not contain any business logic. The middle-tier is comprised of one or more application servers. The goal of the application server is to provide robust, cost-efficient implementation of the logic behind the business processes and business rules. As with the 2-tier model, the business rules implementation is often supplemented by using stored procedures to improve performance.
Because client workstations no longer implement the bulk of the application logic and are only handling user interactions, the resource requirements for the client tier are greatly reduced. As a matter of fact, the client tier in the 3-tier model is often called thin client. In addition, because a centralized application server is handling requests from all of the clients, it has the ability to share resources, such as database connections between all of the clients. As a result, the database server no longer has to maintain dedicated connections for each application user.
Many examples of 3-tier applications servers exist in the industry today. Almost all Enterprise Resource Planning (ERP) vendors implement their applications using the 3-tier model, such as SAP R/3 and PeopleSoft V7 applications. Other examples include leading Enterprise Relationship Management vendors, such as Siebel and Vantive.
DB2 Connect Enterprise Edition servers provide comprehensive support for deploying multi-tier applications. The support provided by DB2 Connect includes a variety of APIs that can be used to develop application logic (ODBC, ADO, DB2 CLI, Embedded SQL, JDBC, and SQLJ), as well as a complete communication infrastructure for interacting with DB2 Family database servers.
DB2 Connect also supports implementations in which a database tier is comprised of multiple DB2 Family database servers. This allows application servers to implement transactions that update data residing on multiple database servers in a single transaction.
The integrity of such distributed transactions is assured by the 2-phase commit protocol support provided by DB2 Connect. For example, an application can update data in a DB2 for OS/390 database and DB2 UDB on Windows NT in the same transaction. If distributed request support is installed and enabled, the application can read an Oracle database and update a DB2 family database in the same transaction.
In the following diagram, the APIs as well as the connectivity mechanism between the application server and the back-end database servers is provided by DB2 Connect Enterprise Edition.
Advanced features of DB2 Connect, such as connection pooling (see Connection Pooling) and connection concentrator (see DB2 Connect Connection Concentrator), greatly reduce application resource requirements and simplify application server implementation.
DB2 Connect Enterprise Edition product (available on its own or as part of the DB2 Connect Unlimited Edition product package) is required for use with application servers. DB2 Connect Personal Edition is not supported and is not licensed for use with application servers. In addition, customers implementing application servers should review terms and conditions provided with their copy of DB2 Connect to understand the number of user licenses that need to be acquired.
There are two deployment methods for DB2 Connect in the application server environment. DB2 Connect Enterprise Edition installed on:
In most situations, installing a copy of DB2 Connect on the same server as the application server itself is the preferred solution. Installing DB2 Connect on the application server allows it to participate in any fail-over and load-balancing scheme that an application server may be implementing. This setup can potentially provide better performance since it eliminates an additional network hop that is required when DB2 Connect is installed on a separate server. Furthermore, the administration can be simplified since there is no need for an installing and maintaining an additional server.
Installing DB2 Connect on a separate server is a good option in situations where DB2 Connect Enterprise Edition is not available for the operating system or hardware platform where application server is running. For example, if the application server is deployed on a Silicone Graphics (SGI) or SCO UnixWare server, deploying DB2 Connect on a separate server is the only option as DB2 Connect Enterprise Edition is not available on these platforms.