		BEA WebLogic Enterprise 4.2 Developer Center
		HOME \| SITE MAP \| SEARCH \| CONTACT \| GLOSSARY \| PDF FILES \| WHAT'S NEW
		GETTING STARTED \| TABLE OF CONTENTS \| PREVIOUS TOPIC \| NEXT TOPIC

Process-Entity Design Pattern

This chapter describes the Process-Entity design pattern. This design pattern is appropriate in situations where a client application normally performs multiple interactions with a remote database. 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.

By designing a single CORBA object on the server machine that represents all the fine-grained data in the database, you can build an WebLogic Enterprise 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.

Motivation

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. However, this approach has the following limitations:

It does not scale well. As the number of clients increases dramatically, you potentially have the situation where the server machine is attempting to manage thousands or millions of database objects, each requiring its own database transactions.
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.

However, if you design a single process object on the server machine that does database interactions on behalf of clients, you can overcome these limitations, reducing message traffic and the number of CORBA objects that need to be managed on the server machine.

Applicability

This 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.

The following figure shows the basic design of the Process-Entity design pattern. The client application issues a request, shown as arrow 1, to the CORBA process object to access database entities. The process object interacts with the database object, shown as arrow 2. Only the subset of database information required by the client is returned in the response back to the client application.

Figure 3-1 Process-Entity Design Pattern

Participants

The client application obtains a reference to the process object from a factory. The process object implements all the interactions with the database. Database records (entities) are retrieved when needed to service 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 C++ Server Applications or Creating Java Server 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 [SmallTalk].

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

Copyright © 1999 BEA Systems, Inc. All Rights Reserved.
Required browser version: Netscape Communicator version 4.0 or higher, or Microsoft Internet Explorer version 4.0 or higher.
Last update: July 01, 1999.