Checkpoint
Where We've Been
After the requirements have been solidified and the design work has begun, three architectures must be considered. The final architecture selected for the application is called the execution architecture.
To provide a technology-expansive set of choices, Remulak will present some solution aspects using servlets, JavaBeans, and JavaServer Pages. Other solution aspects will use servlets, Enterprise JavaBeans, and JavaServer Pages. In the first case, the open-source Tomcat server will be used. In the second, BEA's WebLogic application server will be used.
Many mechanisms are available for communicating between the layers of the application. All have strengths and weaknesses. The one with the most appeal for Remulak Productions will be to use RMI and to pass objects and attributes between the layers.
Transaction management is the ability of the application to ensure that changes are either committed to the database if all goes as planned, or rolled back and discarded otherwise. Both native JDBC transaction management services and an implementation with Enterprise JavaBeans (EJB) will be used.
Where We're Going Next
In the next chapter we:
Explore the issues regarding the transition from the logical perspective offered by the design view of the class diagram to the physical persistence layer (which assumes the existence of a relational database).
Review the issues concerning the use of a visual modeling tool such as Rational Rose to generate a Data Definition Language (DDL) from the class diagram.
Discuss how to translate inheritance and aggregation/composition modeled on the class diagram to a table structure.
Review how native JDBC data access and both container-managed persistence (CMP) and bean managed-persistence (BMP) within the Enterprise JavaBeans (EJB) application provide basic SQL support for Remulak.
Explore how to keep the class diagram and tables in sync.
Review the strengths and weaknesses of implementing the query access as stored procedures and triggers.