The third and fourth steps in sketching out an architecture involve figuring out which design decisions can be safely postponed and which restrictions the deployment environment will place upon our application. Since this is an RMI book, however, we’ll make the following assumption:
There will be a server, or servers, written in Java and registered with a naming service. The client, also written in Java, will connect to the naming service, retrieve a stub for the server, and use the stub to communicate with the server.
As mentioned previously, we will postpone consideration of two key issues: security and scalability.
Writing a security layer is difficult for two reasons. The first is that doing so often requires a good understanding of some rather complicated mathematics. The second is that it’s pretty hard to test. Consider, for example, the functionality involved in depositing money to a bank account. It’s easy to imagine a sequence of automated tests that will give you confidence that the code is correct. It’s much harder to imagine a series of tests that will ensure that no one can intercept and decode privileged information or that the passwords used for authentication are secure. For these reasons, most applications that need security wind up using a thoroughly tested library or package that provides it.
For the bank example, we need to do two things: authenticate the user via password mechanism (i.e., make ...