CORBA 2.6.1 Programmer's Guide for Java
1. Ensure that the $NSD_ROOT/etc/env.sh file was sourced into the OSS shell environment.
2. Run the NonStop CORBA IDL compiler on all your IDL files to produce client stub files and server skeleton files (see
Using the IDL
Compiler for more information):
nsdidl -language java *.idl
Note:
Do not modify the compiler-generated files.
3. Write the client program, server program, and object implementation.
4. Compile all the source code files, including generated ones, using
javac to produce class files.
Makefiles
The NonStop CORBA sample programs use a Makefile to perform the steps involved in building an application. The Makefile describes the
program dependencies in such a way that all you have to do is run the
make command to build all the components of the application. For
example, to build the Stock sample application, be sure you are in the directory containing the copy of the Stock sample, type:
make
This command builds the interface, the server, the implementation, and finally the client.
For examples of how you might use Makefiles, see the sample programs shipped with the NonStop CORBA product. The source code for all the
samples is in the
javasamples directory. The directory for each sample contains a file called Readme, which describes how to build, configure,
and run that sample program.
The sample Makefiles use two files that are shipped with NonStop CORBA, jmacros.mk and jrules.mk, which reside in the $NSD_ROOT/etc
directory. The jmacros.mk file defines macros, and jrules.mk defines dependency rules that are useful for building any NonStop CORBA
application.
The samples vary in complexity and illustrate how to use different NonStop CORBA features, such as the Naming and Event Services, stateful
and stateless objects, application data in a NonStop SQL/MP database, and writing multithreaded applications.
Note:
The
make utility is vital in combining your program modules into a coherent application and enabling you to maintain
individual modules. For detailed information, see the Open System Services User's Guide and to the
Make (1) utility
reference page either online or in the Open System Services Shell and Utilities Reference Manual.
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 run 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.
See
Managing Transactions for additional information and design considerations for transactional applications.
Using the IDL Compiler
This section describes the NonStop CORBA Interface Definition Language (IDL) compiler. You use the IDL compiler to generate language
bindings from the interface definitions you have written in IDL for your CORBA application. (The NonStop CORBA IDL compiler was
implemented using the ANTLR parser-generator. See
www.antlr.org for information about ANTLR)
IDL Compiler Processing
To simply run the NonStop CORBA IDL compiler alone, you invoke the $NSD_ROOT/bin/nsdidl script with options and specify one or more IDL
files. These files contain IDL definitions and can also include preprocessor directives. See
IDL Compiler Syntax for a complete description of the
nsdidl command and associated options.
Preprocessing
OMG IDL preprocessing uses an ANSI C++ preprocessor to provide macro substitution, conditional compilation, and source-file inclusion.
Preprocessor directives can also provide line numbering for diagnostic messages and symbolic debugging, and support implementation-
dependent actions (the
#pragma directive). Preprocessing directives begin with a pound sign (#). Consult your ANSI C++ preprocessor
documentation for further information.
The default preprocessor invoked by the IDL compiler is called cfe. You can use the -preprocessor flag to specify a different preprocessor to
be invoked by the IDL compiler.
To use the default preprocessor, the directory containing cfe must be in the PATH environment variable. For example, to use the /usr/lib/cfe
preprocessor, run the following command from the command line or add it to your OSS .profile or env.sh file:
export PATH=”$PATH:/usr/lib”
Note:
If you change your
.profile file, be sure to source it in for the changes to take effect.