Previous Up Next

Chapter 12  The corbaloc and corbaname URLs

12.1  Introduction

URLs used on the world wide web (WWW) begin with the name of a protocol, followed by ":", for example, "http:", "ftp:" or "file:". A stringified object reference (Section 3.4.2) begins with "IOR:" so this also looks similar to a URL.

In early versions of CORBA, the only kind of string parameter that could be passed to string_to_object() (Section 3.4.2) was a stringified object reference. CORBA has now matured to allow other URL-like strings to be passed as parameters to string_to_object(). A CORBA product may optionally support the "http:", "ftp:" and "file:" formats. The semantics of these is that they provide details of how to download a stringified IOR (or, recursively, download another URL that will eventually provide a stringified IOR).

Although support for "http:", "ftp:" and "file:" is optional, all CORBA products must support "corbaloc:" and "corbaname:", which are two URLs defined by the OMG. The purpose of these is to provide a human readable/editable way to specify a location where an IOR can be obtained.

12.2  The corbaloc URL

Some examples of corbaloc URLs are shown below:


The first URL specifies that an IOR can be obtained by using version 1.2 of the IIOP protocol to send a LocateRequest message (Section 11.3.2) with parameter "NameService" to port 3075 on host host1.

The second URL is different in two ways. First, by omitting "1.2@", it uses the default version (1.0) of the IIOP protocol. Second, the URL specifies two <host>:<port> addresses rather than one. In general, any number of <host>:<port> addresses can be specified, separated by commas. This second form is used to provide fault tolerance: the LocateRequest message will be sent to one of the addresses in the list; if that <host>:<port> cannot be contacted then another address in the list will be tried, and so on.

Many parts of the corbaloc URL have default values:

The CORBA specification currently specifies two protocols that can be used in corbaloc URLs. One protocol is iiop, which has already been discussed. The other protocol is called rir, which seems like a strange name until you realize that it is an acronym for resolve initial references. Unsurprisingly, this protocol specifies that an object reference should be obtained by calling the resolve_initial_references() operation (Section 3.4.1), passing the specified name as a parameter. For example, the corbaloc URL below specifies that an IOR should be obtained by calling resolve_initial_references("NameService"):


One benefit of the rir protocol is that it allows string_to_object() to subsume the functionality of resolve_initial_references(). For example, instead of an application being hard-coded to find the Naming Service by calling resolve_initial_references("NameService"), an application can now be hard-coded to find the Naming Service by obtaining a string from a command-line argument or a configuration file and passing this to string_to_object(). If the string happens to be "corbaloc:rir:/NameService" then it is just as if the programmer had used resolve_initial_references(), but now there is the flexibility for the string parameter to be a stringified IOR or a corbaloc URL that uses the iiop protocol. In this way, applications have some extra flexibility in how they find a CORBA Service.

The rir protocol is not used often in corbaloc URLs. However, it is used more commonly in corbaname URLs, which I now discuss.

12.3  The corbaname URL

A corbaname URL is a corbaloc that specifies how to contact the Naming Service, followed by "#" and then a name within the Naming Service. Some examples are shown below:

Passing of the above strings as a parameter to string_to_object() causes the Naming Service to be located and resolve_str() to be invoked to obtain an IOR from the Naming Service. As the above examples illustrates, a corbaname URL can use either the iiop or rir protocols to locate the Naming Service.

12.4  Architectural Support for corbaloc

12.4.1  Client-side Support for corbaloc

The string_to_object() operation has built-in support for corbaloc and corbaname URLs:

12.4.2  Server-side Support for corbaloc

CORBA does not standardize the server-side support for corbaloc URLs, nor even the terminology for this server-side support. This means that CORBA products provide proprietary mechanisms, often with proprietary terminology. For example:

As can be seen, each CORBA product has its own different “look and feel” for server-side support of corbaloc URLs. Because of this, there is no portable way for a CORBA server to use a corbaloc URL to advertise one of its own objects. Developers concerned with writing portable CORBA applications should use corbaloc URLs only for CORBA Services, for example, the Naming Service, Notification Service, Trading Service and so on.

12.5  Bootstrapping Interoperability Problems

