Configure data access for J2EE application clients

To configure data access for application clients, specify the resource reference and associated database information required for data access. This is part of the assembly and deployment steps for the application client.

There are two essential tools needed to configure data sources used by J2EE Application Clients: the Application Assembly Tool (AAT) to define the resource reference in the deployment descriptor, and the Application Client Resource Configuration Tool (ACRCT) to define the connection to the database in the client deployment environment.

Data access from an application client uses the JDBC drive connection functions directly from the client side. It does not take advantage of the additional pooling support available in the WAS run time. Configuring data access for an application client does not require configuration of a JDBC provider and data source on the WAS server machine.

If you want to take advantage of the pooling and additional database functions provided by WAS, it is recommended that your client application use an enterprise bean running on the server side to perform data access.

Define an application client resource reference in the Application Assembly Tool

  1. Assemble your application client module. For more information, see Assemble application client modules Go to Help documentation. When you reach the step for creating a resource reference, continue with these steps.

  2. Create a new resource reference.

  3. Do the following on the New Resource Reference General Tab:
    1. Enter the Name of this resource reference. The WebSphere Application client run time uses this name for two purposes: to bind the object into the java:comp/env portion of the JNDI namespace, and to find client specific configuration information. If the code for the application client performs a lookup for java:comp/env/jdbc/myDB, the Name of the resource reference should be jdbc/myDB.
    2. In the Type field, select javax.sql.DataSource for JDBC connections.
    3. Set the authentication field to Application if your client application provides authentication information. If the WebSphere Application Client run time provides the authentication information (as configured by the ACRCT), then set this field to Container.

    4. Ignore the sharing scope setting, it is unused in an application client resource reference. All WebSphere Application Client resources are currently unsharable.

  4. Ignore the JNDI name field on the Binding Tab. It is not used in an application client resource reference. The required information is provided in the ACRCT.

Client configuration with the ACRCT

There are two client resources for you to configure in the ACRCT to enable data access from an application client: a data source provider and a data source.

  1. Configure a new data source provider. This provider describes the JDBC database implementation for your client application.

  2. Enter the following information on the General Tab:
    1. A name for this data source provider.
    2. (Optional) A description for this data source provider.
    3. The classpath to the data source provider implementation classes or JAR files. This is optional if the implementation classes or JAR files are already in the classpath configuration of the client.
    4. The name of the implementation class. For example, for DB2 this value is COM.ibm.db2.jdbc.DB2DataSource. Remember this class must implement the javax.sql.DataSource class. The ACRCT does not verify this class and you receive an error when you run your client application if the class does not implement javax.sql.DataSource.

    Use the Custom Tab to configure non-standard properties of the data source provider. This panel enables you to enter property-value pairs. During run time the implementation classname is created and any custom properties added on this panel are set on the newly created data source object using reflection. Any properties configured on this panel must have an appropriate set method on the data source class.

    For example, assume there is a property called use2Phase and its value should be 1. On the custom panel you enter the value use2Phase into the name column and the value 1 into the value column. The WebSphere Application Client run time then uses reflection to find a property on the data source class called, typically setUse2Phase and call that method passing the value of 1.

  3. Click OK.

  4. Configure a new data source. This describes the client properties of the database your client application uses.

  5. Enter the following information on the General Tab:
    1. A Name. This field is required and identifies a name for the ACRCT to use. This name is not used by your client application program.
    2. (Optional) A description of the data source.
    3. The JNDI name. This field is required and must match the value entered in the Name field of the General Tab of the AAT. In the example above, set this value to jdbc/myDB.
    4. (Optional) The Database Name.
    5. (Optional) Your userid in the User field.
    6. (Optional) Your password in the Password field. This password does not display.
    7. Your password again to confirm in the Re-Enter password field.

      Note: The User and Password fields are only used when the Authentication field on the General tab of the AAT is set to Container.

Notes:

  1. These WebSphere objects, which can be bound into the server namespace, are not supported on the client:

    • Java 2 Connector (J2C) objects

    • Connection manager objects

  2. The WAS Client does not provide client database drivers. If your client application uses a database directly, rather than using an enterprise bean, provide the database drivers on the client machine. This action can involve contacting your database vendor to acquire client database driver code and licenses.

  3. Instead of accessing the database directly, it is recommended that your client application use an enterprise bean. Accessing a database through an enterprise bean eliminates the need to have database drivers on the client machine because the database access is handled by the enterprise bean running on the WAS. Enterprise beans can also take advantage of the additional database functions provided by the WAS run time.