4.5 How WebSphere Application Server works with DB2 UDB Server

 < Day Day Up > 



4.5 How WebSphere Application Server works with DB2 UDB Server

In this section we describe how WebSphere Application Server interacts with DB2 UDB Server. The topics covered are J2EE Connector architecture, resource adapters, and DB2 JDBC drivers.

4.5.1 J2EE Connector architecture

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 vendors. It provides the following functionality:

  • Provides connectivity between J2EE components (an application server or an application client) and an EIS.

  • 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:

    • A 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 clients requiring access to EISs.

    • 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.

    • A security contract that enables a secure access to an EIS. This contract provides support for a secure application environment, which reduces security threats to the EIS and protects valuable information resources managed by the EIS.

      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 accesses the EIS. This simplifies writing code to connect to an EIS's data store. The resource adapter provides connectivity between the EIS, the application server, and the enterprise application via the CCI.

  • 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.

4.5.2 JDBC resources

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 core API.

  • The javax.sql package, which is the JDBC 2.0 Standard Extension API. This package provides data source and connection pooling functionality.

JDBC providers and data sources

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 name of a particular vendor. It also makes maintaining the code easier because if, for example, the data source is moved to a different server, all that needs to be done is to update the relevant property in the data source. None of the code using that data source needs to be touched.

The connection is usually a pooled connection, that is, once the application closes the connection, the connection is returned to a connection pool, rather than being destroyed.

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 follows:

  • 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 acquired, the application then sends SQL queries or updates to the database.

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).

    click to expand
    Figure 4-10: Version 4 connection pooling

  • WebSphere Version 5 data source

    In WebSphere Application Server V5, connection pooling is provided by two parts, a JCA Connection Manager and a relational resource adapter. The JCA Connection Manager provides the connection pooling, local transaction, and security supports. The relational resource adapter provides both JDBC wrappers and JCA CCI implementation that allows BMP, JDBC applications, and CMP beans to access the database. Figure 4-11 on page 105 shows the relational resource adapter model.

    click to expand
    Figure 4-11: V5 Resource adapter

WebSphere relational 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:

  1. An EJB performs a JNDI lookup of a data source connection factory and issues a getConnection() request.

  2. The connection factory delegates the request to a connection manager.

  3. 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.

Data source usage guidelines

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.

4.5.3 DB2 JDBC providers

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 generally dependent on a native library, which limits their portability. The JDBC-ODBC Bridge driver is an example of a Type 1 driver.

  • 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 requests to the data source.

  • 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.

DB2 Legacy CLI-based JDBC application driver (Type 2)

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 methods. The Java applications that use this driver must run on a DB2 UDB client, through which JDBC requests flow to the DB2 UDB server. A DB2 Connect Version 8 license/installation is required to access DB2 for OS/390 databases.

click to expand
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.

JDBC 1 connections

The implementation classes for establishing a connection to DB2 UDB servers include COM.ibm.db2.jdbc.app.DB2Driver.

JDBC 2 connections

The implementation classes for establishing a connection to DB2 UDB servers include:

  • COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource

  • COM.ibm.db2.jdbc.DB2DataSource

  • COM.ibm.db2.jdbc.DB2XADataSource

IBM DB2 Universal JDBC driver

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 path between the JDBC driver and DB2 UDB servers. This new IBM JDBC Universal Driver is based on an open distributed protocol, known as Distributed Relational Database Architecture (DRDA), and is compatible with all DB2 UDB server platforms (UNIX, Windows, Linux, z/OS) with appropriate DRDA Application Server (AS) level support, and prerequisite stored procedures.

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.

JDBC 1 connections

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:

    jdbc:db2://server:port/database    jdbc:db2://server/database 

Then Type 4 connectivity is selected. Whereas if the URL is of the form:

    jdbc:db2:database 

Then Type 2 connectivity is selected.

JDBC 2 connections

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.

    Note 

    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 indicate it is faster than the Legacy JDBC drivers but not as fast as the JCC Type 2. The Type 4 driver also supports more security mechanisms than the Type 2 since support for them is in the UDB server but not in the CCC.

  • 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.

click to expand
Figure 4-13: DB2 Java application architecture (Type 4 jdbc driver)

SQLJ support

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.

Note 

SQLJ truly has been greatly enhanced in IBM WebSphere Studio V5.1 products.

SQLJ provides:

  • A static package level security model

  • A static SQL interface (for example, SELECT xxx INTO :hv1, :hv2)

  • Increased development productivity as compared to JDBC, especially if an application is being ported from an existing embedded SQL architecture (C, COBOL, etc.)

DB2 Version 8 provides the following SQLJ utilities, as shown in Figure 4-14 on page 112:

  • sqlj

    IBM SQLJ Translator. It translates an .sqlj source file and creates a serialized profile and a program.

  • db2sqljcustomize

    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 optionally (by default) binds the DB2 packages for this program.

  • db2sqljbind

    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.

  • db2sqljprint

    Prints contents of a DB2 customized profile.

click to expand
Figure 4-14: SQLJ application development

DB2 JDBC driver providers

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 utilizing the different JDBC drivers and the data source implementation classes provided by DB2 UDB V8.

The XA JDBC providers create XADataSource, which supports application participation in a single-phase or a global (two-phase) transaction environment. When this data source is involved in a global transaction, the transaction manager provides transaction recovery facilities.

The other JDBC providers create ConnectionPoolDataSource, which supports application participation in a single-phase transaction environment.



 < Day Day Up > 



DB2 UDB V8 and WebSphere V5. Performance Tuning and Operations Guide2004
DB2 UDB V8 and WebSphere V5. Performance Tuning and Operations Guide2004
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 90

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