|< Day Day Up >|
In this section we describe how WebSphere Application Server
The J2EE Connector architecture (JCA) defines a standard architecture for connecting the J2EE platform to heterogeneous Enterprise Information Systems (EIS), for example, ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language. By defining a set of scalable, secure, and transactional mechanisms, the JCA enables the integration of EISs with application servers and enterprise applications.
WebSphere Application Server V5 provides a complete implementation of the JCA 1.0 specification that is a part of J2EE.
The JCA Resource Adapter is a system-level software driver supplied by EIS vendors or other third-party
Provides connectivity between J2EE
Plugs into an application server.
Collaborates with the application server to provide important services such as connection pooling, transaction, and security services. JCA defines the following set of system-level contracts between an application server and EIS:
connection management contract
that lets an application server pool connects to an underlying EIS, and lets application components connect to an EIS. This leads to a scalable application environment that can support a large number of
A transaction management contract between the transaction manager and an EIS that supports transactional access to EIS resource managers. This contract lets an application server use a transaction manager to manage transactions across multiple resource managers. This contract also supports transactions that are managed internally to an EIS resource manager without the necessity of involving an external transaction manager.
that enables a secure access to an EIS. This contract provides support for a secure application environment, which
The resource adapter implements the EIS-side of these system-level contracts.
Implements the Common Client Interface (CCI) for EIS access. The CCI defines a standard client API through which a J2EE component
Implements the standard Service Provider Interface (SPI) for integrating the transaction, security, and connection management facilities of an application server (JCA Connection Manager) with those of a transactional resource manager.
A resource adapter is used within the address space of the application server, and multiple resource adapters (that is, one resource adapter per type of EIS) are pluggable into an application server. This capability enables application components deployed on the application server to access the underlying EISs.
WebSphere Application Server provides the relational resource adapter (RRA) implementation. This resource adapter provides data access through JDBC/SQLJ to access the DB2 UDB server. The connection management is based on the J2EE Connector Architecture (JCA) connection management architecture. It provides connection pooling, local transaction, and security support.
Container-managed persistence (CMP) beans data access is managed by the WebSphere Persistence Manager indirectly. The JCA Specification supports Persistence Manager delegation of the data access to the JCA resource adapter without knowing the specific backend store. For the relational database access, Persistence Manager utilizes the relational resource adapter to access the data in the database.
WebSphere resource providers are a class of objects that provide resources needed by running J2EE applications in WebSphere. For example, if an application requires database access through a data source, you would need to install a JDBC data source provider and then configure a data source to be used by your application.
The JDBC API provides a programming interface for data access of relational databases from the Java programming language. The JDBC 2.0 API is comprised of two packages:
The java.sql package, which is the JDBC 2.0
The javax.sql package, which is the JDBC 2.0 Standard Extension API. This package provides data source and connection pooling functionality.
A data source represents a real-world data source, such as a relational database. Once a data source object is registered with a JNDI naming service, an application can retrieve it from the naming service and use it to make a connection to the data source it represents.
Information about the data source and how to locate it, such as its name, the server on which it resides, its port number, and so on, is stored in the form of properties on the DataSource object. This makes an application more portable because it does not need to hard code a driver name, which often includes the
The connection is usually a pooled connection, that is, once the application
Data source classes and JDBC drivers are implemented by the database vendor. By configuring a JDBC provider, we are providing information about the set of classes used to implement the data source and the database driver, that is, it provides the environment settings for the DataSource object.
The programming model is as
An application retrieves a DataSource object from the JNDI naming space.
After the DataSource object is obtained, the application code calls getConnection() on the data source to get a connection object. The connection is a pooled connection, that is, it is obtained from a pool of connections.
Once the connection is
WebSphere Application Server V5 provides two types of data sources, each differentiated by how the connections are handled:
WebSphere Version 4 data source
WebSphere Version 4.0 provided its own JDBC connection manager to handle connection pooling and JDBC access. This support is included with WebSphere Application Server V5 to provide support for J2EE 1.2 applications. If an application chooses to use a Version 4 data source, the application will have the same connection behavior as in WebSphere Version 4 (see Figure 4-10).
Figure 4-10: Version 4 connection pooling
WebSphere Version 5 data source
In WebSphere Application Server V5, connection pooling is provided by two
Figure 4-11: V5 Resource adapter
WebSphere provides a Persistence Resource Adapter to provide relational persistence services to the EJB beans that are deployed in the J2EE1.3 application, as well as providing database access to BMP and JDBC applications. The Persistence Resource Adapter has two components: The persistence manager, which supports the new EJB 2.0 CMP persistence model; and the relational resource adapter.
The persistence resource adapter code is included in the following Java packages:
com.ibm.ws.rsadapter.cci - Contains CCI implementation and JDBC wrappers
com.ibm.ws.rsadapter.spi - Contains SPI implementation
com.ibm.ws.rsadapter.jdbc - Contains all the JDBC wrappers
com.ibm.websphere.rsadapter - DataStoreHelper, WSCallerHelper and DataAccessFunctionSet
The EJB 2.0 Persistence Manager utilizes the relational resource adapter to handle the data access to and from the back-end store. The adapter provides relational persistence services to the EJB beans that are deployed in the J2EE1.3 applications. The relational resource adapter implementation is based on the J2EE Connector (JCA) specification and implements the JCA CCI and SPI interfaces.
The relational resource adapter that is available with WebSphere V5 provides JDBC/SQLJ data access to a relational database.
If an application chooses to use a Version 5 data source, the data source will use the JCA connector architecture to get to the relational database. Although there is no difference between the existing WebSphere JDBC support versus the new support in terms of application development, there will be some connection behavior changes because of different architectures.
For an EJB, the sequence is as follows:
The connection factory delegates the request to a connection manager.
The connection manager looks for an instance of a connection pool in the application server. If no connection pool is available, then the manager uses the ManagedConnectionFactory to create a physical (non-pooled) connection.
So from a JDBC application point of view, there is no difference between using a Version 4 data source or a Version 5 data source. It is the implementation of the data source that changes.
The data source that can be used is determined by whether the application is a J2EE 1.2 or a J2EE 1.3 application, and whether it uses EJB 1.1 modules or EJB 2.0 modules. The guidelines for data source use are:
J2EE 1.2 applications
All EJB beans, JDBC applications, or Version 2.2 servlets must use the Version 4 data source.
J2EE 1.3 applications
EJB 1.x modules must use the Version 4 data source.
EJB 2.0 modules, including CMP Version 2.0 and 1.x, must use the Version 5 data source.
JDBC applications and Version 2.3 servlets must use the Version 5 data source.
According to the JDBC specification, there are four types of JDBC driver architectures:
Type 1 - Drivers that implement the JDBC API as a mapping to another data access API, such as ODBC. Drivers of this type are
Type 2 - Drivers that are written partly in the Java programming language and partly in native code. The drivers use a native client library specific to the data source to which they connect. Again, because of the native code, their portability is limited. Notice that a Type 2 has a native component that is part of the driver and is separate from the database access API.
Type 3 - Drivers that use a pure Java client and communicate with a middleware server using a database-independent protocol. The middleware server then communicates the client's
Type 4 - Drivers that are pure Java and implement the network protocol for a specific data source. The client connects directly to the data source.
DB2 UDB Version 8 support Type 2, Type 3, and Type 4 JDBC drivers. The JDBC drivers in previous releases were built on top of DB2 CLI (Call Level Interface). DB2 UDB Version 8 Type 2 and Type 3 drivers continue to use the DB2 CLI interface to communicate with DB2 UDB servers (OS/390 and z/OS , UNIX, Windows, Linux, and iSeries ). DB2 UDB Version 8 adds a new DB2 JDBC Universal Driver (Type 2 and Type 4), which uses the Distributed Relational Database Architecture (DRDA) protocol for client/server communications.
The DB2 JDBC application (Type 2) driver (Figure 4-12 on page 108) enables Java applications to make calls to DB2 UDB through JDBC. Calls to the JDBC application driver are translated to native
Figure 4-12: DB2 Java application architecture (Type 2 jdbc driver)
The DB2 Legacy CLI-based JDBC application (Type 2) driver is included in the COM.ibm.db2.jdbc.app package.
The implementation classes for establishing a connection to DB2 UDB servers include COM.ibm.db2.jdbc.app.DB2Driver.
The implementation classes for establishing a connection to DB2 UDB servers include:
Many new features and enhancements have been made to the JDBC drivers in DB2 UDB Version 8. Among these changes, the biggest change is the architectural improvement that shortens the code
Features unique to the new IBM DB2 JDBC Universal Driver include:
Updateable ResultSet support
Improved security for DB2 authentication
Improved Java SQL error information
Programmatic tracing facilities
The new Universal Driver is com.ibm.db2.jcc.DB2Driver, and is contained in db2jcc.jar and sqlj.zip. The file db2jcc.jar contains the JDBC driver and SQLJ runtime modules. The file sqlj.zip contains the reference implementation of the standard SQLJ precompiler.
The DB2 UDB Version 8 server will use a TCP/IP connection, specified in the DB2 DBM configuration file (SVCENAME), to communicate with the new DB2 JDBC Universal Driver.
When obtaining connections from the JDBC 1 driver manager, if the database URL syntax is of the form:
Then Type 4 connectivity is selected. Whereas if the URL is of the form:
Then Type 2 connectivity is selected.
The implementation classes for establishing a connection to DB2 UDB servers include:
com.ibm.db2.jcc.DB2SimpleDataSource com.ibm.db2.jcc.DB2ConnectionPoolDataSource com.ibm.db2.jcc.DB2XADataSource
The Universal Driver (com.ibm.db2.jcc, also known as JCC) shares the same Java code for both T2 and T4 connectivity, so the Java files are the same regardless of T2 or T4. The major differences are:
The Type 2 driver makes its connections via the C Common Client (CCC) code that is used by CLI and the Legacy JDBC drivers (app/net), and does all communication via the CCC. This allows the Type 2 to use all of the communication protocols that CCC supports (shared memory, SNA, Netbios, etc.). It also allows the JCC Type 2 to run in the UDB server to support Java Stored Procedures (JSPs). (The Type 4 can call all types of stored procedures but cannot be used in the server.) If you have a local UDB server the shared memory connection is very fast. When you code just the database alias in the URL the database must be cataloged using the CLP command or Configuration Assistant.
The Type 2 driver can also make a TCP/IP connection without using the "catalog" if you specify the host name and port number as properties in the URL.
The Type 2 driver requires a DLL/shared library to be installed. The Type 4 driver is a "Pure Java" implementation and most measurements
For DataSources the major difference is the Property "driverType". A value of 2 loads the Type 2, and a value of 4 loads the Type 4 (2 is the default). If you code "driverType=2" and do not code "portNumber" and "serverName", the Type 2 driver will use the "databaseName" as the DB alias to connect to a cataloged database.
Figure 4-13: DB2 Java application architecture (Type 4 jdbc driver)
SQLJ support has been rearchitected in DB2 UDB Version 8. DB2 SQLJ support enables you to build and run SQLJ applets and applications. These Java programs contain embedded SQL statements that are precompiled and bound to a DB2 UDB database.
The IBM Universal driver for JDBC and SQLJ supports JDBC 2 APIs under JRE 1.3, and most of the JDBC 3 APIs under JRE 1.4.
The SQLJ standard has three components: A translator, customizer, and a run-time environment. The translator produces Java code based on the embedded SQL statements within a source SQLJ program. A binary representation of the SQL statements is created in a separate serialized profile (.ser file). Static SQL packages are created when the profile is customized using the db2sqljcustomize command. SQLJ applications require the db2jcc.jar file, and SQLJ program translator also requires the sqlj.zip file.
SQLJ truly has been greatly enhanced in IBM WebSphere Studio V5.1 products.
A static package level security model
A static SQL interface (for example, SELECT xxx INTO :hv1, :hv2)
Increased development productivity as compared to JDBC,
DB2 Version 8 provides the following SQLJ utilities, as shown in Figure 4-14 on page 112:
IBM SQLJ Translator. It
Customizer and online checker. It creates a DB2 customization for the serialized profile, and optionally online-checks SQL. statements that can be dynamically prepared, and
Standalone binder. It binds a previously customized SQLJ profile to a database. This utility can be used to deploy SQLJ applications to new DB2 servers.
Prints contents of a DB2 customized profile.
Figure 4-14: SQLJ application development
WebSphere V5 provides the DB2 Universal JDBC driver provider, DB2 Universal JDBC driver provider (XA), DB2 Legacy CLI-based type2 JDBC driver provider, and DB2 Legacy CLI-based type2 JDBC driver provider (XA) for a J2EE application running on WebSphere to communicate with DB2 UDB V8 by
The XA JDBC providers create XADataSource, which supports application participation in a
The other JDBC providers create ConnectionPoolDataSource, which supports application participation in a single-phase transaction environment.
|< Day Day Up >|