Chapter 6.  Deciding on the Remote Server

In Chapter 5, we briefly discussed the architecture of the bank example. In addition, we discussed the fundamental problems that arise when building distributed applications. In this chapter, I build on that discussion by introducing a set of basic evaluation criteria that will help you refine designs and choose between various design options.

A Little Bit of Bias

Good code invariably has small methods and small objects...no one thing I do to systems provides as much help as breaking it into more pieces

—Kent Beck, Smalltalk Best Practice Patterns

The experienced distributed systems programmer will notice a certain bias in this chapter[25] towards what I call small-scale, semi-independent servers. The “small-scale” part of this is easy to explain. By and large, I build servers with very limited functionality (as little as is reasonable, given the restrictions imposed by the fact that we’re building a distributed system). Then, I tend to give them large interfaces, exposing the same functionality in multiple ways.

As far as I know, there’s no knockdown argument in favor of this style of designing and building programs. Many programmers who have built object-oriented systems tend to agree with Kent Beck.[26] In my experience, his quote almost holds for distributed systems as well—building small servers leads to flexible designs that evolve gracefully over time. However, there is a slight difference, due to network latency, for distributed ...

Get Java RMI now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.