Now that we’ve got a preliminary description of how the application will be structured, a question arises: what is the role of the network in all of this?Or stated more precisely, this important question is:
What problems does making the application distributed cause?
The answer is that there are two main new problems associated to building a distributed application: the possibility of partial failures and the latency of the network. Let’s look at both in more detail.
A partial failure occurs when one of the programs becomes inaccessible to the other programs that are running. This can happen because the program has crashed or because the network is experiencing problems. In either case, the possibility of partial failure can cause problems for the application designer.
Consider, for example, our typical use case. Step 5 stated:
After choosing an action, the user is given a list of valid accounts from which to choose (e.g., “Checking” or “Savings”). The user chooses an account and then the transaction proceeds.
This translates, in the account option, into:
The client program gets a stub for the appropriate account object from a server somewhere. It then proceeds to make method calls on the account server until the transaction is completed.
And the stub, as with RMI applications, plays a role very similar to that of an object reference. That is, it exposes methods that the client application calls.
And this is where ...