ClientServer Concepts

Client/Server Concepts

The first generation of client/server architectures that use a database is called two-tiered. This type of architecture contains two active components: the client, which requests data, and the server, which delivers data. Basically, the application’s processing is done separately for database queries and updates and for business logic processing and user interface presentation. Usually the network binds the back end to the front end, although both tiers can be present on the same hardware. For example, hundreds or thousands of airline seat reservation applications can connect to a central DBMS to request, insert, or modify data. While the clients process the graphics and data entry validation, the DBMS does all the data processing.

In traditional client/server applications, the clients establish connections with the server, and these connections are kept open until the clients terminate. The communication protocols are often proprietary: Examples are SQL-NET for Oracle and TDS for Sybase. Both clients and servers use database-specific libraries to communicate with each other. Security is entirely managed by the database engine. Logins are controlled by the database, such as user roles and permissions on database objects. The typical client/server architecture is shown in Figure 2-1.

click to expand
Figure 2-1: The typical client/server architecture with a DBMS.

If users connect from several remote sites, network latency may affect the application’s response time in a noticeable manner. One possible solution is to replicate the database(s). The synchronization of data between replications is typically performed by the database engines themselves: It isn’t a concern of the client applications. Another possible solution to the poor response time problem is the paging of data.

A feature called database cursors may be used in this case. This approach obviously affects application code, especially on the client side.

Sometimes the application logic (the real business logic) is located in both the client program and in the database itself. Quite often, the business logic is merged into pesentation logic on the client side. As a result, code maintenance and reusability aren’t easily achieved, at least for what resides on the client side. On the database side, logic is often developed using stored procedures (a technique that allows developers to write procedures in a proprietary language and to deploy them in the database itself). To date, some vendors support Java as language to develop stored procedures. However, doing so isn’t recommended, because access to database objects remains somewhat proprietary even when the procedure’s language is Java. Reusability is hard to achieve if pieces of business logic must be distributed across systems and several databases are involved.

Figure 2-2 illustrates the two-tier architecture.

click to expand
Figure 2-2: The two-tier architecture.

Although the two-tiered architecture is common, another type of architecture is being used more and more often as a pattern to build distributed systems. To avoid embedding the application’s logic at both the database side and the client side, a third software tier is inserted. In three-tiered architectures, most of the business logic is located in the middle tier. In this architecture, when the business activity or business rules change, only the middle tier must be modified. Figure 2-3 illustrates the three-tier architecture.

click to expand
Figure 2-3: The three-tier architecture.



JDBC 3. 0. JAVA Database Connectivity
JDBC 3: Java Database Connectivity
ISBN: 0764548751
EAN: 2147483647
Year: 2002
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net