duke@1: The package and all its classes and interfaces
duke@1: were generated by running the tool idlj on the file
duke@1: nameservice.idl, which is a module written in OMG IDL.
duke@1:
duke@1:
For a precise list of supported sections of official specifications with which duke@1: the Java[tm] Platform, Standard Edition 6, ORB complies, see Official Specifications for CORBA duke@1: support in Java[tm] SE 6. duke@1:
duke@1:
duke@1: The interfaces are: duke@1:
duke@1: These two interfaces provide the means to bind/unbind names and object
duke@1: references, to retrieve bound object references, and
duke@1: to iterate through a list of bindings. The NamingContext
duke@1: interface supplies the main functionality for the naming service, and
duke@1: BindingIterator provides a means of iterating through a list
duke@1: of name/object reference bindings.
duke@1:
duke@1:
NamingContext and
duke@1: BindingIterator are included here.
duke@1: duke@1:
NamingContext and
duke@1: BindingIteratorpublic final class NameComponent --
duke@1: a building block for names. (Names are bound to object references
duke@1: in a naming context.)
duke@1: A name is an array of one or more NameComponent objects.
duke@1: A name with a single NameComponent is called
duke@1: a simple name; a name with multiple NameComponent
duke@1: objects is called a compound name.
duke@1:
duke@1: A NameComponent object consists of two fields:
duke@1:
id -- a String used as an identifier
duke@1: kind -- a String that can be used for
duke@1: any
duke@1: descriptive purpose. Its importance is that it
duke@1: can be used to describe an object without affecting syntax.
duke@1: The C programming language, for example, uses the the syntactic convention
duke@1: of appending the extension ".c" to a file name to indicate that it is
duke@1: a source code file. In a NameComponent object,
duke@1: the kind field can be used to describe the type of object
duke@1: rather than a file extension or some other syntactic convention.
duke@1: Examples of the value of the kind field include the strings
duke@1: "c_source", "object_code",
duke@1: "executable",
duke@1: "postscript", and "". It is not unusual
duke@1: for the kind field to be the empty string.
duke@1:
duke@1: In a name, each NameComponent object except the last denotes
duke@1: a NamingContext object; the last NameComponent
duke@1: object denotes the bound object reference.
duke@1: This is similar to a path name, in which the last name is the
duke@1: file name, and all names before it are directory names.
duke@1:
duke@1: duke@1:
public final class Binding --
duke@1: an object that associates a name with an object reference or a
duke@1: naming context.
duke@1: A Binding object has two fields:
duke@1: binding_name - an array of one or more
duke@1: NameComponent objects that represents the bound name
duke@1: binding_type - a BindingType object
duke@1: indicating whether the binding is between a name and an object
duke@1: reference or between a name and a naming context
duke@1:
duke@1: The interface NamingContext has methods for
duke@1: binding/unbinding names with object references or naming contexts,
duke@1: for listing bindings,
duke@1: and for resolving bindings (given a name, the method
duke@1: resolve returns the object reference bound to it).
duke@1:
duke@1:
duke@1:
public final class BindingType --
duke@1: an object that specifies whether the given Binding
duke@1: object is a binding between a name and an object reference (that is,
duke@1: not a naming context) or between a name and a naming context.
duke@1:
duke@1: The classBindingType consists of two methods and
duke@1: four constants. Two of these constants are
duke@1: BindingType objects, and two are ints.
duke@1:
duke@1: The BindingType objects
duke@1: can be passed to the constructor for the class
duke@1: Binding or used as parameters or return values. These
duke@1: BindingType objects are:
duke@1:
public static final BindingType nobject --
duke@1: to indicate that the binding is with an object reference
duke@1: public static final BindingType ncontext --
duke@1: to indicate that the binding is with a naming context
duke@1:
duke@1: The int constants can be supplied to the method
duke@1: from_int to create BindingType objects,
duke@1: or they can be return values for the method value.
duke@1: These constants are:
duke@1:
public static final int _nobject
duke@1: public static final int _ncontext
duke@1: from_int is supplied with anything other
duke@1: than _nobject
duke@1: or _ncontext, it will throw
duke@1: the exception org.omg.CORBA.BAD_PARAM.
duke@1: Usage is as follows: duke@1:
duke@1: BindingType btObject = from_int(_nobject); duke@1: BindingType btContext = from_int(_ncontext); duke@1:duke@1: The variable
btObject refers to a BindingType
duke@1: object initialized to represent a binding with an object reference.
duke@1: The variable btContext refers to a BindingType
duke@1: object initialized to represent a binding with a
duke@1: NamingContex object.
duke@1:
duke@1: The method value returns either
duke@1: _nobject or _ncontext, so
duke@1: in the following line of code, the variable bt
duke@1: will contain _nobject or _ncontext:
duke@1:
duke@1: int bt = BindingType.value(); duke@1:duke@1:
value field. This allows
duke@1: it to perform the function of an OUT or INOUT parameter.
duke@1: The following holder classes are generated for the package
duke@1: org.omg.CosNaming:
duke@1:
NamingContextHolder
duke@1: BindingIteratorHolder
duke@1: BindingHolder
duke@1: BindingListHolder
duke@1: BindingTypeHolder
duke@1: NameComponentHolder
duke@1: NameHolder
duke@1:
duke@1: Note that in the org.omg.CORBA package,
duke@1: there is a holder class for each of the basic Java types:
duke@1: IntHolder, ShortHolder,
duke@1: StringHolder, and so on.
duke@1:
duke@1: Note also that there is a NameHolder class even though
duke@1: there is no Name class; similarly, there is a
duke@1: BindingListHolder class even though there is no
duke@1: BindingList class. This is true because in the OMG IDL
duke@1: interface, Name and BindingList are
duke@1: typedefs. There is no mapping from an IDL
duke@1: typedef to a Java construct, but holder classes
duke@1: are generated if the typedef is for a sequence or
duke@1: an array. As mapped to the
duke@1: Java programming language, Name is an array of
duke@1: NameComponent objects, and a BindingList
duke@1: is an array of Binding objects.
duke@1:
duke@1: All holder classes have at least two constructors and one field:
duke@1:
value field -- an instance of the type being used as
duke@1: an OUT or INOUT parameter. For example, the value field of a
duke@1: NamingContextHolder will be a NamingContext
duke@1: object.
duke@1: BindingHolder object created with the default constructor
duke@1: will have its value field set to null because
duke@1: that is the default value for an object. Other defaults are
duke@1: false for boolean,
duke@1: 0 for numeric and char types, and
duke@1: null for object references.
duke@1: value field is
duke@1: initialized with the instance supplied
duke@1: duke@1: A holder class for a user-defined type (a Java class) has three more duke@1: methods, but application developers do not use them directly. duke@1: duke@1:
duke@1: There is only one method in a helper class that an
duke@1: application programmer uses: the
duke@1: method narrow. Only Java interfaces mapped from IDL
duke@1: interfaces will have a helper class that includes a narrow
duke@1: method, so in the CosNaming package, only the classes
duke@1: NamingContextHelper and BindingIteratorHelper
duke@1: have a narrow method.
duke@1:
public static NamingContext
duke@1: narrow(org.omg.CORBA.Object obj) -- converts the given
duke@1: CORBA object to a NamingContext object
duke@1: public static BindingIterator
duke@1: narrow(org.omg.CORBA.Object obj) -- converts the given
duke@1: CORBA object to a BindingIterator object
duke@1: org.omg.CosNaming.NamingContextPackageorg.omg.CosNaming and also for the class
duke@1: NotFoundReason, which supplies a reason for the exception
duke@1: NotFound.
duke@1: duke@1: There are Helper and Holder classes for the following exceptions: duke@1:
AlreadyBound
duke@1: CannotProceed
duke@1: InvalidName
duke@1: NotEmpty
duke@1: NotFound
duke@1: CosNaming package complies
duke@1: with the OMG COSNaming specification. In other words,
duke@1: the APIs in Sun's naming service are implemented according to the
duke@1: guidelines for a naming service provided by OMG. Therefore, if a
duke@1: third-party vendor has implemented a naming service that is OMG
duke@1: compliant, it is possible to switch between Sun's implementation of
duke@1: CosNaming and the third-party vendor's implementation.
duke@1: However, it is important to understand that there can be minor
duke@1: variations in the way different vendors implement the naming service,
duke@1: such as differences in the exception strings.
duke@1:
duke@1: COSNaming implementation with Sun's RMI-IIOP ORB.
duke@1: Here are the steps to follow:
duke@1: /tmp/services and put the following in it:
duke@1: NameService, <Stringified IOR of the Root Naming
duke@1: Context>.
duke@1:
duke@1: This associates NameService with the Root Naming
duke@1: Context of the CosNaming implementation that you
duke@1: want to use.
duke@1:
duke@1:
duke@1:
duke@1: java -classpath $(CLASSPATH)
duke@1: com.sun.corba.ee.internal.CosNaming.BootstrapServer -InitialServicesFile
duke@1: "/tmp/services" [-ORBInitialPort port]
duke@1:
duke@1:
duke@1: duke@1: Note that the square brackets at the end of the command indicate that duke@1: specifying a port number is optional. duke@1:
duke@1: Now when an application calls the method
duke@1: org.omg.CORBA.ORB.resolve_initial_references, CORBA
duke@1: processes will contact the Bootstrap Server to get the Root Naming
duke@1: Context.
duke@1:
duke@1:
CosNaming API, please see:
duke@1: duke@1: For an overview of Java IDL, please see: duke@1: