|
Greg examines Component Software: Beyond Object-Oriented Programming, by Clemens Szyperski, while William takes a look at Neil J. Gunther's The Practical Performance Analyst: Performance-By-Design Techniques for Distributed Systems.
May 01, 1999
URL:http://www.drdobbs.com/programmers-bookshelf/184410946
Greg is the author of Practical Parallel Programming (MIT Press, 1995), and coeditor with Paul Lu of Parallel Programming Using C++ (MIT Press, 1996). Greg can be reached at [email protected]. William's most recent book is SNMP, SNMPv2, SNMPv3, and RMON 1 and 2, Third Edition (Addison Wesley, 1999). He can be contacted at [email protected].
It's been a long time since I devoted an entire review to a single book. One reason is that comparing and contrasting two or three books gives me a chance to say something about their context, and about the wider state of modern computing as a whole. Another is that there just isn't enough in most books to merit 500 or 600 words of discussion.
Clemens Szyperski's Component Software: Beyond Object-Oriented Programming certainly has enough in it to carry an entire review. In fact, this superb book has made me see the past, present, and near-future state of our industry in a new way. Szyperski not only provides an in-depth exposition, comparison, and critique of today's three major component standards (COM, CORBA, and JavaBeans), he also describes what it will take for those technologies to deliver on the promises that were made for object-oriented programming in its early days.
The second sentence of Component Software defines its subject area. According to Szyperski:
...software components are binary units of independent production, acquisition, and deployment and interact to form a func-tioning system.
The "Foundation" section of the book (Chapters 4 through 11) is a very detailed exploration of why all of the adjectives in that defining phrase are necessary. Components must be independent and binary to allow for multiple independent vendors and robust integration; unlike object-oriented programming, which is primarily concerned with the production of software, component systems must deal with deployment issues, such as installation, versioning, error handling, and cross-platform compatibility.
The "State of the Art" section (Chapters 12 through 19) looks in detail at where component technology is today. These chapters are worth the price of the book by themselves: I have rarely read as clear, as incisive, or as even-handed a comparison of technological alternatives. Szyperski is clearly on intimate terms with COM, CORBA, and JavaBeans; he not only points out their strengths and weaknesses, but also explains why their designers made the design choices they did. The last two sections of the book are "The Next Generation" (Chapters 20 through 25) and "Markets and Components" (Chapters 26 through 28). These are necessarily more speculative, but are still solidly grounded in the needs of real-world, large-scale industrial applications.
The "Foundation" section was the most illuminating for me, but also the hardest work. It starts with Chapter 4, which defines what components are and are not. Some of these definitions may seem like hair-splitting, but each distinction or fine point turns out to have been made for a reason. Chapter 5, "Components, Interfaces, and Re-Entrance," explains why component-based programming is hard to get right. One of the reasons is that it is hard to specify software components at the same useful level of detail as electronic or mechanical components are specified. Another, more fundamental, reason is that callbacks and extensions mean that useful software components are rarely layered as cleanly as purists would like. The examples in this chapter are occasionally hard to follow, but that isn't Szyperski's fault: Simple examples just don't show the problems that real-world systems encounter.
Chapters 6 ("Polymorphism") and 7 ("Object versus Class Composition") look at the idea of substituting components for one another. What does it take to make this possible? To make it safe? To make it economical? What happens when components evolve? Is multiple inheritance a necessary evil? If so, what kind of multiple inheritance? Szyperski points out that this can mean several different things, some of which are more or less necessary, or more or less evil, than others.
Each of the 13 sections in Chapter 8 discusses one aspect of scaling and granularity. Components are units of abstraction, of accounting, of analysis, of compilation, and so on down the alphabet to maintenance and system management. This careful enumeration of what components are good for is used in the later discussion of COM, CORBA, and JavaBeans to analyze what each system does and does not provide.
I could go through the contents of the other chapters at this point, but it would be much better for you to go out and buy the book yourself. Szyperski's English may sometimes sound a bit odd, and some of the things he says about JavaBeans are already a bit out of date, but these are very minor quibbles. Component Software is quite simply the best book on computing I read in 1998, and deserves a wide, attentive audience in both industry and academia.
-- G.V.W.
The Practical Performance Analyst, by Neil J. Gunther, is a superb book that should be on the shelf of every programmer, engineer, systems analyst, and manager who is responsible for performance analysis and design of computer systems or data networks. It is one of the best books on performance analysis I have ever encountered.
The Practical Performance Analyst does not assume a background in performance analysis or queuing theory. Instead, its emphasis is on the practical use of modeling tools, rather than on the mathematical theory underlying those tools. However, although the book is a comparatively easy read, it does require a commitment on the part of the reader. To benefit from the book, you need to give it careful study.
Gunther begins, surprisingly, with a chapter on time. There turns out to be a lot to say on this subject, including the distinction between discrete and continuous time, types of clocks, time scales, how to define and measure response time, and various lifetimes, such as time to failure. Having all this material gathered in a single place is quite useful. The next two chapters cover queuing theory. In keeping with the book's practical orientation, Gunther does not derive the queuing equations, but spends all of the time presenting the results and discussing their applicability. For someone with little or no previous exposure to queueing theory, these two chapters provide an excellent introduction, sufficient for the practical problems of performance analysis.
Perhaps the only significant lack in The Practical Performance Analyst is that it does not deal with self-similar behavior. In recent years, a number of studies have shown that network traffic often shows a self-similar pattern rather than the Poisson (or random) pattern that is typically assumed in the queueing model. In general, performance is worse when self-similar behavior is present. However, no convenient modeling approach has yet evolved for dealing with this phenomenon, so Gunther's omission of this topic is understandable.
The middle section of the book shows how to apply queueing analysis to design problems. Topics covered include symmetric multiprocessors (SMPs), computer clusters, client-server applications, and web servers. In each case, Gunther goes through the steps needed to perform an analysis and provides a number of detailed examples. This concrete approach gives the reader the confidence and the tools to handle his or her own specific design problems.
The final, and most difficult, part of the book delves into more advanced topics. Here the book is concerned with those difficult modeling situations in which there are unstable configurations or large transients to deal with. In some design problems, these factors cannot easily be ignored, so this material is an important element of the book.
Finally, The Practical Performance Analyst includes a CD-ROM with a package of portable C routines called the "PDQ" (short for "Pretty Darn Quick") toolset. With PDQ, you can quickly set up a performance model for testing design alternatives. The only requirement is a knowledge of C. The great advantage of PDQ is the speed with which it can be used. In today's commercial environment, there is often little time budgeted for performance analyses. Indeed, the whole point of The Practical Performance Analyst is to make it possible to effectively do performance analysis while keeping up with the short deadlines the analyst typically faces.
-- W.S.
DDJ
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.