Operations on contexts Hierarchies

Figur e 15- 2 demonstrates how contexts and paths are used. Figure 15-2. Contexts and paths

15.1.1.1 Operations on contexts

Contexts have four main types of operations, corresponding to the following two ways of classifying an operation: Bindingunbinding and querying A binding operation is an operation that adds another server or context to the list of servers or contexts a particular context knows. Querying operations enable a client to find a particular server or context. These operations are very similar to the methods present in the RMI registry. They usually take a path as an argument and resolve the path appropriately by forwarding the binding or querying operation to the appropriate subcontext. Context versus ordinary server Subcontexts are usually treated differently from other types of servers. The basic idea here is that contexts can be bound in as ordinary servers, or they can be bound in as subcontexts. In the first case, they can be retrieved by query operations but are not counted as subcontexts when paths are resolved. In the second case, they arent returned as answers to the standard query operations but are used when paths are resolved. Designing a Naming Hierarchy People tend to be somewhat cavalier when designing hierarchies, more so than when theyre designing software or writing code. In part, this seems to be an attitude that its just a lookup mechanism. Its certainly true that there arent very many design principles for hierarchies. However, there are certain things you should keep in mind. The three most important are: Hierarchical structures tends to be persistent. Naming hierarchies and ways to look up objects are embedded in your application, both in the client querying and in the launch code binding. Moreover, secondary applications also frequently rely on the same naming structure™just because one application creates the servers and is the main user of the servers doesnt mean its the only application that uses them. For example, a mortgage application analysis at our bank may fetch an account object in order to look at the accounts transaction history. The mortgage application isnt the primary user of the servers, and the code may have been implemented by another group entirely. However, it still uses the hierarchical structure. You need to decide whether youre designing for humans or for machines. There is often a convenient logical structure for servers, and then there is a hierarchical structure that humans can navigate. Humans typically prefer descriptive names and longer paths. On the other hand, flatter hierarchies generally require less code and are easier for programmers and systems administrators to maintain. The ultimate example of this is RMIs flat namespace. It quickly becomes unreadable. But the code that interacts with the RMI registry is very simple. The longer the path, the more opportunities you have for federating the naming service. Well talk more about federation later. For now, its enough to say that federation is a way of moving subcontexts to another machine to enable naming services to scale.

15.1.2 Query by Attribute