An Overview of NonStop DOM
The NonStop DOM Framework
The NonStop DOM Object Request Broker (ORB)
NonStop DOM CORBAservices
NonStop TS/MP Process Management
The NonStop DOM Framework Databases
NonStop DOM Transport Protocols
The NonStop DOM product consists of the NonStop Kernel system processes that make up the CORBA-compliant Object Request Broker (ORB), several CORBAservices, an application development environment, and several specialized tools and utilities.
With NonStop DOM, you use the C++ programming language to write CORBA-compliant client applications and application servers. Your NonStop DOM clients and servers run on the Tandem NonStop Kernel and can interoperate with each other or with other CORBA-compliant applications across a heterogeneous network. Using the Internet InterORB Protocol (IIOP), remote CORBA-compliant clients can use the internet to communicate with NonStop DOM application servers.
As the foundation of the ORB, the NonStop DOM system implements the system processes that make up the CORBA-compliant ORB and CORBAservices. The NonStop DOM system implements these processes as server pools running under a Tandem process management product, NonStop TS/MP. A single NonStop TS/MP monitor process manages all NonStop DOM system processes. These processes include the Object Management Group (OMG) specified services, such as the Naming Service and Event Service.
NonStop DOM applications consist of client and server applications that use the NonStop DOM system for their inter-ORB communications. Like the NonStop DOM system processes, it is recommended that you configure your NonStop DOM application servers to run under NonStop TS/MP processes. For performance issues and managability, the NonStop TS/MP processes supporting your application servers should be different than the one running the NonStop DOM system.
The NonStop DOM application development tools consists primarily of the Interface Definition Language (IDL) compiler and the Shared Runtime Library (SRL). Supplimentary tools let you browse and administer the Naming Service database, administer and maintain the NonStop DOM configuration database, and monitor the Event channel.
The NonStop DOM system implements a CORBA 2.0-compliant ORB that uses the high-level layout used by all OMG ORBs, as presented in Figure 1.
Figure 1. common Object Request Broker Architecture (CORBA)
Figure 1 shows how client programs communicate with the application servers (labeled as the "Object Implementation" in the figure) across the ORB via the Static Invocation Interface (SII) or the Dynamic Invocation Interface (DII). The ORB marshals the client requests and demarshals them on the server side. On the server side, the ORB uses the Portable Object Adapter (POA) to route requests to the appropriate application server.
Figure 2 illustrates how the NonStop DOM system connects clients and servers. The figure shows that clients can be either local or remote to the system running the NonStop DOM system. Detailed in the figure are the major components comprised by the NonStop DOM system: the Comm Server, the Location Service Daemon, the Naming Service, and the Event Service. NonStop DOM application servers (the servers you write in C++) can be implemented either as NonStop TS/MP server pools or as stand-alone server processes.
Figure 2. NonStop DOM Framework Details
The NonStop DOM system uses specialized communication components to provide the communication between application clients and object servers. These communication components are the Comm Server and Location Service Daemon (LSD) processes.
As a CORBA-compliant ORB, the NonStop DOM system can communicate across heterogeneous networks. In addition, the NonStop DOM system implements other OMG services, such as the Naming Service, Event Service, and Transaction Service. Both application clients and object servers can use these CORBAservices.
Communication across the NonStop DOM ORB is supported by the following NonStop DOM system processes:
These components ensure delivery of requests and responses to the appropriate object or client. They also provide for the reuse of connection resources, allow access to objects, and provide an infrastructure that uses and manages the system-specific communications.
The section Establishing Connections details how these components handle the connection between the clients and application servers.
Note: These NonStop DOM system processes are transparent to the client and server interactions. CORBA 2.0-compliant clients make requests to the NonStop DOM application servers, just as they would with any other CORBA-compliant ORB; use of the LSD and the Comm Servers is completely hidden from users of the ORB and developers of NonStop DOM applications.
The Location Service Daemon (LSD) serves dual functions. First, it acts as a well-known entry point for initial external client connections and second, it load balances (or maps) external clients to the Comm Servers. The LSD works hand in hand with NonStop DOM Comm Servers to assign servers to client requests.
When a remote client requests a connection to a NonStop DOM application server, the request first goes to the LSD, which returns the TCP/IP address and port of the least busy Comm Server. The Comm Server then provides routing for requests and responses between the client and the NonStop DOM application server.
To help the LSD select a Comm Server, a database (called CSMAP) stores the associations between remote client hosts and Comm Server processes.
The LSD checks the CSMAP and returns a server address that the client can then use to access the NonStop DOM system. The location is a TCP/IP address and port number pair, and usually points to the location of a Comm Server. From that point on, the Comm Server provides the routing for requests and responses between the client and the NonStop DOM application servers.
To determine which Comm Server handles the client requests, the LSD reviews the CSMAP to determine whether the remote client's host has been mapped to a configured Comm Server process. If the LSD finds an association, the address information for that Comm Server is handed back. If the remote client's host is not registered in the CSMAP, the LSD reviews the Comm Servers configured for dynamic assignments and, from this group, selects a Comm Server based on the currently assigned loads. The LSD then returns the TCP/IP address and port number of that Comm Server.
The TCP/IP address for the LSD is also registered in the configuration database. This address is the initial contact point for clients making requests through the NonStop DOM ORB.
The NonStop DOM Comm Server is a router that allows remote clients to communicate with NonStop DOM servers. NonStop DOM uses one or more Comm Server to route communications between remote CORBA clients and local NonStop DOM application server processes. This allows a client to use a single port for access to any number of application servers.
On some ORB platforms, a client must use a separate port number for each server to which it connects. This behavior can dramatically restrict the number of remote clients that can connect to the ORB at any one time.
With the NonStop DOM system, the Comm Server allows a remote client to connect to a single Comm Server process through which it can access any NonStop DOM application server on the system. Using a Comm Server, rather than making each client directly connect to each application server, greatly improves system performance by reducing network resource consumption. Without a Comm Server to direct communications, performance can be adversely affected when a large number of clients request server resources.
By using Comm Servers in conjunction with NonStop TS/MP, the remote client can maintain a single port-level network connection (with the Comm Server) while NonStop TS/MP provides load balancing across the application-server processes configured as server pools. Although a single Comm Server process will handle many remote clients simultaneously, you can also configure additional Comm Server processes as application loads increase.
In addition to routing remote client requests, the Comm Server also maps local client requests to remote servers. When a local NonStop DOM client attempts to access a remote NonStop DOM server (or any other CORBA-compliant server), the Comm Server transparently maps these requests from the Tandem file-system protocol to the CORBA IIOP protocol.
The communication components of the NonStop DOM system (the LSD and Comm Server) provide connections between client requests and the application servers that handle the requests. Using the CSMAP, the NonStop DOM system ensures that the least busy application server receives the client request.
The address of the LSD is "well known," meaning that the Naming Service publishes the TCP/IP address of the LSD so that clients can interface directly with this component. With this, the LSD is the initial contact point for all clients making requests of the services and objects available through NonStop DOM.
The role of the LSD is to appropriately route client requests. Depending on the type of request, the LSD will assign it to either a Comm Server or directly to an application server. Connecting to a Comm Server enables the NonStop DOM system to take advantage of application servers configured as NonStop TS/MP server pools.
By examining the object key of the request, the LSD determines if the request is transient or persistent. A transient request can be handled via a direct TCP server. If the NonStop DOM system contains an available direct TCP server, the LSD returns the TCP/IP address of that server. The client can then communicate directly with that server for the duration of the request. (If there is no available direct TCP server, the LSD routes the request to an available Comm Server.) If the request is persistent, the LSD hands back the TCP/IP address of the Comm Server that will handle the client's request.
To determine application server and Comm Server availability, the LSD uses the CSMAP tables contained in the configuration database. These are the load_table and the map_table. Determining the availability of direct TCP servers is straightforward: the LSD first checks the map_table to see if such a server is configured in the NonStop DOM system. If a direct TCP server exists, then the load_table is checked to see the availability of that server. The process repeats itself until either a direct TCP server can be assigned or until the LSD determines that a Comm Server must be assigned to handle the request.
The process is similar for establishing communications for persistent requests: the LSD checks the map_table and load_table to determine which Comm Server can best handle the request. Once a Comm Server is found, that server will then handle all the remaining requests made by that client.
When resolving a persistent request, the LSD looks first in the map_table to see if the client's TCP/IP address has already been assigned to a Comm Server. If the client has an assigned Comm Server, the LSD returns the TCP/IP address of the Comm Server, which the client can use for the duration of the request.
If the map_table does not list a Comm Server associated with the client, the LSD uses the load_table to assign a Comm Server to the request. The LSD selects a Comm Server based on the current load using a round-robin algorithm to cycle through the configured Comm Servers. The selected Comm Server is then associated with the client in the map_table so that future client requests will resolve appropriately.
In large systems with several Comm Servers configured, you can deterministically route a client to specific Comm Server by using the Configuration Tool to directly add the client and Comm Server association to the map_table. While this is an advanced technique, it is available if you have tasks that need special attention.
NonStop DOM 2.0 implements the following CORBAservices in this release:
More services will be made available in upcoming releases.
The NonStop DOM Naming Service is a full implementation of the OMG COS CORBA Naming Service specification and is fully CORBA 2.0 compliant. The Naming Service provides a repository for the names and locations of NonStop DOM application objects.
The Naming Service enables developers to register object names at runtime. In the Naming Service database, naming contexts and their associated object references are organized into a hierarchical namespace. Client applications can then use the Naming Service to discover the names and object references for objects they wish to use by traversing the naming context hierarchy.
The NonStop DOM Naming Service is fully and transparently integrated with Tandem's Transactional Services and Transactional Management. This makes the Naming Service fully scalable, reliable, and performance oriented.
The Naming Service consists of the Naming Server executable program (deployed as a server pool) and its respective Naming Service database. The Naming Server maintains the naming database with key-sequenced Enscribe files. Applications can bind names to objects and retrieve them using the CORBA-defined object interface to the Naming Service.
The NonStop DOM Event Service is a full implementation of the OMG CORBA Events Service specification and is fully CORBA 2.0 compliant. The Event Service provides asynchronous communication among CORBA objects.
The Event Service allows "supplier objects" to communicate via an event channel, notifying any number of "consumer objects" when events they "subscribe" to take place. The NonStop DOM Event Service is fully and transparently integrated with Tandem's Transactional Services and Transactional Management. This makes the Event Service fully scalable, reliable, and performance oriented.
The Event Service consists of the Event Server executable, and is also deployed as a server pool. The Event server maintains its database using key-sequenced Enscribe files. Applications create objects on the Event Server using the CORBA-defined object interfaces to the Event Service.
NonStop DOM provides the OMG-specified Transaction Service as an add-on product. Implemented as the Object Transaction Service (OTS), it is an object-oriented transaction processing system. Utilizing Tandem's proven highly scalable and reliable large-scale transactional management and services infrastructure, application providers can deliver reliable objects that fully support the ACID properties of a transaction service.
The NonStop DOM system processes (such as the LSD, Comm Server, Naming Server, and Event Server) are deployed as server pools running NonStop Transaction Services/MP (NonStop TS/MP). NonStop TS/MP processes provide scalability and fault tolerance.
A single NonStop TS/MP monitor process manages all NonStop DOM system processes. Configuring the NonStop DOM system processes as NonStop TS/MP server pools provides significant benefits, as NonStop TS/MP:
ABEND or a CPU failure occurs.
Tandem strongly recommends that you also configure any production NonStop DOM application server processes running on the Tandem NonStop Kernel as NonStop TS/MP server pools. In addition to the benefits that NonStop TS/MP provides for the NonStop DOM system processes, it provides the following benefits for application server processes:
NonStop TS/MP server pools increase the throughput of your application servers. Each process in a server pool runs the same application logic. When defining a server pool in your NonStop TS/MP configuration, you can either set the number of processes or specify a maximum number of processes and let NonStop TS/MP start and stop processes. Letting NonStop TS/MP monitor processes allows it to balance the work load.
Note: When referencing the NonStop TS/MP documentation, you will see that they use the term "server class" to denote what this documentation set terms a "server pool."
NonStop DOM system uses the following system databases:
All the databases are implemented using key-sequenced Enscribe files.
The configuration database contains the settings for the different NonStop DOM system components. These settings are initialized when you run the initialization script. The configuration database also contains the two tables CSMAP@load_table and CSMAP@map_table. The Location Service Daemon (LSD) uses these tables to store and resolve the locations of the of the servers that handle client requests.
The Interface Repository (IR) is a set of files that contain definitions of object interfaces hosted on your NonStop DOM application servers. Information in the IR can be used by clients that access servers using the Dynamic Invocation Interface (DII), as defined by the CORBA 2.0 specifications.
You access the IR database programmatically through the interface defined in the CORBA Interface Repository specification.
The Naming Server maintains the Naming Service database, stores associations between user-defined names and their respective objects.
The initial database is created when the NonStop DOM system administrator executes the configure script.
Transport protocols are the underlying communication protocols used by the NonStop DOM system to transmit requests and replies between clients and servers. Clients and servers must support at least one common protocol if they wish to communicate with each other.
The NonStop DOM system supports three communication protocols with the Comm Server. Each of the three predefined transport components supports a different protocol:
A server can support any combination of these protocols:
See Scaling Application Servers for details on setting up the protocols for your NonStop DOM application servers.
All IIOP messaging uses TCP/IP as the underlying protocol. Thus, remote clients must use TCP/IP to access objects hosted on NonStop DOM server processes. TCP/IP can be used in combination with both the Pathway and file-system protocols.
NonStop DOM application servers can use TCP/IP either with or without the services of the NonStop DOM Comm Server. If the server is configured to use the Comm Server, the application server communicates with the Comm Server using either the file-system protocol or the Pathway protocol.
If the Comm Server is not used, remote clients must communicate directly with the NonStop DOM servers. For this type of access, your NonStop DOM servers must be configured to use TCP/IP.
If your NonStop DOM server also supports the Pathway or file-system protocols, local clients can communicate with the server using one of those protocols. Comm Servers do not play a role in such a scenario.
If a Tandem client needs to access a remote IIOP-compliant application server, the client must use TCP/IP (IIOP) to establish communication. In this scenario, the Comm Server is not used.
NonStop DOM complies with CORBA 2.0 in its use of IIOP and TCP/IP for network communications. Tandem NonStop TCP/IP can use any of the following underlying communication protocols:
Tandem strongly recommends configuring your production servers with the Pathway protocol (NonStop TS/MP) because it leverages the features of process management, process persistence, load balancing, and scalability.
A server that supports NonStop TS/MP can be configured as either a stand-alone process or as a process within a server pool. (A server pool is a group of processes within a NonStop TS/MP environment.) In either case, client messages and server replies are sent using NonStop TS/MP interprocess communication (IPC).
NonStop TS/MP is a protocol internal to NonStop DOM; all inter-ORB communication can use this NonStop DOM protocol. However, all heterogeneous ORB communication must still take place via the TCP/IP protocol used by IIOP.
A server that supports only the file-system protocol can be implemented only as a single-named process–it cannot be incorporated into a server pool. The NonStop DOM system manages client access to file-system servers using interprocess communication (IPC).
Clients must use the file-system protocol to talk to a server that supports only this protocol.