Federation Federation and Threading

However, this isnt so bad and is possibly quite good. In particular, there are two benefits: • This is a provable threadsafe locking scheme with no deadlocks. Every request has at most one lock at any given time. • To the extent that the hierarchical structure reflects our plausible assumptions, most threads wont interfere with most other threads, except possibly at the topmost level. Even more importantly, this scenario immediately leads to the concept of federation.

15.3.1 Federation

A federated architecture is one in which multiple servers all support the same set of interfaces and are linked to each other. The linking is done in a way that is essentially transparent to a client but enables the servers to route requests to the server best suited to respond to it. [ 2] [ 2] At least, thats what I think it means. One of the great benefits of writing a book like this is that you get to make up definitions for all the terms everybody uses but that dont have a canonical definition yet. That might seem like a mouthful, but we have a very simple illustration at hand. Weve already got the idea of a context, and its pretty obvious that a context will be a Java object in our implementation of a naming service. The next step is simple: lets make each context an RMI server. We already know that when the client passes in a path to the context, the context will find the appropriate subcontext and forward the request. Theres no reason why the request cant go to another server, running on another machine entirely. The ability to federate contexts, and to do so in a way thats transparent to the client, is a fairly impressive feature that can offer substantial benefits. Consider, for example, a company with four offices in Tokyo, Bangkok, San Francisco, and Reykjavik. Each office maintains a naming context with all the servers for that office, and the contexts are bound into each other as subcontexts. So, for example, the hierarchical structure for Reykjavik looks like Figur e 15- 5 . Figure 15-5. How things look from Reykjavic The hierarchical structure for Bangkok looks like Figur e 15- 6 . Figure 15-6. How things look from Bangkok This is helpful for several reasons: • The local contexts are managed locally by the local systems administrators and developers. Its much better if the naming-service information is maintained by people in a position to know when things go down or get moved to another server. • Each local context serves as a base context for its city. The anticipation is that most of the client applications running in Reykjavik will want to call servers running in Reykjavik. Because they are also using a naming service located in Reykjavik, it follows that when someone in Reykjavik wants to find a printer, if she uses the path printers, it will be resolved to a local printer she would have to use San Franciscoprinters to find a printer in San Francisco. Moreover, the same path, when used by a program running in San Francisco, will find printers in San Francisco. This is a great feature. The same program, performing the same lookup in different locations, will find the appropriate servers. • All servers worldwide are accessible, worldwide. Moreover, this accessibility is easily maintained since the local contexts have exactly three nonlocal references, and those nonlocal references are to naming services in the other cities. When Should a Subcontext Be Federated? Since weve already offered sidebars on designing hierarchies, and on when its appropriate to encode metadata as an attribute, its only reasonable to include a sidebar discussing when a subcontext should be federated. There are two basic tips for when a subcontext should be federated: • Contexts owned by different groups probably should be federated. The group responsible for the maintenance and upkeep of a set of servers ought to own the context in which the servers are registered. Otherwise, simple chores such as moving a server can become needlessly complex. • Federating by location, so that local requests are resolved locally, is often a useful technique. In addition, there are two negative guidelines: • Frequently accessed servers should be accessed via paths that stay inside a single naming service. • Servers that are frequently accessed together, or in a related sequence of operations, should be contained within the same naming service In both cases, the servers can be in different subcontexts. The guideline simply states that paths leading to the servers ought not to cross federation boundaries. The reason for these restrictions is simple: anytime a context forwards a request to a federated subcontext, a remote method call must be made. Anyone who deliberately puts a remote method in the lookup se quence for a commonly used server, or for servers that are accessed together, is simply looking for trouble. Of course, federation isnt just a feature of our naming service, nor does it really require contexts. DNS is an incredibly federated system there is no other way to scale a naming service to the Internet that doesnt support the idea of contexts at all. See DNS and Bind, Fourth Edition by Paul Albitz and Cricket Liu OReilly for more details on DNS.

15.4 The Context Interface