CORBA 2.6 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).●