This chapter is from the book
This chapter is from the book
This chapter is from the book
Federated Naming Service
The naming service supports federation; that is, distinct naming servers can be linked together to create a single naming graph. A client can then navigate seamlessly throughout the naming graph without being aware that it is federated.
The key to federation support is the operation bind_context(), declared in the following IDL fragment:
//IDL
#pragma prefix "omg.org"
module CosNaming {
...
interface NamingContext {
...
void bind_context(in Name n, in NamingContext nc)
raises(NotFound, CannotProceed, InvalidName, AlreadyBound);
...
};
...
};
The bind_context() operation binds a given naming context nc to a name n, enabling arbitrary crosslinks to be created. It is conceptually similar to creating a symbolic link with the UNIX command ln -s.
Figure 4 shows an example of two distinct naming services that have been linked together using bind_context(). This link could be created by invoking bind_context() on the initial context of naming service X, giving the name A/B/C as the first argument and a reference to naming context C as the second argument.
){kind=link}
Figure 4 Making a crosslink between naming services.
The existence of crosslinks has an important impact on the architecture of the naming service. Simple invocations on a naming service can give rise to a chain of remote invocations across the federated graph.
For example, consider a client that resolves an object with the name A/B/C/MyObject. Figure 4 shows that the contexts A/B and A/B/C are located in two distinct naming services. When the client invokes resolve() on the naming service X, this naming service cannot complete the resolution on its own, so it makes a further invocation of resolve() on context C in naming service Y.
Graph or Hierarchy?
The topology of the naming service is typically a tree structure. However, there is nothing in the naming service specification that requires the topology to be a tree. In fact, the topology was deliberately left as flexible as possible to allow the CORBA naming service to be layered on top of a wide variety of naming services. The naming service can take the form of an arbitrary directed graph.
It is therefore possible to introduce cycles into the naming graph, as illustrated in Figure 5.
){kind=link}
Figure 5 Creating a cycle in a naming graph.
By introducing a crosslink between B and U and a further crosslink between V and A, this graph assumes the shape of a bowtie. If you follow the directed links of the graph, it takes you in a complete circuit. For example, the context A can be accessed under any of the names A, A/B/U/V/A, or A/B/U/V/A/B/U/V/A.
If cycles are likely to occur in your naming service, you must avoid getting caught in an infinite loop when traversing the graph. The code examples shown in this chapter are not designed to be used in a naming graph that has cycles.