Chapter 4: JDBC s Role in Java 2 Enterprise Edition

This chapter discusses the role of JDBC in Java 2 Enterprise Edition (J2EE). J2EE is a set of APIs used to develop distributed applications in a reusable component fashion. This chapter explains the relationship between these components and how JDBC is used in conjunction with Enterprise JavaBeans (EJBs).

J2EE’s Layered Architecture

Before covering the world of programming with JDBC, I briefly discuss in this chapter design practices common when developing distributed applications for intranets, extranets, or the Internet. J2EE addresses these practices by providing a rich API and framework that is well suited for building and maintaining solutions that target a Web browser-based audience.

One of the motivations for the use of J2EE is the need for reducing development and maintenance time for individual pieces of code that represent data entities or a part of the application logic. Another key reason for the use of J2EE is the importance of letting developers focus on their core task: the implementation of the business logic. J2EE allows commonly available software modules to take care of most, if not all, horizontal services such as database connection pooling, transactions, access to database objects as objects, security and access control, support for Web markup languages, and transport protocols.

To understand what distributed component computing is, you need to know the basic parts frequently found in a software application, which are the following:

• A graphical user interface (GUI) to interact with the user, validate data entry or selection, receive commands, and display results.

• Data that must be processed in some way to achieve certain results.

• Data access logic and data management.

• Business logic that consists of operations or functions of the program.

This is a simplistic view of what is used within a computer program. In the case of fat clients, all four of these functions are merged in the client code.

When you are designing an application that needs to be available, say, on both an intranet with fixed seat users and an extranet for mobile workers, it is important to consider particular aspects such as client platform capabilities, manageability, and total control over these platforms, network bandwidth, and so on. Using pure HTML interfaces solves many distribution, manageability, and even network issues; therefore, I’ll assume that the application in this example conforms to this characteristic. There won’t be any database, GUI code, or even application logic code on the client. In addition, I’ll assume that the application must be open enough to enable future users to access and process the data using non-HTML devices such as Wireless Application Protocol (WAP) phones. Such phones support a markup language known as Wireless Markup Language (WML). As a last requirement, I want total freedom of choice for the relational database brand and dedication to the application being designed. Finally, the application will provide open interfaces to let other programs access parts of its functionalities.

All these requirements lead to so many constraints that you can no longer design and develop a single and monolithic fat client application that is heavily linked to a particular database. This is where J2EE comes in. By splitting the application in tiers and functionalities in components, J2EE enables developers to address all these constraints at the same time. Because I am discussing database access with JDBC in particular, I show in this section that JDBC is in fact no longer used everywhere, as would have been the case with monolithic applications.

The layers that I am focusing on are the following:

• The client tier

• The presentation tier

• The application logic tier

• The integration tier

• The resource tier

The client tier

The client tier is the platform that provides the users with the graphical elements necessary to access the application data and functionalities. An example is a Web browser. Another example is a wireless phone WAP browser. J2EE supports markup language browsers without restrictions. There is obviously no need for a database and local database access on the client tier itself.

The only software part needed on the client tier is an HTML or WML browser. No database or drivers are needed.

The presentation tier

The presentation tier focuses only on generating appropriate user interface elements for the clients. For example, the presentation tier may generate HTML for Web browsers and WML for WAP phones. Servlets and Java Server Pages (JSPs) are both J2EE APIs used in presentation tiers. They can produce HTML, for example, in a dynamic way, but won’t typically hold any of the application logic (the core processing of the application) because doing so would inevitably cause code overlap. If the case would arise where WML must be provided in a dynamic way, too, in addition to the already-existing generation of HTML, the same SQL queries would have to be placed in the code for the generation of WML as for the generation of HTML.

Therefore, the presentation tier uses only the following:

• Servlets

• Java Server Pages

No database or drivers are needed.

The application logic tier

The application logic tier includes the core logic of the application. This logic is common to the different channels used to access the application: Servlets and Java Server Pages components leverage this logic when necessary. The J2EE standard for implementing business logic is Enterprise JavaBeans (EJBs). EJBs are distributed components that use the Remote Method Invocation (RMI) of Java to call themselves or to be called from servlets and JSPs, for example. Because the application logic usually processes data, it needs to access this data in some way. In fact, the data itself can also be represented as business components by using EJBs called entity beans. Business logic itself is implemented using session beans and normally accesses data only through entity beans. Note that there are two ways of integrating databases with entity beans: One involves development with JDBC to map entity beans to rows in database tables, and the other provides an automatic mapping to the database tables. In the latter case, there is no need to write JDBC code because it is generated by the J2EE container that runs the EJBs.

So, on the application logic tier, only the following components are needed:

• Session beans for the data-processing logic.

• Entity beans to represent data.

• Custom or generated JDBC code to map entity beans to the database.

No database and drivers are needed.

The integration tier

The integration tier typically consists of J2EE connectors to legacy systems. Such connectors may use the Java Messaging Service (JMS) to access mainframes via a Message Oriented Middleware (MOM), for example, or anything else needed to communicate with external systems managing either data or legacy business logic or both. In fact, you may think that the integration tier is a good place to set up, deploy, and run pools of JDBC connections to databases, and indeed, it is a good place for this purpose. Pools of JDBC connections, when deployed in a J2EE environment, are registered in a Java Naming and Directory Interface (JNDI) sort of name space. J2EE containers enable system managers to monitor the pools and set their characteristics, such as minimum and maximum size, auto-increment, and shrinking of connections, without affecting the Java code of all other components.

For simplicity, I’ll assume that the integration tier consists of the following:

• JDBC connection pools

• JDBC drivers used by the pools

Still no database needed! More complex environments necessitate a transaction manager, also called a transaction coordinator. Others may require message-oriented middleware to communicate with other systems.

The resource tier

Finally, the resource tier takes care of data stores such as databases. The resource tier isn’t exactly a J2EE component because there is no particular API for it. It merely represents any data source used by the integration tier.

Therefore, the resource tier may be composed of the following:

• Relational databases

• Hierarchical databases

• Back-end systems, mainframe applications, and so on