Ads 468x60px

Monday, July 25, 2011

Designing a Database Application in JAVA

Designing a Database Application

Knowing the JDBC API and coding cute applets is naturally just the start to database programming in Java. To harness the advantages of Java, application designers need to be able to address the design issues Java raises. The entire Java paradigm empowers developers to write database applications and applets using architectures that before were either very complex or simply not supported by other tools. Two such buzzwords that have been flying around the client/server world for a while are distributed objects and three-tier client/server.

Security Issues

Before going off the edge and into the deep end, Java does put some restrictions on applets for security reasons that can appear to be particularly limiting to the database developer. The following two particular applet restrictions affect database programmers:
  • Limited access to native libraries
  • Limited network access
The native call limitation affects programmers who need to use some sort of C- or operating system-level library to design an applet. This is especially troublesome to applet writers who take advantage of a database-specific feature not supported outside of native calls.
To veteran client/server developers, however, the most troubling idea is likely that your Web server must be on the same machine to which your applet connects for database access. Specifically, most Java virtual machines restrict applets from connecting to any machine except the host that served the applet. The applet cannot connect directly to any local or third-machine databases. As limiting as this particular restriction seems, a three-tier architecture provides a liberating solution.

Constructing a Three-tier Application

Two-tier applications tend to push a lot of processing onto the client machines. This architecture poses several problems:
  • Client-side resource requirements balloon with the extra processing needs. It is not uncommon to find business applications requiring Pentiums with 32M of RAM.
  • User interface and business processing tend to get rolled together, especially with the rapid application development tools on the market. With the user interface so closely tied to business processing, changes to one end up having a direct impact on the other, making maintenance a headache.
  • With all this redundant processing occurring on many client machines rather than in a central location, new applications are forced to reinvent the wheel when dealing with the same business processing.
With the guaranteed execution environment of the Java virtual machine and an easy-to-use Internet socket interface, Java is actually well suited to implementing three-tier systems. A three-tier application is one in which a third application layer exists between the client and server layers of traditional two-tier client/server development. This middle layer has a wide variety of uses depending on the application.
In the three-tier architecture, the middle layer separates business processing from the visual representation of data. This layer, called the application server, is responsible for knowing how to find and manipulate business data. The client evolves into a much leaner application, responsible only for retrieving information from the application server and displaying it on the screen.
In addition to removing a huge processing burden from client machines, this application server can be used to consolidate enterprise-wide business rules.
Where business rules had to be rewritten for each two-tier application thrust on the desktop, application servers process business rules in a single place for multiple applications to use. When the business rules change, a change to the application server takes care of that change for all the applications being run by the business.
Of specific interest to Java developers is the ability to hide any knowledge of the database server from the client. Because Internet clients view the applet or application as interfacing with a single application server, you can use that application server to determine such issues as where the data really exists. Additionally, this back-end independence enables applications to scale much easier across CPUs. Figure 15.4 shows a three-tier architecture.

A Three-tier Bug Tracking System

The application server forms the core of a three-tier architecture. In it, the business rules are defined and processed. Implementing the counter using a three-tier architecture would naturally be overkill. Instead, the ideal application for a three-tier design is one in which some manipulation of data occurs or where the data can be viewed in multiple fashions (or even better, by multiple applications). The first step in building an application server would thus be to identify the data processing needs of the application.

Implementing a Three-tier Application with Java

Figure 15.5 shows a bug tracking application implemented as a three-tier Java application.

The only processing done on the client is the painting of GUI widgets and user data entry. On the other end, the database server runs on a machine otherwise inaccessible to the client applet. The application server bridges this gap by finding desired data, mapping it from its relational state into objects, and performing operations on those objects.
With any three-tier architecture, the greatest programming challenge is getting the three layers to communicate with one another. JDBC or some similar set of database access classes should handle the application server-to-database server communication in a manner transparent to the application developer. The client-to-application server solution is still left wanting.
The two best methods for providing such communication in Java are Java sockets or distributed objects.
Compared to sockets from other languages, Java sockets are quite simple to use. Sockets, however, force the developer to make esoteric decisions about exactly what is being communicated between client and application server because method calls and object passing are better handled by the distributed objects solution. A socket solution generally best fits an application when the scope of communication is limited and well-defined. The bug tracking system would be best implemented in this manner.
Distributed objects provide the more elegant solution. From the developer's point of view, the application server objects appear to be part of the same application as the client, just residing on a central server and available to other applications simultaneously. The developer handles communication simply through method calls.


Although the original Java release did not address the issue of database access, the JDBC specification attempts to address this issue by defining a set of interfaces that can give applications access to data independent of the DBMS being used to store that data. Though this back-end independence can be very liberating, it is important to balance it with the advantages of the DBMS being used.
Many books cover only the subjects of database application design and programming. This chapter does not attempt to delve into those matters; instead, it focuses on the application of Java to database programming.
Programmers interested in using Java to write database applications should become familiar with the general subject matter.
In spite of the vastness of the subject matter, this chapter should whet your appetite for database programming and prepare you at least enough to write simple applets and applications. Much of the Java experience you already have translates into many of the issues specific to Java database programming. For example, applets written to use a database must work around the strict security limitations of Java virtual machines. Using the basics of a three-tier architecture can help an applet get around this limitation while giving it greater functionality. It is, however, important not to overdesign a simple applet just for the sake of doing a three-tier design.


Post a Comment