Home > Store

ACM.Szyperski:Component Software_p2, 2nd Edition

Register your product to gain access to bonus material or receive a coupon.

ACM.Szyperski:Component Software_p2, 2nd Edition


  • Sorry, this book is no longer in print.
Not for Sale



  • Updated material where the technology has moved on e.g. EJBs, CORBA, COM
  • New sections added to cover new and emerging technologies e.g. COM+, .NET, XML, SOAP, BizTalk, discussing how they work, pros & cons of each
  • Updated sections on the state of the component market, standards and future markets and developments
  • Continued use of the main component programming languages (Java & Component Pascal) plus new sections using C#
  • Updated diagrams from OMT to UML
  • Updated and expanded glossary to cover new areas


  • Copyright 2003
  • Edition: 2nd
  • Book
  • ISBN-10: 0-201-74572-0
  • ISBN-13: 978-0-201-74572-6

The author describes his book as a "unique blend of market and technology coverage, broad and fair coverage of current technologies and a deep discussion of real problems with their solutions where known".

The first edition won the "Jolt Award" became the leading book on the market to combine explanations of what the key technologies are, how to use them and why they are important in the software market-place, and look at these in terms of both the technical and business issues. The book was also the first to define components and clarify the key questions surrounding them, show how they are key to software design and offer a historical overview of their development.

Sample Content

Table of Contents

Preface to the second edition.


About the author.

About the contributing authors.



1. Introduction.

Components are for composition.

Components—custom-made versus standard software.

Inevitability of components.

The nature of software and deployable entities.

Components are units of deployment.

Lessons learned. 2. Market versus technology.

Creating a market.

Fundamental properties of component technology.

Market development.

Strategic Focus (January 1995).

Ovum (1995).

IDC (May 1996).

IDC (April 1999).

ComponentSource (2001).

Flashline (2001). 3. Standards.

The utmost importance of (quasi) standards.

Wiring standards are not enough.

Too many competing standards are not useful.

Where is software component technology today?

What's next?


4. What a component is and is not.

Terms and concepts.



Components and objects.


Whitebox versus blackbox abstractions and reuse.


Explicit context dependencies.

Component “weight”.

Standardization and normalization.

Horizontal versus vertical markets.

Standard component worlds and normalization. 5. Components, interfaces, and re-entrance.

Components and interfaces.

Direct and indirect interfaces.


Interfaces as contracts.

Contracts and extra-functional requirements.

Undocumented “features”.

What belongs to a contract?

Safety and progress.

Extra-functional requirements.

Specifying time and space requirements.

Dress code—formal or informal?

Callbacks and contracts.

Examples of callbacks and contracts.

A directory service.

A client of the directory service.

Same client, next release.

A broken contract.

Prevention is better than cure.

Proofing the directory service.

Test functions in action.

From callbacks to objects.

From interobject consistency to object re-entrance.

Self-interference and object re-entrance: a summary.

Processes and multithreading.


Specification statements. 6. Polymorphism.

Substitutability—using one for another.

Types, subtypes, and type checking.

More on subtypes.

Object languages and types.

Types, interfaces, and components.

The paradigm of independent extensibility.

Safety by construction—viability of components.

Module safety.

Module safety and metaprogramming.

Safety in a multilanguage environment.

Safety, security, trust.

Dimensions of independent extensibility.

Bottleneck interfaces.

Singleton configurations.

Parallel, orthogonal, and recursive extensions.

Evolution versus immutability of interfaces and contracts.

Syntactic versus semantic contract changes.

Contract expiry.

Overriding law.

Other forms of polymorphism. 7. Object versus class composition or how to avoid inheritance.

Inheritance—the soup of the day?

More flavors to the soup.

Multiple inheritance.


Back to basic ingredients.

The fragile base class problem.

The syntactic fragile base class problem.

The semantic fragile base class problem.

Inheritance—more knots than meet the eye.

Approaches to disciplined inheritance.

The specialization interface.

Typing the specialization interface.

Behavioral specification of the specialization interface.

Reuse and cooperation contracts.

Representation invariants and method refinements.

Disciplined inheritance to avoid fragile base class problems.

Creating correct subclasses without seeing superclass code.

From class to object composition.

Forwarding versus delegation (or making object composition as problematical as implementation inheritance).

A brief review of delegation and inheritance. 8. Aspects of scale and granularity.

Units of abstraction.

Units of accounting.

Units of analysis.

Units of compilation.

Units of delivery.

Units of deployment.

Units of dispute.

Units of extension.

Units of fault containment.

Units of instantiation.

Units of installation.

Units of loading.

Units of locality.

Units of maintenance.

Units of system management.

Summary. 9. Patterns, frameworks, architectures.

Forms of design-level reuse.

Sharing consistency—programming languages.

Sharing concrete solution fragments—libraries.

Sharing individual contracts—interfaces.

Sharing individual interaction fragments—messages and protocols.

Sharing individual interaction architecture—patterns.

Sharing architecture—frameworks.

Sharing overall structure—system architecture.

Systems of subsystems—framework hierarchies.

Interoperability, legacies, and re-engineering. 10. Programming—shades of gray.

Different programming methods for different programmers.

Programming to a system.

Connection-oriented programming.

Connection-oriented programming—advanced concepts.

Events and messages.

Message syntax and schema—XML.

Events versus calls.

Call syntax and protocol—SOAP.

Ordering of events—causality, races, and glitches.

Very late binding—dispatch interfaces and metaprogramming.

Degrees of freedom—sandboxing versus static safety.

Recording versus scripting. 11. What others say.

Grady Booch (1987).

Oscar Nierstrasz and Dennis Tsichritzis (1992 and 1995).

Gio Wiederhold, Peter Wegner, and Stefano Ceri (1992).

Ivar Jacobson (1993).

Meta Group (1994).

Jed Harris (1995).

Ovum Report on Distributed Objects (1995).

Robert Orfali, Dan Harkey, and Jeri Edwards (1995, 1996).

Johannes Sametinger (1997).

UML 1.3 Standard (1999).

Desmond D'Souza and Alan Wills (1999).

Krzysztof Czarnecki and Ulrich Eisenecker (2000).

Peter Herzum and Oliver Sims (2000).

CBSE Handbook (2001).


12. Object and component “wiring” standards.

Where it all came from.

From procedures to objects.

The fine print.

Specification of interfaces and object references.

Interface relationships and polymorphism.

Naming and locating services.

Compound documents.

On the wire—the rise of XML.

XML, XML Namespaces, XML Schema.

XML support standards.

XML document object and streaming models.


XML web services: WSDL, UDDI, WSFL, XLANG.

Web services and programming models.

Which way? 13. The OMG way: CORBA, CCM, OMA, and MDA.

At the heart—the object request broker.

From CORBA to OMA.

CORBA timeline.

A bit of history—system object model (SOM).

Common object service specifications (CORBAservices).

Services supporting enterprise distributed computing.

Services supporting architecture using fine-grained objects.

CORBA Component Model.

Portable object adapter.

CCM components.

CCM containers.

CORBA-compliant implementations.

BEA's WebLogic.

IBM's WebSphere.

IONA's Orbix E2A Application Server Platform.

Borland's Enterprise Server.

Non-for-profit implementations.


Application objects.


Meta-object facility.

Model-driven architecture (MDA). 14. The Sun way—Java, JavaBeans, EJB, and Java 2 editions.

Overview and history of Java component technologies.

Java versus Java 2.

Runtime environment and reference implementations.

Spectrum of editions—Micro, Standard, and Enterprise.

Java, the language.

Interfaces versus classes.

Exceptions and exception handling.

Threads and synchronization.

Garbage collection.


Events and connections.



JAR files—packaging of Java components.

Basic Java services.


Object serialization.

Java native interface.

Java AWT and JFC/Swing.

Advanced JavaBeans specifications.

Component variety—applets, servlets, beans, and Enterprise beans.

Java server pages (JSP) and servlets.

Contextual composition—Enterprise JavaBeans (EJB).

Data-driven composition—message-driven beans in EJB 2.0.

Advanced Java services.

Distributed object model and RMI.

Java and CORBA.

Enterprise service interfaces.

Java and XML.

Interfaces versus classes in Java, revisited.

JXTA and Jini.

Jini—federations of Java objects.

JXTA—peer-to-peer computing.

Java and web services—SunONE. 15. The Microsoft way: COM, OLE/ActiveX, COM+, and .NET CLR.

The first fundamental wiring model—COM.

COM object reuse.

Interfaces and polymorphism.


Interfaces and versioning.

COM object creation and the COM library.

