HP NonStop CORBA 2.3 Programmer's Guide for Java Next HP NonStop CORBA 2.3 Programmer's Guide for Java Part number: 520547003. Published November 2003. Legal Notice Abstract This manual provides information for application programmers about writing applications for HP 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: HP NonStop" CORBA® 2.
Components of the NonStop CORBA Environment Using the NonStop Distributed Component Console Running NSDAdminServer and NSDEnvironServer Application Profiles: Configuring and Managing an Application 3.
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 to View the Naming Service The
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 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 figure) Comm Server Receives and Relays Reply (flows 9
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.
New and Changed Information Prev Next New and Changed Information This publication has been updated to reflect new product names: ● Since product names are changing over time, this publication might contain both HP and Compaq product names. ● Product names in graphic representations are consistent with the current product interface.
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 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. Note This guide focuses on the use of features specific to 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.
[] {} | ... "" 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 ]... Prev New and Changed Information Up Home Next Chapter 1.
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 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 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.
not supported for production use). For more information on JORB Lite, 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.
Services Shell and Utilities Reference Manual. Most OSS commands have direct counterparts in UNIX, although some commands and utilities are unique to OSS. In some cases, OSS extends a UNIX command to provide access to features of the NonStop Kernel. To get online information about OSS commands and utilities, use the man command (an abbreviation for manual).
> export NSD_ROOT=/usr/tandem/nsdoms > export JAVA_HOME=/usr/tandem/java > export JREHOME=$JAVA_HOME/jre > export CLASSPATH=.:$NSD_ROOT/lib/jorb.jar:$NSD_ROOT/lib/jts.jar:$NSD_ROOT/lib/ejb.jar > export PATH=$PATH:$NSD_ROOT/bin:$COMP_ROOT/usr/lib:$JAVA_HOME/bin $NSD_ROOT designates the root directory where NonStop CORBA files reside. This guide sometimes refers to directory names relative to $NSD_ROOT; in these cases, the notation $NSD_ROOT means your setting of the NSD_ROOT variable.
in the NonStop Server for Java (NSJ) Tools Reference Pages. Working in the NonStop CORBA Administrative Environment Applications that you write use services provided by the NonStop CORBA administrative environment. This section gives a brief overview of the administrative environment. For more information on the NonStop CORBA administrative environment, see the NonStop CORBA 2.3 Administration Guide.
● Object Transaction Service (OTS) ● OTS Transaction ID Broker (XID) When you use the Console to make configuration changes, it stores the changes in the configuration database. The Console software also checks entries to make sure they fall between allowed ranges. If you change one field in the Console screens that has dependencies on other fields, the Console will either automatically make changes to the other fields or leave them blank, prompting you to fill in a value.
default@ORB entity is used. This entity acts as a subsystem configuration domain for any settings not found in an application's profile@ORB entity. If you don't set them in the application's profile, the default@ORB entity sets the log filename, trace filename, url_path name, and interface repository filename. See the NonStop CORBA 2.3 Administration Guide for a complete listing of the default@ORB entity settings.
Default is true. 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 -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. -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.
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.
environments, see the TS/MP System Management Manual (note that in TS/MP documentation, server pools are called server classes). The following sample OSS script illustrates how the environment might be configured: In the following script, the trace settings have been disabled by placing the comment character open bracket [ in front of the line. For more information about tracing see Tracing and Debugging Applications. # # Bank server PATHMON start-up and configuration script.
PMLOG=$(info_define -detail =_DEFAULTS | awk '/VOLUME/ {print $3}').
set server env BANK_CFG_LOG=TRUE 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 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 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 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 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.
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
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 NonStop CO
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.
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 a Server Pool a
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 calling the trace facility,
implementation components, Components of Transaction Service Implementation TransactionalObject interface, TransactionalObject Interface Transactions checked, Checked Transaction Behavior design considerations for, Designing a Client in NonStop CORBA applications, Managing Transactions propagation of context, TransactionalObject Interface setting timeout for, Transaction Branches and the Diamond Access Problem Transient objects, State Policy Transparency of objects, local/remote, Designing a Client Transpor
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.
