package-summary.html

API資料大全

    reference or between a name and a naming context
    </OL>
    <P>
    The interface <code>NamingContext</code> has methods for
	binding/unbinding names with object references or naming contexts,
	for listing bindings,
    and for resolving bindings (given a name, the method
    <code>resolve</code> returns the object reference bound to it).
   
  <P>
  <LI><code>public final class <B>BindingType</B></code> --
    an object that specifies whether the given <code>Binding</code>
    object is a binding between a name and an object reference (that is,
    not a naming context) or between a name and a naming context.
    <P>
    The class<code>BindingType</code> consists of two methods and
	four constants. Two of these constants are
	<code>BindingType</code> objects, and two are <code>int</code>s.
	<P>
	The <code>BindingType</code> objects
    can be passed to the constructor for the class
    <code>Binding</code> or used as parameters or return values.  These
	<code>BindingType</code> objects are:
    <UL>
    <LI><code>public static final BindingType <B>nobject</B></code> -- 
	to indicate that the binding is with an object reference
    <LI><code>public static final BindingType <B>ncontext</B></code> -- 
	to indicate that the binding is with a naming context
    </UL>
    <P>
	The <code>int</code> constants can be supplied to the method
	<code>from_int</code> to create  <code>BindingType</code> objects,
	or they can be return values for the method <code>value</code>.
	These constants are:
	<UL>
    <LI><code>public static final int <B>_nobject</B></code>
    <LI><code>public static final int <B>_ncontext</B></code>
	</UL>
    If the method <code>from_int</code> is supplied with anything other
	than <code>_nobject</code>
    or <code>_ncontext</code>, it will throw
	the exception <code>org.omg.CORBA.BAD_PARAM</code>. 
	<P>Usage is as follows:
    <PRE>
       BindingType btObject = from_int(_nobject);
       BindingType btContext = from_int(_ncontext);
    </PRE>
    The variable <code>btObject</code> refers to a <code>BindingType</code>
    object initialized to represent a binding with an object reference.
    The variable <code>btContext</code> refers to a <code>BindingType</code>
    object initialized to represent a binding with a
    <code>NamingContex</code> object.
    <P>
    The method <code>value</code> returns either
    <code>_nobject</code> or <code>_ncontext</code>, so
    in the following line of code, the variable <code>bt</code>
    will contain <code>_nobject</code> or <code>_ncontext</code>:
    <PRE>
       int bt = BindingType.value();
    </PRE>
  </UL>
  
  <H3>Holder Classes</H3>
 
  OMG IDL uses OUT and INOUT parameters for returning values from operations.
  The mapping to the Java programming language, which does not have OUT
  and INOUT parameters, creates a special class for each type, called
  a holder class. 
  An instance of a holder class can be passed to a
  Java method as a parameter, and
  a value can be assigned to its <code>value</code> field.  This allows
  it to perform the function of an OUT or INOUT parameter.  
  <P>The following holder classes are generated for the package
  <code>org.omg.CosNaming</code>:
  <UL>
  <LI><code>NamingContextHolder</code>
  <LI><code>BindingIteratorHolder</code>
  <LI><code>BindingHolder</code>
  <LI><code>BindingListHolder</code>
  <LI><code>BindingTypeHolder</code>
  <LI><code>NameComponentHolder</code>
  <LI><code>NameHolder</code>
  </UL>
  <P>
  Note that in the <code>org.omg.CORBA</code> package, 
  there is a holder class for each of the basic Java types:
  <code>IntHolder</code>, <code>ShortHolder</code>, 
  <code>StringHolder</code>, and so on.
  <P>
  Note also that there is a <code>NameHolder</code> class even though
  there is no <code>Name</code> class; similarly, there is a
  <code>BindingListHolder</code> class even though there is no
  <code>BindingList</code> class.  This is true because in the OMG IDL
  interface, <code>Name</code> and <code>BindingList</code> are 
  <code>typedef</code>s.  There is no mapping from an IDL 
  <code>typedef</code> to a Java construct, but holder classes
  are generated if the <code>typedef</code> is for a sequence or
  an array.  As mapped to the
  Java programming language, <code>Name</code> is an array of
  <code>NameComponent</code> objects, and a <code>BindingList</code>
  is an array of <code>Binding</code> objects.
  
  All holder classes have at least two constructors and one field:
  <UL>
  <LI><code><B>value</B></code> field -- an instance of the type being used as
    an OUT or INOUT parameter.  For example, the <code>value</code> field of a
    <code>NamingContextHolder</code> will be a <code>NamingContext</code>
    object.  
  <LI>default constructor -- a constructor that creates a new holder object
    initialized with the default value for the type.  For example, a new
    <code>BindingHolder</code> object created with the default constructor
    will have its <code>value</code> field set to <code>null</code> because
    that is the default value for an object.  Other defaults are
    <code>false</code> for  <code>boolean</code>,
    <code>0</code> for numeric and char types, and
    <code>null</code> for  object references.
  <LI>constructor from an instance -- a constructor that creates a new
    holder object whose <code>value</code> field is
    initialized with the instance supplied
  </UL>
  <P>
  A holder class for a user-defined type (a Java class) has three more
  methods, but application developers do not use them directly.
 
  <H3>Helper Classes</H3>
  Helper classes, which are generated for all user-defined types
  in an OMG IDL interface, supply static methods needed to manipulate
  those types.  
  <P>
  There is only one method in a helper class that an
  application programmer uses:  the
  method <code>narrow</code>.  Only Java interfaces mapped from IDL
  interfaces will have a helper class that includes a <code>narrow</code>
  method, so in the <code>CosNaming</code> package, only the classes
  <code>NamingContextHelper</code> and <code>BindingIteratorHelper</code>
  have a <code>narrow</code> method.
  <UL>
  <LI><code>public static NamingContext
  <B>narrow</B>(org.omg.CORBA.Object obj)</code> -- converts the given
   CORBA object to a <code>NamingContext</code> object
  <LI><code>public static BindingIterator
  <B>narrow</B>(org.omg.CORBA.Object obj)</code> -- converts the given
   CORBA object to a <code>BindingIterator</code> object
  </UL>
