Designing a Distributed Object Application
Subtopics
What You Need to Know
To design a new application or component, you take some or all of the following steps:
- Define client requirements (not only required services, but also factors such as performance, interoperation with other systems, and concurrent access to data).
- Evaluate available class libraries and frameworks to see what existing software you can use.
- Identify new classes required by the application and define the inheritance and usage relationships among the classes.
- Make decisions about server implementation.
- Design or modify clients to take advantage of new features.
Note: Some applications require a bridge between object-oriented architectures. For information on this topic, see the NonStop DOM Reference Guide
The components of a hypothetical application could use NonStop DOM and other CORBA implementations. The term local objects can signify any kind of object class supported by the system, for example, a proprietary C++ object class. CORBA objects are objects that comply with the CORBA standards and are accessible to remote clients. NonStop DOM objects are CORBA-compliant objects that you create with NonStop DOM.
To create an application, you need to do the following:
- Define new object classes and create new class libraries and frameworks, or modify existing ones to suit your application.
- Create the client programs.
- Create the server programs. To create a NonStop DOM server, link object implementations. The same program can be both a client and a server.
Object-Oriented Design Methodologies
Tandem does not recommend a specific object-oriented design methodology except to suggest that you choose an approach oriented to distributed, standards-based computing.
Sometimes it is possible to adapt an existing methodology to a distributed environment. For example, a design methodology 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 DOM 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 server process.
What You Need to Know
Subtopics discussed in this section:
The issues for designing an application depend on the type of component you are implementing. In general, object class and server design are closely linked, whereas a client is concerned primarily with the interfaces of classes it will use.
Designing Object Classes
To design object classes, you must consider issues such as:
- Reuse. How to reuse existing software whenever possible by deriving new classes from existing classes.
- Granularity. How to design methods and data to limit the number of interactions among distributed components.
- Parallelism. How to provide for stateless requests when possible and stateful requests when necessary. In stateless processing, a series of method invocations for the same object can result in requests to different processes in a server pool. In stateful processing, requests for the same object are handled by the same server process, allowing the server to treat the requests as a series and to coordinate concurrent access to the same object by different clients.
- Service Packaging. Whether to provide a new service as a class library or a framework. A user program calls classes in a class library; a framework calls the user program for application-specific processing.
- Concurrency. Whether multiple instances of a class 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; for example, a relational database.
- Transaction Management. How to manage concurrent transactions, especially if a class uses external frameworks or services to perform transactions. (A class that has this responsibility is a client of the Object Transaction Service.)
- Factory and Control Objects. Whether to define classes to control the activities of other classes, 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 instrumentation for troubleshooting.
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:
- Partitioning. Which object classes to load into the same server for best performance. NonStop DOM differs from some other ORB implementations in that you decide in advance which object classes can run in a server. The set of objects that actually run in the server is determined at runtime in response to client requests.
- Object References. How to tailor the construction of object references—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.
- Parallelism. Whether the server requires threads or 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 creation and invocation, you can ensure that the same code will work, regardless of where the object is.
- Static or Dynamic Invocation. For example, whether the client will use a predictable set of object classes or might find out about new classes at runtime.
- Object Lifecycle. Issues such as creating, locating, and releasing objects, including how to use the Name Service.
- Server Selection. For example, whether to request a specific server or use any server that can host a class.
- Server Pools. Implications of the use of server pools and whether the use of server pools must be transparent to the application.
- Transaction Management. Whether a client or an object has responsibility for managing nested transactions.
- Concurrency. Whether clients or an object must coordinate concurrent access to data.
- Interoperability. For example, ensuring that a client developed on some other platform can interact with NonStop DOM servers.
- Parallelism. Whether the client requires threads.
Background Topics
To design an application or component, you must understand the following topics:
- General principles of object-oriented design.
- Object features such as inheritance, object-reference styles, and predefined classes and frameworks.
- CORBA and related service definitions, if your components must interoperate with other CORBA-compliant systems.
You must also understand the following features of NonStop DOM and other Tandem products:
- Advantages and implications of using NonStop TS/MP server pools.
- NonStop DOM support for stateless and stateful request processing.
- Interfaces and functionality of the threads package (and features NonStop DOM application should not use) if your application requires threads.
- Interface differences between some other CORBA environment and NonStop DOM if your application has components on multiple platforms or if you are modifying an existing application to use NonStop DOM.
- Features and advantages of Tandem database products.