These files also serve to illustrate: some issues in starting up a persistent server.
Although the CORBA Naming service is the sanctioned CORBA method for inter-orb naming, its IDL and semantics can be complicated too learn and to use in simple applications. Unless you have an existing CORBA name service installed, you might find it easiest to use a more straightforward mechanism (see the discussion of naming in the main ORBLink documentation tree.
The detailed semantics of a CORBA naming service are discussed in any good book on CORBA. They will not be described here.
orblinkyou should load the file naming-invoke.cl and evaluate
(in-package :user) (require :orblink) (load "naming-invoke.cl") (load-naming)
This will define the class
orblink/naming:NamingContextwhich implements the IDL interface
CosNaming::NamingContextdefined in the file CosNaming.idl.
You can instantiate an instance of
You can then publish and re-use this IOR however you want.
In many situations the naming service is used expressly to avoid, or at any rate to minimize the complexity of, publishing the IOR. In certain such situations it can be convenient for the IOR to be persistent, which means that the server will always listen on the same port and on the same host (with the same marker).
(orblink/naming:start-nameserver)will create an instance of
orblink/naming:NamingContext[which, of course, is something different from the IDL compiler generated class
COSNaming:NamingContext] whose IOR is persistent over invocations. In this case, this should be the first object published; normally you will want a single Lisp world dedicated to running the nameserver.
Any other ORBLink invocation can then get the IOR of this NamingContext by invoking the
(orblink/naming:nameservice-ior)function with appropriate host keyword argument. The
(start-nameserver)invocation can fail in two ways:
orblink/naming:*default-naming-port*It is worthwhile to study the code in
naming-administration.clas it illustrates the process of creating a persistent IOR.
Of course, the code in the other .cl files can be used to study the implementation of a nontrivial IDL interface.
Here are the files used in this directory:
orblink/namingpackage and the
CosNaming::NamingContextIDL interface as the Lisp class named
This Lisp class defines a single slot,
that holds an
alist encoding the bindings managed by that naming
context. This file contains implementations for all of the
IDL-defined operations in the interface
namingcontextimplementation (that is an instance of class
orblink/naming:NamingContext, may contain bindings that point to proxies for the IDL interface
CosNaming::NamingContext. Thus, the utility functions cannot normally be invoked iteratively.
CosNaming::BindingIteratorIDL interface. The interface is implemented by a Lisp class named