Chapter 13: JDBC Connectivity solve, and code can
Chapter 13: JDBC Connectivity solve, and code can quickly become vendor-specific again (this time, depending on the JDBC driver vendor). Furthermore, the rapid maturation of J2EE has consolidated its overall architecture. There is growing momentum to adopt the same resource adapter model to the Enterprise Information System (EIS) throughout the J2EE stack. Architecturally, JDBC connections are connections to external/legacy systems, which are considered part of the EIS. In the J2EE architecture, these connections should be managed through a well-defined Connector architecture. This is the subject matter of J2EE Connector Architecture (JCA). For more information, see the following URL: http://java.sun.com/j2ee/connector/ In this architecture, J2EE software components access EIS resources via resource adapters with a common set of well-defined interfaces. These interfaces enforce well-defined contracts (between application server and resource adapter) in connection management, transaction management, and security. The evolution of the JDBC standard is migrating to this new JCA architecture as it becomes better defined. The first step toward this migration is to detach any direct coupling between the application logic and the specific EIS resource that it needs. This can be accomplished by an intermediary indirect lookup mechanism. JNDI is a Java-based industry standard that can serve this purpose. JDBC 3 is the first version to be designed with this migration in mind. In fact, JDBC 3 is the first specification that clearly spells out the different architectures that JDBC can operate in including two-tier and three-tier models. The three-tier model corresponds to the application server model and is the model of operation favored by J2EE applications. The JDBC specification also attempts to accommodate JDBC 1 and 2 drivers and model of operations, while formalizing JNDI as the preferred way for applications to obtain a data source. It also formalizes connection pooling as a value-added service of the application server or Servlet container. JDBC 4, finalized in December of 2006, continues to support all features of the previous three versions. In addition, JDBC 4 addresses some features that make development easier, improve connection pooling, expose physical database row IDs for developers, and introduce a new XML data type to JDBC. With the introduction of Tomcat 6 in early 2007, JDBC 4 is still in its infancy in terms of vendor support. Regardless of the JDBC version, the JDBC driver still must translate the unified JDBC commands into native commands to connect to the different servers. JDBC drivers have evolved significantly over the past few years and most of them today are high-performance Type IV drivers (explained in the next section). However, some legacy systems still exist that support only the older Type I to Type III drivers. It is a good idea to gain some familiarity with different types of JDBC drivers that may be around. JDBC Driver Types There are four different types of JDBC drivers: Type I to Type IV. In general, the higher driver types represent an improvement on architecture and performance, as described here: . Type I: These drivers are the most primitive JDBC drivers, as they are essentially data access adapters. They adapt another data access mechanism (such as ODBC) to JDBC. These drivers completely rely on the other data access mechanism to work and, as such, create double the
For reliable and cheap web hosting services please check tomcat web hosting website.