Initializing objects, persistence, structured storage, monikers.

From COM to distributed COM (DCOM).

Meta-information and automation.

Other COM services.

Uniform data transfer.

Dispatch interfaces (dispinterfaces) and dual interfaces.

Outgoing interfaces and connectable objects.

Compound documents and OLE.

OLE containers and servers.

Controls—from Visual Basic via OLE to ActiveX.

Contextual composition and services.

COM apartments—threading and synchronization.

Microsoft transaction server—contexts and activation.

COM+—generalized contexts and data-driven composition.

Take two—the .NET Framework.

The .NET big picture.

Common language infrastructure.

COM and platform interoperation.

Exemplary .NET language—C#.

Visual Studio .NET.

Assemblies—the .NET components.

Common language frameworks.

AppDomains, contexts, reflection, remoting.

Windows Forms, data, management.

Web Forms, Active Server Pages (ASP) .NET.

XML and data.

Enterprise services.

Web services with .NET. 16. Some further technologies.

Computer Associates' Advantage Plex.

Hitachi Appgallery.

Groove Transceiver. 17. Strategic comparison.

Shared attributes.


Consequences for infrastructure vendors.

Consequences for component vendors. 18. Efforts on domain standards.

OMG Domain Technology Committee.



Business processes and documents.

OASIS and ebXML.

RosettaNet and PIPs.



Java domain standard efforts.

OLE for process control.

Industry associations.

Information technology industry groupings.

Trade associations.

User associations. 19. Ongoing concerns.

Domain standards.

Rethinking the foundations of software engineering.

But is it object-oriented?

Object mobility and mobile agents.

Foundations—better contracts for better components.

part four Components meet architecture and process.

20. Component architecture.

The roles of an architecture.

Conceptualization—beyond objects?

Definitions of key terms.

A tiered component architecture.

Components and middleware.

Components versus generative programming. 21. Component frameworks.

Contributions of contextual component frameworks.

Foundation and roots.

Component frameworks versus connectors.

Component frameworks versus metaprogramming.

Component frameworks versus aspect-oriented programming.

Frameworks for contextual composition.

COM+ contexts.

EJB containers.

CCM containers.

CLR contexts and channels.

Tuple and object spaces.

BlackBox component framework.

Carrier-rider-mapper design pattern.

Directory objects.

Hierarchical model view separation.

Container modes.

Cascaded message multicasting services.

Advanced applications based on compound documents.

BlackBox and OLE.

Portos—a hard realtime component framework and its IDE.

Structure of Portos.

Realtime scheduler.

Cross-development environment. 22. Component development.

The methodology—component-oriented programming.

Problems of asynchrony.


Learning from circuit design.

Living without implementation inheritance.

Nutshell classes.

Language support.

Dynamic base objects with forwarding semantics.

Caller encapsulation.

The environment—selecting target frameworks.

The tools—selecting programming languages. 23. Component distribution and acquisition.

Building what sells—applications not components?

Product cataloging and description.

Component location and selection.


Intermediaries. 24. Component assembly.

Systematic initialization and wiring.

Visual component assembly.

Compound documents to supersede visual assembly.

Components beyond graphical user interface environments.

Managed and “self-guided” component assembly.

End-user assembly.

Component evolution. 25. On the horizon.

Advanced object composition.


Split objects.

Environmental acquisition.

Dynamic inheritance.

New forms of object and component abstraction.

Subject-oriented programming.

Aspect-oriented programming.

XML components.

part five Markets and components.

26. Gamut of markets.


Component platforms and infrastructure.


Component design and implementation tools.

Component testing tools.

Component assembly tools.

Component system diagnosis and maintenance.

Professional services.

Component system and framework architects.

Component assembly consultants.

Component configuration management.

Component warehouses, marketing, and consulting.

Component operators, web services, application service providers. 27. New professions.

Component system architect.

Component framework architect.

Component developer.

Component assembler. 28. A component marketing paradox.


Pay per use.

Co-placement of advertisements.

Leveraging on newly created markets.

Leverage of integrative forces. Epilogue.
Appendix A Java versus C# versus Component Pascal.
Useful addresses and bibliography.


Preface to the second edition

