Applying this to Bank versus Accounts

However, the database probably already has a fixed schema, which were not allowed to alter. Yet, as our bank moves into the age of the Internet, we could easily want to record more information. For example, we may want to record more detailed information about where from, exactly, the request came. Was this a withdrawal of extra cash from a supermarket cashier? Was a casino involved? Was some other banks ATM involved? Was the transaction generated by an Internet-based service that provides automatic bill paying by mimicing an ATM? And so on. Because our primary information is stored in a shared resource the original database for both the Bank and Account s options, and because to access this information we need to store it in a second database, [ 7] the answer to this question doesnt favor either the Bank option or the Account option. [ 7] In order to make ad-hoc queries across accounts. Advantage: neither 6.2.2 How Well Does the Given Server ReplicateScaleto Multiple Machines? This is only important if you anticipate the application scaling to handle demands beyond the capacity of a single JVM on a single machine. For example, it seems unlikely that our printer server will ever really need this sort of scalability. In order to answer this question, consider the following scenario: a single JVM, containing all our servers, is created. Clients find the servers using the registry and proceed to make calls on them. However, this system doesnt scale very well, and users are upset by how badly the system performs. Then, an order comes down from on high: two JVMs, each containing half of the server, should be created. In addition, a new third server, which knows how to redirect clients to a correct server, should be built. Clients will make a simple query to the third server to find out which server should handle their requests, and then conduct all their business with the designated server. In other words, we will distribute the processing and then implement a simple form of load balancing. This new architecture looks something like Figur e 6- 3 . Figure 6-3. Load-balancing architecture Now the question becomes: how hard is it to implement this scenario? If we need to, can we easily migrate from the single JVM scenario to the multiple JVM scenario?

6.2.2.1 Applying this to Bank versus Accounts

Accounts easily scale to multiple machines. Since they register as small-grained servers in the naming service, they are location-independent. That is, in order to distribute the servers on two machines, they are simply launched in separate JVMs and registered from there. Consider the following code, which launches a set of Account servers given names and balances: public static void mainString[] args { Collection nameBalancePairs = getNameBalancePairsargs; Iterator i = nameBalancePairs.iterator ; whilei.hasNext { NameBalancePair nextNameBalancePair = NameBalancePair i.next ; launchServernextNameBalancePair; } } private static void launchServerNameBalancePair serverDescription { try { Account_Impl2 newAccount = new Account_Impl2serverDescription.balance; RemoteStub stub = UnicastRemoteObject.exportObjectnewAccount; Naming.rebindserverDescription.name, stub; System.out.printlnAccount + serverDescription.name + successfully launched.; } catchException e{} } This can easily be run on more than one machine, launching different sets of accounts. All that is required is that the function getNameBalancePairs return different accounts when the code is run on different machines. When the client asks the naming service for Account , it automatically gets a stub for the correct server regardless of on which computer the server runs. Bank , on the other hand, doesnt easily spread to multiple machines. After all, the whole idea behind Bank is that all the accounts can be manipulated using a single server. We run into problems when two clients, communicating with two different Bank servers, try to manipulate the same account information. That is, suppose each client calls: public void makeWithdrawalAccount account, Money amount throws RemoteException, OverdraftException, NegativeAmountException; In addition, suppose that each of these calls attempt to withdraw all the money in the account. If both clients are calling the same instance of Bank , we can easily imagine that the code is clever enough to spot the problem. [ 8] However, if the clients are talking to two instances of Bank , running as separate servers on distinct computers, the only way to spot the problem is to have the servers communicate with each other. [ 8] Exactly how to write this sort of code will be covered in Chapt er 11 and Chapt er 12 . One solution to this problem is to use the persistent store as a shared resource. That is, before attempting to make a deposit or a withdrawal, Bank can always check to see whether the operation is possible. But this solution can be difficult to implement and makes the interaction with the database more complex. Whats more, all this really does is take messages that should be sent directly from one Bank to another and route them through a third-party server. This may cause performance problems. An alternative solution, which might seem rather clever, is to register the Bank s with the naming service. However, instead of registering them under Bank names, register them under the names of the accounts. That is, each instance of Bank would be registered many times, once for each account it supports. Clients would look up an account and be directed to an instance of Bank . By partitioning the accounts Bank 1 handles those accounts, Bank 2 handles these accounts..., we avoid the problem when two servers manipulate the same account information. This solution still requires some changes in the implementation of Bank . The problem, however, is that if we dont change the implementation of Bank , then once a client has a reference to Bank , it can call any method on any account. This explicitly breaks the partitioning weve set up. More importantly, it violates the single most important rule of client-server programming: servers should never trust clients to do the right thing, especially when sensitive data is involved. This is worth repeating: servers should never trust clients to do the right thing, especially when sensitive data is involved. Why? Clients tend to get rewritten more often than servers. Hence, their code evolves more rapidly and is tested less thoroughly. [ 9] Since one client-side error can result in a corrupted server, its just good sense for the server to validate all incoming data. Paranoia is not just the best policy, its the only reasonable policy. [ 9] Not to mention the possibility of malicious clients... Of course, once weve added the additional layer of code to make sure that clients are invoke only transactions on permissible accounts, we no longer deal with our original implementation of Bank anymore. Weve created an intermediate abstraction and transformed Bank s into Branch es. Advantage: Accounts slightly 6.2.3 Can a Single Server Handle a Typical Client Interaction?