One obvious requirement for interoperability between different CORBA products is that they must be able to speak the same on-the-wire protocol (IIOP). However, that by itself it not sufficient. Another, less obvious requirement for interoperability is for one CORBA product to be able to find, say, the Naming Service or the Notification Service of another CORBA product. For example, how can an Orbix client find (connect to) the Naming Service of an Orbacus installation. This is often called a bootstrapping problem. The corbaloc and corbaname URLs were invented to address such bootstrapping issues, as I now discuss.

A CORBA application connects to a CORBA Service—for example, the Naming Service, Transaction Service, Notification Service, and so on—by calling resolve_initial_references() and passing the name of the desired service as a parameter. The CORBA specification does not specify how resolve_initial_references() works (that is an implementation detail), but in most CORBA products this operation looks in a configuration file to find a name-of-CORBA-servicestringified-IOR mapping1 and then passes the stringified IOR as a parameter to string_to_object(). These mappings are normally set up during the installation and configuration of a CORBA product. To configure, say, Orbix to use an Orbacus Naming Service is a matter of obtaining a stringified IOR of the Orbacus Naming Service (typically from the Orbacus configuration file) and copying this into the Orbix configuration file. Then the next time an Orbix client calls resolve_initial_references("NameService"), the client will be directed towards the Orbacus Naming Service. This technique works fine, but it is a bit cumbersome because stringified IORs are not human readable. However, with the introduction of corbaloc URLs, the technique becomes much easier. Now, instead of copying a stringified IOR of the Orbacus Naming Service into the Orbix configuration file, it is sufficient to copy a corbaloc URL into the Orbix configuration file. The fact that corbaloc URLs are easy to read (and edit) by humans makes it more feasible for an organization to use several different CORBA products.2

Sometimes, practical or organizational issues may make it awkward to update a configuration file with a stringified IOR or corbaloc URL for, say, the Naming Service of another CORBA product. To work around this, the OMG defined two standard command-line options that all CORBA products must support.3

The first command-line option takes the form:

-ORBInitRef <name>=<value>

An example is shown below:

-ORBInitRef NameService=corbaloc::host1:3075/NameService

The <value> in <name>=<value> is a stringified IOR or URL that is used if resolve_initial_references() is called with "<name>" passed as a parameter. This command-line argument takes precedence over any corresponding information in the CORBA product’s configuration file. You need to specify this command-line option each time you run an application, so regular use of it can get somewhat tedious. However, this command-line option is useful if, for example, restrictive file permissions prevent you from modifying the configuration file of a CORBA installation. It can be useful also when trouble-shooting a connectivity problems in a network.

The second command-line option takes the form:

-ORBDefaultInitRef <URL-up-to-but-not-including-final-"/">

Some examples are shown below:

-ORBDefaultInitRef corbaloc:iiop:1.2@host1:3075
-ORBDefaultInitRef corbaname::host1/NameService#x/y

A call to resolve_initial_references("<name>"), results in "/<name>" being appended to the string provided by the command-line argument after -ORBDefaultInitRef; the result of this string concatenation is then passed as a parameter to string_to_object().

The intention of -ORBDefaultInitRef is that a user can set up a centralized store of name  IOR mappings and then applications can be started with a single -ORBDefaultInitRef command-line argument that points to this centralized store. This is usually more convenient than starting many applications, each with several -ORBInitRef command-line arguments.

You need to specify the -ORBDefaultInitRef command-line option each time you run an application so, just as with -ORBInitRef, regular use of it can get tedious. In general, it is usually more convenient to create or modify a configuration file for a CORBA installation than to use these command-line options every time you run a CORBA-based application.

If both -ORBInitRef and -ORBDefaultInitRef command-line arguments are used then the -ORBInitRef arguments take precedence.

For example, the entry in the Orbacus configuration file is called ooc.orb.service.<service>. The corresponding entry in the Orbix configuration file is called initial_references:<service>:reference.
It is rare for an organization to deliberately decide to use several CORBA products. However, several CORBA products may make their way into an organization if different departments or development teams make independent choices about which middleware technology they will use, or if the development of CORBA applications is outsourced to other organizations.
When a CORBA application calls ORB_init(), it passes command-line arguments as a parameter to ORB_init(). This provides the mechanism by which command-line arguments are communicated to the CORBA runtime system.

Previous Up Next