Rating: 
Summary: Overall Disappointing
Review: Although I found some useful bits in here, it did not come across as good to me as some earlier reviewers found it. Maybe I missed something.I did find some useful coverage of some good development practice e.g. the use of layered architectures, components as large grained deployment and distribution units, explicit component artifacts including external description through code, build and deployment, etc. But I did not get much more from these discussions than I already knew. I did not find the "interoperability protocol" explanation helpful: e.g. "design-time interface" was a very fancy word for a simple list of the artifacts required at design time. The authors do not seem to recognize that these include both things needed for tools to manipulate a component at design or build time, as well as those needed by developers to understand, use, or test a component. The book sorely needs a clearer high-level view of how components are configured together, rather than the nitty-gritty of proxies, separating functional vs. platform-specific code, etc. I see some links to the never-ending saga of the elusive "business object" track at the OMG. Overall I was disappointed. I'd say between 1 and 2 "stars". Your milage may vary.
Rating: 
Summary: Dispelling Myths, Doing it Right
Review: As an OO practitioner and methodologist for the last 10 years, I found the Herzum / Sims book to be right on the money in several regards. OO has a lot of theoretical ideas which just don't seem to pan out in practice. The Business Component Factory cleary explains why, and shows what really works in the true industrial setting. It is rich in practical advise, and low in BS. Very refreshing for the software practitioner who is frustrated by the OO theoreticians who spout their wisdom from the ivory towers, but have rarely, if ever, had to work on real projects. Along these lines, the BCF book dispels the OO myth that all classes / objects must be as intelligent as possible, and admits that, in reality, it is often best to have "focus" classes. These classes contain the intelligence of a group of related classes (grouped in a component) and give the advantage of lower coupling for the other classes, and of providing a focus target for process and use case modeling. Hence, Herzum / Sims tie the use case models effectively to classes, then to components. The BCF book also points out that components need to be "first class citizens" in the UML metamodel, which map from analysis through design into code. As the UML currently stands, packages and (UML-style) components fail miserably in this area. Herzum / Sims show how to get around this deficiency and model and produce large-scale software units (components) effectively. There is much more to the book than described above, but the above two points emphasize that the BCF book is not afraid to take on conventional wisdom (even the sacred UML), to point out flaws in this "wisdom", and to discuss what really works. Highly recommended, especially for anyone working on large-scale system development.
Rating:
Summary: Dispelling Myths, Doing it Right
Review: As an OO practitioner and methodologist for the last 10 years, I found the Herzum / Sims book to be right on the money in several regards. OO has a lot of theoretical ideas which just don't seem to pan out in practice. The Business Component Factory cleary explains why, and shows what really works in the true industrial setting. It is rich in practical advise, and low in BS. Very refreshing for the software practitioner who is frustrated by the OO theoreticians who spout their wisdom from the ivory towers, but have rarely, if ever, had to work on real projects. Along these lines, the BCF book dispels the OO myth that all classes / objects must be as intelligent as possible, and admits that, in reality, it is often best to have "focus" classes. These classes contain the intelligence of a group of related classes (grouped in a component) and give the advantage of lower coupling for the other classes, and of providing a focus target for process and use case modeling. Hence, Herzum / Sims tie the use case models effectively to classes, then to components. The BCF book also points out that components need to be "first class citizens" in the UML metamodel, which map from analysis through design into code. As the UML currently stands, packages and (UML-style) components fail miserably in this area. Herzum / Sims show how to get around this deficiency and model and produce large-scale software units (components) effectively. There is much more to the book than described above, but the above two points emphasize that the BCF book is not afraid to take on conventional wisdom (even the sacred UML), to point out flaws in this "wisdom", and to discuss what really works. Highly recommended, especially for anyone working on large-scale system development.
Rating:
Summary: THE book to read to understand components
Review: Components have become a hot topic for a couple of years now, but until recently there has been no really good book to recommend to people who want to learn more about the topic. ... This deficiency has now been handsomely overcome with the publication of Peter Herzum and Oliver Sims new book. I recommend this book without any qualification: This is THE book to read to understand components and the impact of components on enterprise application development. Everyone involved in architecting enterprise applications or developing component-based applications will want to read this book. A high-level table of contents will provide a good overview to the scope of this book: 1. Component-Based Development 2. The Business Component Approach 3. The Distributed Component 4. The Business Component 5. The Business Component System 6. The Federation of System-Level Components 7. Development Process 8. Technical Architecture 9. Application Architecture 10. The Project Management Architecture 11. Component-Based Modeling 12. Component-Based Design 13. Transitioning When you consider that, for the past year, we have had technologies like MTS and Enterprise JavaBeans, which provide delivery systems for server-size business components, but no general description of what a business component is, or how one might go about developing an enterprise application, you realize how important Business Component Factory will be. This is the book that is going to introduce the upcoming generation of software developers to the concepts that we are going to rely on as we develop enterprise applications in the next decade. Herzum and Sims define a business component as follows: "A business component is the software implementation of an autonomous business concept or business process. It consists of all of the software artifacts necessary to represent, implement, and deploy a given business concept as an autonomous, reusable element of a larger distributed information system." Those familiar with the move toward business components will probably find this definition unexceptional. What they will be more surprised with, however, is how Herzum and Sims proceed to extend this definition into a precise description. They define a business component, for example, as incorporating a three or multi-tier distributed system within itself. Thus, a business component is made up of other components that fall into four groups: User Interface components, Workspace components that marshal information on the client, enterprise components that contain business logic and reside on the server, and resource components that manage legacy or database resources. They proceed to define each carefully, work out how one approaches developing such components and what roles they play in various architectural views. I haven't the space to pursue the development of Herzum and Sims concepts here. Meantime, however, you owe it to yourself to acquire and read this book.
Rating:
Summary: Full lifecycle view, business advatage to large grain CBD
Review: Herzum and Sims have taken a brave approach to components, emphasizing the view of components through the development lifecycle, where the same component exists from requirements through design to implementation, with only a different view on it. They do a good job of completing the lifecycle with project management aspects of component development as well. The book seems high level, but they enter into a lot of technical detail as well, while not getting involved in a specific technology. The book is used by me as a textbook for graduate students, as it covers all aspects in detail but generically. The advantage of the book is the way in which components are defined. Business Components are large grained, made up of many parts which they define in layers. This leads to a wider view of the concept, and leads to a re-organization of the development process. The book is structured around an architecture for development, which establishes a production-line approach. This ensures the component concept is bought into throughout the organization. This is the only book to focus on large grained components, with a pure business advantage, but explained technically. This is and is not a how to book. It is a roadmap for what to do and how to arrange it, but not the specific technology to use. There is a lot of detail in this thick book, but it is easy to read. Very unique approach, and the only book describing aspects you will not learn elsewhere. Other books only describe the overall concept. This one tells you exactly how to fit it into your organization, down to how to structure teams! The book is very comprehansive, and really does follow the development lifecycle. You will gain knowledge of : components on a business level, a new lifecycle for development that is very tailored to components in business, techniques for developing systems, from individual components to integrating federations of components form third parties, all the other aspects thinner books leave out.
Rating:
Summary: Somewhat useful
Review: I am about 70% through the book. I did get a few useful points, but not much more. Many points are elaborations on Sims' earlier book "Building Business Objects"; most others are standard good practice in building distributed systems. The one thing that looked promising - the idea of "full-lifecycle interfaces" - turned out to be a half-baked idea. My quick summary of what I've read: Components as independent units of development, delivery, deployment, or replacement is not a new idea; so a component has to "include" at least both its interfaces and its implementation. There is nothing new about treating a large chunk of running code as a singleton-like object, itself comprised of others objects (whether running on a single tier or multiple); methods like Fusion did this in '93. Distributed systems on Corba-like infrastructure only scale for large-grained not-too-numerous objects, so no surprise here. Don't try to pass pointers to non-distributed objects in distributed calls ... Duh. Large grained chunks called "Distributed Components" (DCs) are usually in 1 tier of a 4-tier architecture; something thats been practiced in the Smalltalk world for years: we called them View, Application Model, Model, and Data, with code split accordingly. And the pseudo-IDL language the authors use mixes specifications and implementations very badly. I found the repeated claims of traceability, autonomy, and "fundamental" units of reuse unconvincing. The idea of "business component assembly" confuses interfaces and implementations; and the idea of traceability appears based on the idea that changes made in design and implementation are directly reflected back into the specification level (Fig 5.5), making traceability moot. I've reached Ch 8 and see that I am about to be reminded to separate infrastructure-dependent code from the primary function code (with some admittedly pretty lego-block pictures). From what I've seen so far, I can see some value in a design pattern that summarize what this book says. But as a book it did not do much for me.
Rating:
Summary: Good
Review: It is a good book recommended from Cuttler
Rating: 
Summary: Good information, but not all that new.
Review: One of the things I've noticed over the years is that many books on computer - related topics tend to recycle a lot of concepts; it sometimes makes me wonder if there is ever anything new in the world of software engineering. For example, for a while now, we've been reading a lot of philosophy and techniques about object-oriented programming. Good stuff, but not all that different from what good designers and programmers were already doing years before. Well, in this book the "objects" get bigger, and they're described with different words. Something about this recycling process which is a particular irritant to me is that the people who write these books seem to feel the need to invent new words (or assign new meanings to old words). I've always thought that the purpose of language is to communicate -- reassigning word meanings is not something I find helpful. Who, for example, ever heard of "process management architecture"? Much of the material in this book is stuff you've seen before -- the words are different or they're used with different meanings or in new contexts -- but a lot of the concepts are familiar. The book does expand its scope somewhat to cover much more of the "development process", resulting in more of a mix of technical and process information than is typical. This is good, as all too often we tend to separate the technology from the process. Bottom line: Useful information. Nothing particularly new or revolutionary. Could have been a couple of hundred pages shorter. I frequently found myself needing to re-read something or refer to the glossary to re-discover a definition.
Rating:
Summary: One of the most important books I've read in the last 10 yea
Review: There are a lot of books out there that discuss component-based development, but this is the first book I've read that details a complete methodology for making CBD work in the real world. Many of the principles discussed in the book are either common-sense best practices, or have been covered by other authors in the past. This book, however, ties together a wide range of process and architectural concepts into a complete blueprint for creating a rapid component and application development "factory". As the authors point out repeatedly throughout the book, many of their requirements for a true component factory do not yet exist in commercially available products. However all their recommendations have been derived from the real-world experience of Peter Herzum and his team creating such a factory. Most of the material is highly applicable today, and it also provides a glimpse into what the rapid development of business systems will be like as the technological infrastructure matures over the next decade. This book has already had a profound impact on my thinking regarding large scale business systems development, and I know that I will be referring to it for years to come. The bottom line - if you're interested or involved in component-based development, read this book!
Rating:
Summary: An excellent guide to successful adoption of Enterprise CBD
Review: This book is the first I have read that really tackles all aspects of what is required for Enterprise Application Development through a CBD approach. By defining the levels of component granularity and a recursively discrete approach to breaking a business problem down into components and their constituents as finer grained components, the true requirements for CBD are evident and determined. Many books I have read make the same mistake of only discussing development of components at one level (usually what Herzum defines as the distributed component level) and fail to address the many of the aspects of CBD that are not covered by development alone (deployment, testing, management, integration, and a roadmap for the development process and managment of that process through to delivery of a component based system). The book also talks and applies the component levels to the commonly depicted 4 tier architecture and importantly introduces the concept of components needing to be not only strongly typed for internal systems but also strongly tagged (supporting XML based component messaging/invocation) for virtual and extended systems. The coverage of what is required from a Component Execution Environment (CEE) when components are more course grained than simple distributed components is well covered and continues to define the true requirements for a Business Component Execution Environment (BCVM). The book is a must read for anyone serious about adopting CBD on and enterprise scale. The book goes well beyond the common text available for CBD (that all concentrate on the short sighted development requirements for distributed components in a fine grained component containment model). I agree with another reviewer that for those of us that have been developing systems in EJB, COM+/DCOM and CORBA much of the book covers lessons we have painfully had to learn in developing multiple component based systems that have to inter-operate, but it goes beyond that in looking at what is necessary for component based systems at the next architectural level (one that may well incorporate disparate distributed component models).
| 