Writing a book is hard work; preparing a new edition of one’s own old words is even harder in many ways. My motivation for venturing into this work is the strong and positive feedback and encouragement I received over the past years from so many of my readers. The first edition of this book achieved a level of worldwide recognition well beyond my hopes. Today, the topic area is prominent enough to attract many good authors to write books on the many facets of component software. Some of this work comes to my attention in its early stages, for instance when submitted to a conference where I serve on the program committee. More mature work reaches me in my function as series editor of Addison-Wesley’s Component Software Series. Yet, all this is only scratching the tip of the proverbial iceberg: much is happening in this field at large. Any fair and complete coverage of this ballooning field is now close to impossible and I make no pretense that this second edition gets close to such coverage. Instead, I hope to include what I perceive as the major trends, both as a continuation from what I described in the first edition and also entirely new developments that have emerged since.

In its first edition, this book has been adopted as primary or recommended reading for many university courses in countries around the globe. Close to my heart is the fact that the first edition was translated into Polish — my family name is Polish — but reading it is entirely beyond my own language skills as I hardly speak two Polish words. Some of these developments are traced on a web page I maintain (there is a link from my homepage at www.research.microsoft. com/~cszypers/). Some of the problems I had reported as open in the first edition have attracted the attention of several researchers, leading to progress on several fronts: this second edition reports on some of the progress made.

Concurrent to these scientific developments, we have seen an explosive development of component software technologies. On the one hand, many technologies did not survive long after I closed the first edition in mid 1997 — OpenDoc and SOM are two visible cases; there are many others. On the other hand, many of the technologies relevant today were not even around back then. For example, Enterprise JavaBeans and Java 2 Enterprise Edition on the Java front, as well as the CORBA Component Model and CORBA 3 had yet to happen. CORBA had yet to embrace Java and J2EE had yet to embrace CORBA. COM+ had just become visible and .NET did not exist back then. XML and UML were just appearing on the radar screen, but hadn’t had their overwhelming impact yet. Practically all XML-related standards (XML Schema, XML Namespaces, XPath, XLink, XPointer, XQuery, XSL, XSLT, and others) had yet to be publicized. Web Services and their supporting standards (SOAP, WSDL, UDDI, and so on) were entirely unheard of. Much of the work leading to many of these had, of course, been going on behind the scenes — and for years — but it had been far too early for any useful coverage to be included in a work like this book.

At the time of writing the first edition, it had been painfully clear that for component technologies to go much further, domain-specific standards were an absolute requirement. Much has happened since, especially in connection with XML. Put under pressure by a rapidly tightening need for businesses to form business-to-business chains, and put into agreeable form by the technology-neutral and thus "harmless" XML approach, domain-specific standards are now mushrooming. Organizations such as BizTalk, DMTF, IETF, OAG, OASIS, OMG, UDDI, W3C, and WS-I rapidly build repositories of XML-based domain standards. Domain-specific organizations in many industries are adding to this gold rush. Clearly, we will soon see too many rather than too few standards in many important domains, which will undoubtedly lead to a shakeout over the coming years. (However, notice that the world seems to have an insatiable hunger for standards!)

In line with many hopeful predictions, yet still not quite as explosive as some had hoped, the market side of software components has also matured significantly since this book first appeared. There are now several companies, including ILOG and Rogue Wave Software, deriving most of their revenue from software components and several others fully focusing on making the market-side work, including ComponentSource and Flashline. The latter companies include warehousing, brokering, and mediation services that bridge supply and demand sides, just as is already well-established practice in the component worlds of other engineering disciplines.

All in all, it is now time for a second edition. The theme, the balanced and critical viewpoint (I hope), overall structure, and emphasis on foundations and principles have not changed. A myriad of detail-level improvements and corrections re-establish the link to this quickly evolving field. The most significant additions can be found in Part Three, covering the state-of-the art component technologies. Part Four used to be about the next generation of technologies and problems to tackle. This has now changed and offers, instead, a perspective on components meeting architecture and processes. While this has always been the main theme of the fourth part, it is now possible to draw on rich examples from current technologies rather than on speculation of what might be.

For guidance on how to read this book and on whom it addresses, consult the original preface that I retain in its entirety.

The endless struggle for perfect terminology

What is a software component? As with the first edition, this book has many pages on that fundamental question. It contains three different definitions that adopt different levels of abstraction: a first one is found at the very beginning of the original Preface; a second in Chapter 4; and a final one in Chapter 20. The existence of more than one definition in this book — and quite a few more cited from related work (see Chapter 11) — has led to some turbulence. Krzysztof Czarnecki and Ulrich Eisenecker (2000), in their excellent book Generative Programming, went as far as claiming that the term "component" (and thus "software component") cannot be defined — for a brief discussion see section 11.12.

