Brought to you by EarthWeb
ITKnowledge Logo Login Graphic Click Here!
Click Here!
ITKnowledge
Search this book:
 
Search the site:
 
EXPERT SEARCH ----- nav

EarthWeb Direct

EarthWeb Direct

EarthWeb sites: other sites

Previous Table of Contents Next


Chapter 8
The Three-Tier Approach for Using Distributed Objects

In This Chapter

This chapter discusses an alternative to the two-tier model. The Java Remote Method Invocation allows distribution of objects across software tiers while providing an ideal place for the application logic. The areas discussed in this chapter include:

  An introduction to software partitioning
  Object persistency
  Java Remote Method Invocation
  CORBA

The first chapters of this book mentioned the next wave of client-server architectures. This wave presents a philosophy with a great impact on software design. Indeed, it changes the commonly accepted rules of implementing data access and processing both at the client and the database sides. The following paragraphs discuss these issues, but try to keep things simple while providing possible solutions in Java.

Recall the basics of traditional client-server architecture involving a relational database. As Figure 8-1 shows, Java Database Connectivity (JDBC) is located on the client side. Most of the code that accesses and processes data uses JDBC intensively and is also located on the client side. The code embeds the application logic— for example, Structured Query Language (SQL) queries, information on data type conversions, and information on data structures. There is, however, a part of the code located on the database side. Indeed, stored procedures also hold information on data or contain SQL expressions to be executed by the database engine.


Figure 8-1:  Two-tier architecture with JDBC on the client side.

It is very difficult to modify the code on both sides as often as the rules change. All clients that connect to the database must be modified to reflect the new rules. Programmers know that it is annoying to maintain different pieces of software that basically access the same data. The code of one program may barely import into another program even when developed with the same programming language and tools. Approaches such as standard in-house developed libraries address the problem but too often, do not totally solve it.

The idea of three-tier architecture involves moving most of the code that accesses and processes data into a third tier. This tier basically holds all of the business logic necessary to run the clients, if not the business itself.

How does it work? Let’s begin with the easiest part: Almost nothing changes on the database side. It still maintains data and holds the most important stored procedures or those that consume the most CPU cycles. It keeps its role of providing concurrent accesses, integrity, recovery, and ease of data administration.

Clients no longer hold any bytecode that accesses data using SQL. They will never see rows of data. They will never map these rows of data to local variables or object data members. Because the clients are written in Java and there are only objects in Java, the clients will keep manipulating data as Java objects and will eventually call the appropriate methods on these objects.

The remaining part is the most sensitive one: the third tier. This tier is a client of the database and, in a sense, a server for the client applications. This tier holds the code to access data and SQL queries, using JDBC to perform its operations. This is where rows of data are mapped into Java objects. For example, a query returning a list of employees would return a set of Java objects called employee, and a method called raiseSalary could be invoked on individual employee objects or a set of objects.

The client application uses employee objects and knows the raiseSalary method but they are not implemented within its code. Shared objects are called proxy objects on the client side. They are implemented in the middleware and whenever a client invokes the raiseSalary method, the raiseSalary method is triggered within the middleware, executing an SQL update that will update the employee’s salary in the database. The object implementation is called the nonvisible object — the implementation is not visible from the clients.

Figure 8-2 clearly illustrates the architecture. JDBC is located within the middleware.


Figure 8-2:  The three-tier architecture with JDBC in the middleware.

Let’s discuss the software bus that ties proxy objects and nonvisible objects (NVOs) together. Actually, a big part of the real implementation of three-tier architectures is dependent on this software bus. There are numerous possibilities but the most common in Java are RMI and CORBA. RMI stands for Remote Method Invocation while CORBA stands for Common Object Request Broker Architecture. These concepts are described later.

The rows of data must be mapped into Java object data members within the middleware. This hard work is necessary because of the impedance mismatch between all object-oriented programming languages and SQL. By definition, the data that is stored in database tables is persistent. All first-generation client-server clients were used to access persistent data in tabular format through SQL, but now we want them only to manipulate objects.

Object Persistency

Usual Java objects or class instances are transient, unless they are serialized to a file. This simply means that they do not persist outside of the application that instantiated them. Values fill data members at run time, and these data members are garbage-collected and cleared when no longer used. Exiting the program destroys the objects.

If you use a proper object-oriented programming language such as Java, you may think that there should be a way to avoid constructing essential objects each time you need them. Indeed, why should you need to perform the same operations to build objects each time the program executes? There must be some way to avoid this rebuilding.

Object persistency is the solution. It allows you to keep objects data members alive, even when the application is not running. There are many ways to make objects persistent (to persistify objects), and database management systems seem well suited for this purpose. They offer many data-oriented services, plus a common query language. While SQL is used within the scope of relational databases, an object query language (OQL) queries objects stored within object database management systems (DBMS).

The most common DBMS is relational, not object-oriented; but it does not matter. It is easy to write methods to perform the most basic tasks related to persistency. Here are a few of them:

  Creation of a new object
  Deletion
  Update
  Query that returns one object or a set of objects
  Duplication of objects (object cloning)

There is no need to define a custom query language to perform lookups on persistified objects; a single querySQLWhere() method whose arguments are vectors of data member names and values is a good start.


Previous Table of Contents Next
HomeAbout UsSearchSubscribeAdvertising InfoContact UsFAQs
Use of this site is subject to certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.