In an application that requires access to an enterprise information system, an Appli- cation 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 cate- gories: 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 exam- ple,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 pro- graming 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 sys- tem.
• 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 develop- ment. 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 enter- prise information system integration. These tools will come from different vendors, provide varied functionalities, and serve various steps in the application develop- ment 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 Provid- ers to look at the scope and structure of data and functions in an existing infor- mation system.
• Object-oriented analysis and design tools, which enable Application Compo- nent Providers to design an application in terms of enterprise information sys- tem functionality.
• Application code generation tools, which generate higher level abstractions for accessing data and functions. A mapping tool that bridges different program- ming models, such as an object to relational mapping, will fall into this cate- gory.
• Application composition tools, which enable Application Component Provid- ers to compose application components from generated abstractions (such as those described in previous bullets). These tools will use the JavaBeans com- ponent 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 require- ments.
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.
PROGRAMMING ACCESS TO DATA AND FUNCTIONS 151
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 appropri- ate setter methods, then calling the method corresponding to the enterprise in- formation system function, and finally calling the getter methods to retrieve the results.
• A clear separation of concern between access objects and components will en- able a component to be adapted to different enterprise information system re- sources. 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 Java- Beans 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 appli- cation 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 compo- nents. For example, if an access object follows the set-execute-get design pat- tern 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 require- ments 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 ac- cess 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 syn- chronization 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 sys- tem 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 PurchaseFunc- tion
// set fields for this purchase order pf.setCustomer("Wombat Inc");
pf.setMaterial(...);
CONNECTIONS 153
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 (see Section 5.5.1 on page 130) 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, aPurchase- Orderaggregated access object can drive its purchase requisition business process through thePurchaseFunctionaccess object and use a data access objectPurchaseData 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 functional- ity 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 function- ality 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.