I received a lot of feedback on the first edition that addressed my choice of terminology, telling me that I had overstretched certain terms. I ran into particular trouble with my use of the terms "binary form" and "no persistent state," both of which I claimed a software component had to comply with. This has led to toing and froing on various occasions, but I have ended up defending my original choice of words. Such disputes over words have led to rather productive opinion-forming exchanges over the deeper issues — the one that has run the longest and is my favorite being the "Beyond Objects" series of monthly columns in Software Development magazine (www.sdmagazine.com), created by Roger Smith. This series includes contributions by Grady Booch, Cris Kobryn, Bertrand Meyer, Bruce Powel Douglass, Jeff Scanlon, and me; others might chip in as the series evolves. I encourage readers to browse these columns as they are naturally closer to the pulse of time than a book can be.

New terminology in this second edition focuses on two developments — the growing importance of component deployment, and the relationship between components and services. To address the deployment process, I now distinguish deployable components (or just components) from deployed components (and, where important, the latter again from installed components). Component instances are always the result of instantiating an installed component — even if installed on the fly. Services are different from components in that they require a service provider. A service is an instance-level concept — where such instances can be component instances. These instances are "live" and thus require grounding in concrete hardware, software, and organizational infrastructure. The term "service" is unfortunately even more overloaded than the term "component." I did not try to rename the many things called service throughout the book, following the many established usages of this word. Instead, I use the term "web service" when referring to a service that is concretely provided, ultimately by some organization (or individual). This convention isn’t strictly accurate, as non-web services can have the same properties, but trying to establish an entirely new term, such as "provided service" seemed worse. (To be even more precise, most concrete discussion in this book is about XML web services — a subset of web services that relies on XML as the fundamental representation format.)

I have tried to improve some terminology over the first edition to minimize misunderstandings. After careful deliberation, I decided to change terms only in two cases. I avoided changes in all other cases to maintain continuity from the first edition and avoid confusion that would be caused by the many references to this book that can be found in the wider literature. (For the same reason, I also decided to leave the top-level chapter structure intact.)

The first change is from old "binary form" to new "executable form." This new term makes it much more obvious that I am after a form for components that is defined relative to some execution engine, whether this is a script interpreter, a JIT compiler, or a processor, and that I am not insisting on the binary format dictated by a particular processor or operating system. This change causes some slight friction when discussing the notions of "COM as a binary standard" and "binary release-to-release compatibility." I retained the use of "binary" in these widely established cases. The new term is also somewhat too specific in that a software component also contains metadata and resources (immutable data), none of which are executable in a strict sense, but then neither are they necessarily binary. (For completeness, a degenerate component might contain nothing but such non-executable items. Other authors have thus opted for "machine interpretable.") Finally, there is a danger that some might interpret executable as meaning "must have a main() entry point," which clearly isn’t intended. With terminology it is impossible to win.

The second change is from old "no persistent state" to new "no observable state." This addresses a common confusion, that persistence in the sense of external stable storage is somehow involved here, which wasn’t the intention. Another common confusion cannot be addressed by simple terminology change. This is that whenever I say "component" (or, more precisely, "software component") I am not referring to object-like instances, but, rather, to notions that are more stable across time and space, such as classes, modules, or immutable prototype objects. Components are the units of deployment and, often, components contain classes or other means to create regular instances (objects). I am not, in general, worried about stateful objects, but merely exclude stateful components, which amounts to excluding the observable use of global variables (aka static variables). Occasionally it is appropriate to use such variables for caching purposes — thus the restricted exclusion of an observable state only. Much of this confusion has been triggered by the discussion of whether or not to support objects that carry state across transactional session boundaries in systems such as COM+ or EJB (EJB does allow such objects; COM+ does not.) As should be clear by now, such "stateful objects" and the claim that software components have no (observable) state have nothing to do with each other.

Updated statement and time stamp

