Java IoT Authors: Yeshim Deniz, Liz McMillan, Zakia Bouachraoui, Pat Romanski, Courtney Abud

Related Topics: Java IoT

Java IoT: Article

JDK Naming Services: COSnaming and JNDI

JDK Naming Services: COSnaming and JNDI

Recently, a number of factors have conspired to ensure that the days of not considering or using a naming service and/or a directory service are probably numbered. The computing world has become more distributed and the resources more vast; finding these resources using naming and directory services has become pure necessity. Systems that were reasonably isolated in the past are now becoming part of large, integrated intranets, and in turn are merging or using the Internet. The upshot? A need for integrated naming and directory services.

The cost and availability of products implementing these services have made them available to a wide audience, not just the domain of large and expensive systems. With this in mind, it is no surprise to learn that future versions of Java will include facilities to make it easier for everyone to create applications that use naming and directory services. Specifically, JDK 1.2 will include: (1) a transient implementation of the CORBA Naming Service; (2) classes and interfaces to communicate with a CORBA Naming Service; and (3) the Java Naming & Directory Interface (JNDI) as a standard extension to enable access within Java to any naming or directory service.

This will bring the world of naming and directory services to everyone in the Java world, and probably means that a naming service should be standard in every Java application. This article focuses on the naming services and explains:

  • What a naming service and directory service are
  • The CORBA Naming Service
  • How to use the CORBA naming service facilities included in JDK 1.2
  • JNDI 1.1

    What are naming and directory services? A naming service lets you find resources in a distributed system using human-readable names. This contrasts with a directory service that provides a database of information about the resources in the distributed system and how to interact with them. By its very nature, a directory service incorporates a naming service. Sometimes these services are so closely intertwined that it is difficult to distinguish between the two. From a Java application development perspective, our interest in this article is the naming service, the interface we deal with, not the underlying directory service.

    The CORBA Naming Service
    This service (also known as the Common Object Services Naming Service - CosNaming for short) became an OMG standard in September 1993. It provides a principal mechanism through which an ORB-based system can locate objects it intends to use. The purpose of the service was not to reinvent new naming and directory services, but to provide an object-oriented interface to existing nonobject-based name and directory services, such as the DCE CDS, ISO X.500, Sun NIS+ and the Internet's LDAP. Key design points for the specification included the following:

  • The design imparts no semantics or interpretation of the names themselves.
  • Clients need not be aware of the physical location of the name servers.
  • Existing names and directory services employed in different network computing environments can be encapsulated transparently using name contexts.

    Because the CORBA Naming Service is a specification, it can have many different implementations and clients may differ in how they use it. Although it is possible to find an object using the standard "mini-naming service" provided by the standard ORB object invocation services, the CORBA service provides significant advantages:

  • An object's interface name is defined at compile time. To change an interface name requires that you recompile your applications. A naming service, on the other hand, allows object implementations to bind logical names to its' objects at runtime.
  • An object may implement only one interface name, but the naming service allows you to bind more than one logical name to a single object. (When I mention a naming service in this article, I will be referring to the CORBA Naming Service.)

    The naming service maps human-readable names to object references and stores those names in a namespace. This name-to-object reference is called a name binding. To resolve a name means to find the object associated with the name. To bind a name is to create a name-to-object association. You have the option to associate one or more names with an object reference. Every object has a unique reference. The naming service organizes the namespace in a treelike structure of naming contexts. A naming context contains a list of one or more names that have been bound to an object or to another naming context object. Name context hierarchies enable clients to navigate through the different naming context trees to find the objects they want. Naming contexts from different domains can be used together to create federated name services for objects.

    You can reference an object using a sequence of names that forms a hierarchical naming tree. This sequence of names is known as a compound name. You always define a name relative to its naming context. The last component in the compound name is known as the object's simple name. You can start from any context and use a sequence of names to resolve a name. An example structure of a CORBA Naming Service is shown in Figure 1; a compound name would be /Offices/Australia/Melbourne/David, where Offices, Australia and Melbourne are the context names and David is the simple name

    The Java Interfaces
    All CORBA interfaces are defined using the language-neutral OMG Interface Definition Language (IDL). The OMG then provides language-specific mappings from the OMG IDL to Java (see the OMG IDL-to-Java Language Mapping document orbos/98-01-06 Final), enabling implementation of the CORBA interfaces in Java. The CosNaming module (mapped to the org.omg.CosNaming package in Java) provides all the interfaces required by the CORBA Naming Service with the resulting key Java interfaces as follows:

  • NamingContext: This, the central interface in CosNaming, provides operations to bind names to object references and creates subcontexts to resolve names to object references.
  • NameComponent: This represents the names, defined as sequences of NameComponent objects. All that is really required is to set the id for the NameComponent.
  • BindingIterator: The NamingContext list method returns a BindingIterator object that enables you to iterate on a set of names and thus traverse the naming hierarchy.

    Specific Java ORB vendors implement these interfaces to provide the specific services and functionality of their products.

    How To Use the Naming Service
    NamingContext and BindingIterator are the two key interfaces that implement the naming service. NamingContext objects contain a set of name-to-object bindings. The new_context method returns a naming context. The bind_new_context method creates a new context and binds it to the name you supply. You invoke the bind method on the NamingContext object to associate an object's name with a naming context. You can use rebind to bind a name that already exists; this will create a naming hierarchy. You unbind to remove a name from a binding context. Finally, the destroy method deletes a naming context.

    You can find a named object by using the resolve method. This will retrieve an object bound to a name in a given context. You can then use the list method, which returns a BindingIterator object to iterate through a returned set of names.

    Using the CORBA Naming Service in JDK 1.2
    JDK 1.2 comes with the following:

  • Java IDL Object Request Broker: This is compliant with the CORBA/IIOP 2.0 Specification (OMG document orbos/97-02-25) and supports transient CORBA objects - objects with lifetimes limited by their server process' lifetime.
  • Java Mapping of the CORBA Specifications contained in the following packages: - org.omg.CORBA contains the core CORBA interfaces and classes.
    - org.omg.CORBA.ContainedPackage contains a class describing a CORBA object in a CORBA container.
    - org.omg.CORBA.ContainerPackage contains a class describing a CORBA container object.
    - org.omg.CORBA.InterfaceDefPackage contains a class that is the description of a CORBA interface definition.
    - org.omg.CORBA.ORBPackage contains a class for the CORBA InvalidName exception. - org.omg.CORBA.portable contains classes and interfaces for developing ORB implementations.
    - org.omg.CORBA.TypeCodePackage contains classes for CORBA exception that can be thrown by TypeCode operations.
    - org.omg.CosNaming contains classes and interfaces for communicating with the CORBA Naming Service.
    - org.omg.CosNaming.NamingContextPackage contains helper and holder classes for CORBA exceptions that can be thrown by the CORBA Naming Service.
  • Transient CORBA Naming Service, tnameserv, stored in the bin directory: This service does not store any namespace information and all namespace data is lost once the naming service is closed. This provides a base implementation so that developers can test their applications, but a full persistent implementation will require the purchase of a commercial naming service.

    In addition to these components included in the JDK, you can also download the idltojava compiler free from the Java Developer Connection. idltojava is hard-coded to use a default preprocessor. On Windows machines it uses the MS Visual C++ preprocessor (although this can be changed). Therefore, to use idletojava you have to have a compatible preprocessor.

    Using the JDK 1.2 Naming Service
    The following example shows how to develop a simple application using the JDK 1.2 naming service. A more complex example could have been created, but this simple one is excellent for the purpose. We will create a distributed version of the "Hello World" application. For all intents and purposes, it will operate as a standard ORB-based application except that we will use a naming service to find the object instead of letting the ORB try and find it. The "Hello World" program has a single operation that returns a string to be printed.

    The resulting application will operate as follows: the JDK 1.2 tnameserv will be started. A HelloServer will be started and this will:

  • Create and initialize the ORB (the default ORB in JDK 1.2).
  • Create a HelloServer and register it with the ORB.
  • Get the root naming context from the transient naming service.
  • Bind an object reference of the HelloServer to the name "Hello" in the naming context.
  • Wait for invocations from the client.

    A HelloClient will be started and this will:

  • Create and initialize the ORB.
  • Get the root naming context from the transient naming service.
  • Use the naming context to resolve the object named "Hello" to an object reference. This will return an object reference to the remote HelloServer.
  • Use the object reference and call the HelloServer's sayHello() method. The ORB will handle the communications and the operation will return a string from the remote HelloServer.
  • Print the string returned from the HelloServer.

    Creating the Application
    Step 1: Create a simple Hello interface in hello.idl as follows:
    module HelloApp
    interface Hello
    string sayHello();

    Step 2: Use the idltojava compiler as follows to compile the hello.idl file into the required Java mapping:
    idltojava Hello.idl

    This will automatically produce the following files (do not modify them):

    Step 3: Use the JDK 1.2 Java compiler and compile the foregoing classes:
    javac *.java

    Step 4: Create the HelloServer.java source file as in Listing 1.

    Key points of the code include the following: HelloServant extends the _HelloImplBase server-side skeleton automatically created by the idltojava compiler. Typically, a naming context is passed to a naming server when it is started. You will always invoke resolve_initial_references to obtain the initial naming context regardless of how the ORB finds it. The ORB method resolve_initial_references returns a reference of type Object so we must narrow it to the derived NamingContext type. The NamingContextHelper is a helper object automatically generated by the idltojava compiler. We create a naming context called "Hello" and rebind it relative to the initial naming context.

    Step 5: Create the HelloClient.java source file as in Listing 2.

    Key points of the code include the following: we use almost exactly the same process as HelloServant except that instead of binding a name to a naming context, we resolve a name. The resolve returns an object reference with which we can invoke methods: in this case, the sayHello() method.

    Step 6: Compile HelloServer.java and HelloClient.java, ensuring that the HelloApp package is correctly referenced in your classpath.

    javac HelloServer.java HelloClient.java

    Running the Application
    Step 1: Start the transient naming service.
    tnameserv -ORBInitialPort 900

    Step 2: Start the HelloServer.
    java HelloServer -ORBInitialPort 900

    Step 3: Start the HelloClient.
    java HelloClient -ORBInitialPort 900

    The outcome is that the HelloClient will print the string "Hello World" to the console.

    Using Other CORBA Naming Services
    You may decide that the transient naming service is not enough for your production system, that you want to use something like Iona's ORBIX or Borland's VisiBroker in production. This will require no changes to the previous example. All you need to do is start the required naming service and ensure that the clients and servers use the correct port. That's it! The following shows the same example being run using Borland's VisiBroker.

    Step 1: Start the VisiBroker Smart Agent.
    start osagent -c

    Step 2: Start the naming service.

    java -DORBservices=CosNaming
    -DSVnameroot=HelloTest -DJDKrenameBug
    Factory HelloTest namingLog

    -DORBservices=CosNaming is a required parameter for initializing the ORB to use the naming service. -DSVnameroot=HelloTest sets the root context for the naming service. -DJDKrenameBug is a work around for a bug in the Windows JDK.

    Step 3: Start the HelloServer.
    java -DORBservices=CosNaming
    -DSVnameroot=HelloTest HelloServer

    Step 4: Start the HelloClient.
    java -DORBservices=CosNaming
    -DSVnameroot=HelloTest HelloClient

    JNDI, a new addition to the Java APIs, provides Java with a unified interface to multiple naming and directory services. It doesn't matter what underlying implementations you use because your interface at the application level will always be the same.

    JNDI provides both an API for almost all software developers and a Service Provider Interface (SPI) for the underlying service providers. These interfaces are contained in three packages:

  • javax.naming for the naming operations
  • javax.naming.directory for the directory operations
  • javax.naming.spi, which contains the SPI

    JNDI has the following key benefits:

  • It integrates multiple naming and directory interfaces into a single interface.
  • It takes advantage of the Java environment by using native Java objects for all processing.

    As a result, messy object type conversions are eliminated. The API is simple and clean. As with all Java APIs, a lot can be done with a little.

    The Naming Interface
    The core interface in javax.naming is Context. Like NamingContext in the CORBA specifications, it defines basic operations such as adding a name-to-object binding, looking up the object bound to a specified name, listing the bindings, removing a name-to-object binding and creating and destroying subcontexts, etc. Of all the operations, lookup() will probably be used most often. This will return an object of whatever class is required by the Java application. One deals with complete Java objects and not generic Java wrappers. This approach differs from the CORBA approach in which data is described and wrapped by generic objects. The JNDI approach makes it much easier and cleaner to deal with naming services in the Java world while still having the flexibility of the world promised by the CORBA Naming Service.

    Other key classes and interfaces in javax.naming include:

  • Binding, which represents a name-to-object binding found in a context
  • CompositeName, which represents a composite name that is a sequence of component names spanning multiple namespaces
  • CompoundName, which represents a name from a hierarchical namespace
  • InitialContext, which is the starting context for performing naming operations
  • Name, which represents a generic name
  • Reference, which represents a reference to an object found outside the naming/directory system

    The Directory Interface
    Unlike the CORBA Naming Service, JNDI extends its world to include the directory service. The DirContext interface enables the directory capability by defining methods for examining and updating attributes associated with a directory object. Each directory object contains a set of zero or more objects of the class Attribute. An Attribute represents an attribute associated with a named object and is denoted by a string identifier; it can have zero or more values of any type.

    Once again, DirContext.search() will probably be the most commonly used operation. This supports content-based searching and returns the matching directory objects along with the requested attributes. Other key classes and interfaces in javax.naming.directory:

  • Attributes represent a collection of attributes.
  • InitialDirContext is the starting context for performing directory operations.
  • SearchControls encapsulates factors that determine the scope of search and what gets returned as a result of the search.
  • SearchResult represents an item returned as a result of the DirContext.search() methods.

    The Service Provider Interface
    The SPI provides a way for service providers to develop and hook up their naming and directory implementations to the JNDI. JNDI allows specification of names that span multiple namespaces. Thus the SPI provider methods allow different provider implementations to cooperate so as to complete client JNDI operations.

    Service Provider Reference Implementations
    In addition to providing the SPI, JNDI 1.1 also provides reference implementations for the following naming and directory services:

  • CORBA Naming Service (as used in the following example)
  • LDAPv3
  • NIS
  • File system

    Most major naming and directory service vendors have made a commitment to support JNDI and develop specialized SPI implementations. To use these reference implementations, JNDI 1.1 requires that certain environment variables or system properties be set, thus providing JNDI with information on the service provider configuration. This may not be how commercial providers implement their solutions, but it is a good way to ensure that the required settings are not hard-coded into the solution. All reference implementations require you to set the java.naming.factory.initial system property to the name of the factory class that produces the initial context implementation (you set system properties via the -D switch when you run java). Some service provider reference implementations also require the setting of specialist properties as in Listing 3.

    In addition, with the CosNaming server provider reference implementation, you will also need to set java.naming.corba.orb (see the next example and Listing 4).

    The Outcome
    This example will do exactly the same as the JDK 1.2 example previously outlined, except that instead of using the CORBA APIs we will use the JNDI APIs. This will also use the reference implementation of the CosNaming SPI provided in the JNDI 1.1.

    Creating the Application
    Steps 1 to 3 are the same as for the previous JDK 1.2 example.

    Step 4: Create the HelloServer2.java source file as in Listing 4. Key differences with this version of HelloServer2 (compared to HelloServer) are that our process to get a naming context is considerably easier. Instead of calling resolve_initial_references and then narrowing the object using NamingContextHelper in the CORBA naming service example, with the JNDI example all we do is create a new InitialContext. In addition, in the CORBA naming service example we create a NameComponent and rebind that to the naming context, whereas in the JNDI example we can rebind the object directly, making the process much simpler.

    Step 5: Create the HelloClient2.java source file as in Listing 5. Key differences with this version of HelloClient2 (compared to HelloClient) are that our process to get a naming context is considerably easier. Instead of calling resolve_initial_references and then narrowing the object using NamingContextHelper as in the CORBA naming service example, with the JNDI example all we do is create a new InitialContext. Note that the InitialContext has been set using the environment variable set at java.naming.corba.orb (this is not required, but is a nice implementation approach). In the CORBA naming service example we create a NameComponent and resolve that to the naming context; in the JNDI example we can look up the object directly, making the process much simpler.

    Step 6: Compile HelloServer2.java and HelloClient2.java ensuring that the HelloApp package is correctly referenced in your classpath.
    javac HelloServer2.java HelloClient2.java

    Running the Application
    Step 1: Start the transient naming service.
    tnameserv -ORBInitialPort 900

    Step 2: Start the HelloServer2.
    java -Djava.naming.factory.initial=com.sun.
    HelloServer2 -ORBInitialPort 900

    When running an application using JNDI we need to set the system property, telling JNDI which naming service to actually use. In this example we will use the CORBA naming service. Note that the default port for the naming service is 900. You can reset this, however, by resetting the org.omg.CORBA.ORBInitialPort system property (as undertaken with the -ORBInitialPort argument above).

    Step 3: Start the HelloClient2.
    java -Djava.naming.factory.initial=com.sun.
    HelloClient2 -ORBInitialPort 900

    Naming services provide a way to find resources using names. In a world of increasing complexity and interconnectivity, it has now become mandatory to use these services. Therefore, no matter how simple your Java application is, you should seriously consider designing and implementing it so that it uses a naming service to find the resources required by your application. The new version of the JDK makes the choice of using a CORBA Naming Service easy as one is provided free in the JDK itself. Although this will not provide all the functionality you need - after all, it's only a transient service - it will give you everything you need to develop an application that uses a naming service. That's half the battle. As can be seen from the examples, using a naming service is not really a complex process, but they add much power and flexibility to the implementation of your applications.

    With the advent of JDK 1.2, Java now brings the use of CORBA Naming Services to the masses. However, the additional introduction of JNDI 1.1 extends this functionality so you can use any naming service and any directory service as well. For the first time, the power of both services is integrated into a simple implementation independent Java API. The JNDI allows you to go beyond just CORBA Naming Services to provide an integration point for all naming and directory services in an enterprise. By using JNDI, you can get access to any naming and directory service from anyone, anywhere, anytime, and thus increase the power of Java as a key tool in the enterprises of the future.

  • More Stories By David Cittadini

    David Cittadini is based in Melbourne, Australia, and is a director of software development and consulting companies in Australia and New Zealand. He specializes in developing and consulting in leading-edge technologies, enterprise architectures and distributed enterprise systems. He is a member of the OMG and is also a Sun-certified Java developer.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

    IoT & Smart Cities Stories
    After years of investments and acquisitions, CloudBlue was created with the goal of building the world's only hyperscale digital platform with an increasingly infinite ecosystem and proven go-to-market services. The result? An unmatched platform that helps customers streamline cloud operations, save time and money, and revolutionize their businesses overnight. Today, the platform operates in more than 45 countries and powers more than 200 of the world's largest cloud marketplaces, managing mo...
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
    When Enterprises started adopting Hadoop-based Big Data environments over the last ten years, they were mainly on-premise deployments. Organizations would spin up and manage large Hadoop clusters, where they would funnel exabytes or petabytes of unstructured data.However, over the last few years the economics of maintaining this enormous infrastructure compared with the elastic scalability of viable cloud options has changed this equation. The growth of cloud storage, cloud-managed big data e...
    The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
    Your applications have evolved, your computing needs are changing, and your servers have become more and more dense. But your data center hasn't changed so you can't get the benefits of cheaper, better, smaller, faster... until now. Colovore is Silicon Valley's premier provider of high-density colocation solutions that are a perfect fit for companies operating modern, high-performance hardware. No other Bay Area colo provider can match our density, operating efficiency, and ease of scalability.
    CloudEXPO has been the M&A capital for Cloud companies for more than a decade with memorable acquisition news stories which came out of CloudEXPO expo floor. DevOpsSUMMIT New York faculty member Greg Bledsoe shared his views on IBM's Red Hat acquisition live from NASDAQ floor. Acquisition news was announced during CloudEXPO New York which took place November 12-13, 2019 in New York City.
    At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
    Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust tha...
    The graph represents a network of 1,329 Twitter users whose recent tweets contained "#DevOps", or who were replied to or mentioned in those tweets, taken from a data set limited to a maximum of 18,000 tweets. The network was obtained from Twitter on Thursday, 10 January 2019 at 23:50 UTC. The tweets in the network were tweeted over the 7-hour, 6-minute period from Thursday, 10 January 2019 at 16:29 UTC to Thursday, 10 January 2019 at 23:36 UTC. Additional tweets that were mentioned in this...
    Today's workforce is trading their cubicles and corporate desktops in favor of an any-location, any-device work style. And as digital natives make up more and more of the modern workforce, the appetite for user-friendly, cloud-based services grows. The center of work is shifting to the user and to the cloud. But managing a proliferation of SaaS, web, and mobile apps running on any number of clouds and devices is unwieldy and increases security risks. Steve Wilson, Citrix Vice President of Cloud,...