Chapter 13. Developing Full-Scale Java EE Applications


  • Entity Beans

  • Creating Entity Beans with the Top-Down Approach

  • Creating Entity Beans with the Bottom-Up Approach

  • Assembling Enterprise Applications

  • Importing Existing Enterprise Applications

  • Consuming Java Enterprise Resources

  • Java EE Platform and Security Management

  • Understanding the Java EE Application Server Runtime Environment

  • Ensuring Java EE Compliance

  • Refactoring Enterprise Beans

  • Database Support and Derby Integration

THE PREVIOUS TWO CHAPTERS PROVIDED SOME STRATEGIES for extending web applications with Java enterprise-tier technology. This chapter continues the path of those chapters and handles topics such as entity beans, consuming resources, assembling applications from multiple code modules, and verifying the J2EE 1.4 compliance of enterprise applications.

Entity Beans

Beginning with the Enterprise JavaBeans 1.1 specification, entity beans have been a required part of the Java EE platform. Entity beans provide a Java idiom (method invocation) for accessing relational functionality in addition to the container benefits provided in the J2EE 1.4 specification, such as transaction support and security. An entity bean allows persistence to be handled by the container (container-managed persistence, or CMP) or by the developer (bean-managed persistence, or BMP). The difference between the two is that with CMP beans you need to define how the Java representation is mapped to the relational model (the container handles the code generation required to make this happen), whereas in BMP beans you must provide both the data representation and the implementation that reflects changes to the Java object model in the database. One common approach to bean-managed persistence is to use JDBC in the enterprise bean lifecycle methods.

A developer starting with an existing relational database must map the relational model currently in the database (if the database is in use by other applications, schema changes typically are not possible) to an object model. There are many possible complex mappings between an object model and the relational database. Relational database views are analogous; some of the same issues may be encountered during the mapping process (for example, a view can be created that cannot be updated, normally because of constraint violations).

Container-managed persistence provides some development advantages over beanmanaged persistence. CMP beans allow you to work on an abstract schema, which is the combination of fields and relationships, independent of the underlying mapping to the relational database. The underlying mapping is provided by the application server, through the native object to relational mapping functionality. This capability extends to queries, which are written based on the abstract schema in the Enterprise JavaBeans Query Language (EJBQL). The query language is similar to the query capability provided in SQL.

This separation allows you to provide an object model and implementation that is separate from the mapping, thereby reducing the coupling. Thus, container-managed beans can be developed faster. Some proponents also claim that their runtime performance is better than that of BMP beans because the optimizations can be done in the server.

Bean-managed persistence requires that you implement the life-cycle methods to interact with the persistent storage mechanism. Typically, you would provide and execute SQL queries in the implementation of the life-cycle methods (ejbStore would perform an update, ejbCreate would perform an insert, and ejbLoad would perform a select). The disadvantage of doing JDBC directly in the entity bean is that you do not achieve productivity gains and may not achieve increased performance because of the impedance mismatch between the programming language and a relational database. (Programming languages operate on one object at a time, whereas a relational database can operate on sets of data.) The performance increase may not be realized, because one common mapping is between a row and an object instance. In the entity model, set operations are performed by iterating over a collection of Java objects that cause SQL statements operating on a single row to be invoked. You may be able to incorporate existing tuned queries directly into this model or by using a different data representation to enable set-based operations.

NetBeans IDE provides both a top-down and a bottom-up approach for creating a related set of CMP entity beans. The top-down approach first creates the entity beans that describe the abstract schema (fields and relationships representing the data model). The Sun Java System Application Server provides a facility for automatically generating the required database tables. Or you can have the database schema created and use the application server mapping facility. The bottom-up approach generates the beans based on an existing database schema (the generation will produce CMP entity beans).




NetBeans IDE Field Guide(c) Developing Desktop, Web, Enterprise, and Mobile Applications
NetBeans IDE Field Guide(c) Developing Desktop, Web, Enterprise, and Mobile Applications
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 279

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net