WAS v8.5 > Develop applications > Develop data access resources > Develop data access applications

Develop data access applications

We can use data access applications to manipulate data from outside sources for use within the application serving environment. We can access data in various ways:

• using standard or extended APIs
• using container-managed persistence beans
• using bean-managed persistence beans, session beans, or web components.
• using Service Data Objects (SDO)

1. Decide how to implement data access.

   The EJB programming model provides several distinct server-side component types: entity, session, and message-driven beans, and servlets. Of these types, entity beans are typically used to model business components in an application. Entity beans have both state and behavior.

   The state of entity beans is persistent and is stored in a database. As changes are made to an entity bean, its state is kept in synchronization with the database record representing the bean. There are two types of entity beans provided by the EJB model and these two types differ in the mechanism used to provide persistence. These two types of entity beans are container-managed persistence beans and bean-managed persistence (BMP) beans.

   • With BMP beans, the developer manually produces code to manage the persistent state of the bean.
   • With CMP beans, the EJB container manages the persistent state of the bean. Persistent state management is a complex and difficult task; using CMP beans allows the developer to concentrate on business logic by delegating persistence behavior to the container.

     Typical examples of CMP beans are Customer, Account, and so on. Because CMP beans are objects, their data (state) is accessed using field accessors. For example, a Customer entity bean is likely to have fields such as name and phoneNumber. These pieces of data are accessed using the accessor methods getName()/setName() and getPhoneNumber()/setPhoneNumber(). As a developer, you are not concerned with how this data is eventually stored and retrieved from the backend database and can assume the integrity of the data is maintained by the container.

   See the topic, Developing enterprise beans for information on developing entity beans.

   Tips:

   • To maximize the efficiency of application requests to relational databases, consider using Structured Query Language in Java (SQLJ) when developing BMP and CMP beans. This option is available for applications that use the DB2 JDBC Universal Driver to access DB2 databases.
   • Also consider using cursor holdability for potential performance gains; see the topic, JDBC application cursor holdability support, for details.

   An alternative to developing entity beans is using the Service Data Objects (SDO) framework, which is a unified framework for data application development. With SDO, we do not need to be familiar with a technology-specific API in order to access and utilize data. You need to know only one API, the SDO API, which lets you work with data from multiple sources, including relational databases, entity EJB components, XML pages, web services, the Java Connector Architecture, JSP, and more.

2. Look up a data source or connection factory using a resource reference. See the topic, Looking up data sources with resource references for relational access for more information. Do not perform this step if you work with CMP beans. The EJB container handles this process for CMP beans.

   To run applications on WebSphere Application Server, your code must use resource references to logically named data sources or connection factories. Mapping the resource references to actual resources is usually done at assembly time. The Application Server administrator configures those resources.

   • For relational database access, administrators configure a JDBC provider and associated data sources, which work with the embedded WebSphere Relational Resource Adapter.

   • For non-relational database access, administrators install a Java EE Connector Architecture (JCA) resource adapter onto an application server and configure associated connection factories.

   Generic work context implementation provides a mechanism for a resource adapter to control the contexts in which instances of work submitted by the resource adapter to the product work manager for execution are executed. By submitting a work instance that implements the WorkContextProvider interface, the resource adapter can propagate various types of context to the WAS. The application server then, if it supports the propagated context type, sets the provided context as the execution context of the work instance during its execution.

3. Get a connection to a data source or a connection factory. See the "Getting connections" section of the topic, Connection life cycle for details.) Do not perform this step if you work with CMP beans. The EJB container handles this process for CMP beans.

   The connection management architecture for both relational and procedural access to enterprise information systems (EIS) is based on the JCA specification. The Connection Manager (CM), which pools and manages connections within an application server, is capable of managing connections obtained through both resource adapters (RAs) defined by the JCA specification, and data sources defined by the JDBC Extensions Specification.

Subtopics

• Extensions to data access APIs
  If a single data access API does not provide a complete solution for the applications, use WAS extensions to achieve interoperability between both the JCA and JDBC APIs.
• Recreating database tables from the exported table data definition language
  When the WAS deployment tooling deploys an EJB jar file containing container-managed persistence enterprise beans, it selects the target database and creates a corresponding Table.ddl file. This file contains the SQL statement necessary to generate the database table for the CMP beans.
• Container managed persistence bean associated technologies
  WAS delivers container-managed persistence services beyond the standards set by the EJB specification.
• Manipulating synchronization of entity beans and datastores
  We can indicate that a particular EJB type should not synchronize its state to persistent storage prior to each findBy invocation using environment variables or a marker interface.
• Avoiding ejbStore invocations on non-modified EntityBean instances
  We can configure your EntityBean instances to bypass an invocation of the ejbStore method if they have not been modified during the current transaction.
• Resource reference benefits
  WAS requires your code to reference application server resources (such as data sources or J2C connection factories) through logical names, rather than access the resources directly in the JNDI name space. These logical names are called resource references.
• Access data using Java EE Connector Architecture connectors
  To access data from a JCA compliant application in WAS, you configure and use resource adapters and connection factories.
• JDBC application cursor holdability support
  The cursor holdability feature can reduce the overhead of JDBC interaction with your relational database, thereby helping to increase application performance.
• Data access bean types
  For easy data access programming, WAS provides a special class library that implements many methods of the JDBC API for you. The library is essentially a set of Service Data Objects (SDO).
• Access data from application clients
  To access a database directly from a Java EE application client, you retrieve a javax.sql.DataSource object from a resource reference configured in the client deployment descriptor. This resource reference is configured as part of the deployment descriptor for the client application, and provides a reference to a pre-configured data source object.
