![]() |
![]() |
|
|
Process-Entity Design Pattern
This topic includes the following sections:
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 a BEA Tuxedo CORBA client/server application that provides the following performance benefits:
Increasing Scalability and Resource Utilization
This topic includes the following sections:
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:
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:
Applicability
This topic includes the following sections:
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:
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:
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 BEA 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
![]() |
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|