|
|
|
|
|
|
This topic includes the following sections:
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 WebLogic Enterprise client/server application that provides the following performance benefits:
About the Process-Entity Design Pattern
This topic includes the following sections:
Increasing Scalability and Resource Utilization
In a conventional 2-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:
Limitations of the Two-tier System
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:
Advantages of the Process-Design Entity Pattern
This topic includes the following sections:
Applicability
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.
Figure 3-1 shows the basic design of the Process-Entity design pattern in a CORBA application.
This process flows in the following sequence:
Request Flow in CORBA Applications
Figure 3-1 Process-Entity Design Pattern in a CORBA Application
Figure 3-2 shows the basic design of the Process-Entity design pattern in an EJB application.
This process flows in the following sequence:
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.
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 <HYPERLINK to Creating C++ Server Applications or Creating Java Server Applications>.
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.
|
|
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|