6.7 Programming Access to Data and Functions

In an application that requires access to an enterprise information system, an Application Component Provider is responsible for programming access to resources managed by the enterprise information system, including tables, stored procedures, business objects, and transaction programs. The Application Component Provider also has to write the business and application logic when developing functionality of applications that target enterprise information system.

The API for accessing an enterprise information system belongs to two categories: a client-level API to access data and execute functions (for example, java.sql.PreparedStatement and java.sql.ResultSet in JDBC 2.0) and a system-level API for getting connections and demarcating transactions (for example, javax.sql.DataSource in JDBC 2.0).

In the J2EE programming model, a container assumes primary responsibility for managing connection pooling, transactions, and security. The level of service provided is based on the declarative specification of application requirements by an Application Component Provider or Deployer. This leaves an Application Component Provider to concentrate on programming access to data and functions being managed by an enterprise information system.

6.7.1 Client API for Enterprise Information System Access

A client API for accessing data and functions can be difficult to understand and use for one or more of the following reasons:

• The client API may be tied to a specific enterprise information system programing model.
• The client API may not present object-oriented abstractions. For example, it may require remote function calls to access business functions on an ERP system.
• An Application Component Provider who is proficient with the JavaBeans component model and visual application composition and development tools may see any API that does not support such functionality as being difficult to use.
• The lack of application development tool support for a specific client API may force Application Component Providers to hand-code all data and/or function access.

These factors increase the need for tools to support end-to-end application development. Application Component Providers also have to use additional programming techniques to simplify enterprise information system integration.

6.7.2 Tools for Application Development

The J2EE programming model recognizes that Application Component Providers will rely on enterprise development tools for simplifying development during enterprise information system integration. These tools will come from different vendors, provide varied functionalities, and serve various steps in the application development process. A number of these tools will be integrated together to form an end-to-end development environment. The tools include:

• Data and function mining tools, which enable Application Component Providers to look at the scope and structure of data and functions in an existing information system.
• Object-oriented analysis and design tools, which enable Application Component Providers to design an application in terms of enterprise information system functionality.
• Application code generation tools, which generate higher level abstractions for accessing data and functions. A mapping tool that bridges different programming models, such as an object to relational mapping, will fall into this category.
• Application composition tools, which enable Application Component Providers to compose application components from generated abstractions (such as those described in previous bullets). These tools will use the JavaBeans component model to enhance ease of programming and composition.
• Deployment tools, which are used by Application Component Providers and Deployers to set transaction, security, and other deployment time requirements.

Since programming access to enterprise information system data and functions is a complex application development task in itself, we recommend that application development tools should be used to reduce the effort and complexity involved in enterprise information system integration.

6.7.3 Access Objects

A component can access data and functions in an enterprise information system in a couple of ways, either directly by using the corresponding client API or indirectly by abstracting the complexity and low-level details of enterprise information system access API into higher level access objects. An Application Component Provider comes across these access objects in different forms, scopes, and structure.

The use of access objects provides several advantages:

• An access object can adapt the low-level programming API used for accessing enterprise information system data and/or functions to an easy-to-use API that can be designed to be consistent across various types of enterprise information systems. For example, an access object may follow a design pattern that maps function parameters to setter methods and return values to getter methods. The Application Component Provider uses a function by first calling the appropriate setter methods, then calling the method corresponding to the enterprise information system function, and finally calling the getter methods to retrieve the results.
• A clear separation of concern between access objects and components will enable a component to be adapted to different enterprise information system resources. For example, a component can use an access object to adapt its persistent state management to a different database schema or to a different type of database.
• Since access objects can be made composable through support for the JavaBeans model, components can be composed out of access objects or can be linked with generated access objects using application development tools. This simplifies the application development effort.

Since access objects primarily provide a programming technique to simplify application development through one or more of the above advantages, we recommend that Application Component Providers consider using them anywhere they need to access data or functions in an enterprise information system. In some cases tools may be available to generate such access objects. In other cases they will need to be hand-coded by Application Component Providers.

6.7.3.1 Guidelines for Access Objects

Here are some guidelines to follow in developing access objects:

• An access object shouldn't make assumptions about the environment in which it will be deployed and used.
• An access object should be designed to be usable by different types of components. For example, if an access object follows the set-execute-get design pattern described previously, then its programming model should be consistent across both enterprise beans and JSP pages.
• An access object shouldn't define declarative transaction or security requirements of its own. It should follow the transaction and security management model of the component that uses it.
• All programming restrictions that apply to a component apply to the set of access objects associated with it. For example, an enterprise bean isn't allowed to start new threads, to terminate a running thread, or to use any thread synchronization primitives. Therefore, access objects should conform to the same restrictions.

6.7.3.2 Examples of Access Objects

Access objects can be used in a number of ways, as represented in the following examples:

• Encapsulating functions

An access object can encapsulate one or more enterprise information system functions, such as business functions or stored procedures. The following code implements an access object that drives a purchase requisition business process on an enterprise resource planning system by mapping purchasing functions to method calls on a purchase function object.

PurchaseFunction pf = // instantiate access object for PurchaseFunction
// set fields for this purchase order
pf.setCustomer("Wombat Inc");
pf.setMaterial(...);
pf.setSalesOrganization(...);
po.execute();
// now get the result of purchase requisition using getter methods

• Encapsulating persistent data

A data access object can encapsulate access to persistent data such as that stored in a database management system. Data access objects can provide a consistent API across different types of such systems. Data access objects used by the sample application are used to access order objects stored in different types of databases.

• Aggregating behaviors

An access object can aggregate access to other access objects, providing a higher level abstraction of application functionality. For example, a PurchaseOrder aggregated access object can drive its purchase requisition business process through the PurchaseFunction access object and use a data access object PurchaseData to maintain persistent attributes of the purchase order.

6.7.3.3 Usage Scenarios for Access Objects

A component can use access objects in different ways depending on the functionality they offer. A couple of common ways to use access objects would be:

• Define a one-to-one association between components and access objects. That is, each access object encapsulates the enterprise information system functionality required by a particular component. This usage scenario will typically be used to enable Web access to enterprise information system resources being encapsulated by an access object.
• Define components to aggregate the behavior of multiple access objects. This will happen often where a component accesses multiple enterprise information system resources or adds additional business logic to the functionality defined by multiple enterprise information system resources.