Frequently Asked Questions
You may have noticed that Ice does not have a naming service along the lines of CORBA. Depending on how you create your application, no such service is necessary at all, or you can use IceGrid, which provides equivalent functionality without of all of CORBA's complexity.
An Ice client can create a proxy at any time by specifying an object identity and one or more endpoints. For example,
myobject:ssl -p 17054 -h host.acme.com
is a proxy that accesses an object with the identity myobject on port 17,054 on the machine host.acme.com. Such stringified proxies are human-readable and easy to keep up to date, and they work without the help of any additional service.
If you want to avoid hard-coding endpoint information into your code or configuration files, you can advertise key objects that clients need to bootstrap in the IceGrid registry. The stringified proxy of such an object is simply its identity. For the preceding example, if the object is registered as a well-known object, its proxy is:
myobject
This is about as simple as it can get—the object identity is the name of the object. In effect, IceGrid acts as a naming service for such objects. Because IceGrid can be replicated, well-known objects do not introduce a single point of failure.
Note that you should use well-known objects only for the handful of key objects that clients need to bootstrap. Once clients have access to these key objects, they can obtain proxies to more objects by invoking operations. For example, you may have a factory interface with a find operation that allows clients to look for specific objects. Because the find operation is implemented by the same server that hosts the objects, there is no risk of ending up with inconsistent system state, as can happen with an external naming service.
So, to answer the question, Ice does have a naming service, but one that is far simpler and more effective than the CORBA naming service (and many applications do not need even that because they can simply construct the proxies they need).
In contrast, CORBA and its naming service have quite a few problems.
Briefly, the CORBA naming service is a database of names, organized into a hierarchical structure much like a file system with directories and files. A client can contact the naming service and provide a path name, such as /mynames/myapp/startup, and the service returns an IOR (Interoperable Object Reference) that is stored under that name.
CORBA IORs are the moral equivalent of Ice proxies: CORBA clients need an IOR to invoke an operation on an object, much like Ice clients need a proxy to do the same thing. However, IORs differ from Ice proxies in an important way: CORBA IORs are opaque. CORBA clients and servers are not allowed to look inside an IOR in any way and must treat it as an opaque blob of unknown data.
Of course, this causes a problem for clients: to invoke an operation on an object, a client must have an IOR, but the only way to get the IOR is to invoke an operation. The CORBA naming service was intended to solve this chicken-and-egg problem: the client can contact the naming service to look up the IORs for the objects it is interested in and can then use the returned IORs to invoke operations. However, this extra level of indirection suffers from the very same problem, because the naming service itself is composed of objects that the client needs an IOR for. CORBA deals with this by providing an API call resolve_initial_references that can return an IOR for the naming service (as well as for other CORBA services). In fact, resolve_initial_references can be thought of as a "mini naming service", with a simpler API and a non-hierarchical namespace.
Another option for CORBA clients to obtain IORs is to read them from a local file as a string. Unfortunately, stringified IORs are large and incomprehensible to humans. Here is a typical stringified IOR:
IOR:000000000000000d49444c3a54696d653a312e300000000000000001000000 00000000f000010100000000066d6572676500060b000000d7030231310c000016 7e0000175d360aed118143582d466163653a20457348795e426e5851664e527333 3d4d7268787b72643b4b4c4e59295a526a4c3a39564628296e4345633637533d6a 2c77245879727c7b6371752b7434567d61383b3422535e514a2b48322e772f354f 245e573e69512b6b24717a412f7822265c2172772d577d303927537d5e715c5757 70784a2734385832694f3e7433483753276f4825305a2858382e4a30667577487b 3647343e3e7e5b554b21643d67613c6d367a4e784d414f7a7658606d214a45677e 272f737756642420000000000000
There is no easy way to create these IORs: a server has to create an object adapter, obtain the IOR from the adapter, and then print it out. Obviously, copying these IORs to potentially thousands of client configuration files is tedious and error-prone, which is why CORBA defined a naming service.
In a later revision of the specification, CORBA added non-opaque IORs, known as corbaloc and corbaname IORs. However, such IORs are not general-purpose because only some of the details of an IOR can be specified this way.
In summary, CORBA's choice to make IORs opaque represents one of its most serious architectural blunders. Besides other drawbacks, this choice created the need for a naming service that, otherwise, would have been completely unnecessary. To add insult to injury, IORs were made opaque not because this provided any intrinsic advantage, but because vendors were unable to agree on what IORs should contain.