CORBA 2.3.7 Programmer's Guide for Java
Interface objects typically run on a client workstation or other end-user device, such as a
bank-teller input device or a gas-station pump.
●
Control objects typically run on a server machine. These objects are sometimes called
business-transaction objects because each operation on the object corresponds to a unit of work,
such as withdraw funds from account or transfer funds between accounts.
●
Entity objects represent persistent data that needs to survive a use case (such as a business
transaction).
●
These are conceptual classifications. Neither CORBA nor NonStop CORBA defines specific interfaces
to correspond to these types of objects.
Interface Objects
In general, an interface object can interact with control objects or entity objects. In an OLTP
environment, the user usually interacts with an interface object, which in turn interacts with a control
object to initiate a transaction. The control object interacts with one or more entity objects to perform the
transaction. Transactions are almost always performed against more than one database, or at least more
than one database record, so interface objects seldom interact directly with entity objects.
There are no special considerations for interface objects in NonStop CORBA.
Control Objects
Control objects do not interact directly with a database. Instead, they interact with (or coordinate) entity
objects, which represent and manipulate the data.
In some cases, a control object implements an entire transaction and is, therefore, responsible for
beginning and committing that transaction.
In other cases, several control objects implement different parts of a transaction. In such cases, a
higher-level control object should be defined to coordinate the work and begin and commit the
transaction.
Because a control object does not exist outside a business transaction, a control object does not pose the
same types of object-sharing problems as objects representing shared-data resources.
However, you must consider other issues if the object will be implemented in a server poolspecifically,
whether the object needs to maintain dynamic context between calls. For example, an operation that
debits an account can use an account-number parameter to get all the context it needs from a database,
and does not have to retain dynamic state. In contrast, an operation that iterates through a result set must
maintain dynamic state in the form of a cursor for the result set. Whether an object maintains dynamic
context between calls has implications for load balancing, and therefore for application throughput, as
described in Parallel Processing and Its Implications.
Entity Objects
An entity object typically represents stored data, although it could also represent a device. Entity objects