JDBCs Relationship to Enterprise JavaBeans

JDBC’s Relationship to Enterprise JavaBeans

For a J2EE developer, the most relevant application layer to program with JDBC is within Enterprise JavaBeans. Indeed, because EJBs either act on data directly or represent data in an object-oriented way, database access, querying, updating, deleting, and inserting happen at this layer.

To better understand this section, consider the simple case of a piece of code that implements a money transfer within a bank. The functionality is limited to transferring an amount of money from account A to account B, with the simple constraint that, if either debiting account A or crediting account B fails, the whole operation fails, and both accounts remain unchanged. This means that both operations must be performed within a single transaction that must either commit or roll back.

In a traditional world, this may have been implemented as a single database stored procedure. A client program simply calls the stored procedure with the amount and account A and account B parameters and waits until the operation is completed.

Using J2EE in a simple way, consider that there are three components: Account A, Account B, and a Transfer facility. Accounts A and B are business data components; Transfer is a business logic component.

Business logic components

The Transfer facility doesn’t represent data, yet it must access data. I’ll call this component TransferService. Because TransferService doesn’t represent data, this component is a session bean and not an entity bean. The only business method that it provides is transfer(int fromAccountNumber, int toAccountNumber, float amount).

It is the TransferService component’s job to find Accounts A and B and perform the transfer operation by debiting A and crediting B within the scope of a transaction. Transactions can be entirely managed by the J2EE container, so there is no need to define anything particular to handle commits and rollbacks in the code.

Business data components

Accounts A and B are entity beans and may be looked up using a specific EJB API method; because all accounts represent real data, they don’t reside in memory in a permanent way. Looking up entity beans causes some SQL code to be executed to retrieve the data present in the database and build the entity’s instance in memory.

Both beans have the same interface — that is, they offer simple, bean-related methods such as debit(float amount) and credit(float amount). J2EE defines two methods to provide database mapping code for entity beans: container-managed persistence and bean-managed persistence. Container-managed persistence enables the developer of the bean to concentrate on the bean attributes and forces the J2EE container to provide the mechanisms to map the bean with a row in a database table, whereas bean-managed persistence forces the developer to write the entire code needed to mirror the bean’s attribute in a database.

XREF 

For more information about container-managed persistence and bean-managed persistence, see

In some way, both credit(float amount) and debit(float amount) cause SQL to be executed to update the account balance values in the database tables.

In the J2EE framework, there is no SQL code writing involved outside the entity beans; there is even the possibility to not write any SQL at all by using container-managed persistence.