CORBA 2.6.1 Programmer's Guide for C++

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.
However, if the interface definition is changed to have one attribute, the client can send one message to get all the information:
interface account {
struct CustomerRecord {
string name;
string address;
};
readonly attribute CustomerRecord customer;
} ;
Isolate CORBA functions and database access functions from business logic. Isolating CORBA functions from non-CORBA functions is
often referred to as delegation.
Independent data access objects (DAOs) allow SQL/MP and SQL/MX database accesses, which are process-blocking operations,
to be isolated from other functions that can be implemented using multithreading. Data access objects can be implemented as context-
free TS/MP servers, configured as server pools, that instantiate only one object per process and have the following POA policy settings:
Lifespan policy
PERSISTENT
State policy
STATELESS
Threading policy
SINGLE_THREAD_MODEL
Use server pools to distribute objects and when possible, requests for the same object, across processors, as described in Parallel
Processing and Its Implications.
Ensure that the amount of data transferred with each remote operation is neither too large nor too small.
Whenever possible, use data types that have low marshaling costs, such as primitive data types and structs. Avoid using the any data
type if at all possible.
Consider using fewer, larger CORBA objects (coarse object granularity).
Parallel Processing and Its Implications
NonStop CORBA can run application servers as server pools. This style of implementation allows many processes to act as one logical server;
each new unit of work goes to the next available free server process in the pool. Server processes can run in different processors to allow for
parallel processing.
In general, the implementation of an object in a server pool is transparent to the programmer except for the following characteristics:
Class data for an object class applies only to the object instances in one process, not to the entire object class (which might have
instances in other processes).
TS/MP load balancing is available only for stateless servants.
If you use server pools, you must decide how to provide for stateless requests when possible and stateful requests when necessary. In
stateless processing, a series of operations on the same object can result in requests to different processes in a server pool. In stateful
processing, operations on the same object are handled by the same process, allowing the server to treat the requests as a series and to
coordinate concurrent access to the same object by different clients.
Designing a Server
Most server design decisions depend on the characteristics and relationships among objects that will run in the server. To design a server, you
consider issues such as:
Object references. How to tailor the construction of an object reference—the handle by which a client refers to an existing object—to
meet application requirements for persistence, to support either one or multiple instances of a class in a process, and to satisfy server-
pool requirements.
Concurrency. Whether the server requires threads.
Parallelism. Whether the server can run as a server pool.
Designing a Client
To design a client, you consider issues such as:
Local/remote transparency. Whether the location of an object must be transparent to the client. By using certain calls for object