Security Scalability Design Postponements

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, well 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.

5.4.1 Design Postponements

As mentioned previously, we will postpone consideration of two key issues: security and scalability.

5.4.1.1 Security

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 its pretty hard to test. Consider, for example, the functionality involved in depositing money to a bank account. Its easy to imagine a sequence of automated tests that will give you confidence that the code is correct. Its 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 sure the user has the authority to perform operations on a given account and guarantee that the information sent between the client and the server is secure from eavesdropping. Since this second task is easily accomplished via SSL™and doesnt impact our design at all™postponing security issues amounts to assuming that the user authentication task is easily solved and doesnt significantly impact the rest of the design. RMI allows you, via the definition custom socket factories, to use any type of socket as the basic network communication layer. By default, RMI uses the socket classes found in the java.net package. The relationship between SSL and RMI is discussed in Chapt er 18 .

5.4.1.2 Scalability

Our basic use case implies two very nice properties of our application. The first is that there isnt a great deal of state associated with a client. The second is that there isnt a lot of interaction between distinct clients. The first property implies that state management is fairly simple. When a client executes the basic use case, the server needs to authenticate the client and get the clients bank account data from a persistent storage mechanism. Its plausible for us to assume that authentication is a once-per- client-session cost, and that the associated bank account information is not a large amount of information nor hard to retrieve from the server. The second property amounts to the following two assumptions: • Two clients dont usually access the same bank account at the same time. • Requests that one client makes e.g., a deposit or withdrawal wont affect other clients. Note the presence of the word usually™we will, in later chapters, insert safeguards to guarantee data integrity in the case that multiple clients attempt to access the same account at the same time. Those safeguards wont affect our scalability assumptions, however. We can restate these assumptions in a more general form: • Two clients dont usually access the same changeable information at the same time. • The changeable information is relatively isolated. Changes one client makes rarely affect other clients and do so in a known way. These generalized assumptions, and the assumption that the state associated to a client is small, imply that once the single-client application is written, it will be fairly easy to make the application scale. Hence, we can safely postpone worrying about scalability until we understand the single- client scenario. This is because of the following three implications: • The changeable information, which is small and well-defined, can be cached in server memory. • Processing can be isolated. Therefore, you can use multiple servers on multiple machines without worrying about server communication. • Because clients rarely access the same information simultaneously, caching the changeable information is still a valid strategy even with multiple servers. These generalized assumptions hold for a surprisingly large number of applications the what-I- put-in-my-shopping-cart-doesnt-affect-your-shopping-cart-at-all principle. And often, the key to making an application scale is figuring out how the generalized assumptions fail and limiting the resulting problems. For example, both of the generalized assumptions fail in a scheduling application. That is: • People trying to schedule meetings often access the same information simultaneously, such as the schedules of other people and the list of available rooms and locations. • A scheduling decision made by one user can definitely affect the other users. The trick is to realize that you still have some sort of isolation going on. There are actually two types of isolation in the scheduling scenario: the people who need to be at a meeting and the geographic location of the meeting. If I need to meet with Bob and Sandy in Colorado, and you need to meet with Alex and Pat in Oregon, then our requests are completely independent, and that fact should be reflected in the code. A little confused? Its okay. Read this section again later. The key thing to remember is that if you can isolate the clients from each other, or control how the clients affect eac h other, then the application can be made to scale without too many problems.

5.4.2 Implications of the Environment