HP NonStop CORBA 2.6 Programmer's Guide for Java HP NonStop CORBA 2.6 Programmer's Guide for Java Part number: 525937001. Published November 2003. Legal Notice Abstract This manual provides information for application programmers about writing applications for HP NonStop" CORBA® 2.6 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.
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
A.4. Message Flows A.5. CORBA Process Run-Time Environment List of Tables 1.1. Java Sample Programs 5.1. Error Log Information 5.2. Tracing Options 5.3. Tracing Options for NonStop CORBA subsystem 11.1.
Copyright 2003 Hewlett-Packard Development Company L.P. Hewlett-Packard, HP, the HP invent logo, 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 Hewlett-Packard Development Company L.P. in the U.S. and/or other countries.
subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013. Hewlett-Packard Development Company L.P. 10600 Ridgeview Court Cupertino, CA 95014 USA Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). Export of the information contained in this publication may require authorization from the U.S. Department of Commerce. HEWLETT-PACKARD DEVELOPMENT COMPANY L.P.
New and Changed Information New and Changed Information This edition of the HP NonStop CORBA 2.6 Programmer's Guide for Java describes the following new features for HP NonStop CORBA 2.6: ● Support for the OMG CORBA 2.6.1 specification. The section number headings and specification versions have been updated to match the current OMG CORBA 2.6.1 specification. ● Support for GIOP/IIOP versions 1.1 and 1.2. ● Support for Portable Interceptors.
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 Programmer's Guide for Java provides information about designing and implementing application programs for the NonStop CORBA 2.6 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.6 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 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.
[] {} | ... "" Other punctuation Brackets enclose optional syntax items. For example: TERM [\system-name.]$terminal-name INT[ERRUPTS] A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list may be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines.
Long Commands If the syntax of a command is too long to be shown on a single line, each continuation line is indented three spaces, the first of which is separated from the preceding line by a blank line. This spacing distinguishes items in a continuation line from items in a vertical list of selections. For example: ALTER [ / OUT file-spec / ] CONTROLLER [ , attribute-spec ]... New and Changed Information Chapter 1.
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 is based on the OMG standards for CORBA 2.6. This guide describes features specific to the NonStop CORBA implementation as the features apply to designing and coding applications.
Before You Begin To design an application or component, you must understand the following topics: ● General principles of object-oriented design ● Object features such as inheritance and predefined classes and frameworks ● CORBA and related services You must also understand the following characteristics of NonStop CORBA and related products, which are described in later sections of this guide: ● Advantages and implications of using NonStop TS/MP (Pathway programming environment) server classes and st
● Create the server programs. More specifically, NonStop CORBA application processes that you might design are: Clients running on a NonStop system These processes reside on the same NonStop system (or Expand network) as the NonStop CORBA Object Request Broker (ORB) and act as CORBA clients. Clients running elsewhere as network or remote clients These processes reside on some other system (not the same NonStop system or Expand network as the NonStop CORBA ORB). The processes act as CORBA clients.
A feed (Feed) Demonstrates: ● ● Two object interface definitions written in IDL ● A server that implements the two interfaces defined by the interface definition ● A client application that makes use of an instance of a calcFactory object and an instance of a NS_Calculator object calc Interoperability between JORB Lite and NonStop CORBA for Java Demonstrates the use of the NonStop CORBA Event Service. The Event Service is a CORBA specified facility which decouples communication between objects.
Illustrates using TS/MP with the Java Transaction Service (JTS), the NonStop CORBA Naming Service, Location Service Daemon (LSD), and Communication Server (Comm Server) to provide a scalable and reliable implementation of a SQL/MP backed Bank. The sample consists of: an interface (bank.idl), a client (Client) and a server (Server). The server publishes the Interoperable Object Reference jts_bank (IOR) of the Transactional_AccountsImpl object using the NonStop CORBA Naming Service.
Demonstrates: stack-tie ● An object interface definition written in IDL ● A server that implements the interface defined by the interface definition ● A client which makes use of an instance of a stack object ● The portability of 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 Demonstrates: ● stock ● An object interface definition written in IDL ● A server that implements the int
J2EE, the Bootstrap Service Daemon provides a standard interoperable protocol for resolving an initial reference ID and for listing the supported initial reference IDs. The BSD configuration is held in the configuration database. Configuration database This database is built during the installation and configuration of NonStop CORBA. It contains an entry for the Naming Service that includes an IOR used by ORB::resolve_initial_references.
● Naming Service (implemented as a server pool or NonStop TS/MP server class). NonStop CORBA implements the Interoperable Naming Service specified in the OMG CORBA 2.6.1 specifications, with the exception that the Resolve Initial References (RIR) URL is not supported. ● Event Service. A standard application service (one of the OMG Common Object Services) for asynchronous communication among objects ● Transaction Service.
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.
● 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 .
nm The nm command writes the name list of each specified object file to the standard output file. The nm command displays symbolic information appearing in an object file, executable file, or object-file library. nm can be used to find symbols that show up in unresolved external error messages. vi This utility is the OSS editor used to create and update OSS files. jdb You must use the jdb tool to debug your NonStop CORBA application programs.
Using the NonStop Distributed Component Console Many NonStop CORBA administrative and configuration tasks can be performed using the NonStop Distributed Component Console. See the NonStop CORBA 2.6 Administration Guide for basic information on using the Console.
Caution: Be very careful to keep changes made through the Console and changes made to the $NSD_ROOT/bin/nsdstart script or $NSD_ROOT/etc/env.sh consistent with your intentions. If you have used the Console to change trace settings, those changes will not be reflected in scripts. Running NSDAdminServer and NSDEnvironServer The NSDAdminServer is started by the NonStop CORBA installer, and it must be running before you can use the NonStop Distributed Component Console.
Default is false. If set to true, then tcp_server must also be set to true. When tcp_server and use_comm_server are set to true, you can set either tsmp_server to true, or fs_server to true, or both. host_name {DNS-name | IP-address} You must specify a name or a TCP/IP address if tcp_server is true and use_comm_server is false. DNS-name represents the name form of the address, and IP-address represents the numeric (dot-decimal) form of the address.
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. max_threads number The maximum number of servant threads available in a process. Default is 4097. The effective maximum number of threads in a server depends on the size of each thread's stack and the number of NSK threads available in a CPU.
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.
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.
deriving objects that execute within transactional boundaries from TransactionalObject. Note that TransactionalObject will be replaced in the future by the OTSPolicy component. When building a Java application you would gain access to the Current interface and stub by including the file jts.jar in your CLASSPATH specification. To see an example of building a transactional client and server, consult the jts_bank sample program.
-D name Define name as a macro, with definition '1'. This option is the same as if the -D name=1 option is used. -D name=definition Define name as a macro, with definition as the definition. -I dir Insert the specified directory name into the search path for #include files with names not beginning with a slash (/). dir is inserted ahead of the standard list of include directories. You can specify dir more than once to add multiple directories to the search path. The default is the current directory.
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 the command and before any filenames.
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 if you want to enable tracing.
Server-pool client Clients can run as server pools. You need to set up the environment in a NonStop TS/MP configuration. Server-pool server Servers running as server pools require you to set up the environment in a NonStop TS/MP 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, HP recommends using a script.
set set set set set set set set set set set set pathway pathway pathway pathway pathway pathway pathway pathway pathway pathway pathway pathway maxparams maxserverclasses maxserverprocesses maxstartups maxtcps maxterms maxdefines maxpathcoms maxspi maxlinkmons maxexternaltcps maxprograms 8 4 40 40 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 stdin /dev/null set server stdout $PWD/server.log set server stderr $PWD/server.log [ [ [ [ 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.
Chapter 5. Tracing and Debugging Applications Chapter 5.
esadmin Tool Commands Viewing the Naming Service 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.
For a more general understanding of NonStop CORBA component interactions, architecture, and message flows, see Appendix A, Architectural Walkthrough. Using the Error Logging Facility Unexpected conditions detected by NonStop CORBA can be logged through the Event Management Service (EMS) on NonStop 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.
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.
Calling the Error Logging Facility Each call to the error logging facility is made at one of four severity levels: Critical, Error, Warning, or Informational: ● Critical indicates an error that could result in significant loss of, or damage to, your subsystems environment. ● Error indicates an error occurred that might require some user action to fix the problem (for example, a configuration error).
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.
● 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. While NonStop CORBA reserves the error numbers ranging from 0 through 6999, you can add user-defined error numbers in the numbers ranging from 7001 through 7100.
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.String pp_text) public static void set_component_name(java.lang.String pp_comp_name) public static void set_log_file_name(java.lang.
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.
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 NSDOM_CFG_TRACE_PI NSDOM_CFG_TRACE_PI_DETAIL pi ssl NSOTS or application transaction activity ORB proxy processing: method dispatches and results of method invocations.
application processes. See the NonStop TS/MP System Management Manual for information on PATHCOM commands. To disable tracing, reverse the earlier modification, then restart the processes. You should disable tracing as soon as your troubleshooting is completed because tracing can consume resources and produce considerable output.
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 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. And another gets the default trace object: get_default().
data display is mixed ASCII and hexadecimal where an ASCII character is enclosed within square brackets [ ] and the hexadecimal digit is enclosed within parentheses ( ). -o The -o switch decodes and displays the object key information in a form similar to that displayed by the Console (seeFigure 5.3). -r The -r switch is optional and specifies that the IOR is to be displayed in raw format. IOR-filename This option specifies the name of the IOR file to be displayed. The default filename is objref.
c:\jorblite\lib\lite.dbm. 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.6 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 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 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.
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.
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. Otherwise, TS/MP server processes are deleted if they are inactive for some time, even if a stateful session is still in progress. The use of stateful servants thus disallows dynamic shrinking of the server pool.
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. When configured this way, the server pool appears as a single IP host to the outside world.
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. You can also use the two alternatives in combination if you need more than sixteen Comm Server processes.
Chapter 7. Managing Transactions 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.
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. This problem is not specific to NonStop CORBA, and can occur in any system where TMF is used. It is most likely to occur in highly distributed applications with distributed databases.
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.
● Interacting with a user who may not respond immediately Note: On NonStop systems, threads are not run in separate processors. To take advantage of parallel processing, use separate processes rather than threads. Multithreading on NonStop 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.
By using the ORB_CTRL_MODEL threading policy, servers can take advantage of multithreading without doing any explicit programming. In certain situations, however, you might also find it desirable to make a server explicitly spawn new threads. Such threads can coexist with POA-spawned threads. When doing explicit multithreading in server programs, keep the following points in mind: ● Do not make process-blocking calls from a thread.
Chapter 9. Designing Advanced Applications Chapter 9.
more important in the highly distributed environment of a NonStop system than they are on other platforms. ● 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.
Object Roles and Relationships The following three-tier classification of object roles is not specific to NonStop CORBA but is used throughout this section: ● 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.
described in Parallel Processing and Its Implications. Entity Objects An entity object typically represents stored data, although it could also represent a device. Entity objects 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.
readonly attribute string CustomerName; readonly attribute string CustomerAddress; } If this type of object is distributed, the client must send a separate message to read each attribute.
Parallel Processing and Its Implications NonStop CORBA can run application servers as server pools. This style of implementation allows many processes to act as one logical server; each new unit of work goes to the next available free server process in the pool. Server processes can run in different processors to allow for parallel processing.
an object interface. ● Server pools. Implications of the use of server pools and whether the use of server pools must be transparent to the application. ● Transaction management. Whether a client or object has responsibility for managing nested transactions. ● Concurrency. Whether clients or an object must coordinate concurrent access to data, and whether the client requires threads. ● Interoperability.
Taking Advantage of Concurrency If your application has the potential for concurrency (that is, it includes thread-blocking operations but not process-blocking operations), you may be able to use multithreading to reduce the number of processes required to handle a given workload. For details, refer to Writing Multithreaded Applications. If your application performs process-blocking operations, you can take advantage of process concurrency by using 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. For specific details about the NonStop CORBA implementation that may be useful in porting applications, refer to the NonStop CORBA 2.6 Programmer's Reference.
additional rework. Chapter 9. Designing Advanced Applications Chapter 11.
Chapter 11. Developing Prototype Applications on a PC Chapter 11. 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 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.
Table 11.1.
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 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 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_process $ztc1 host_name oss2.widget.com port_number 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.
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 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) defined, Introduction to NonStop CORBA Components reconfiguring for scalability, Adjusting TS/MP Configuration Parameters using with Parallel Library TCP/IP, Using Parallel Library TCP/IP Building applications, Tips for Building NonStop CORBA Application Components Building transactional clients and servers, Special Considerations
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.
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 introduction to, Using the Error Logging Facility log entries, Design of the Error Logging Facility log entries (table), Information in the Error Log message logging
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 Granularity of objects, Object Distribution H host_name (see Application profiles) I IDL introduction to, Development Begins with IDL and CORBA Objects IDL compiler code-generation options, IDL Code-Generation Opt
using with Parallel Library TCP/IP, Using Parallel Library TCP/IP Interoperable Naming Service (INS), Introduction to NonStop CORBA Components Interoperable object references (see IORs) IORs actual TCP/IP addresses in, Configured Versus Actual TCP/IP Addresses and stateful objects in server pools, IORs for Stateful Objects in a Server Pool and stateless objects in server pools, IORs for Stateless Objects in a Server Pool configured addresses in, Configured Versus Actual TCP/IP Addresses content of, Content
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 Implications reference for further information, Writing Your Application to Use Server Pools using Parallel Library TCP/IP for, Using Parallel Library TCP/IP using server pools for, Overview of Scalability Choices when performed, by TS/MP, IORs for St
N Naming context, defined, Viewing the Naming Service Naming Service adding, renaming, or removing a context, Using the Console to View the Naming Service how to view, Viewing the Naming Service using ns_browse with, Setting Up ns_browse to View the Naming Service viewing or saving an object reference, Using the Console to View the Naming Service viewing with Console, Using the Console to View the Naming Service NonStop CORBA architecture basic (figure), Architectural Walkthrough extended view (figure), Arc
nsdom_ir (see Application Profiles) NSJTS, Managing Transactions NSotsTM process, Components of Transaction Service Implementation NSotsXID process, Components of Transaction Service Implementation O Object classes design considerations for, Designing Object Interfaces and Classes Object interfaces design considerations for, Designing Object Interfaces and Classes Object references (see IORs) Object Transaction Service (OTS), Managing Transactions Object-oriented design, Object-Oriented Design Methodologie
Performance, tuning NonStop CORBA applications for, Tuning Applications for Performance Persistent objects and state policy, State Policy in application design, Designing Object Interfaces and Classes POA policy for stateful and stateless objects 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 fo
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.
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 information, global negative effect on portability, Global State Information negative effect on scalability, Object Distribution State policy description of, State Policy Stateful objects and IORs, IORs for Stateful Objects in a Server Pool and server pools, Stateful
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 calling the trace facility, Calling the Trace Facility choices in Console, How to Enable and Disable Tracing component ca
Transient objects, State Policy Transparency of objects, local/remote, Designing a Client Transport protocols and state policy, State Policy choosing for performance, Choosing the Most Efficient Transport Protocol information in IORs, Object References profile tags in IORs, Content of Object References selecting for clients, profile@ORB Client Transport Protocols selecting for servers, profile@ORB Server Transport Protocols Troubleshooting introduction to, Troubleshooting Application Components naming servi
Appendix B.