I completed the second edition in the first half of 2002 — after a lengthy journey of well over a year’s duration. I wish to acknowledge that I have added yet another bias to my list of biases — this time by joining Microsoft Research in 1999. While I hope that I succeeded in retaining the balance of my original work, I certainly understand if readers are more skeptical about this than they were before this development. After all, I am now employed by one of the primary parties involved, rather than being an academic observer with a hand in a small Swiss company alone (a role that I happily still retain). However, this book should certainly not be seen as necessarily coinciding with the views of Microsoft. Some may sense that I am overly or prematurely enthusiastic about .NET or web services, but I gave the same benefit of the doubt to then-young Java (JavaBeans, for instance, emerged while I was working on the first edition) and today I am giving it to the CORBA Component Model.

To offset such skepticism, I invited Dominik Gruntz to carefully review and contribute to the core chapter on Java and Stephan Murer to do the same for the core chapter on OMG standards and technologies. Both are long-standing friends who had already helped with their comments on the draft of the first edition. I am most grateful to them both for accepting my invitation and helping me to uphold the spirit of this book into its second edition. I would like to thank Christian Becker, Bill Councill, Scott Crawford, George Heineman, and an anonymous reviewer for reviewing the entire draft and providing many useful comments and suggestions. Hans Jonkers and Ron Kay provided further comments on the basis of the first edition. Alistair Barros drew on his extensive experience and helped with many details regarding EJB servers.

Any remaining mistakes and possibly undue bias are of course mine.

Clemens Szyperski
Redmond, May 2002


(The following preface remains unedited from the first edition. References to "recent" developments should be seen from a historic perspective in our fast-moving world.)

Software components enable practical reuse of software "parts" and amortization of investments over multiple applications. There are other units of reuse, such as source code libraries, designs, or architectures. Therefore, to be specific, software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system. Insisting on independence and binary form is essential to allow for multiple independent vendors and robust integration.

Building new solutions by combining bought and made components improves quality and supports rapid development, leading to a shorter time to market. At the same time, nimble adaptation to changing requirements can be achieved by investing only in key changes of a component-based solution, rather than undertaking a major release change.

For these reasons, component technology is expected by many to be the cornerstone of software in the years to come. There exists at least one strong indicator: the number of articles and trivia published on these matters grows exponentially. Software component technology is one of the most sought-after and at the same time least-understood topics in the software field. As early as 1968, Doug McIlroy predicted that mass-produced components would end the so-called software crisis (Naur and Randall, 1969). With component technology just on the verge of success in 1997, this is a 30-year suspense story.

Software components are clearly not just another fad — the use of components is a law of nature in any mature engineering discipline. It is sometimes claimed that software is too flexible to create components; this is not an argument but an indication of immaturity of the discipline. In the first place, component markets have yet to form and thus many components still need to be custom-made. Introduction of component software principles at such an early stage means: preparing for future markets.

Even in a pre-market stage component software offers substantial software engineering benefits. Component software needs modularity of requirements, architectures, designs, and implementations. Component software thus encourages the move from the current huge monolithic systems to modular structures that offer the benefits of enhanced adaptability, scalability, and maintainability. Once a system is modularized into components, there is much less need for major release changes and the resulting "upgrade treadmill" of entire systems.

Once component markets form, component software promises another advantage: multiplication of investment and innovation. Naturally, this multiplier effect, caused by combining bought and custom-made components, can only take effect when a critical mass is reached — that is, a viable market has formed. For components to be multipliers, there needs to be a competitive market that continually pushes the envelope — that is, it continually improves cost—performance ratios. However, creating and sustaining a market is quite a separate problem from mastering component technology. It is this combination of technical and economic factors that is unique to components.

It is indeed the interplay of technology and market strategies that is finally helping components to reach their long-expected role. However, it would be unfair to say that technically this has been possible since the early days of objects. After all, objects have been around for a long time: Simula’s objects, for example, date back to 1969. The second driving force behind the current component revolution is a series of technological breakthroughs. One of the earliest was the development at Xerox PARC and at NeXT in the late 1980s. The first approach that successfully created a substantial market came in 1992 with Microsoft’s Visual Basic and its components (VBXs). In the enterprise arena, OMG’s CORBA 2.0 followed in mid-1995. The growing popularity of distribution and the internet led to very recent developments, including Microsoft’s DCOM (distributed component object model) and ActiveX, Sun’s Java and its JavaBeans, the Java component standard.

