---

Chapter 3  The corbaloc and corbaname URLs

• Introduction
• The corbaloc URL
• The corbaname URL
• Architectural Support for corbaloc
• Bootstrapping Interoperability Problems

3.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 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() 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.

3.2  The corbaloc URL

Some examples of corbaloc URLs are shown below:

corbaloc:iiop:1.2@host1:3075/NameService
corbaloc:iiop:host1:3075,iiop:host2:3075/NameService

The first URL specifies that an IOR can be obtained by using version 1.2 of the IIOP protocol to send a LocateRequest message 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 default protocol is iiop.
• If the protocol is iiop then the default version of IIOP that is used is 1.0. It is advisable to specify the most recent version of IIOP that is understood by both the client and server application. This is because more modern versions of IIOP tend to have better capabilities that might make client-server interaction more efficient.
• The default port number is 2809. This is the port that the Internet Assigned Numbers Authority (www.iana.org) has assigned for use with corbaloc.

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, 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"):

corbaloc:rir:/NameService

One benefit of the rir protocol is that 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 passing "NameService" to resolve_initial_references(), 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 we now discuss.

3.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:

corbaname::foo.bar.com:2809/NameService#x/y
corbaname::host1,:host2,:host3/NameService#x/y
corbaname:rir:/NameService#x/y

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.

3.4  Architectural Support for corbaloc

3.4.1  Client-side Support for corbaloc

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

• If the parameter to string_to_object() starts with "IOR:" then the operation treats it as a stringified object reference and builds a corresponding proxy.
• If the parameter starts with "corbaloc:rir" then the string_to_object() operation calls resolve_initial_references() and passes the specified name as a parameter.
• If the parameter is a corbaloc URL that uses the iiop protocol then the operation opens a socket connection to the specified host and port, and sends a LocateRequest message, using the specified name as the object key in the header of the message. The IOR embedded in the returned LocateReply message is used as the return value of string_to_object(). An important point to note is that corbaloc is built on top of existing low-level GIOP messages so the OMG did not have to define a new version of GIOP to support corbaloc URLs.
• If the parameter to string_to_object() is a corbaname URL then the embedded corbaloc details are use to locate a Naming Service. Then string_to_object() invokes resolve_str() on the Naming Service, passing it the string after the embedded "#" as a parameter. The IOR returned from resolve_str() is used as the return value of string_to_object().

3.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:

• The Orbix implementation repository has built-in, server-side support for corbaloc URLs, and this is referred to as named keys. A named key is a mapping from the name component in a corbaloc URL to a stringified IOR. The named_key sub-commands of the itadmin administration utility are used to create, show, list and delete named keys. By default, the Orbix implementation repository listens on port 3075 so corbaloc URLs should be formatted as shown below:

          corbaloc::<host-of-IMR>:3075/<name>
          
  

  When the itconfigure utility is used to set up an Orbix domain, named keys are automatically created for whatever CORBA Services are added to the domain. For example, if the domain has a Naming Service then a named key called NameService is created. For a long time, Orbix did not expose APIs for embedding server-side corbaloc support in normal server applications. Orbix 6.1 Service Pack 1 is the first version of Orbix to expose these APIs.
• Orbacus provides some proprietary APIs (in the BootManager interface) that can be used by developers to embed server-side corbaloc support in their own server applications. These APIs are used by the Orbacus implementation repository, which looks up name→stringified-IOR mappings in a configuration file.
• TAO provides proprietary APIs that have different names, but similar semantics, to those of Orbacus.
• OmniORB server-side support for corbaloc URLs relies upon placing objects into a specific, predefined POA. OmniORB also provides a prewritten server application called omniMapper that listens on a specified port and looks up name→stringified-IOR mappings in a configuration file.

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. Having said that, the exportObjRef() utility function supports a "corbaloc_server#..." format of instructions (page ??) that encapsulates the proprietary APIs of Orbix, Orbacus, TAO and omniORB. Developers concerned with writing applications that must be portable to a wider range of CORBA products should use corbaloc URLs only for CORBA Services, for example, the Naming Service, Notification Service, Trading Service and so on.

3.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 we now discuss. A CORBA application connects to a CORBA Service—for example, the Naming 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-service→stringified-IOR mapping¹ and then passes the stringified IOR as a parameter to the string_to_object() operation. 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.² 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.³ 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, say, restrictive file permissions prevent them 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 the -ORBDefaultInitRef command-line option is that a user can set up a centralized store of name → IOR mappings. Once this has been done, 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/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.

---

1

For example, the entry in the Orbacus configuration file is ooc.orb.service.<service>. The corresponding entry in the Orbix configuration file is initial_references:<service>:reference.

2

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.

3

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.

---