Now that we have another naming service, it’s natural to wonder how much work it is to adapt our existing code to use it. The answer is that it’s pretty easy to switch between naming services. In order to adapt an application, we need to do three things:
Decide how we’re going to store information in the naming service
Rewrite the launch code to create the necessary contexts and store the stubs appropriately
Rewrite the client’s lookup code to reflect the new naming structure
There are two very important things you don’t need to change:
The actual servers. Neither the interfaces nor the implementations need to change at all.
The distributed garbage collection strategy. Because leases are automatically maintained by RMI, binding stubs into this naming service will keep the associated servers alive, just as binding stubs into the RMI registry kept the associated servers alive.
way to adapt the bank example is to bind stubs
into two different contexts,
savings. Stubs for
checking accounts will be bound into
checking and stubs for
savings accounts will be bound into
Another way to accomplish this is to create
an attribute called
account_type and use two values
to gratuitously demonstrate federation in action,
we will actually launch each of our contexts in a
separate JVM. To do this, we will use the
AdditionalContextLauncher class. Here’s ...