Network Deployment (Distributed operating systems), v8.0 > Develop and deploying 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)
Procedure
- 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 (CMP) 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 that 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, you 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.
- 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 WAS, 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.
New feature: 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 WAS's 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. New feature:
- 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 Java EE Connector Architecture (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.
Related
Extensions to data access APIs
Recreating database tables from the exported table data definition language
Container managed persistence bean associated technologies
Manipulating synchronization of entity beans and datastores
Avoiding ejbStore invocations on non-modified EntityBean instances
Resource reference benefits
Access data using Java EE Connector Architecture connectors
JDBC application cursor holdability support
Data access bean types
Access data from application clients
Data access with Service DataObjects, API versions 1.0 and 2.01
Use the Java Database Connectivity data mediator service for data access
Use the EJB data mediator service for data access
Establishing custom finder SQL dynamic enhancement server-wide
Establishing custom finder SQL dynamic enhancement on a set of beans
Establishing custom finder SQL dynamic enhancement for specific custom finders
Disable custom finder SQL dynamic enhancement for custom finders on a specific bean
Deploy SQLJ applications
Change the error detection model to use the Exception Checking Model
Exceptions pertaining to data access
CMP connection factories collection
Connection life cycle
Develop enterprise beans