How does the EAServer naming service work?  JNDI support

Chapter 5: Naming Services

CORBA CosNaming API support

The EAServer naming service is an implementation of the CORBA CosNaming component. The CosNaming component is a collection of interfaces that defines the naming service. These interfaces provide support for object binding and lookup.

EAServer implements the NamingContext interface to bind a name to an object, thereby creating a NamingContext object. Client applications use the NamingContext interface to “resolve” a bound name to its referenced object.

CosNaming::Name represents a name context that can be bound to an object implementation or another name context. CosNaming::Name is a sequence of one or more NameComponent structures. The NameComponent consists of two attributes: the identifier and the type. Both of these attributes are represented as IDL strings.

The IDL specification for NameComponent and the NamingContext interface is:

module CosNaming
    typedef string Istring;
    struct NameComponent {
        Istring id;
        Istring kind;
    typedef sequence<NameComponent> Name;

Binding names

There are four methods to create bindings:

To remove an object reference from a name context, EAServer uses the unbind function. When you shut down the server, all bound objects are automatically unbound using this function. However, you can also use unbind when you delete a package or component from the repository. If you use persistent name storage, use unbind to remove references to deleted packages and components on the external server.

Resolving EAServer objects

EAServer uses the resolve method to retrieve an object based on the name context into which it is bound. The name context used to retrieve an object must be identical to the object’s bound name context. The naming service performs the “narrowing” of the object to the appropriate return type. In other words, the client does not need to cast the returned object to a more specialized interface.

There are two ways for Java clients to access the naming service to resolve object names:

Resolving objects using the CosNaming interface

The service provider interface (SPI) uses the CosNaming interface to connect to the EAServer name server and retrieve the CORBA Interoperable Object Reference (IOR) associated with the server’s manager object. Once the IOR is retrieved, the naming service creates a session with the manager object and then creates an instance of the requested object. The SPI returns an instance of the requested object to the client.

After initializing the ORB, call the orb.resolve_initial_references method to obtain the initial naming context. The naming context is an object that implements the CosNaming::NamingContext IDL interface; it is used to resolve EAServer component and service names to server-side objects.

The initial NamingContext has the name context that was specified in the com.sybase.CORBA.NameServiceURL ORB initialization property. Your client program invokes the NamingContext::resolve operation to obtain an instance of the EAServer authentication service as well as component instances.

The NamingContext::resolve operation takes a CosNaming::Name parameter, which is a sequence of CosNaming::NameComponent structures. The Java definitions of these types and the NamingContext::resolve operation follow:

package org.omg.CORBA.CosNaming;

class NameComponent {
  public String id;    // Represents a node in a name
  public String kind;  // Unused, can contain comments

  // Construct a NameComponent instance with the
  // specified initial values for id and kind fields
  public NameComponent(String id, String kind);

interface NamingContext {
  ... other methods not shown ...
  public org.omg.CORBA.Object resolve
   (NameComponent[] n)

In Java, a name is represented by an array of NameComponent instances, with the id field of each instance set to a node of the name. For example, the name:


can be represented by the array theName which is created in this code fragment:

import org.omg.CORBA.CosNaming.*;
import org.omg.CORBA.CosNaming.NamingContextPackage.*;
public class myApplet extends Applet {

  NamingContext nc;
  ... deleted code that retrieves initial NamingContext ...

  NameComponent theName[] = {
    new NameComponent("USA", ""), 
    new NameComponent("Sybase", ""),
    new NameComponent("Jaguar", ""),
    new NameComponent("TestPackage", ""),
    new NameComponent("TestComponent", "")
  } ;

For convenience, the naming service allows you to specify multiple nodes of a name in one NameComponent instance, using a forward slash (/) to separate nodes. The name from the example above can be represented in a one-element array as shown below:

  NameComponent theName[] = {
    new NameComponent(

NamingContext::resolve resolves a name to an object; this method either returns an org.omg.CORBA.Object instance or throws an exception.

For complete information about instantiating and resolving objects with CORBA naming services, see Chapter 12, “Creating CORBA Java Clients,” in the EAServer Programmer’s Guide.

Interoperable naming

EAServer supports interoperable naming for EJB 2.0, and implements the NamingContextExt interface, which enables you to look up objects with URLs and stringified names (an object reference converted to a string.)

The IDL specification for the NamingContextExt interface is:

module CosNaming {
  interface NamingContextExt: NamingContext{
    typedef string URLString;
    typedef string Address;
    typedef string StringName;

    StringName to_string(in Name n) raises(InvalidName);
    Name to_name(in StringName sn) raises(InvalidName);

    exception InvalidAddress{};

    URLString to_url(in Address addrkey, in StringName sn)
                     raises(InvalidAddress, InvalidName);
    Object resolve_str(in StringName n) 
                     raises(NotFound, CannotProceed, InvalidName);

The com.sybase.CORBA.ORB implementation supports corbaloc and corbaname URLs, which allow you to define object references that are more readable and easier to use than IORs. The corbaloc URL format is similar to FTP or HTTP URLs and can be modified more easily than IORs. corbaloc URLs can be used for objects that are accessible through IIOP or resolve_initial_references (rir:). This is an example of the corbaloc format that uses the rir protocol, where “NamingService” is the key string that is passed to resolve_initial_references:


When you use rir, you cannot use any other protocol. This example uses IIOP to look up the key string “Prod/TradingServices” on the host “”:

When you use the corbaloc format to reference beans on another server, you must be sure that both servers use interoperable security; for more information, see the EAServer Security Administration and Programming Guide.

A corbaname URL is similar to a corbaloc URL, but it also contains a stringified name that identifies a naming context binding. In this example, the host is “”, the key string is “dev/NContext1”, and “#” marks the beginning of the stringified name:

When an object reference does not contain an object key, the default key “NamingService” is used. In this example, “NamingService” is used to look up a NamingContext, then the stringified name “a/b/c” is used to resolve the final object:

You can reference local beans (those that run within the same Java VM by prefixing the bean name with “local:”; for instance, local:ejb/MyBean.

To define this reference using the corbaname format, use this syntax:


For information on using interoperable naming URLs for EJB 2.0 components and clients, see Chapter 9, “EAServer EJB Interoperability,” in the EAServer Programmer’s Guide.

Network name service

The Network repository type provides a mapping between a client’s location and the name servers that respond to the client’s request. A mapping specifies either an IP address to a location name, or a location name to a name server. Here are some sample network properties:

203.97.*.* = Wellington

Copyright © 2005. Sybase Inc. All rights reserved. JNDI support