Concepts

The BC4J-VSM is a multi-tier application that stores persistent data in a database. The following figure gives a high-level view of the architecture.

The BC4J framework provides two important objects for working with the database: entity objects and view objects.

• An entity object stores the business logic and column information for a database table (or view, synonym, or snapshot). Entity objects answer the question, "What objects are relevant to the business?" They are nouns in the problem domain. You can create entity objects from existing database tables (reverse generation) or define entity objects and use them to create database tables (forward generation).

• A view object uses a SQL query to specify filtered subsets of business data that can be related to attributes from entity objects. View objects answer the question, "What data is relevant to the task?" You can query a set of data exactly as you want to show it in the display. The view object defines the attributes of the view row class, which represents a row in the query result, and optionally refers to underlying entity objects.

View objects provide clients with row sets they can scroll through and update without concern for or knowledge of the underlying entity objects. Clients manipulate data by navigating through the result set, getting and setting attribute values; changes are made to the data in the underlying database when the transaction is committed. Relationships between view objects are expressed using view links. Each view object provides a default iterator that you can use to navigate through its result set. For example, the following figure shows the relationship between a view object, entity object, and the underlying database table. A view object named EmpNames operates on the Emp entity object to provide a view of the EMPNO and ENAME columns of the EMP table.

By eliminating the substantial coding and testing work related to common "application plumbing" facilities, BC4J lets application developers focus full-time on implementing business solutions. The benefits of using this framework include reduced development cost, lower project risk, and shorter time-to-market.

About Transactions

A transaction is an interface to manage database operations. All operations to modify data in a transaction must succeed before the server will accept the changes. These operations include methods that set attribute values, standard SQL calls (such as INSERT, UPDATE and DELETE), or more specialized RPC-like calls such as calling Java stored procedures or PL/SQL packages. A transaction is an atomic unit; the effects of the operations in a transaction can be either all committed (saved to the database) or all rolled back (undone).

For example, when a client using a banking service transfers money from a savings account to a checking account, the transaction consists of three separate operations: decrement the savings account, increment the checking account, and record the transaction in a transaction journal. If all three operations are performed to maintain the accounts in proper balance, the transaction is committed and the effects of the operations applied to the database. But, if something (such as insufficient funds, invalid account number, or a hardware failure) prevents any of the operations from completing, the entire transaction must be rolled back so that the balance of all accounts is correct.

Transactions also provide multi-user consistency to a shared store of data. When a client changes data, locks ensure that other clients don't make other changes until the first client is finished. When a transaction is committed or rolled back, the locks are released. This is a "pessimistic" locking mode, which the Business Components for Java framework assumes by default.

Application modules provide default transaction and concurrency support. No coding is required unless you want to customize the default behavior.