NonStop CORBA 2.3 Programmer's Guide for Java Next NonStop CORBA 2.3 Programmer's Guide for Java Part number: 520547001. Published April 2002. Legal Notice Abstract This manual provides information for application programmers about writing applications for Compaq NonStop" CORBA® 2.3 in Java. The information provided focuses on the NonStop CORBA-specific implementation of the Object Management Group's CORBA standards. Product Version: Compaq NonStop" CORBA® 2.
Working in the NonStop CORBA Administrative Environment Components of the NonStop CORBA Environment Using the NonStop Distributed Component Console Running NSDAdminServer and NSDEnvironServer Application Profiles: Configuring and Managing an Application 3.
Design of the Trace Facility Information Collected in a Trace Categories of Tracing How to Enable and Disable Tracing Calling the Trace Facility Trace Settings for Application Processes Simple Tracing Example How the Trace Facility Interface Works Using the showior tool The showior Tool Syntax Examples of showior Commands Using the esadmin Tool The esadmin Tool Syntax Running the esadmin Tool esadmin Tool Commands Viewing the Naming Service Using the Console to View the Naming Service Setting Up ns_browse t
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. Writing Multithreaded Applications Overview of Multithreading Multithreading in Client Applications Multithreading in Server Implementations 9.
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
Copyright 2002 Compaq Information Technologies Group, L.P. Compaq, the Compaq logo, Alpha, Atalla, CLX, Deskpro, Enform, Expand, Guardian, Himalaya, Inspect, Integrity, NonStop, OpenVMS, PayMaster, ProLiant, ServerNet, SignMaster, SNAX, Tandem, VAX, VMS, and WebSafe are trademarks of Compaq Information Technologies Group, L.P. in the U.S. and/or other countries.
information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
About This Guide Prev Next About This Guide Table of Contents Who Should Read This Guide Organization of this Guide Manuals in the NonStop CORBA Set Your Comments Invited Reader Comments Notation Conventions This NonStop" CORBA® 2.3 Programmer's Guide for Java provides information about designing and implementing application programs for the NonStop CORBA 2.3 environment. The guide explains how to take advantage of the specific implementation features of NonStop CORBA.
Organization of this Guide Section 1, Introduction to NonStop CORBA Programming, describes prerequisite knowledge and basic design activities. The major components of NonStop CORBA are introduced. Section 2, NonStop CORBA Administrative Environment, describes working in the Open System Services (OSS) environment and in the NonStop CORBA administrative environment. The NonStop Distributed Component Console is introduced. Application profiles are described.
Manuals in the NonStop CORBA Set The NonStop CORBA 2.3 Getting Started Guide describes how to install the product and verify installation. It also includes an introduction to the product. The NonStop CORBA 2.3 Administration Guide gives basic configuration information and describes how to use the NonStop Distributed Component Console and the command-line interface to perform configuration tasks. The NonStop CORBA 2.
Also, please include the document title associated with your comments: To help us improve our software documentation, please answer the following questions in your comments: ● Are the documents technically accurate? ● Do they provide the information you need? ● Is the organization and content clear? ● Is the format convenient to use? If you are reporting a documentation error, please cut and paste the section in question into your e-mail message or include a copy of the page in your FAX.
{} | ... "" Other punctuation Long Commands A group of items enclosed in braces is a list from which you are required to choose one item. The items in the list may be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines.
Chapter 1. Introduction to NonStop CORBA Programming Prev Next Chapter 1. Introduction to NonStop CORBA Programming Table of Contents Before You Begin Design Activities Introduction to NonStop CORBA Components NonStop CORBA Programming Environments Compaq NonStop" CORBA® 2.3 is based on the OMG standards for CORBA 2.3. This guide describes features specific to the NonStop CORBA implementation as the features apply to designing and coding applications.
● CORBA and related services You must also understand the following characteristics of NonStop CORBA and related products, which are described in later chapters of this guide: ● Advantages and implications of using NonStop TS/MP (TMF programming environment) server classes and stateless or stateful request processing. TS/MP server classes are referred to as server pools in NonStop CORBA.
Clients running elsewhere as network or remote clients These processes reside on some other system (not the same NonStop Himalaya system or Expand network as the NonStop CORBA ORB). The processes act as CORBA clients. Such network clients send IIOP requests for the services of an application through the NonStop CORBA communication services. Network clients often use a different vendor's ORB. The IIOP protocol allows the different ORBs to communicate.
object key to determine how to forward requests. The LSD configuration is held in the configuration database. The LSD updates the database for each new client-address/Comm-server mapping, and it updates existing mappings daily. Interoperable Location Service Daemon (ILSD) The ILSD acts as a forwarding agent for the Interoperable Naming Service. Like the BSD and LSD, ILSD uses an object's object key to determine how to forward requests.
see Developing Prototype Applications on a PC in this guide. Prev About This Guide Up Home Next Chapter 2.
Chapter 2. NonStop CORBA Administrative Environment Prev Next Chapter 2. NonStop CORBA Administrative Environment Table of Contents Working in the Open System Services (OSS) Development Environment Using Guardian Commands and Files Through OSS OSS Environment Variables and the env.
● User commands and utilities. The osh command enters the OSS environment and starts an OSS shell process. To work with NonStop CORBA, you need to have a basic understanding of the OSS environment and you need to know how to use some of the OSS commands. A few of the commands most used in preparing a NonStop CORBA application are described in the following sections.
OSS Environment Variables and the env.sh File A shell implements environment variables that you can set and display. Processes started from the OSS shell can access exported environment variables. For example, NonStop CORBA processes and utilities use environment variables when you configure the system, develop a component, or run an application. The $NSD_ROOT/etc/env.sh file stores shell commands that set environment variables. The env.sh shell script must be executed during shell initialization by using .
make This utility helps you build and maintain an application that consists of multiple, interdependent modules. You use a file, called Makefile by default, to describe the dependencies among program modules. Thereafter, when you modify a module on which other modules depend, the make utility automatically initiates recompilation of the dependent modules.
● The $NSD_ROOT/etc/env.sh file contains environment settings. ● The Configuration database (nsdcfgdb) contains entities for ORB components and application profiles. ● The adminDB stores the operational data used by the NSDAdminServer and NSDEnvironServer processes. The location of the database is given by the environment variable NSDOM_ADMIN_DB.
Note You can set many configuration database entities by using the NonStop Distributed Component Console. These database settings apply to all applications, unless overridden by an application-specific configuration entity (that is, profile@ORB). Application-specific entities are managed by using the cfgmgt tool. See Application Profiles: Configuring and Managing an Application for more information. Note The Console is also useful when you troubleshoot your application.
Several of the server transport protocol settings are interrelated, and you must use caution when setting them. You may wish to refer to Writing Scalable Applications for a discussion of how the choice of server transport protocols affects application design. The rules are: tcp_server {true | false} Default is false. If set to true, you must either set use_comm_server true (called indirect TCP server) or set both host_name and port_number. use_comm_server {true | false} Default is false.
fs_client {true | false} Default is true. tcp_client {true | false} Default is true. profile@ORB Miscellaneous Settings These settings are all optional. They apply only to the application using the profile. You can set the defaults for these values by using the Console, or by editing the default@ORB entity using the cfgmgt tool. log_file {EMS-process-name | STDCOLL | STDOUT | STDERR | oss-file-name} Default is STDCOLL. trace_file {file-name | STDOUT | STDERR} Default is STDOUT.
Chapter 3. Compiling and Building an Application Prev Next 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.
4. Create the server: ● Compile the server skeleton code produced by the IDL compiler, producing class files. ● Create the server main program and object implementation. Code must be written for each method declared in the IDL interface definition. 5. Start the server program. It uses the NonStop CORBA ORB implementation contained in the NonStop CORBA jorb.jar file. 6. Start the client application program. It also uses the NonStop CORBA jorb.jar file.
Special Considerations for Building Transactional Clients and Servers When building a transactional CORBA application with the Object Transaction Service (OTS), it is necessary to have access to the CosTransactions::Current interface and a communications stub for the NonStop Transaction Manager (NSotsTM process). During development you accomplish access by including declarations from the file CosTransactions.idl and deriving objects that execute within transactional boundaries from TransactionalObject.
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 a macro, with definition '1'. This option is the same as if the -D name=1 option is used.
If you make an error while entering a compiler option, the following message appears: nsdidl: Error: unknown option: -demo, use: nsdidl [-?][-v][-D name][-D name=definition][-U][-I dir][-language (C++ | J ava)][-version][-o dir][-generate arg][-h suffix][-s suffix][-client suffix][-se rver suffix][-no_][-include level][-typecodes][-IR][-ir][-preprocessor arg][-pre processed][-map2package module package][-dll define-name][filename]* 1 error In the command line, you must place any options you are using after
Chapter 4. Deploying a NonStop CORBA Application Prev Next 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 if you want to enable tracing.
Server-pool server Servers running as server pools require you to set up the environment in a Pathway configuration. The sample script shown below illustrates how the environment is configured (this example is from the Bank sample program supplied with NonStop CORBA). For server-pool environments, Compaq recommends using a script. If you are not familiar with configuring Pathway environments, see the TS/MP System Management Manual (note that in TS/MP documentation, server pools are called server classes).
set set set set set set set set pathway pathway pathway pathway pathway pathway pathway pathway maxtcps maxterms maxdefines maxpathcoms maxspi maxlinkmons maxexternaltcps maxprograms 0 0 27 8 8 16 0 0 start pathway cold ! reset server set set set set set server server server server server processtype pri cwd program hometerm oss 160 $PWD $JAVA_HOME/bin/oss/posix_threads/java $G_HOMETERM set server env JAVA_HOME=$JAVA_HOME set server env JREHOME=$JREHOME set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM [
[ [ [ [ Can be static or dynamic, as Bank Server is accessible via the TS/MP protocol. Dynamic will be started by PATHMON when a client requests access to the Bank Service. Since only one Bank server is configured by default, it is best for it to be static. [ See TS/MP Manuals and Tuning Notes Appendix A. [ Set TIMEOUT to a sensible value; this sets how long a SEND through the [ LINKMON will be allowed to be outstanding.
Chapter 5. Tracing and Debugging Applications Prev Next Chapter 5.
Using the Console to View the Naming Service Setting Up ns_browse to View the Naming Service The ns_browse Tool Syntax Examples of ns_browse Commands Troubleshooting Application Components Troubleshooting a NonStop CORBA application or component involves evaluating information from the following sources: ● 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.
Using the Error Logging Facility Unexpected conditions detected by NonStop CORBA can be logged through the Event Management Service (EMS) on NonStop Himalaya systems. Looking at the log messages is one of the first things to do when troubleshooting a problem. Often the source of a problem can be ascertained readily from information contained in the log. Refer to the EMS FastStart Manual, EMS Manual, and EMS Reference Summary for background information and usage questions about EMS.
Exception type (not all log messages are associated with an exception) Exception name (not all exceptions are named) Class name Line identifier of the class that logged the error ExcptType ExcptName File Line While much of this information is composed by the error logging facility at the time the call is made, you must supply some of it when you make your calls.
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 MY_COLLECTOR in the $NSD_ROOT/etc/env.sh file or in log_file in the default@ORB entity in the configuration database.
The date and time of the event is given first. Because the log might contain many messages from a number of different processes, examining EMS messages that were logged during a particular interval is a useful strategy. The second part contains the text error message GIOP Proxy demarshal 0 profiles, which provides information that can help you troubleshoot the problem.
/* Log message where severity = INFORMATIONAL */ log_info(java.lang.Class pp_src_class, int pv_src_line_num, int pv_err_num, java.lang.String pp_text) /* 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.
Config_Log.log_info() Config_Log.set_component_name() Config_Log.set_log_file_name() Calling these methods causes the error logging facility to do the following: ● Get the date, time, process name, process ID, and thread ID using system calls. ● Compose a message using both user-supplied information and information gathered from the system. ● Send an EMS message or record a message in the log file. Error Numbers Error numbers identify a problem that might occur in the NonStop CORBA environment.
extends java.lang.Object { public static void log_critical(java.lang.Class pp_src_class, int pv_src_line_num, int pv_err_num, java.lang.String pp_text) public static void log_error(java.lang.Class pp_src_class, int pv_src_line_num, int pv_err_num, java.lang.String pp_text) public static void log_info(java.lang.Class pp_src_class, int pv_src_line_num, int pv_err_num, java.lang.String pp_text) public static void log_warning(java.lang.Class pp_src_class, int pv_src_line_num, int pv_err_num, java.lang.
designed so that more than one process can write trace information to a trace file. The configuration database specifies the file to which the trace facility writes. By default, the trace facility writes to stdout. If a trace message is generated before org.omg.CORBA.ORB.init() is called, the trace facility also writes to stdout. You can change the location either by using the Console or by using the cfgmgt tool.
NSDOM_CFG_TRACE_GIOP_FW orb_giop_connections NSDOM_CFG_TRACE_ORB orb_request_queue NSDOM_CFG_TRACE_POA poa NSDOM_CFG_TRACE_OTS none NSDOM_CFG_TRACE_PROXY NSDOM_CFG_TRACE_PROXY_DETAIL orb_proxy NSDOM_CFG_TRACE_THREADS threads NSDOM_CFG_TRACE_TIMER event_time NSDOM_CFG_TRACE_DETAIL none NSDOM_CFG_TRACE_FULL_BUFFERING none ORB GIOP protocol layer ORB request processing POA activity NSOTS or application transaction activity ORB proxy processing: method dispatches and results of method invocati
Using the Console to set tracing is the easiest method, but this method offers limited choices for tracing and sets tracing for NonStop CORBA subsystem processes, not application processes. See the NonStop CORBA 2.3 Administration Guide for general information about using the Console. The tracing choices offered in the Console are: ● None ● Basic ● Detailed Table 53 shows the available trace settings. The Basic and Detailed columns show the settings that are set by using the Console.
Comm Server NSDOM_CFG_TRACE_CS Event Service NSDOM_CFG_TRACE_ES NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA ILSD NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA IR NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA LSD NSDOM_CFG_TRACE_ORB Naming Service NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA OTS NSDOM_CFG_TRACE_ORB NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_OTS NSDOM_CFG_TRACE_ORB XID Broker NSDOM_CFG_TRACE_POA NSDOM_CFG_TRACE_OTS NSDOM_CFG_TRACE_CS NSDOM_CFG_TRACE_SOCKEH NSDOM_CFG_TRACE_GFSEH NSDOM_CFG_TRACE_GCFEH NSDOM
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 Methods The methods shown below are provided to simplify the task of adding trace statements to your application code. // trace data method static void trace(String trace_data); // trace method void trace(String trace_data); These methods open the trace file and write the trace message.
public static Config_trace get_default(); public void open_trace_file(); public void set_trace_file_name(String pp_trace_file_name); public static void trace(String pp_trace_data); public void trace_data(String pp_trace_data); } Trace Method Descriptions Two methods are used to create a trace message: trace() and trace_data(). One sets the trace filename: set_trace_file_name(). Two others open open_trace_file() and close close_trace_file() the trace file.
The -a switch is and optional switch available only if you are running showior from JORB Lite. 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 ( ).
For example, if the NameService file is copied into the directory c:\jorblite\lib\NameService, the Naming Service setting in lite.dbm would resemble the following: NS@name_service_settings RootNamingContextIORFile c:\jorblite\lib\NameService The CLASSPATH and PATH settings can be changed by editing and running the env.bat file. The esadmin Tool Syntax esadmin esadmin has no options.
● Admin/Trace ● File/New The Event Channel Status window displays statistics for the specified event channel. The statistics displayed are updated periodically. To adjust the update interval, go to the Admin menu and click Preferences. Set the desired update interval using the dialog displayed. To display and alter event channel policies, go to the Admin menu and click Policies. This command displays the current policy values.
● View an object reference ● Save an object reference An example of the Console view of the Naming Service is shown in Figure 53 . Figure 5.3. Naming Service Display For more information about using the Console, see the NonStop CORBA 2.3 Administration Guide and the online help provided with the Console. Setting Up ns_browse to View the Naming Service The ns_browse tool runs on the NonStop Himalaya system, and it allows you to look at entries stored in the Naming Service database.
When NonStop CORBA is installed, the Naming Service writes the stringified IOR of the root naming context into the $NSD_ROOT/urls/NameService file. This ASCII file must be copied to the computer where JORB Lite is installed and the full pathname of this file must be specified in the lite.dbm Naming Service setting. For example, if the NameService file is copied into the directory c:\jorblite\lib\NameService, the Naming Service setting in lite.
This option lists the contexts and objects bound into the naming context specified by context-name. This is not a recursive operation; it only displays the immediate contents of the context, not recurrences thorough any contexts subordinate to the base. If no context-name is given, this command lists contents of the base naming context. new_context context-name This option creates a new naming context in the base naming context, and returns the stringified IOR for the new naming context.
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. Run ns_browse to remove a naming context with name TestCtx1 "" from the naming context with name TestCtx test.
Chapter 6. Writing Scalable Applications Prev Next Chapter 6.
● Configure application server processes as server pools. NonStop CORBA then uses the capabilities of TS/MP to spread the workload among multiple processes, adds new processes as needed, and provides load balancing. ● Configure the Comm Server, LSD, ILSD, and/or BSD processes in your NonStop CORBA system to use Parallel Library TCP/IP, so that a single TCP/IP port is shared by multiple communications processes. ● Increase the number of Comm Server processes to support increased request traffic.
Stateful and Stateless Objects In NonStop CORBA, objects can be either stateful or stateless. The use of stateful and stateless objects is closely related to the use of server pools. If an object is stateful, all operations directed to that object must be handled by the same servant (instance of the object). Operations directed to other objects in the class can be handled by different servants in other processes.
object whose lifespan policy is TRANSIENT is stateful by default. The state policy (com.tandem.nsdom.PortableServer.StatePolicy) is a NonStop CORBA proprietary policy you can apply to allow persistent stateful objects in a server-pool process to be accessed by the GIOP over TS/MP transport protocol. (By default, an object with a lifespan policy of PERSISTENT is assumed to be stateless.) The state policy has two values: STATEFUL and STATELESS.
If more than one client process is used, TS/MP can route requests from different clients to different Comm Server processes and thus to different factory servers; a Comm Server process is typically configured to use an application server within its own processor whenever possible. This arrangement provides for additional load balancing. If you use a stateful POA for a servant in a TS/MP process, always set the DELETEDELAY parameter in the TS/MP configuration to zero.
your NonStop CORBA configuration. In a traditional configuration without Parallel Library TCP/IP, each configured Comm Server, LSD, ILSD, and BSD process runs as a server pool consisting of one process listening at an assigned TCP/IP port; thus there is a one-to-one ratio between communications processes and ports. 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.
time spent by the LSD process in distributing requests. If the Comm Server processes are configured to use Parallel Library TCP/IP, the LSD uses a round-robin algorithm; otherwise, it uses a least-busy algorithm. Parallel Library TCP/IP is the recommended alternative. If you do not use Parallel Library TCP/IP, it is recommended that you configure multiple Comm Server processes to avoid performance bottlenecks.
Chapter 7. Managing Transactions Prev Next Chapter 7.
Use of TMF NSJTS uses the NonStop Transaction Management Facility, or TMF, for transaction management. NSJTS serves in both superior and subordinate roles to TMF. NSJTS and TMF communicate through a pseudo-file called a recoverable resource manager (RM) file. They exchange signals through this file using the TMF APIs. These signals are used to start and terminate transactions. The RM file is also used during the initialization of NSJTS to recover any in-doubt transactions following a failure.
If an attempt is made to terminate a transaction when its reference count indicates that another thread may potentially be working on the transaction, the Transaction Service components of NonStop CORBA throw the exception BAD_INV_ORDER. Transaction Branches and the Diamond Access Problem Because of the way TMF handles distributed transactions, you may need to design your application to avoid database access deadlocks between transaction branches, sometimes called the diamond access problem.
In this figure, the application starts a debit/credit transaction on System A. The debit account is held on System B and the credit account is held on System C. System D has an object that requires input from both debits and credits (in this case a Bank Vault Account that tracks debits and credits). The problem occurs when Systems B and C attempt to write to the Bank Vault object on System D. At that time, one write operation might be locked out by the other.
In configurations where the NSotsTM process runs as a server pool with multiple processes, contention between NSotsTM processes can cause the diamond access problem to occur. To avoid this cause of the problem, no application changes are required. NonStop CORBA provides the NSotsXID process to act as a broker between NSotsTM processes, so that only one process has control at a time.
Chapter 8. Writing Multithreaded Applications Prev Next Chapter 8. Writing Multithreaded Applications Table of Contents 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.
Note On NonStop Himalaya systems, threads are not run in separate processors. To take advantage of parallel processing, use separate processes rather than threads. Multithreading on NonStop Himalaya systems is non-preemptive. Multithreading in Client Applications One typical use of multithreading in NonStop CORBA client programs is to issue concurrent requests to one or more objects. When multithreading is not used, operations are synchronous.
spawns a new thread (if 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. If the thread does not release control of the processor, the POA thread cannot run and spawn or reuse a thread.
Chapter 9. Designing Advanced Applications Prev Next Chapter 9.
● The role of each object interfacefor example, whether each object represents an entity in a databaseand 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.
● Interface objects typically run on a client workstation or other end-user device, such as a bank-teller input device or a gas-station pump. ● Control objects typically run on a server machine. These objects are sometimes called business-transaction objects because each operation on the object corresponds to a unit of work, such as withdraw funds from account or transfer funds between accounts.
can be used by either interface objects or control objects: an interface object need not always use a control object for access to an entity object. Entity objects are typically shared by multiple clients, usually control objects, so the application designer must expect and prepare for concurrent invocations of the same object by multiple clients. An entity object does not typically control other entity objects.
However, if the interface definition is changed to have one attribute, the client can send one message to get all the information: interface account { struct CustomerRecord { string name; string address; }; readonly attribute CustomerRecord customer; } ; ● Isolate CORBA functions and database access functions from business logic. Isolating CORBA functions from non-CORBA functions is often referred to as delegation.
● Class data for an object class applies only to the object instances in one process, not to the entire object class (which might have instances in other processes). ● TS/MP load balancing is available only for stateless servants. If you use server pools, you must decide how to provide for stateless requests when possible and stateful requests when necessary. In stateless processing, a series of operations on the same object can result in requests to different processes in a server pool.
● Interoperability. For example, ensuring that a client developed on some other platform can interact with NonStop CORBA servers. Tuning Applications for Performance The following sections provide some performance tuning suggestions for NonStop CORBA applications. Choosing the Most Efficient Transport Protocol For remote object references, the IIOP protocol (which uses TCP/IP) must be used for transport.
Adjusting Process Priorities In general, processes that provide services should have higher priority than processes that request those services. More specifically, consider the process flow as a river at whose delta are services (both COS and application) or entity objects, whose tributaries are control objects, and whose source streams are Comm Server, TCP/IP, and similar processes that are conduits for client requests.
Chapter 10. Porting CORBA Applications to NonStop CORBA Prev Next Chapter 10. Porting CORBA Applications to NonStop CORBA Table of Contents 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.3. For specific details about the NonStop CORBA implementation that may be useful in porting applications, refer to the NonStop CORBA 2.3 Programmer's Reference.
Prev Chapter 9. Designing Advanced Applications Up Home Next Chapter 11.
Chapter 11. Developing Prototype Applications on a PC Prev Next Chapter 11. Developing Prototype Applications on a PC Table of Contents 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 with out tying up NSK system resources.
System Services, you can run your program on either the PC or on the NSK system. You will get the same execution results. The example that follows later in this section shows that you can develop NonStop CORBA applications using JORB Lite, move the compiled .class bytecode files to the OSS environment, and run the applications using NonStop CORBA. Caution The JORB Lite environment is provided for application development. The JORB Lite environment is not to be used for production.
in the HTML APPLET tag. Through these PARAM tags the applet obtains the ORB configuration. Specifically, the Java applet ORB.init() call uses the Java applet parameters shown in Table 121. Table 11.1.
This parameter specifies the state of SOCKEH tracing. If enabled, the output goes to stdout by default. NSDOM_CFG_TRACE_SOCKEH_DETAIL This parameter specifies the state of SOCKEH DETAIL tracing. If enabled, the output goes to stdout by default. ORBprofile This parameter specifies the ORB profile name. Note You must specify both ORBprofile and NSDOM_CFG_PROFILE to specify an ORB profile. The sample Applet HTML code below shows the specification for a JORB Lite applet:
Appendix A. Architectural Walkthrough Prev Next 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. If 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. If 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. If 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.
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. This section describes the flow of messages from a client to and from a single service, the Naming Service, as an example of how the flow might happen in a typical application.
● Comm Server receives and relays reply (flows 9 and 10 in the figure). ● Client ORB processes reply. The client is now ready to execute methods against the root naming context. The following sections describe each of the above events in more detail: Naming Service Calls ORB_init (flow 1 in the figure) When the Naming Service calls ORB_init, the NS@ORB entity is read. The ORB sets up a GIOP server component for the configured server transport protocols.
ORB.resolve_initial_references (NameService) , for example), but this relatively simple way is used for this example. Network Client ORB Tries to Contact Target Object (flow 4 in the figure) Once it has the CORBA::Object, the client ORB narrows the reference to a COSNaming Naming Context. The client ORB must determine if the target object is a naming context, so it performs the following: ● Connects to the address in the IIOP profile (LSD). ● Sends an _is_a request to the LSD.
Comm Server Receives and Relays Reply (flows 9 and 10 in the figure) When the server_agent receives the reply, it ● Demarshals the reply through the request ID. ● Interposes original request ID. ● Asks the originating client_agent to relay the reply. The client_agent then relays the reply (flow 10 in the figure), sending the reply message on its connection. Client ORB Processes an is_a Reply Now the client ORB demarshals the reply. It ● Sees the result is true.
Appendix B. Object References Prev Next Appendix B.
Obtaining Object References NonStop CORBA obtains server IORs at three points: ● Explicitly, when the application calls CORBA::Object::object_to_string(). This action is usually done when an IOR must be "hand delivered" to a client, for example, during initial testing of a system when the Naming Service is being avoided. ● Implicitly, when an object is returned as an out parameter or result for an operation. An example is found in the Naming Service resolve() operation.
NSDOM_GCF_IOP::Profile_Tag Addresses If a server is configured to enable GIOP over TS/MP (tsmp_server true), the profile address will contain pathmon-process-name and server-class. NSDOM_GFS_IOP::Profile_Tag Addresses If a server is configured to enable GIOP over the Guardian file system (fs_server true), the address field will contain a Guardian file system address. If the servant's POA has the PERSISTENT lifespan policy, the profile address will be set to pname.subdevice.
tcp_server tcp_process host_name port_number true $ztc1 oss2.widget.com 0 When NonStop CORBA builds an IOP::TAG_INTERNET_IOP profile, the profile's host field must be in dot-decimal form to avoid having to export the DNS/host-file configuration to every client. Also, the port field must have the actual port number selected by TCP if it was configured as 0.
pool after sending the reply This behavior is similar to the CORBA process-per-request scenario. Because NonStop CORBA establishes a new TS/MP link to process each request, load balancing occurs at the time of the request. IORs for Stateful Objects in a Server Pool A stateful request (that is, a request for an operation on a stateful object) must always go to the process where the object was created. Therefore, NonStop CORBA generates a reference for a stateful object.
Index Prev Index Symbols .profile script, OSS Environment Variables and the env.
B BAD_INV_ORDER exception, Checked Transaction Behavior Basic Object Adapter (BOA), porting considerations, Applications Using Proprietary Features Bootstrap Service Daemon (BSD) reconfiguring for scalability, Adjusting TS/MP Configuration Parameters Bootstrap Service Daemon (BSD) defined, Introduction to NonStop CORBA Components using with Parallel Library TCP/IP, Using Parallel Library TCP/IP Building applications, Tips for Building NonStop CORBA Application Components Building transactional clients and s
See NonStop Distributed Component Console Control objects considerations for, Control Objects defined, Object Roles and Relationships use of, Designing Object Interfaces and Classes CORBA objects, Development Begins with IDL and CORBA Objects CosTransactions module, Managing Transactions CosTransactions.
Error logging and EMS collectors, Starting a Separate EMS Collector for NonStop CORBA Messages 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 y
F Factory objects in application design, Designing Object Interfaces and Classes stateless, using for scalability, Using Stateless Factory Objects to Create Stateful Servants fs_server See Application profiles G GIOP over Guardian file-system protocol, Choosing the Most Efficient Transport Protocol GIOP over TS/MP protocol, Choosing the Most Efficient Transport Protocol Global state information negative effect on portability, Global State Information negative effect on scalability, Object Distribution Gran
See IDL Interface objects considerations for, Interface Objects defined, Object Roles and Relationships Interface Repository (IR) defined, Introduction to NonStop CORBA Components Interoperable Location Service Daemon (ILSD) reconfiguring for scalability, Adjusting TS/MP Configuration Parameters Interoperable Location Service Daemon (ILSD) defined, Introduction to NonStop CORBA Components using with Parallel Library TCP/IP, Using Parallel Library TCP/IP Interoperable Naming Service (INS), Introduction to No
introduction to, Developing Prototype Applications on a PC limitations, Developing Prototype Applications on a PC using applets with, JORB Lite Applet Support JTS client stub, Components of Transaction Service Implementation jts.
M Makefiles, Makefiles Managing processes, using TS/MP, Writing Your Application to Use Server Pools Marshaling costs, limiting, Object Distribution MAXLINKMONS parameter, in TS/MP, Adjusting TS/MP Configuration Parameters MAXLINKS parameter, in TS/MP, Adjusting TS/MP Configuration Parameters MAXSERVERS parameter, in TS/MP, Adjusting TS/MP Configuration Parameters Memory leaks, Checked Transaction Behavior Modularizing applications, Object Distribution Multithreading in clients, Multithreading in Client App
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 Manager (NSotsTM process), Special Considerations for Building Transactional Clients and Servers ns_browse commands, Examples of ns_browse Commands introduction to, Setting Up ns_browse to View the Naming Service syntax, The ns_browse Tool Syntax NSDAdminServer defined, Compo
distribution of, Object Distribution lifecycle considerations for, Designing a Client Open System Services (OSS) environment variables, OSS Environment Variables and the env.
description of, State Policy port_number See Application profiles Porting applications from other ORBs, Porting CORBA Applications to NonStop CORBA Preprocessing See IDL compiler Preprocessor options, IDL compiler, Preprocessor Options Prerequisite knowledge for writing NonStop CORBA applications, Before You Begin Priority of processes, Adjusting Process Priorities Process-blocking operations explanation of, Multithreading in Server Implementations increasing concurrency for, Using Multithreaded Servers iso
S Scalability features automatically provided, Writing Scalable Applications taking advantage of, Writing Scalable Applications using server pools for, Using Stateless Objects and Server Pools Scripts .profile, OSS Environment Variables and the env.
Severity levels See Error logging showior commands, Examples of showior Commands introduction to, Using the showior tool syntax, The showior Tool Syntax SINGLE_THREAD_MODEL threading-policy setting, Multithreading in Server Implementations Skeletons (figure), Development Process State policy description of, State Policy State information, global negative effect on portability, Global State Information negative effect on scalability, Object Distribution Stateful objects and IORs, IORs for Stateful Objects in
See Application Profiles tcp_process See Application profiles tcp_server See Application profiles Thread-blocking operations explanation of, Multithreading in Server Implementations increasing concurrency for, Using Multithreaded Servers Thread-safe code, Multithreading in Server Implementations Threading See Multithreading Threading policy, Multithreading in Server Implementations Trace facility See Tracing trace_file See Application Profiles Tracing available settings, How to Enable and Disable Tracing ca
how implemented, Managing Transactions 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, lo
See Application Profiles tsmp_client See Application Profiles tsmp_server See Application profiles U use_comm_server See Application profiles X XID broker, Transaction Branches and the Diamond Access Problem XID broker process, Components of Transaction Service Implementation Prev Appendix B.
