ACM.Szyperski:Component Software_p2, 2nd Edition

About

Features

• 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

Description

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.


Preface.


About the author.


About the contributing authors.


Acknowledgements.

I. MOTIVATION—COMPONENTS AND MARKETS.

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?

II. FOUNDATION.

Terms and concepts.

Components.

Objects.

Components and objects.

Modules.

Whitebox versus blackbox abstractions and reuse.

Interfaces.

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.

Versions.

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.

Histories.

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.

Mixins.

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).

III. COMPONENT MODELS AND PLATFORMS.

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.

SOAP.

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.

CORBAfacilities.

Application objects.

CORBA, UML, XML, and MDA.

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.

JavaBeans.

Events and connections.

Properties.

Introspection.

JAR files—packaging of Java components.

Basic Java services.

Reflection.

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.

Categories.

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.

Differences.

Consequences for infrastructure vendors.

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

OMG Domain Technology Committee.

OMG BODTF.

W3C.

Business processes and documents.

OASIS and ebXML.

RosettaNet and PIPs.

BizTalk.org.

DMTF's CIM and WBEM.

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.

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.

Multithreading.

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.

Superdistribution.

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.

Delegation.

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.

Components.

Component platforms and infrastructure.

Tools.

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.

Branding.

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.
Glossary.
Index.

Preface

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.

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.

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.