<H2>Package <code>org.omg.CosNaming.NamingContextPackage</code></H2>
This package supplies Helper and Holder classes for the exceptions used
in the package <code>org.omg.CosNaming</code> and also for the class
<code>NotFoundReason</code>, which supplies a reason for the exception
<code>NotFound</code>.  
<P>
There are Helper and Holder classes for the following exceptions:
<UL>
<LI><code>AlreadyBound</code>
<LI><code>CannotProceed</code>
<LI><code>InvalidName</code>
<LI><code>NotEmpty</code>
<LI><code>NotFound</code>
</UL>

<h2>Naming Service Compatibility</h2>

Sun's implementation of the <code>CosNaming</code> package complies
with the OMG <code>COSNaming</code> specification.  In other words,
the APIs in Sun's naming service are implemented according to the
guidelines for a naming service provided by OMG.  Therefore, if a 
third-party vendor has implemented a naming service that is OMG
compliant, it is possible to switch between Sun's implementation of
<code>CosNaming</code> and the third-party vendor's implementation.
However, it is important to understand that there can be minor
variations in the way different vendors implement the naming service,
such as differences in the exception strings.

<h3>Instructions for Using a Third Party's Naming Service</h3>
Although we encourage using an ORB and ORB services that are both
from one vendor, it is possible to plug in a third party's 
<code>COSNaming</code> implementation with Sun's RMI-IIOP ORB.
Here are the steps to follow:
<OL>
  <LI>Create a properties file for the Bootstrap server and give it
      two entries.  For example, you could call this properties file 
      <code>/tmp/services</code> and put the following in it:
      <code>NameService, <Stringified IOR of the Root Naming Context></code>.
      <P>
      This associates <code>NameService</code> with the Root Naming
      Context of the <code>CosNaming</code> implementation that you 
      want to use.
  <LI>Start the standalone Bootstrap server using the following command:
  <pre>
      <code>
      java -classpath $(CLASSPATH)
      com.sun.corba.ee.internal.CosNaming.BootstrapServer -InitialServicesFile
      "/tmp/services" [-ORBInitialPort port]
      </code>
  </pre>
  <P>
  Note that the square brackets at the end of the command indicate that
  specifying a port number is optional.
