Why NonStop DOM
Differentiating Features of NonStop DOM
Major Features and Functionally
NonStop Distributed Object Manager/MP (NonStop DOM) provides an infrastructure and development environment that enables you to develop distributed-object applications and components that run on the Tandem NonStop Kernel. The NonStop DOM infrastructure provides the services and tools to help software developers build object-oriented components and distributed-object systems using the C++ programming language. These systems can be implemented at the application level, the system level, or as middleware software.
NonStop DOM 2.0 is an implementation of the common Object Request Broker Architecture (CORBA) defined and promoted by the Object Management Group (OMG). Because NonStop DOM 2.0 complies with CORBA 2.0, as defined by the OMG, application clients and components you develop with NonStop DOM can interoperate with other CORBA-compliant servers running on different platforms.
This topic discusses the advantages and practical challenges of distributed object computing and shows how NonStop DOM and its underlying technologies meet these challenges.
NonStop DOM is an industrial-strength implementation of OMG's Object Management Architecture (OMA) that can be used in large scale, enterprise wide, mission critical systems.
The NonStop DOM system architecture combines the flexibility of object technology with the robustness of a transaction processing monitor. This unique combination provides the availability and scalability required for mission-critical applications. In addition, NonStop DOM ensures the integrity of its own data stores and offers an object transaction service you can use to maintain a secure environment for your applications.
NonStop DOM gives you a CORBA 2.0-compliant object-oriented development system that provides differentiation in the areas of scalability, availability, and data integrity (transaction protection). With tight integration between Tandem's transaction services and transaction monitors, NonStop DOM contains the true functionality of an object transaction monitor.
Scalability allows a system to grow dynamically as usage increases. NonStop DOM provides scalability in the following dimensions:
Optimized for use in transaction processing, NonStop DOM allows the mapping of a large number of clients to a smaller number of servers, effectively sharing resources. Because the NonStop DOM system processes run in a NonStop TS/MP environment, you get the strength of Tandem's transaction services (for process management, availability, and load balancing) in a CORBA-compliant environment.
NonStop DOM is compliant with the CORBA 2.0 specification [96-03-04] of the Object Management Group (OMG). Being CORBA-compliant means that NonStop DOM interoperates with other CORBA-compliant Object Request Brokers (ORBs). By using the Internet InterORB Protocol (IIOP) defined by CORBA, NonStop DOM can interoperate with other heterogeneous OMA-based environments that comply with the CORBA IIOP protocol.
Also noteworthy, NonStop DOM is language-compliant and object-adapter compliant with the OMG's CORBA 2.1 ORB Portability specification [97-05-15], which enhances the interoperability of the components you write with NonStop DOM.
Writing client and server objects compliant with CORBA 2.0 offers the following benefits:
By implementing certain system-specific processes using NonStop TS/MP server pools, the ORB provided with NonStop DOM offers availability and scalability advantages over other CORBA-compliant ORBs. NonStop TS/MP runtime code resides in every ORB running NonStop DOM and can also be included into your NonStop DOM application servers.
The NonStop DOM ORB runs on Tandem NonStop Kernel systems. The NonStop DOM application servers that you write in C++ use this ORB for communications to and from remote clients. The major features differentiating the ORB supplied with NonStop DOM from other ORBs are:
With NonStop DOM, you can increase the ORB capacity without disturbing running applications. NonStop DOM provides several ways of scaling the ORB itself:
You can increase the number of remote clients connected to the NonStop DOM ORB without requiring configuration changes on either the client workstation or the NonStop DOM system. When a remote client first makes a connection to the ORB, the NonStop DOM system transparently assigns an existing port number to the client.
In practice, a single Comm Server can handle up to hundreds of clients, and a TCP/IP process can handle up to hundreds of Comm Servers.
NonStop DOM allows the scalability of application server processes by supporting the use of NonStop TS/MP server pools. A NonStop TS/MP server pool consists of multiple processes (CPU resources) that implement the same application logic. NonStop TS/MP provides load balancing, dividing requests among the servers in the pool.
A client program need not be aware of whether an object class is running in a server pool or an individual server process. In fact, the same server program can normally run in either mode; you specify the preferred mode in a configuration file for each server. (Tandem recommends the use of server pools to provide availability, autorestart, scalability, and load balancing.)
NonStop DOM provides source code portability for applications that comply with the CORBA 2.0 and the OMG portability specifications. Most of the Tandem differentiated features, such as scalability, are transparently available; application servers ported to the Tandem system do not need to change in order to exploit the scalability of NonStop DOM.
To support continuous availability, an object-oriented runtime environment must provide fault tolerance on the following three levels:
The NonStop DOM system provides the first level of fault tolerance by running on the NonStop Kernel, which offers such features as NonStop process pairs, mirrored disk controllers, and fault-tolerant communications subsystems.
The ORB supports fault tolerance by using NonStop Transaction Services/MP (NonStop TS/MP) as a process manager for ORB processes. NonStop TS/MP provides automatic restart when a server process fails. Automatic restart is also available to application components that use NonStop TS/MP server pools.
NonStop DOM provides application transaction protection and data integrity by means of the Object Transaction Service (OTS) add-on package. OTS offers transaction protection for data stores managed by the NonStop DOM ORB. Specifically, OTS protects the data stores in the Naming Service and the Implementation Repository databases, which contain ORB configuration information.
The NonStop DOM OTS uses NonStop TM/MP as the underlying mechanism for transaction protection. This ensures transaction protection and data integrity in line with Tandem fundamentals.
You can use the OTS to protect your application-specific data when either the application itself needs transaction protection or when the client implementation has requested transaction protection.
The NonStop DOM system provides network session concentration to reduce the number of TCP/IP ports needed by the host. NonStop DOM provides network session concentration with the use of Comm Servers. Comm Servers are NonStop DOM system components that manage the linkages between remote clients and local servers. Comm Servers use the following protocols:
NonStop DOM is based on the CORBA Object Model as defined in CORBA 2.0 specifications . The NonStop DOM implements the following features in a CORBA-compliant ORB:
Internet InterORB Protocol (IIOP) is the standard protocol that different ORBs must use to communicate across the Internet. This protocol is standardized by the OMG. With IIOP compliance, objects that you write in NonStop DOM can be used by other ORBs and clients, and NonStop DOM clients can use the objects located on other IIOP-compliant ORBs.
The NonStop DOM IDL compiler (NSDIDL) conforms with the CORBA 2.0 and Portable Object Adapter (POA) specifications defined by the OMG. The compiler generates stubs and skeletons for use by client and server objects, respectively.
NSDIDL supports OMG standard C++ language bindings, as defined in the OMG CORBA and POA specifications.
The NonStop DOM Portable Object Adapter (POA), defined in the CORBA 2.1 portability specification, replaces the Basic Object Adapter (BOA) defined in CORBA 2.0. An Object Adapter is the primary way that an object implementation accesses services provided by an ORB.
The NonStop DOM POA:
Application programmers upgrading from the BOA to the POA can rethink design issues because they will probably need to alter their application interfaces to make use of the POA. However, basic BOA usage can easily be mapped to basic POA usage.
The NonStop DOM supports the Static Invocation Interface (SII).
The Naming Service provides for the binding of human-readable object names to NonStop DOM objects, and the resolving of these named objects in client requests. NonStop DOM Naming Service strictly adheres to the CORBA 2.0 specification. The Naming Service database in NonStop DOM is implemented as a structured Enscribe file.
The Event Service allows for decoupled communication between suppliers and consumers of events through the use of an event channel. Suppliers and consumers register with the event channel. At registration the supplier/consumer indicates either the push or pull model. When the push model is used, the supplier initiates the transfer of the event. For the pull model, the consumer requests the event transfer. NonStop DOM supports both the generic and the typed communication models.
All server pools and system infrastructure in the NonStop DOM provide user-configurable error logging, tracing, and event channel messaging. Application programmers may instrument objects that take advantage of these debugging features.
NonStop DOM also supplies an IDL interface to the Error Logging facility, thus allowing the developer to log application specific information.
Legacy wrapping is never an easy task. Many times, the legacy itself requires modification. However, Tandem's supplied set of generic legacy wrappers act as an integration framework for your legacy. This means no modification of your legacy is required, and your legacy can interoperate transparently with existing CORBA objects and components.