There is one technical issue that turned out to be a major stumbling block on the way to software component technology. The problem is the widespread misconception of what the competing key technologies have to offer and where exactly they differ. In the heat of the debate, few unbiased comparisons are made. It is a technical issue, because it is all about technology and its alleged potential. However, it is just as much a social or societal issue. In many cases, the problems start with a confusion of fundamental terminology. While distribution, objects, and components really are three orthogonal concepts, all combinations of these terms can be found in a confusing variety of usages. For example, distributed objects can be, but do not have to be, based on components — and components can, but do not have to, support objects or distribution.

The early acceptance of new technologies (and adoption of "standards") is often driven by non-technical issues or even "self-fulfilling prophecies." Proper standardization is one way to unify approaches and broaden the basis for component technology. However, standards need to be feasible and practical. As a sanity check, it is helpful if a standard can closely follow an actual and viable implementation of the component approach. What is needed is a demonstration of the workability of the promised component properties, including a demonstration of reasonable performance and resource demands. Also, there need to be at least a few independently developed components that indeed interoperate as promised.

For a good understanding of component software, the required level of detail combined with the required breadth of coverage can become overwhelming. However, important decisions need to be made — decisions that should rest firmly on a deep understanding of the nature of component software. This book is about component software and how it affects engineering, marketing, and deployment of software. It is about the underlying concepts, the currently materializing technologies, and the first stories of success and failure. Finally, it is about people and their involvement in component technology.

This book aims to present a comprehensive and detailed account of most aspects of component software: information that should help to make well-founded decisions; information that provides a starting point for those who then want to dig deeper. In places, the level of detail intentionally goes beyond most introductory texts. However, tiring feature enumerations of current approaches have been avoided. Where relevant, features of the various approaches are drawn together and directly put into perspective. The overall breadth of the material covered in this book reflects that of the topic area; less would be too little.

Today there are three major forces in the component software arena. The Object Management Group, with its CORBA-based standards, entered from a corporate enterprise perspective. Microsoft, with its COM-based standards, entered from a desktop perspective. Finally, Sun, with its Java-based standards, entered from an internet perspective. Clearly, enterprise, desktop, and network solutions will have to converge. All three players try to embrace the other players’ strongholds by expansion and by offering bridging solutions. As a result, all three players display "weak spots" that today do not withstand the "sanity check" of working and viable solutions. This book takes a strategic approach by comparing technical strengths and weaknesses of the approaches, their likely directions, and consequences for decision making.

Significant parts of this book are non-technical in nature. Again, this reflects the very nature of components — components develop their full potential only in a component market. The technical and non-technical issues are deeply intertwined and coverage of both is essential. To guide readers through the wide field of component software, this book follows an outside-in, inside-out approach. As a first step, the component market rationale is developed. Then, component technology is presented as a set of technical concepts. On the basis of this foundation, today’s still evolving component approaches are put into perspective. Future directions are explained on the grounds of what is currently emerging. Finally, the market thread is picked up again, rounding off the discussions and pointing out likely future developments.

Who should read this book — and how: roadmaps

As wide as the spectrum of this book is so, it is envisioned, are the backgrounds and interests of its expected readers. To support such a variety of readers, the book is written with browsing in mind. Most chapters are relatively self-contained and so can be read in any order, although sequential reading is preferable. Where other material is tightly linked, explicit cross-references are given. For selective "fast forwards," various references to later sections are given to aid skipping to natural points of continuation. Forward references are always of an advisory nature only and can be safely ignored by those reading the book sequentially.

Professionals responsible for a company’s software strategy, technology evaluation, or software architecture will find the book useful in its entirety. Reading speed may need to be adjusted according to pre-existing knowledge in the various areas covered in Parts Two and Three. The numerous discussions of relative advantages and disadvantages of methods and approaches are likely to be most useful.

Managers will find the coverage sufficiently general to enable the formation of a solid intuition, but may want to skim over some of the more detailed technical material. In the end, decisions need to be based on many more factors than just the aspects of a particular technology. To this end, the book also helps to put component technology into perspective. A suggested path through this book is Part One; Chapters 4, 8, and 11 of Part Two; Chapters 12 and 17 of Part Three; Part Five.

Developers will appreciate the same intuition-building foundation, but will also find enough detail on which to base technical decisions. In addition, developers facing multiple platforms or multiple component approaches will find the many attempts at concept unification useful. Fair technical comparison of similarities and differences is essential to develop a good understanding of the various tradeoffs involved; terminology wars are not. A suggested path through this book is Parts Two, Three, and Four, supported by Parts One and Five if market orientation is required.

