CORBA 2.6.1 Programmer's Guide for C++

Chapter 9. Designing Advanced Applications
Chapter 9. Designing Advanced Applications
Object-Oriented Design Methodologies
Designing Object Interfaces and Classes
Object Roles and Relationships
Object Distribution
Parallel Processing and Its Implications
Designing a Server
Designing a Client
Tuning Applications for Performance
Choosing the Most Efficient Transport Protocol
Taking Advantage of Concurrency
Adjusting Process Priorities
Adjusting Message-Buffer Sizes
This section suggests effective ways to design and tune your applications to take advantage of the features of NonStop CORBA and the
NonStop systems.
Object-Oriented Design Methodologies
HP does not recommend a specific object-oriented design methodology except to suggest that you choose an approach oriented to distributed,
standards-based computing.
Sometimes you can adapt an existing approach to a distributed environment. For example, a design approach that emphasizes the finest
possible granularity for objects, on the assumption that the cost of messages is trivial, can result in an application that is inefficient when
distributed. NonStop CORBA lets you preserve the reuse benefits of finely grained objects without compromising performance, either by
wrapping a set of small objects in a larger object or by ensuring that certain objects always run in the same process.
Designing Object Interfaces and Classes
The following is a summary list of the issues you should consider when designing object interfaces (in IDL) and the resulting object classes in a
NonStop CORBA application. These considerations may be more important in the highly distributed environment of a NonStop system than they
are on other platforms.
The role of each object interface—for example, whether each object represents an entity in a database—and the relationships among
objects.
Local/remote transparency. The implications of having users, information, and therefore objects distributed across a network.
Reuse. How to reuse existing software whenever possible by deriving new object interfaces or classes from existing ones.
Granularity. How to design operations and data to limit the number of interactions among distributed components.
Parallelism. Whether to take advantage of server pools, and whether requests to the same object could be handled by multiple
processes in parallel.
Service packaging. Whether to provide a new service as a library or a framework.
Concurrency. Whether multiple instances of an object can exist concurrently in the same process, and whether multiple clients can
use the same instance concurrently.
Persistence. Whether an object or its state must be accessible after the process that hosted it has stopped, and how to provide a
reusable reference to a persistent object.
Database mapping. How to map between instance data and persistent storage (such as a relational database).
Transaction management. How to manage concurrent transactions, especially if an object uses external frameworks or services to
perform transactions. (An object that has this responsibility is a client of the Transaction Service, or NSOTS.)
Factory objects and control objects. Whether to define objects to control the activities of other objects—for example, factory
objects to create other objects, or control objects to manage concurrent access to data or maintain class data across a server pool.
Exception and error reporting. How to provide uniform exception and error reporting, including response to unsupported requests, and
how to provide instrumentation for troubleshooting.