End-to-end paths for Data access resources
This page provides a starting point for finding information about data access. Various enterprise information systems (EIS) use different methods for storing data. These backend data stores might be relational databases, procedural transaction programs, or object-oriented databases.
The flexible IBM WebSphere Application Server provides several options for accessing an information system backend data store:
- Programming directly to the database through the JDBC 4.0 API, JDBC 3.0 API, or JDBC 2.0 optional package API.
- Programming to the procedural backend transaction through various J2EE Connector Architecture (JCA) 1.0 or 1.5 compliant connectors.
- Programming in the bean-managed persistence (BMP) bean or servlets indirectly accessing the backend store through either the JDBC API or JCA-compliant connectors.
- Use container-managed persistence (CMP) beans.
- Use the IBM data access beans, which also use the JDBC API, but give you a rich set of features and function that hide much of the complexity associated with accessing relational databases.
Service Data Objects (SDO) simplify the programmer experience with a universal abstraction for messages and data, whether the programmer thinks of data in terms of XML documents or Java objects. For programmers, SDOs eliminate the complexity of the underlying data access technology such as, JDBC, RMI/IIOP, JAX-RPC, and JMS, and message transport technology, such as java.io.Serializable, DOM Objects, SOAP, and JMS.
Subtopics
- (zos) Use optimized local adapters for inbound support
Use this task when we are implementing the optimized local adapters support for calling inbound to WebSphere Application Server for z/OS EJB applications.
- (zos) Use optimized local adapters for outbound support
Use this task when we are implementing the optimized local adapters support for calling programs in external address spaces from WebSphere Application Server for z/OS applications.
- (zos)(dist) Task overview: Storing and retrieving persistent data with the JPA API
The Java Persistence API (JPA) for the application server defines the management of persistence and object and relational mapping within Java Enterprise Edition (Java EE) and Java Standard Edition (Java SE) environments.
- Task overview: Accessing data from applications
Various enterprise information systems (EIS) use different methods for storing data. These backend data stores might be relational databases, procedural transaction programs, or object-oriented databases.
- Configure data access for the Application Client
Configuring data access for the Application Client involves specifying the resource reference and associated database information required for data access. This specification is done as part of the assembly and deployment steps for the Application Client.
- Enable DB2 Performance Expert Extended Insight
If we have a DB2 database configured in the Application Server, enable DB2 Performance Expert Extended Insight (PEEI) to employ an end-to-end monitoring system for the environment. PEEI features allow you to monitor transactions throughout the system stack and tune the resources according to the comprehensive data reports.
- 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.
- Establishing 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.
- Extend DB2 data source definitions at the application level
Extend data source definitions, which consist of non-core or custom properties, for DB2 data sources to add a greater level of application flexibility when we are using the DB2 Universal JDBC driver or DB2 Using IBM JCC driver. This capability is sometimes referred to as heterogeneous pooling. Use this feature to configure a DB2 data source in the application server with a core set of data source properties, and defer to individual applications to define any custom or non-core properties, like currentSchema or clientApplicationInformation, to be application specific. We can also use these extended definitions to override any non-core or custom properties that are already defined for the data source. In addition, this feature can reduce the number of physical connections that the application server uses by employing one connection pool between resources that connect to the same data source.
- Passing client information to a database
Using a WAS API or trace function, we can pass unique client information about every connection that originates from the same data source.
- Directory conventions
References in product information to app_server_root, profile_root, and other directories imply specific default directory locations. Become familiar with the conventions in use for WebSphere Application Server.
Related information:
Administer Data access resources
Scripting for data access resources
Establishing high availability for Data access resources
Troubleshooting Data access resources