Database Aspects in J2EE

Webtop computing really emerged when Web browsers became universally available on the desktops at the office, at home, or on the road and when technologies to serve dynamic pages matured enough to serve the needs of professional applications. Webtop computing is what makes e-business really work. It enables secured access to corporate resources such as application suites, enterprise databases, and documents from any authorized Web browser from anywhere. It serves a large audience that may be composed of employees, partners, suppliers, customers, distributors, and resellers — who all want everything but fat legacy applications on their desktops.

Webtop computing enables Application Service Providers (ASPs) to leverage the same infrastructure to serve applications to a wider audience than a single user group in a given company. This drastically reduces platform and application investments as well as the management of platforms and applications. One of the main advantages of the Webtop approach is the ease of support of various client platforms and distribution of new releases of the applications without affecting those clients.

Webtop computing was really made possible thanks to Java 2 Enterprise Edition (J2EE). J2EE is a set of APIs from Sun Microsystems that forms a robust framework for N-tiered applications. The best proof of its worldwide adoption is the number of high-end vendors who offer J2EE-compliant application servers as core products along with their ordinary line of software. Most database vendors have developed application servers; nearly all middleware vendors have done so, too. J2EE is becoming mainstream.

J2EE defines the logical tiers for N-tiered applications by providing rich APIs and container services that distributed component-holding presentation logic or business logic can use. Several specific services are especially interesting for anyone having to integrate with databases because they take care of certain technical aspects that developers often forget or have no time to implement themselves; those services are the following:

• Connection pooling

• Distributed transaction management (or transaction coordination)

• Transparent persistence for objects that represent business data

Connection pooling is quite useful in an environment in which many components deal with their own logic and database objects. Connection pooling is of extreme importance to provide concurrency and scalability to three-tier applications. J2EE application servers that provide this sort of pooling hide all the complexity of maintaining connections to back ends such as databases and allowing transactions to go one way or the other.

Connection pooling is simple from a component developer perspective: Application servers are typically able to maintain pools of connections to databases and allow components to access those connections when necessary. The advantage is that referring to a connection pool while programming enables developers to forget about accessing specific databases when they implement components, at least for the connection establishment aspects, because they can simply refer to connection pools known only at deployment time by providing some sort of naming in deployment descriptors. Database connections will be provided to those components at deployment time. The application server will make sure that the connections are used in an optimal manner by making the pool grow or shrink, depending on the demand for new connections.

Distributed transaction management provides ACID properties to groups of operations made on tables residing on several databases. ACID stands for Atomicity, Consistency, Isolation, Durability and is normally provided by the database engines themselves for local transactions. A commit/rollback mechanism is used to ensure those properties. However, when dealing with several databases, something called a two-phase commit is necessary. A two-phase commit isn’t provided by JDBC drivers and database engines; it is a feature of transaction managers. Transactions that span on multiple databases either succeed on each database or fail on each database: This ensures the consistency of data updates in distributed systems.

The third aspect is transparent persistence for objects. J2EE defines what is called bean-managed persistence requires developers to program those operations with JDBC.