HP NonStop CORBA 2.6.1 Programmer's Guide for Java HP NonStop CORBA 2.6.1 Programmer's Guide for Java Part number: 525937–007. Published July 2011. Legal Notice Abstract This manual provides information for application programmers about writing applications for HP NonStop™ CORBA® 2.6.1 in Java. The information provided focuses on the NonStop CORBA-specific implementation of the Object Management Group's CORBA standards. Product Version: HP NonStop™ CORBA® 2.6.
IDL Compiler Syntax 4. Deploying a NonStop CORBA Application 5.
Using Stateless Factory Objects to Create Stateful Servants Adjusting TS/MP Configuration Parameters Using Parallel Library TCP/IP Increasing the Number of Comm Server Processes Using Multiple Instances of NonStop TCP/IP Using Multithreaded Servers 7. Managing Transactions Components of Transaction Service Implementation Use of TMF Transaction Service Features Not Supported in NonStop CORBA TransactionalObject Interface Checked Transaction Behavior Transaction Branches and the Diamond Access Problem 8.
Naming Service Calls ORB_init (flow 1 in the figure) Naming Service Creates and Publishes Root Naming Context IOR URL (flow 2 in the figure) Network Client Imports IOR (flow 3 in the figure) Network Client ORB Tries to Contact Target Object (flow 4 in the figure) LSD Builds and Sends Forwarding Reply (flows 5 and 6 in the figure) Client ORB Tries Again (flows 6 and 7 in the figure) Comm Server Receives and Relays Request (flows 7 and 8 in the figure) Naming Service Processes Request (flows 8 and 9 in the fi
New and Changed Information New and Changed Information This edition of the HP NonStop CORBA 2.6.1 Programmer's Guide for Java includes: In Chapter 2, subsection profile@ORB Server Transport Protocols is updated. In Appendix B, subsection IOP::TAG_INTERNET_IOP_Addresses is updated. In Appendix B, subsection Configured Versus Actual TCP/IP and TCP/IPv6 Addresses is updated. This edition of the HP NonStop CORBA 2.6.1 Programmer's Guide for Java includes: In Chapter 5.
© Copyright 2006 and 2011 Hewlett-Packard Development Company L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice.
About This Guide About This Guide Who Should Read This Guide Organization of this Guide Manuals in the NonStop CORBA Set Notation Conventions This NonStop CORBA 2.6.1 Programmer's Guide for Java provides information about designing and implementing application programs for the NonStop CORBA 2.6.1 environment. The guide explains how to take advantage of the specific implementation features of NonStop CORBA.
Manuals in the NonStop CORBA Set The NonStop CORBA 2.6.1 Getting Started Guide for C++ describes how to install the product and verify installation. It also includes an introduction to the C++ product. The NonStop CORBA 2.6.1 Getting Started Guide for Java describes how to install the product and verify installation. It also includes an introduction to the Java product. The NonStop CORBA 2.6.
"s-char..." - A dash in a command usually indicates a separate flag. "" When quotation marks surround a defined syntax symbol (such as a bracket or brace), they symbolize an actual character that must be entered as shown. For example: Other punctuation Punctuation not previously described (such as parentheses, commas, and semicolons) must be entered as shown. For example: "[" repetition -constant-list "]" error := NEXTFILENAME ( file-name ) ; LISTOPENS SU $process-name.
Chapter 1. Introduction to NonStop CORBA Programming Chapter 1. Introduction to NonStop CORBA Programming Before You Begin Design Activities Sample Programs Introduction to NonStop CORBA Components NonStop CORBA Programming Environments NonStop CORBA 2.6.1 is an implementation of the Common Object Request Broker Architecture (CORBA) defined and promoted by the Object Management Group (OMG). Because NonStop CORBA 2.6.1 is based on CORBA 2.6.
Make decisions about server implementation. Design or modify clients to take advantage of new features. To create an application, you have to: 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.
A "pull" consumer that requests events from the event channel as it requires them ins Illustrates some of the basic concepts of Interoperable Naming Service programming with NonStop CORBA. The ins sample shows you: A server that publishes its reference as an IOR URL through the Naming Service A client that uses orb. string_to_object to transform a URL to an object reference A client that uses jpathsend orb.
An object interface definition written in IDL (without the operations) A server that implements a dynamic interface A client application that makes use of the dynamic interface The portability of Java CORBA applications across JORB Lite, NonStop CORBA (C++ and Java), and other ORBs Interoperability between JORB Lite, NonStop CORBA (C++ and Java), and other ORBs Introduction to NonStop CORBA Components You will work with several NonStop CORBA components as you design and write your applications, including:
configuration tool. For some application-specific configuration settings you also use a command-line interface as described later in this manual. For more information about the NonStop CORBA architecture, see Architectural Walkthrough in this guide and the architecture section of the NonStop CORBA 2.6.1 Administration Guide. NonStop CORBA Programming Environments You can develop applications on the NonStop system directly.
Chapter 2. NonStop CORBA Administrative Environment Chapter 2. NonStop CORBA Administrative Environment Working in the Open System Services (OSS) Development Environment Using Guardian Commands and Files Through OSS OSS Environment Variables and the env.
The OSS run command lets you run a process with specific attributes. For example, you could use the following syntax to run a named process: run -name=Guardian-process-name program-name For example, run -name=/G/svr Test_DII_SVR -ORBprofile tcp_sample_svr In this example, svr is an arbitrary process name. tcp_sample_svr is passed when org.omg.CORBA.ORB.init() is called. OSS Environment Variables and the env.sh File A shell implements environment variables that you can set and display.
Business domains are collections of related business application processes, configuration data, and NonStop services for CORBA. You can identify the business domains by using the Console. The NSDAdminServer process provides services that are independent of any security domain, such as system configuration information. The NSDEnvironServer process provides services for a specific security domain. The $NSD_ROOT/etc/env.sh file contains the environment settings.
CORBA application by using the flag. The improves handling of marshalled typecode indirections (which NonStop CORBA encodes by default). flag If no -ORBprofile argument is passed in the run command to a NonStop CORBA application, the default@ORB entity is used. This entity acts as a subsystem configuration domain for any settings not found in an application's profile@ORB entity.
false. The default is false. Since the default is false, you must set this configuration value when you want NonStop CORBA to allow wchar and wstring to be transmitted over GIOP 1.0. Many vendors, including NonStop CORBA 2.3 B13, allow wchar and wstring to be transmitted over GIOP 1.0. NonStop CORBA also allows wchar and wstring to be transmitted over GIOP 1.0. If the allow_wchar_wstring_in_1_0 key value is set to false, marshalling exceptions are thrown when GIOP 1.0 is in effect.
Chapter 3. Compiling and Building an Application Chapter 3.
1. Define the CORBA object's interface in a CORBA Interface Definition Language (IDL) file. 2. Compile the IDL file using the NonStop CORBA IDL compiler. Compiling the IDL file generates the files specified in the CORBA IDL to Java Language Mapping specification. For an interface IFace , the following Java source files would be generated: IFace.java — signature interface IFaceOperations.java — operations interface (also contains signatures) IFaceHelper.java — marshaling and Any support, etc.
1. Ensure that the $NSD_ROOT/etc/env.sh file was sourced into the OSS shell environment. 2. Run the NonStop CORBA IDL compiler on all your IDL files to produce client stub files and server skeleton files (see Using the IDL Compiler for more information): nsdidl -language java *.idl Note: Do not modify the compiler-generated files. 3. Write the client program, server program, and object implementation. 4. Compile all the source code files, including generated ones, using javac to produce class files.
IDL Compiler Syntax nsdidl Compiler Syntax The following line is the command-line syntax for running the IDL compiler. The IDL compiler is invoked with the -language Java option to generate Java code. You can display help text by using the -? option. For example, to invoke the compiler to generate Java bindings, type the following command: nsdidl -language Java idlfile1[, idlfile2 ]... Preprocessor Options -D name Define name as -D name=definition a macro, with definition '1' .
Chapter 2. NonStop CORBA Administrative Environment Chapter 4.
Chapter 4. Deploying a NonStop CORBA Application Chapter 4. Deploying a NonStop CORBA Application The general steps to consider in deploying a NonStop CORBA application after you have compiled your files are: Check that you have set up your application profile as described in Application Profiles: Configuring and Managing an Application. Use the Console to make sure that any other subsystem configuration profile settings are correct. Decide whether you want to enable tracing.
esac done shift $(($OPTIND - 1)) print "Configuring $SERVER_CLASS" # Set G_HOMETERM to the terminal identifier on which standard # output is displayed. # When HOMETERM env variable is set the script used to fail. # The format of the HOMETERM set will be checked for $., # if it is not of the required format then it will use the default # HOMETERM set using who -m command DEFAULT=$(echo $HOMETERM | awk -F ".
[ Set TIMEOUT to a sensible value; this sets how long a SEND through the [ LINKMON will be allowed to be outstanding. set server createdelay 1 secs set server deletedelay 15 secs set server TIMEOUT 10 SECS set server MAXLINKS 16 set server LINKDEPTH 1 set server maxservers 6 set server numstatic 1 set server cpus (0,1,2,3) set server tmf on, AUTORESTART 0 add server $SERVER_CLASS start server $SERVER_CLASS eof Chapter 3. Compiling and Building an Application Chapter 5.
Chapter 5. Tracing and Debugging Applications Chapter 5.
System exceptions raised by the NonStop CORBA run-time environment, reported to the client program. Other exceptions, raised by object classes, reported to the client program. Run-time errors logged as text in a specified log file, displayed on the standard output device, STDERR , or sent to the Event Management Service (EMS). Generally, the log file contains information about unexpected error conditions encountered by the NonStop CORBA run-time.
Field Description Field Name Date and time the exception was logged No field name Error number for this entry No field name Text description of the exception No field name Severity level of the exception Severity Name of the component that logged the error Component Name of the process that logged the error PName Process ID of the process that logged the error PId Thread ID of the thread that logged the error TId Exception type (not all log messages are associated with an exception) ExcptT
To start an alternate collector for the NonStop CORBA Software Developer Kit (SDK) environment, you enter the following commands at the TACL prompt: > EMSACOLL /NAME $xxx, NOWAIT/ BLOCKING OFF For more information about starting the EMS collector, see the EMS Manual. Note: The variable $xxx is the process name for the collector that you set using file or in log_file in the default@ORB entity in the configuration database. MY_COLLECTOR in the $NSD_ROOT/etc/env.
/* Set component ID */ set_component_name(java.lang.String pp_comp_name) /* Set log file name */ set_log_file_name(java.lang.String pp_file_name) Component Names Each NonStop CORBA component should be assigned a unique component name so NonStop CORBA can identify the process that is logging the error message. Component names are assigned once for each process, which must be done before an error message can be logged.
"Error writing to CustDB"); ... } How the Error Logging Facility Works The public API section of the error logging facility is based on the severity levels of the messages you log: Critical, Error, Warning, or Informational. These severity levels are reflected in the methods defined in the com.tandem.nsdom.Config.Config_Log class , as shown in the following code. //com.tandem.nsdom.Config.Config_Log Class public class Config_Log extends java.lang.Object { public static void log_critical(java.lang.
Console or by using the cfgmgt tool. Information Collected in a Trace Each time a trace message is generated, the trace facility writes the following information to the trace file: Trace message date and time Process name and process ID that produced the trace message Thread ID Trace data provided by you Although most of this information is provided by the system, you must supply a specific trace message. This message helps to determine where in the code the trace message was generated.
Set the environment variables before starting the processes by using an export statement. Note: To enable tracing for SSL, the JSSE javax.net.debug property is used. For example, java -Djavax.net.debug=ssl Server -ORBprofile java_ssl_server Tracing starts at process initialization, so you need to start or restart the process you want to trace after you have enabled tracing. You can use the Console to start and stop NonStop CORBA subsystem processes, or you can use Guardian or PATHCOM commands.
Calling the Trace Facility To generate a trace message, you call the trace_data or trace() method defined in the com.tandem.nsdom.Config.Config_Trace object. The call must be complete with the required parameter values. The trace facility then creates a trace message and writes the message to an ASCII trace file. The trace file information and other configuration data used by the trace facility must be specified in the NonStop CORBA configuration before the call (see How to Enable Tracing).
Trace Records This section describes the trace records for IIOP/SSL. The trace records are emitted by the SSL server. The SSL version is also included in the trace records. SSL_accept The SSL_accept trace record is emitted by a SSL server and is triggered when a hello message is sent from the client to the server. The accept side of the SSL handshake is traced. The SSL version is included in the trace record.
installation. The showior Tool Syntax showior [-a | -o | -r ] IOR-filename where -a The -a switch is optional and available when you are running showior from C++ or Java. When used, -a specifies that the profile data is to be displayed in an ASCII/hexadecimal-formatted table. The default profile data display is mixed ASCII and hexadecimal where an ASCII character is enclosed within square brackets [ ] and the hexadecimal digit is enclosed within parentheses ( ).
Alternatively, you can specify a file containing an event-channel object reference. This file could, for example, be created by another program that created an event channel. If you use a file-based IOR for the event service, the event channel can be on any accessible system. After you have chosen the event channel to administer, the esadmin tool displays the Event Channel Status window.
Display the Naming Service tree Add a naming context Rename a naming context or name Remove a naming context or name View an object reference Save an object reference An example of the Console view of the Naming Service is shown in Figure 5–3. Figure 5.3. Naming Service Display For more information about using the Console, see the NonStop CORBA 2.6.1 Administration Guide and the online help provided with the Console.
where -ior stringified-NamingContext This option specifies the stringified object reference of a naming context to be used as the base naming context for the requested operation. If this option is not specified, ns_browse uses the root naming context as the base naming context.
Another way is to bind a new context TextCtx1 "" into the TestCtx test context by using the -ior option to specify the TestCtx test naming context as the base naming context for this operation. To do this action, you need the stringified IOR of the TestCtx test context, which is returned by ns_browse when that context is created. ns_browse -ior IOR:004532... bind_new_context TestCtx1 "" 5. Run ns_browse to list the contents of the naming context with name TestCtx test : ns_browse list TestCtx test 6.
At most, one of -i, -w, -r should be specified. If none are specified, "-i" is assumed. At most, one of -t and -d should be specified. When neither is specified all orphaned contexts older than 30 days are candidates for deletion. When -r is specified, the -t and -d options have no effect. Chapter 4. Deploying a NonStop CORBA Application Chapter 6.
Chapter 6. Writing Scalable Applications Chapter 6.
In the POA in the CORBA server application, ensure that the proprietary state policy has a value of STATELESS. You can do this either by setting the lifespan policy to PERSISTENT or by directly setting the state policy to STATELESS. Note: The use of server pools provides a number of other advantages, including availability, automatic load balancing, and process management (allowing the operator to configure, monitor, start, and stop processes).
The Comm Server process relays the first request to the server using the GIOP over TS/MP protocol, and TS/MP selects a server process, within the application server pool, to host a factory object. The factory object creates a stateless worker object and returns the worker's object reference to the Comm Server, which relays the object reference to the client. Subsequent requests from the client are routed through the same Comm Server and sent directly to the same worker object.
When you configure these processes with Parallel Library TCP/IP, up to sixteen Comm Server, LSD, ILSD, or BSD processes running in a server pool can share the same port. When configured this way, the server pool appears as a single IP host to the outside world. A round-robin filter distributes the incoming connections among the communications processes in the pool.
Chapter 7. Managing Transactions Chapter 7.
termination. This means that all other threads must have suspended and that any references to Control , Coordinator , and Terminator object implementations must have been released. Without these checks, some application work might not actually complete within the transaction's boundaries.
Chapter 8. Writing Multithreaded Applications Chapter 8. Writing Multithreaded Applications Overview of Multithreading Multithreading in Client Applications Multithreading in Server Implementations This section describes how to make appropriate threading decisions and write multithreaded NonStop CORBA applications. Java programmers should use standard Java multithreading in NonStop CORBA applications.
With ORB_CTRL_MODEL, the POA initially creates a single thread to handle requests for objects in a server. When a new request arrives, the POA either reuses an existing thread from the thread pool or spawns a new thread (When the thread pool is empty and the maximum number of threads has not been reached) to handle the new request. For a new or reused thread to be activated, the thread processing the original request must have become blocked or have explicitly released control of the processor.
Chapter 9. Designing Advanced Applications Chapter 9.
references are created by an object interface associated with the server. The resolution of issues for object interface design depends on the object references that are created and returned, the strategy for finding and creating object instances, and other aspects of interface design and use.
interface account { readonly attribute string CustomerName; readonly attribute string CustomerAddress; } When this type of object is distributed, the client must send a separate message to read each attribute.
Static invocation or dynamic invocation. For example, whether the client will use a predictable set of object interfaces or might find out about new interfaces at run time. Object lifecycle. Issues such as creating, locating, and releasing objects, including how to use the Naming Service. Server selection. For example, whether to request a specific server or use any server that can host an object interface. Server pools.
Chapter 10. Porting CORBA Applications to NonStop CORBA Chapter 10. Porting CORBA Applications to NonStop CORBA Global State Information Database Access Applications Using Proprietary Features This section describes general considerations for porting CORBA applications from other ORBs to NonStop CORBA 2.6.1. For specific details about the NonStop CORBA implementation that may be useful in porting applications, see the NonStop CORBA 2.6.1 Programmer's Reference.
Chapter 11. Using the IIOP/SSL API Chapter 11. Using the IIOP/SSL API SSLIOP IDL Interface SSLIOP::Current SSLIOP::Current_get_methods SSLIOP::Current::get_peer_certificate() SSLIOP::Current::get_peer_certificate_chain() This section describes the objects used by applications to access IIOP/SSL. Note: Before you begin to use IIOP/SSL you must have installed the IIOP/SSL option for NonStop CORBA. For more information about configuring and managing IIOP/SSL, see the NonStop CORBA 2.6.1 Administration Guide.
const ServiceId SSLIOP = 0x4E534400; // NSDOM specific service id number 0 typedef unsigned long ComponentId; const const const const ComponentId ComponentId ComponentId ComponentId TAG_CIPHER_INFO = 0; TAG_PEER_DN = 1; TAG_PEER_CERT = 2; TAG_PEER_CERT_CHAIN = 3; struct TaggedData { ComponentId tag; sequence data; }; struct CipherInfo { int cipher_bits; string cipher; }; typedef sequence ServiceContextBody; }; #pragma prefix "omg.
// If within an SSL session, obtain a pointer to the certificate chain. if ( ssiop ->SSL_session() ) { SSLIOP::SSL_cert_var chain = ssliop->get_peer_certificate_chain(); // walk the cert chain and print the subject and issuer's DN for (int i=0; i < chain ->length(); i++) { CORBA::Octet *der_cert = chain[i]; // Use OpenSSL to parse the certificate. // Convert to OpenSSL internal X509 format (DER to Internal X509) X509 *peer_x509 = ::d2i_X509(0, &der_cert, cert->length() ); // Obtain the subject's DN.
Chapter 12. Developing Prototype Applications on a PC Chapter 12. Developing Prototype Applications on a PC JORB Lite Applet Support Initializing the ORB Java Applet Configuration Resolving the Initial Naming Service Reference One major feature of the Java language is the ability to "write once, run anywhere." You can develop and test applications on a workstation using JORB Lite without tying up NSK system resources.
A Java applet uses the following signature for the ORB initialize call: public static ORB init(Applet app, Properties props) Java Applet Configuration JORB Lite applets and applications use different mechanisms to obtain the NonStop CORBA framework configuration information. With JORB Lite, applications obtain configuration information from the configuration file specified by the application parameter ORBlitedbm . However, Java applets have a restriction in that they cannot read data from local disk files.
value="jorb/NameService"> In this example, the main class file is AppletExample.class . The Naming Service root naming context URL can be found at webpage/jorb/NameService .
Appendix A. Architectural Walkthrough Appendix A.
Figure A-2 expands the view of NonStop CORBA to include several more important concepts. Stubs and skeletons exist for each object type. The ORBs must use one or more transport protocol mechanisms or transport types. When the TCP/IP transport protocol is used, the Bootstrap Service Daemon (BSD), Interoperable Location Service Daemon (ILSD), and Location Service Daemon (LSD) might be called upon, and Comm Servers (CS) might be used. When Comm Servers are used, the LSD must also be used.
A layered architecture view of the NonStop CORBA architecture would look like Figure A-3. In this view the application might be a client, a server, or both. In all cases, the applications use IDL compiler-generated code to communicate with the ORB and POA. When the application needs the Transaction Service, you can use the JTS run-time. The GIOP layer represents the general inter-ORB implementation. Below the GIOP there are three alternatives.
The following sections elaborate on the static view of NonStop CORBA components shown in Figures A-1 and A-2, by describing one way that requests and responses flow between the components. Walkthrough of Message Flows Using the Naming Service as an Example Message flows in a NonStop CORBA subsystem can be complex. Understanding the patterns is often helpful in debugging an application or tuning for performance. You may find it useful as background information when you deploy applications.
Naming Service calls ORB_init (flow 1 in the figure). Naming Service creates and publishes URL for the root naming context IOR (flow 2 in the figure). Network client imports IOR (flow 3 in the figure). Network client ORB tries to contact target object, for example, Naming Service root naming context (flow 4 in the figure). LSD sends forwarding reply (flows 5 and 6 in the figure). Client ORB tries again (flow 7 in the figure). Comm Server receives and relays request (flows 7 and 8 in the figure).
Naming Service Creates and Publishes Root Naming Context IOR URL (flow 2 in the figure) The Naming Service takes the following actions: Creates a naming context POA with a state policy of stateless. Creates a servant reference (this is an abstract reference). Creates the IOR URL . The information created is stored in the IOR. IOR = object_to_string(servant) . Tsmp profile contains pathmon:server_class . IIOP profile contains lsd1@actual_tcp_address . Object key contains stateless , tsmp relay profile.
Using the mapped Comm Server when mapping is present. (When the mapping is older than 24 hours, it updates the timestamp in the record.) Creating a new mapping for the Comm Server when no mapping is present. To create the mapping, the LSD searches the csmap@load_table for the least busy server, skipping dedicated comm_servers, and writes the new record in csmap@map_table , keyed by client’s TCP/IP address.
Appendix B. Object References Appendix B.
Addresses Servers may be configured as direct or indirect TCP servers: Direct TCP servers are configured with tcp_server true , and the host_name and port_number are specified. These servers communicate directly with TCP sockets. Indirect TCP servers are configured with tcp_server true and use_comm_server true . They are accessed by the NSK message system. Access via TCP will be bridged through a Comm Server. This configuration is useful with stateless servants, and for TCP connection concentration.
There are two distinct types of server pool objects: stateless and stateful. IORs for Stateless Objects in a Server Pool A stateless request (that is, a request for an operation on a stateless object) can go to any free server process within a server pool. The list below explains how NonStop CORBA creates and uses object references for stateless objects. In this scenario, the client can be local or remote with respect to the server pool.
Index Index Symbols .profile script, OSS Environment Variables and the env.
running on NonStop system, Design Activities Comm Servers defined, Introduction to NonStop CORBA Components increasing number of, Increasing the Number of Comm Server Processes reconfiguring for scalability, Adjusting TS/MP Configuration Parameters using with Parallel Library TCP/IP, Using Parallel Library TCP/IP Compiler options (see IDL compiler) Concurrency and client design, Designing a Client and object design, Designing Object Interfaces and Classes and performance tuning, Taking Advantage of Concurre
and EMS collectors (figure), Starting a Separate EMS Collector for NonStop CORBA Messages calling the error logging facility, Calling the Error Logging Facility component names, Component Names error numbers, Error Numbers example EMS message, Examining EMS Messages examples, Error Logging Examples facility, Design of the Error Logging Facility information system supplies, System-Supplied Information information you must supply, User-Supplied Information interface, How the Error Logging Facility Works intro
introduction to, Development Begins with IDL and CORBA Objects IDL compiler code-generation options, IDL Code-Generation Options errors, nsdidl Compiler Error Handling introduction to, Using the IDL Compiler preprocessing, Preprocessing preprocessor options, Preprocessor Options syntax, nsdidl Compiler Syntax ILSD (see Interoperable Location Service Daemon (ILSD)) Indirect TCP/IP server, Addresses Interface Definition Language (see IDL) Interface objects considerations for, Interface Objects defined, Object
Lifespan policy, relationship to state policy, State Policy LINKMON processes increasing maximum requests from, Adjusting TS/MP Configuration Parameters increasing number that can communicate with servers, Adjusting TS/MP Configuration Parameters Load balancing done by NonStop CORBA ORB, Writing Scalable Applications for Comm Server processes, Increasing the Number of Comm Server Processes for stateful objects, IORs for Stateful Objects in a Server Pool limitations of TS/MP, Parallel Processing and Its Impl
message flows, Walkthrough of Message Flows Using the Naming Service as an Example overview, Architectural Walkthrough NonStop Distributed Component Console defined, Components of the NonStop CORBA Environment introduction to, Using the NonStop Distributed Component Console using for tracing, How to Enable and Disable Tracing using to view naming service, Using the Console to View the Naming Service NonStop TCP/IP, using multiple instances of, Using Multiple Instances of NonStop TCP/IP NonStop Transaction M
OSS (see Open System Services (OSS)) OTS client stub, Components of Transaction Service Implementation P Parallel Library TCP/IP, using, Using Parallel Library TCP/IP Parallel processing considerations for, Parallel Processing and Its Implications with stateless and stateful requests, Parallel Processing and Its Implications pathmon (see Application profiles) PATHMON process, role in availability, Stateful and Stateless Objects Performance, tuning NonStop CORBA applications for, Tuning Applications for Per
Scripts .profile, OSS Environment Variables and the env.
description of, State Policy Stateful objects and IORs, IORs for Stateful Objects in a Server Pool and server pools, Stateful and Stateless Objects defined, Stateful and Stateless Objects POA policy for, State Policy servants, scalable, Using Stateless Factory Objects to Create Stateful Servants Stateful servants, scalable, Using Stateless Factory Objects to Create Stateful Servants Stateless objects and IORs, IORs for Stateless Objects in a Server Pool and server pools, Stateful and Stateless Objects defin
implementation components, Components of Transaction Service Implementation TransactionalObject interface, TransactionalObject Interface Transactions checked, Checked Transaction Behavior design considerations for, Designing a Client in NonStop CORBA applications, Managing Transactions propagation of context, TransactionalObject Interface setting timeout for, Transaction Branches and the Diamond Access Problem Transient objects, State Policy Transparency of objects, local/remote, Designing a Client Transpor