</OL>
<P>
Now when an application calls the method 
<code>org.omg.CORBA.ORB.resolve_initial_references</code>, CORBA
processes will contact the Bootstrap Server to get the Root Naming
Context.

<h2>Package Specification</h2>

<ul>
 <li><a href="http://www.omg.org/pub/docs/formal/97-12-10.pdf">
   OMG Naming Service Specification in pdf format</a>
 <li><a href="http://www.omg.org/pub/docs/formal/97-12-10.ps">
   OMG Naming Service Specification in ps format</a>
</ul>

<h2>Related Documentation</h2>

For an overview and examples of how to use the 
<code>CosNaming</code> API, please see:
<ul>
  <li><a href="../../../../guide/idl/jidlNaming.html">
	Naming Service</a>
</ul>
<p>
For an overview of Java&nbsp;IDL, please see:
<ul>
  <li><a href="../../../../guide/idl/index.html">
	Java&nbsp;IDL home page</a>
</ul>
<P>
<DL>
<DT><B>Since: </B><DD>JDK1.3</DD>
</DL>
<HR>

<!-- ========== START OF NAVBAR ========== -->
<A NAME="navbar_bottom"><!-- --></A>
<TABLE BORDER="0" WIDTH="100%" CELLPADDING="1" CELLSPACING="0">
<TR>
<TD COLSPAN=2 BGCOLOR="#EEEEFF" CLASS="NavBarCell1">
<A NAME="navbar_bottom_firstrow"><!-- --></A>
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="3">
  <TR ALIGN="center" VALIGN="top">
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../../overview-summary.html"><FONT CLASS="NavBarFont1"><B>Overview</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#FFFFFF" CLASS="NavBarCell1Rev"> &nbsp;<FONT CLASS="NavBarFont1Rev"><B>Package</B></FONT>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <FONT CLASS="NavBarFont1">Class</FONT>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="package-use.html"><FONT CLASS="NavBarFont1"><B>Use</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="package-tree.html"><FONT CLASS="NavBarFont1"><B>Tree</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../../deprecated-list.html"><FONT CLASS="NavBarFont1"><B>Deprecated</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../../index-files/index-1.html"><FONT CLASS="NavBarFont1"><B>Index</B></FONT></A>&nbsp;</TD>
  <TD BGCOLOR="#EEEEFF" CLASS="NavBarCell1">    <A HREF="../../../help-doc.html"><FONT CLASS="NavBarFont1"><B>Help</B></FONT></A>&nbsp;</TD>
  </TR>
</TABLE>
</TD>
<TD ALIGN="right" VALIGN="top" ROWSPAN=3><EM>
<b>Java<sup><font size=-2>TM</font></sup>&nbsp;2&nbsp;Platform<br>Std.&nbsp;Ed. v1.3</b></EM>
</TD>
</TR>

<TR>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
&nbsp;<A HREF="../../../org/omg/CORBA/TypeCodePackage/package-summary.html"><B>PREV PACKAGE</B></A>&nbsp;
&nbsp;<A HREF="../../../org/omg/CosNaming/NamingContextPackage/package-summary.html"><B>NEXT PACKAGE</B></A></FONT></TD>
<TD BGCOLOR="white" CLASS="NavBarCell2"><FONT SIZE="-2">
  <A HREF="../../../index.html" TARGET="_top"><B>FRAMES</B></A>  &nbsp;
&nbsp;<A HREF="package-summary.html" TARGET="_top"><B>NO FRAMES</B></A></FONT></TD>
</TR>
</TABLE>
<!-- =========== END OF NAVBAR =========== -->

<HR>
<font size="-1"><a href="http://java.sun.com/cgi-bin/bugreport.cgi">Submit a bug or feature</a><br>For further API reference and developer documentation, see <a href="http://java.sun.com/products/jdk/1.3/devdocs-vs-specs.html">Java 2 SDK SE Developer Documentation</a>. That documentation  contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples. <p>Java, Java 2D, and JDBC are trademarks or registered trademarks of Sun Microsystems, Inc. in the US and other countries.<br>Copyright 1993-2000 Sun Microsystems, Inc. 901 San Antonio Road<br>Palo Alto, California, 94303, U.S.A.  All Rights Reserved.</font>
</BODY>
</HTML>