• Data access with Service DataObjects, API versions 1.0 and 2.01
  The Service Data Objects (SDO) framework is a data-centric, disconnected, XML-integrated, data access mechanism that provides a source-independent result set.
• Use the Java Database Connectivity data mediator service for data access
  The following steps demonstrate how to create the metadata for a JDBC data mediator service (DMS), as well as how to instantiate the DMS dataGraph.
• Use the EJB data mediator service for data access
  The following steps use code samples to describe a simple instance of how to create the EJB data mediator service (DMS) metadata.
• Establish custom finder SQL dynamic enhancement server-wide
  Enable support for dynamic SQL enhancement of all custom finders, defined in all beans, by modifying the custom properties of the application server in the dmgr console.
• Establish custom finder SQL dynamic enhancement on a set of beans
  We can enable support for all custom finders defined on beans by modifying the application server's custom properties through the dmgr console.
• Establish custom finder SQL dynamic enhancement for specific custom finders
  We can add an environment variable to establish support for custom finders to use in data access applications.
• Disable custom finder SQL dynamic enhancement for custom finders on a specific bean
  We can disable support for all custom finders defined on a specific bean by modifying the application's EAR file.
• Deploy SQLJ applications
  Use SQLJ to develop data access applications that connect to DB2 databases. SQLJ is a set of programming extensions that enable you to use the Java programming language to embed statements that provide SQL (Structured Query Language) database requests.
• Change the error detection model to use the Exception Checking Model
  The error detection model has been expanded and the data source has a configuration option used to select the exception mapping model or the exception checking model for error detection. This configuration option allows the Error Detection Model to comply with JDBC 4.0.
• Exceptions pertaining to data access
  All enterprise bean container-managed persistence beans under the EJB 2.x specification receive a standard EJB exception when an operation fails. JDBC applications receive a standard SQL exception if any JDBC operation fails. WAS v8.5 provides special exceptions for its relational resource adapter (RRA), to indicate the connection currently held is no longer valid.
• CMP connection factories page
  Use this page to view existing container managed persistence (CMP) connection factories settings.
• Use Bean Validation in RAR modules
  WAS validates resource archive (RAR) JavaBeans constraints in compliance with the Java Connector Architecture (JCA) version 1.6 specification.
• JCA 1.6 support for annotations in RAR modules
  

  The Java Connector Architecture (JCA) v1.6 specification adds support for Java annotations in resource archive (RAR) modules. Annotations are a means of specifying metadata, or configuration data, for a RAR module in the class files that make up the module.

• Extensions to data access APIs
  If a single data access API does not provide a complete solution for the applications, use WAS extensions to achieve interoperability between both the JCA and JDBC APIs.
• Recreating database tables from the exported table data definition language
  When the WAS deployment tooling deploys an EJB jar file containing container-managed persistence enterprise beans, it selects the target database and creates a corresponding Table.ddl file. This file contains the SQL statement necessary to generate the database table for the CMP beans.
• Container managed persistence bean associated technologies
  WAS delivers container-managed persistence services beyond the standards set by the EJB specification.
• Manipulating synchronization of entity beans and datastores
  We can indicate that a particular EJB type should not synchronize its state to persistent storage prior to each findBy invocation using environment variables or a marker interface.
• Avoiding ejbStore invocations on non-modified EntityBean instances
  We can configure your EntityBean instances to bypass an invocation of the ejbStore method if they have not been modified during the current transaction.
• Resource reference benefits
  WAS requires your code to reference application server resources (such as data sources or J2C connection factories) through logical names, rather than access the resources directly in the JNDI name space. These logical names are called resource references.
• Access data using Java EE Connector Architecture connectors
  To access data from a Java EE Connector Architecture (JCA) compliant application in WAS, you configure and use resource adapters and connection factories.
• JDBC application cursor holdability support
  The cursor holdability feature can reduce the overhead of JDBC interaction with your relational database, thereby helping to increase application performance.
• Data access bean types
  For easy data access programming, WAS provides a special class library that implements many methods of the JDBC API for you. The library is essentially a set of Service Data Objects (SDO).
• Access data from application clients
  To access a database directly from a Java EE application client, you retrieve a javax.sql.DataSource object from a resource reference configured in the client deployment descriptor. This resource reference is configured as part of the deployment descriptor for the client application, and provides a reference to a pre-configured data source object.
• Service Data Objects version 2.1.1
  Service Data Objects (SDO) is a framework for data application development that provides an architecture and application programming interfaces (API). WAS v8.5 includes an implementation of SDO 2.1.1 interfaces. After the product is installed and SDO is enabled, SDO 2.1.1 becomes the default SDO implementation when programming with SCA or SDO interfaces.
• Data access with Service DataObjects, API versions 1.0 and 2.01
  The Service Data Objects (SDO) framework is a data-centric, disconnected, XML-integrated, data access mechanism that provides a source-independent result set.
• Use the Java Database Connectivity data mediator service for data access
  The following steps demonstrate how to create the metadata for a JDBC data mediator service (DMS), as well as how to instantiate the DMS dataGraph.
• Use the EJB data mediator service for data access
  The following steps use code samples to describe a simple instance of how to create the EJB data mediator service (DMS) metadata.
• Develop a custom DataStoreHelper class
  Apply the WebSphere extension, GenericDataStoreHelper class, to create our own data store helper for data sources the application server does not support. With this helper class, your JDBC configuration can use database-specific functions during transactions.

Related concepts:

Connection life cycle

Related

Develop enterprise beans

+

Search Tips   |   Advanced Search