The Right Tool at the Right Time

The Java programming language got to where it is today not simply by being in the right place at the right time, but by being the right tool in the right place at the right time.

There's been a lot of research into object-oriented design since the 1960s, and there are now quite a few object-oriented languages, but before Java, no purely object-oriented language had come into widespread use for general-purpose programming. Undeniably, C++ has achieved great popularity, but because it is a hybrid language, it is all too easy to lapse into non-object-oriented ways and to abuse the features it has inherited from C. Java, for many people, has turned out to be a better C++. Java is C++ stripped of the unsafe features that can lead to programming errors. After all, consumer gadgets, such as VCRs and toasters, should not crash and require rebooting.

Java enforces object-oriented programming because it was designed from the beginning as an object-oriented language. Though this is not a book about object-oriented design or programming, the fact that Java is so thoroughly object-oriented means that our approach must, by necessity, be object-oriented, as well. It will especially affect the way we approach using a database. In the end, to use Java effectively, we need to be true to its object-oriented nature.

Networking is Fundamental

The key to the growth of the Internet and the Web is networking. In the famous formula immortalized as Metcalf's Law, Robert Metcalf, inventor of Ethernet and founder of 3Com, observed that a network increases in proportion to the square of the number of participants. (Actually, the formula is n² n, which approaches n² for large numbers.) This is because, as the number of participants increases, the number of possible links and interactions between them increases geometrically. Synergy is obtained as more people work together and interact with each other.

Tapping this new market/community/cyberspace and harnessing that synergistic energy is an exciting challenge. Java and databases are fundamental building blocks for building network-based applications that meet this challenge.

Networks and Applications

Despite the hype, not all network applications are Web applications. There are two principal types of applications designed to run on a network: client-server and multitier (or n-tier) applications.

Client-server applications are the most traditional type. Typically, client-server applications involve a database on the server and an application running on the users' computers, where most of the processing takes place (Figure 1-1). The main drawback of this architecture is maintainability. When a new version of the application is introduced, it must be distributed to many users at the same time, lest incompatibilities between versions cause problems. Another drawback is that the client machine must typically be fairly powerful, because most of the processing takes place on the client machine.

Figure 1-1. Client-server architecture.

Multitier applications introduce an intermediate layer, called middleware, which, like the database, runs on a server possibly, but not necessarily, the same server as the database. In a multitier application, much of the processing that ran on each user's machine is moved into this middleware layer and is shared by all users. The user's machine is typically responsible only for presenting the information to the user and allowing the user to interact with the display and provide input (Figure 1-2).

Figure 1-2. Multitier architecture.

Organizations of all sizes use distributed applications, and these applications can be built using either the client-server or the multitier model. Some examples of these applications include:

• Library reference database

• Enterprise resource planning (ERP) systems

• Customer Relationship Management (CRM) systems

• Procurement systems

• Document storage

A Web application is a specific variety of multitier application. Where a more traditional architecture would use a stand-alone application on the client machine, a Web application generates HTML documents and interacts with a Web browser on the client, using the HTTP protocol.

Some examples of the types of Web sites using this architecture include:

• Information, news sites

• Catalog sales

• Entertainment, gaming

• Brokerages, auctions

All of these distributed applications have one important thing in common: Except for possibly games, they all exist primarily to move and process information. This information must be reliably stored and retrieved it must be persistent.

The Value of Persistence

Virtually all applications, not just network applications, need some degree of persistence. The importance of persistence is easy to overlook at first. Imagine a student writing a research paper, using a PC to format and print it. Imagine that the PC was unable, for some reason, to save the file to disk. The student would probably be wise to (at least) print out the paper once in while, in case the electricity is shut off. Paper isn't usually the best way to store information that is in a digital format but it's better than not storing the information at all.

Similarly, when a user places an order from an online catalog or a writer submits a story to a Web magazine, this information needs to be stored somehow. The easiest way may be to keep these records in memory, but as was the case with the poor student, this isn't very safe, because a system crash or a power outage would permanently erase them. It would be better to write them out to a file or a set of files in the operating system.

Consider a Web magazine. It may be sufficient simply to create a file for each article. Perhaps there is a single editor or a webmaster responsible for putting the article in the right place in the Web server's file system and updating the appropriate Web pages to link in the new story.

Other types of Web sites have more complex needs. They need to keep track of such things as user names, passwords, preferences, and orders. Writing these bits of information out to files and managing them quickly becomes a major development task. The issues involved are far from trivial.

Database management system vendors have already solved the issues that arise from managing lots of information for lots of users: such things as allowing concurrent access, combining information from different sets of data on a record-by-record basis, providing different levels of access according to user, and treating a set of changes as a single transaction to ensure integrity of the data.

If a distributed application requires more than trivial persistence, a database system is almost always the best solution.