Academics and students on advanced courses will find the book a useful and rich source of material. However, although it could serve as reference reading for various units, it is not a textbook. Those studying units focusing on component technology will benefit the most from reading this book, including coverage of specific component technologies such as Java or ActiveX. If the units are on software engineering, students will also benefit from the information in these pages. Finally, if the units are on advanced or comparative programming languages, students could find this book useful as they may expand to language issues in component technology. A suggested path through this book depends on the needs of the particular subject. Part Two, and in particular Chapter 4, forms a basis; Chapters 5, 6, and 7 can be included for more intensive courses or postgraduate studies. The remaining chapters of Part Two can be included selectively. Part Three offers a rich selection of detailed information on current technology. Part Four explores current developments. Parts One and Five may be of interest for readers on courses with an organizational or market perspective.

Statement and time stamp

I completed this book in the first half of 1997. In a rapidly emerging and changing field, a certain part of the material is likely to be out of date soon. I tried to avoid covering the obviously volatile too deeply and, instead, aimed at clear accounts of the underlying concepts and approaches. For concreteness, I nevertheless included many technical details. I am a co-founder of Oberon microsystems, Inc., Zurich (founded in 1993), one of the first companies to focus fully on component software. In addition to carefully introducing and comparing the main players, I frequently drew on Oberon microsystems’ products for leading-edge examples and comparison. These include the programming language Component Pascal, the BlackBox component framework and builder, and the component-oriented real-time operating system Portos with its development system Denia. The choice of these examples clearly reflects my involvement in their development, as well as my active use of several of these tools in university courses. Despite this personal bias, I aimed at a fair positioning of all the approaches I covered.

This book in its present form would not have been possible without the help of many who were willing to read early drafts and supported me with their scrutiny and richness of comments and ideas. In particular, I would like to thank Cuno Pfister, who reviewed the entire draft, some parts in several revisions, and provided numerous comments and suggestions. Daniel Duffy, Erich Gamma, Robert Griesemer, Stephan Murer, Tobias Murer, Wolfgang Pree, and Paul Roe also commented on the entire draft. Dominik Gruntz, Wolfgang Weck, and Alan Wills provided deep and important comments on selected chapters. Marc Brandis, Bert Fitié, John Gough, and Martin Odersky provided further important comments. Remaining mistakes and oversights are of course mine.

Clemens Szyperski
Brisbane, June 1997

About the contributing authors

Dominik Gruntz is professor for software architecture and design at the Northwestern Switzerland University of Applied Sciences, Aargau, Switzerland. He runs courses on distributed component software and framework design. He is a member of the enterprise computing research group and leads the mobile enterprise project. Dominik also has a lectureship at the Swiss Federal Institute of Technology (ETH) in Zurich.

He has deep knowledge of the Java platform (from J2ME to J2EE) and is a Sun Certified Programmer for the Java 2 Platform. He is also interested in the .NET platform and currently writing a book on C#.

From 1995 to 1999, Dominik worked at Oberon microsystems, Inc., where he contributed to the BlackBox Component Framework. He also examined the Microsoft Component Object Model (COM) and taught this technology in industry courses and at conferences.

Dominik has a masters and a Ph.D. in Computer Science from ETH Zurich.

Stephan Murer is the Chief Information Systems Architect of Crédit Suisse Financial Services, a major financial services company based in Zurich. He is responsible for the overall design of all Crédit Suisse information systems. He has been with Crédit Suisse since 1994 as head of Advanced Technologies and project manager IT Strategy, among other positions. Stephan is also a member of the investment committee of Innoventure, Crédit Suisse’s venture capital company, where he helps develop startup companies in Switzerland.

From 1992 to 1994, he was a postdoctoral researcher at the International Computer Science Institute at the University of California in Berkeley. In Berkeley, Stephan worked in Professor Jerome Feldman’s group on the Sather programming language and extensions to it for parallel computing.

In 1992, he received his Ph.D. from the Swiss Federal Institute of Technology (ETH) in Zurich. He worked on the ADAM parallel computer architecture, a project conducted at the Laboratory of Computer Engineering and Networks under the supervision of Professor Albert Kündig. In 1988 he received his degree in Computer Science from the ETH Zurich.



Submit Errata

More Information

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020