User's Manual

98 Chapter 9. Persistence Tutorial
In addition, there are numerous examples that one could concoct where an EJB server (at least
initially) could be deemed to be an overkill given the problem being tackled. This is the sledge-
hammer-to-crack-a-nut problem. In essence, the J2EE specification does not mandate a 2, 3,
or multitier application model, nor realistically could it do so. The point is that it is important
to use appropriate tools for a given problem space.
Given that the most common usage for WAF deployment is, to use Sun’s term, the "Web-
centric application scenario", Red Hat opted for the "3-tier Web-centric" architecture, in which
"[t]he Web container is essentially hosting both presentation and business logic, and it is as-
sumed that JDBC (and connectors in the future) will be used to access the EIS resources."
Coarse-grained interoperation of WAF with other systems would certainly be a sound applica-
tion of EJB or JMS. However, Red Hat does not currently have clear requirements in this area.
More activity is anticipated in this area during future WAF implementations, initiated both by
Red Hat and by others building on top of WAF.
(As an aside, commercial J2EE containers such as WebLogic and Oracle’s 9i typically make
it a goal to provide a "simple mechanism for balancing load across several machines without
too much thinking," even when you are only using the Servlet API, as opposed to EJBs.)
Regarding the other reasons for using EJBs outside of distributed objects, the following points
should clarify the extent to which Red Hat is "reinventing the wheel":
1. Persistence: There are two standard types of persistence: Bean-Managed Persistence
(BMP) and Container-Managed Persistnce (CMP). BMP does not provide much advan-
tage, and CMP, unfortunately, does not provide automatic SQL generation. In short, the
WAF persistence layer is designed to address a different set of requirements than CMP.
2. Connection pooling: Red Hat is not reinventing connection pooling; rather, its code is
writtten against the J2EE-standard API for connection pooling, the JDBC 2.0 Optional
Package at http://java.sun.com/products/jdbc/articles/package2.html.
3. Transaction monitoring: EJB’s declarative-style transaction management is one of its
more attractive features, but not compelling enough for Red Hat to make it the deciding
factor in using EJBs. Red Hat does not "reinvent" transaction management, either; it
simply leaves the applications responsible for managing transactions.
Red Hat has found, through input from prospective customers, partners, and analysts, that the
market perspective on the necessity and appeal of the "full J2EE architecture" is not clear-cut.
Being able to run WAF atop a J2EE web container alone has benefits of its own: simplicity of
development and deployment, low run-time overhead, and broad availability of stable open-
source/affordable implementations. In other words, 3-tier Web-centric is quite defensibly the
appropriate tool for Red Hat’s primary problem space.
1.3. What are the primary benefits/goals of the persistence API?
The persistence API provides the following benefits:
• It provides an abstraction for physical data models for greater database independence.
• It isolates the java classes from data model changes (e.g., if a column is renamed, no Java
code must be changed).
• It provides support for user-defined object types.
• It decreases the amount of time it takes to implement a new object type.
• It can automatically generate SQL statements that can be run on different databases. Thus,
it is possible to write one PDL file that can be used on N databases. Without persistence,
a developer may be required to write N different DDL scripts and then N different sets of
SQL statements to use the tables.