CORBA 2.3.7 Programmer's Guide for Java

can be used by either interface objects or control objects: an interface object need not always use a
control object for access to an entity object.
Entity objects are typically shared by multiple clients, usually control objects, so the application designer
must expect and prepare for concurrent invocations of the same object by multiple clients.
An entity object does not typically control other entity objects. The exception occurs when an entity
object is a composite of other entity objects; for example, a customer object could consist of basic
customer information from one entity object and transaction history from another.
An entity object need not be persistent to represent persistent data.
Object Distribution
The client programmer does not need to know whether an object is local or remote, so long as the
application and the framework or library have been designed with local/remote transparency in mind.
However, object distribution has implications for application performance.
If possible, design and distribute your objects according to the following guidelines:
Avoid the use of global state information. Global state information limits an application's ability to
take advantage of the scalability features of NonStop CORBA and the NonStop systems.
●
Put the objects with the most interactions closest together.
If a control object has many interactions with an entity objectfor example, doing a linear search of
many entity objectsand the control object has a few well-defined interfaces to an interface object,
place the control object on the same machine as the entity object.
Likewise, if a control object uses a database directly, you should locate the object on the same
machine as the database.
●
Minimize the number of interactions with a remote object.
Design both data and operations so that interactions with remote objects require as few remote
operations as possible. (This approach also benefits performance when the target object is local,
although not so dramatically.)
For example, if a control or entity object returns to a client an object consisting of many read-only
attributes, consider returning a struct instead. The get_ operations for accessing attributes are
translated into individual network messages, whereas structs are passed by value as part of the
operation that returns them.
The following example shows an IDL object definition with multiple attributes:
interface account {
readonly attribute string CustomerName;
readonly attribute string CustomerAddress;
}
If this type of object is distributed, the client must send a separate message to read each attribute.
●