Book Review: Engineering Distributed Objects

Of course he was delighted to get a bite.

"Silkworm, Michael?"

"Silkworms only live in Mulberry trees, and only eat Mulberry leaves."

Hmm, I thought, trying rapidly to reason au façon Jackson. If silkworm(X) and eats(X, Y) then mulberry(Y). Mulberry = RE. Silkworm = me. Eat = read. Oh dear.

"No, it doesn't look like Mulberry,"

said the Silkworm,

"but I'll take it anyway."

Teaching point made. Of course, it's impossible to read all about RE let alone all about everything else; but one advantage of not really being a silkworm is not being rule-bound. Wolfgang Emmerich's purpose in this finely-crafted book certainly isn't RE, but there is in fact an excellent section in the review chapter on Distributed System Requirements. It is certainly the best treatment of that specialised topic I've ever seen: a taste of Mulberry at least.

The rest of the book is an extraordinarily clear and readable account of the challenge of creating clean and 'transparent' distributed systems, built up from canonical software Objects as far as possible, and illustrated in UML and C++, Java and CORBA.

Non-Object-Oriented caterpillars will have to make do by skimming the text to locate the introductory sections, the pedagogically clear and accurate diagrams, and the key points (which helpfully have little key icons beside them).

The really serious and difficult requirements for distributed systems are not functions but -ilities (or qualities): portability, scalability, and reliability (including fault tolerance).

Another crucial quality is the transparency already mentioned: the ability of a complex heterogeneous system to appear to users as if it was 'a single integrated computing facility'. Because systems are complicated, it takes careful and systematic design to make all the machinery in the middle - between you and the data you want, for instance - invisible or transparent. The components that Emmerich describes indeed form a new layer or stratum of system structure, 'middleware', between shared services and individual clients. Transparency is not one but many requirements: performance transparency, concurrency transparency, location transparency, migration transparency to name just some of them. In fact you could argue that transparency was the key meta-requirement for distributed systems; it governs all other requirements and design approaches, but is itself more of a far-distant goal than a simply-definable requirement.

Constraints such as heterogeneity are also extremely important in distributed systems. It is so likely as to be almost certain that any large system will encompass diverse hardware and software components, many of which may represent substantial earlier investments. The distributed system builder must live within these constraints.

This looks like an excellent, clear, and comprehensive book that brings the growing and important topic of engineering large distributed software systems to a wider industrial audience. There is a helpful index and a detailed bibliography. Students will find that Emmerich's teaching skill is as great as his technical expertise. Requirements caterpillars who want to keep up with the times would also do well to look at it.

© Ian Alexander 2003