In the previous chapter, we discussed the
architecture of the bank example in detail and
concluded that implementing many small
Account servers seems
like a good design decision. In this chapter,
we’ll tackle the design of
interface. As part of this, we will also discuss
the issues involved in building data objects,
objects designed to be passed by value over the
wire. By the end of this chapter, you will have a
list of basic design criteria that will help you
design your own remote interfaces.
Every program has (at least) two purposes: the one for which it was written, and another for which it wasn’t.
that we’ve decided to have many little
Account servers, the
next step is to design the
interface. Just as the choice of server
architectures was substantially influenced by the
problems that arise in the design of distributed
applications, the design of the server interface
is also affected by both network latency and the
possibility of partial failure.
But interfaces also need to be designed with the application’s (or at least the server’s) lifecycle in mind. As the quote at the beginning of this section suggests, the simple truth is that nobody ever really knows how an application, or even a server, will be used once it is deployed. Over time, how an application is used and what functionality it needs to support will change. A needlessly ...