Chapter 9. Scenario 2: Non-secure RPC application 177
Root contexts: Unlike a DCE CDS cell namespace, CORBA CosNaming
allows for more than one root context. (A CORBA CosNaming context can
roughly be compared with a directory in CDS.)
Object UUIDs: CORBA CosNaming does not support DCE UUIDs. In DCE,
object UUIDs are used to distinctly identify multiple interchangeable servers
by name, for example, or to identify objects inside the server application.
Management: Some implementations of CORBA CosNaming do not offer
management tools. However, the IBM WebSphere Application Server
implementation of CORBA offers the regimpl tool for management.
WebSphere supports the CORBA CosNaming service, which binds CORBA
objects to a public name. Clients are “bootstrapped” according to the CORBA
programming model. CORBA-compliant Interoperable Object References (IORs)
must be obtained, and server objects must be bound to the CORBA CosNaming
service. WebSphere also enables you to manage namespace bindings and
name servers through the administrative console.
For a detailed description of IBM WebSphere Application Server name server,
refer to chapter 13, “Using naming,” of the
IBM WebSphere Application Server
Enterprise, Version 5, Applications
. (See “Related publications” on page 421 to
learn how to download this document.)
9.2 DCE application
This section briefly describes the sample DCE dependent program, which makes
use of DCE RPC basic, namespace, and endpoint services without using DCE
security. The key DCE services that are used by this program are extracted and
explained. The complete source code can be found in Appendix B, “Scenario 2:
Source code listings” on page 331.
The application logic of the sample application again is simple: The application
client sends a string message to the application server in one parameter of the
remote procedure call. The application server, after writing the client’s message
to standard output, replies to the application client with another string message in
another parameter of the same call in reverse character order.
9.2.1 Configuring and running the DCE application
For the example to run, the directory /.:/servers has to exist in the DCE CDS
namespace. If it does not already exist, it can be created using the command:
cdscp create directory /.:/servers
(The issuer of this command has to be logged in to DCE as cell administrator.)
178 DCE Replacement Strategies
To build the application, the DCE IDL compiler has to process the IDL definition
of this example in order to produce a client and a server stub.
Start the application server by entering its executable name on the command
line. For the application client, the string message and the number of RPC calls
must be added to the command, separated by a blank. For example:
$ client_s2 “Hello World” 5
9.2.2 Application client
The client program uses a sequence of calls to the DCE naming service API
(rpc_ns_*) to obtain a partial bound bind handle to the server. It exclusively looks
for a binding using the UDP protocol. When it finds a binding handle to the
server, it immediately invokes an RPC to that server, leaving the endpoint
resolution to the DCE RPC run time. The client sample application uses to these
key services to make a connection to the server:
When calling this API, the application client passes in the server’s entry name
and the interface handle of the interface to be imported. The service returns
an import context handle to be used in the subsequent calls.
With the import context handle, created with the previous API, the application
client parses the namespace for server bindings, meeting its needs. In this
case, a binding handle to the application server is using the protocol UDP.
The application client calls this API in a loop until either no more entries are
available or a suitable binding is found. To filter out binding handles that use
UDP, the client converts the retrieved bindings into string form and performs a
After successfully retrieving a binding handle to the server, the application
client closes the import context using rpc_ns_binding_import_done.
9.2.3 Application server
The application server uses a sequence of calls to the RPC server, RPC naming
service, and RPC endpoint API (rpc_server_*, rpc_ns_*, and rpc_ep_*,
respectively), using only the UDP protocol. It exports a partial binding to its DCE
CDS name service entry /.:/servers/greet and full bindings to the local endpoint
map. When this is accomplished, it starts listening for client calls. The server
program in this example accepts a maximum of 5 concurrent client connections.