Process-Entity Design Pattern

This topic includes the following sections:

•	About the Process-Entity Design Pattern

•	Increasing Scalability and Resource Utilization

•	Applicability

•	Participants

•	Other Considerations

•	Related Concepts

About the Process-Entity Design Pattern

The Process-Entity design pattern encapsulates a design solution that incorporates a single process object on the server machine that handles all client application interactions with database records, known as entities. This design pattern is appropriate in situations where a client CORBA or EJB application normally performs multiple interactions with a remote database.

By designing a single CORBA object or EJB on the server machine that represents all the fine-grained data in the database, you can build an Oracle Tuxedo CORBA client/server application that provides the following performance benefits:

•	Instead of having multiple client interactions with a database, you can have a single process object on the server machine that handles all client requests for database interactions, thus simplifying network traffic.

•	The process object can selectively pass data fields to the client, transferring only the necessary data rather than full database records, thus reducing the amount of data sent over the network and improving performance.

•	The process object encapsulates access to the database. Clients make invocations on the object, and the object in turn accesses the database.

Increasing Scalability and Resource Utilization

This topic includes the following sections:

•	Limitations of the Two-tier System

•	Advantages of the Process-Entity Design Pattern

Limitations of the Two-tier System

In a conventional two-tier system that presents the database layer as a set of shared data, a pure object-oriented approach would be to represent the database records as shared CORBA objects (in CORBA applications) or entity beans (in EJB applications). However, this approach has the following limitations:

•	It does not scale well. As the number of clients increases dramatically, the server machine might be required to manage thousands (or even millions) of database objects, each requiring its own transaction context.

•	It does not use network resources efficiently. When database objects are instantiated in the server machine’s memory, the entire database object is read into or written from memory regardless of how much data the client application really needs from the object.

•

For EJB applications, the conventional way to access a database is via entity beans, where an entity bean represents a row in a database table. However, to access an entity bean, a client application must make two calls: the first call obtains the object reference to the entity bean, and the second call invokes a method on that entity bean. Obtaining the object reference for the client is an expensive operation, particularly in high-volume enterprise applications.

Advantages of the Process-Entity Design Pattern

However, if you design a class for the process object on the server machine that does database interactions on behalf of clients, you can overcome these limitations by:

•	Reducing the number of CORBA objects or EJBs that need to be managed on the server machine.

•	Reducing message traffic.

•	For EJB applications, eliminating the need for client applications to obtain an object reference to the entity bean, and avoiding the use of fine-grain (single-row) entity beans.

Applicability

This topic includes the following sections:

•	Request Flow in CORBA Applications

•	Request Flow in EJB Applications

The Process-Entity design pattern is almost universally applicable in enterprise-class, mission-critical applications. It is appropriate for situations in which a client application needs to interact with database records stored on a server machine.

Request Flow in CORBA Applications

Figure 3‑1 shows the basic design of the Process-Entity design pattern in a CORBA application.

Figure 3‑1 CORBA Process-Entity Design Pattern

This process flows in the following sequence:

1.	The client application issues a request to the CORBA process object to access database entities.

2.	The CORBA object submits a request to the database.

3.	The database returns a response to the CORBA object.

4.	The CORBA object returns a response to the client that contains only the subset of database information that the client requires.

Request Flow in EJB Applications

Figure 3‑2 shows the basic design of the Process-Entity design pattern in an EJB application.

Figure 3‑2 EJB Process-Entity Design Pattern

This process flows in the following sequence:

1.	The client application issues a request to the entity bean, using RMI on IIOP, to access database entities.

2.	The entity bean submits a request to the database.

3.	The database returns a response to the entity bean.

4.	The entity bean returns a response to the client that contains only the subset of database information that the client requires.

Participants

The client application obtains a reference to the process object from a factory (for CORBA applications) or the home interface (for EJB applications). The process object implements all the interactions with the database. Database records (entities) are retrieved when needed to handle client invocations on the process object. Operations on the process object return specific data fields to the client application, which then performs all the required processing on that data.

Other Considerations

You should design the process object to pass the minimum amount of information actually needed by a particular client request. Implement the operations on a process object so that the operations do as much “dense” processing as possible. Design your clients applications so that they do not invoke more than one process operation to get the data they need to accomplish a task.

If more than one operation needs to be invoked, design the process object so that the additional invocations are done by the process object on the database, and not by the client application on the process object. This reduces the number of invocations that the client application sends over the network. When the client application needs to make serial invocations on a process object, make the process object stateful. For more information about making objects stateful, see Creating CORBA Server Applications in the Oracle Tuxedo online documentation.

For CORBA applications, avoid the use of attributes in your OMG IDL. Attributes are expensive to retrieve over the network. Instead, implement an operation on the process object that returns a data structure containing all the values your client application is likely to need for an operation.

Related Concepts

•	SmallTalk MVC (Model-View-Controller) design pattern.

•	Flyweight design pattern, Object-Oriented Design Patterns, by Gamma et al.