This architecture is for a relatively simple website that uses a J2EE-compliant application server. The diagram shows one new database in the Middle Tier of a website and no existing databases or systems in the EIS Tier. There are four ways that a database could be used in this architecture:
- The first way is with a transparent interface such as Java Data Objects (JDO)
coupled with an object database. In this case, there is no need for a mapping
layer because the Java object model is the same model used by the object
database. See transparent
persistence in object databases (new window).
The lack of a mapping layer is show in this diagram.
- The second way is with a transparent interface such as Java Data Objects (JDO) coupled with a relational database. In this case, there is a need for a mapping layer because the Java object model may not match the model used by the relational database. Nevertheless, the mapping can be moved to one location as described in JDO data conversion (new window). Also see transparent persistence in object-relational mapping (new window).
- The third way is with a call-level interface such as JDBC coupled with a relational database. In this case, there is a need for a mapping layer because the Java object model may not match the model used by the relational database. The mapping would need to be done at the application level as described in JDBC data conversion (new window). Be sure to take a look at transparent persistence vs. JDBC call-level interface (new window). This outlines some disadvantages of using JDBC that you should consider when designing persistence for J2EE.
- The fourth way is with SQLJ and a relational database. Having a new database would make it possible to minimize the mapping described in SQLJ data conversion (new window). Also see SQLJ (new window) and mapping SQL and Java data types (new window).
More on the general topic: Architectures using databases in the middle tier
based on 6 reviews.
based on 8 reviews.