This file contains a text only excerpt from "The Essential Distributed
Objects Survival Guide" by Robert Orfali, Dan Harkey, and Jeri Edwards
(Wiley, September 1995).  This excerpt was reproduced with permission
of the publisher.  All rights reserved.

This file contains the following sections:

     - Title
     - Back Cover Text
     - Executive Overview
     - Worldwide Ordering Information
     - Copyright Page
     - Foreword
     - Preface
     - Acknowledgements
     - Notices
     - Contents at Glance
     - Contents
     - List of Boxes
     - Chapter 2. From Distributed Objects To Smart Components
     - Trademarks



----------------------------- Title ------------------------------------


                         The Essential

                      Distributed Objects

                         Survival Guide

         Robert Orfali  -  Dan Harkey  -  Jeri Edwards


----------------------- Back Cover Text --------------------------------

Client/Server / Networking                                    $29.95 USA
                                                              $39.50 CAN


          Distributed Objects Are Closer Than You Think

Distributed Objects and components are a revolution in the making.
They will change the way we develop, build, assemble, sell, and
distribute software.  Their effects will be felt by everyone in the
software business--developers, integrators, IS shops, power users,
and distributors.

  * How do you get ready for the the distributed objects revolution?

  * Should you choose CORBA, OLE, or OpenDoc?

  * Are you having trouble juggling all the new acronyms, products,
    and standards?

  * What do components have to do with client/server?


                     You need a guide!

Award-winning authors Orfali, Harkey, and Edwards combine detailed
technical explanations with their unique brand of offbeat humor--using
clever cartoons, controversial soapboxes, and witty quotes.  Here are
some of the exclusives you'll find in this information-packed
Survival Guide:

  * Covers CORBA, OLE, and OpenDoc in depth, and compares them.

  * Explains how distributed objects, components, and client/server
    come together.

  * Covers components suites, business objects, compound documents,
    frameworks, and more.

  * Covers key products, such as SOM, Orbix, ObjectBroker, Taligent,
    NeXT, Newi, and DOE.

You'll get all the practical information you need to make informed
decisions about distributed objects, component technologies, and their
standards.  Don't make a move without this book!

Robert Orfali, Dan Harkey and Jeri Edwards make
their living designing, building, and evaluating distributed objects
and client/server products.  Their Essential Client/Server
Survival Guide won the Software Development/Jolt Award for Best
Book of 1994.  Robert and Dan are distributed object consultants at
IBM, while Jeri is Director of Transaction Processing and Client/Server
Development at Tandem Computers.  She also manages a large development
effort for creating mission-critical server objects.


John Wiley & Sons
Professional, Reference, and Trade Group
605 Third Avenue, New York, NY 10158-0012
New York - Chichester - Bisbane - Toronto - Singapore



----------------------- Executive Overview ----------------------------


Title: The Essential Distributed Objects Survival Guide (Wiley, Sept 1995)
       by Orfali, Harkey, and Edwards
       604 pages, 260 illustrations, IBM Puborder: SR28-5898
       ISBN 0-471-12993-3, $29.95

This new book by award winning client/server authors Bob Orfali and
Dan Harkey of IBM, and Jeri Edwards, director of OLTP and object
development at Tandem Computers, provides a gentle introduction to
distributed objects for mere mortals.  The 600-page book follows the
same friendly style as the authors' "Essential Client/Server Survival
Guide," (Wiley 1994; ISBN 0-471-13119-9; Puborder SR28-5572)--winner
of the Software Development Jolt Award for Best Computer Book of 1994.

The new Survival Guide provides comprehensive coverage of the big three
object/component technologies--CORBA, OLE, and OpenDoc.  It also provides
an overview of Taligent's CommonPoint, Newi, and OpenStep.  The book
explains concepts such as components, frameworks, and business objects.
If you don't have much time, you can take the 200-page scenic tour; it
provides an overview without getting into the technical details.  The
book includes in-depth comparisons of CORBA/OpenDoc versus COM/OLE and
lots of cartoons.  Here's a snapshot of the Table of Contents:

Part 1: Client/Server with Distributed Objects   (42 pages)

  Introduces distributed objects and components and what objects do
  for client/server systems.

Part 2: CORBA: The Distributed Object Bus  (171 pages)

  Introduces CORBA 2.0, IDL, and Interface Repository.  Covers
  all 16 CORBA object services.  Provides an overview of the key
  commercial ORBs--including SOM, Orbix, ObjectBroker, DOE,
  ORB Plus, and Expersoft's PowerBroker.

Part 3: Frameworks for Business Objects and Components  (120 pages)

  Defines frameworks, business objects, and compound documents.
  Covers CORBA's Common Facilities, OpenDoc, OLE, OpenStep, NeXT,
  CommonView, and Newi.

Part 4: OpenDoc Under the Hood (100 pages)

  Covers the OpenDoc Object Model, Bento, and OSA Scripting.

Part 5: OLE/COM Under the Hood (110 pages)

  Covers the COM object model, OLE, OCXs, and OLE automation.
  Opinionated comparisons of OLE with CORBA/OpenDoc abound (but
  are carefully contained in Soapboxes).

Part 6: Component Nirvana: Client/Server with Parts (30 pages)

  Covers COM/OLE-CORBA/OpenDoc interoperability and provides comparison
  tables of the two models.  The book concludes with a discussion of
  component suites and the business infrastructure required for a
  component industry to succeed.


All Survival Guides are available in local bookstores, IBM puborder,
by calling Wiley at (800) CALL WILEY, by sending an e-mail inquiry to
compbks@jwiley.com, or by calling the IBM Education and Training
Bookstore at (800) 426-8322. Corporate and bulk orders can be placed
by calling 1-(800) 850-6789.



---------------- Worldwide Ordering Information --------------------------


Ordering Information

This book is available in bookstores or it can be ordered by calling
John Wiley & Sons at 1-(800) CALL WILEY or by sending an e-mail inquiry
to compbks@jwiley.com; from IBM Mechanicsburg (IBM Publication number
SR28-5898); or by calling the IBM Education and Training Bookstore at
(800) 568-6294.  Corporate and bulk orders can be placed by calling
1-(800) 850-6789.

Complete and up to date ordering information can be found on
the John Wiley & Sons World Wide Web Home page at http:\\www.wiley.com.

International Orders can be placed at the following addresses:


Asia

Asian Distribution Centre For:
Bangladesh, Brunei, Cambodia, Hong Kong, India, Indonesia, Laos,
Malaysia, Mauritius, Myanmar, Nepal, Pakistan, People's Republic of China,
Philippines, Singapore, South Korea, Sri Lanka, Taiwan, Thailand, Vietnam

John Wiley & Sons (ASIA) Pty. Ltd.
2 Clementi Loop
Jin Zing Distriparl
Singapore 0512
Telephone: 65 258 1147
Fax: 65 258 0697


Canada

John Wiley & Sons Canada, Ltd.
Trade Sales, Marketing and Editorial Division
5353 Dundas Street West, 4th Floor
Etobicoke, ON
M9B 6H8
Phone (416)236-4433
Fax (416)236-4448


Europe

John Wiley & Sons, Ltd.
Customer Service
Distribution Centre
1 Oldlands Way
Shripney
Bognor Regis
PO22 9SA, UK
Telephone: (+44) (0) 1243 829121
Fax: (+44) (0) 1243 820250


Australia

Jacaranda Wiley Ltd.
33 Park Road (P.O. Box 1226)
Milton, Queensland 4064
Telephone: (07) 369-9755
Toll free: 008 777-474
Fax: (07) 369-9155



---------------------- Copyright Page ---------------------------------


Publisher:  Katherine Schowalter
Editor:  Theresa Hudson
Managing Editor: Frank Grazioli
Text Design & Composition: Robert Orfali, Dan Harkey, and Jeri Edwards

Designations used by companies to distinguish their products are often
claimed as trademarks.  In all instances where John Wiley & Sons, Inc.
is aware of a claim, the product names appear in initial capital or all
capital letters.  Readers, however, should contact the appropriate
companies for more complete information regarding trademarks and
registration.

This text is printed on acid-free paper.

Copyright (c) 1994 by John Wiley & Sons, Inc.

All rights reserved.  Published simultaneously in Canada.

This publication is designed to provide accurate and authoritative
information in regard to the subject matter covered.  It is sold with the
understanding that the publisher is not engaged in rendering legal,
accounting, or other professional service.  If legal advice or other
expert assistance is required, the services of a competent professional
person should be sought.

Reproduction or translation of any part of this work beyond that
permitted by section 107 or 108 of the 1976 United States Copyright Act
without the permission of the copyright owner is unlawful.  Requests for
permission or further information should be addressed to the Permissions
Department, John Wiley & Sons, Inc.

Library of Congress Cataloging-in-Publication Data:

Orfali, Robert.
   The essential distributed objects survival guide  /
                 Robert Orfali, Dan Harkey, Jeri Edwards
        p.     cm.
   Includes index.
   ISBN 0-471-12993-3

   Additional CIP Data available upon request.

Printed in the United States of America
10 9 8 7 6 5 4 3 2 1



---------------------- Foreword ---------------------------------------


Greetings, Earthlings!  I'm Zog, the captain of the Martian team.
My team and I first visited earth over a year ago to understand what
client/server is all about.  During that visit, we discovered the
Essential Client/Server Survival Guide and found it to be absolutely
vital in our mission to explore this new technology.  So we were
very excited to hear about The Essential Distributed Objects
Survival Guide by the same authors.  We returned to earth to explore
this new technology and pick up a copy of the book.  It was just
what we were looking for.

So what did I like about this book?  It felt like it was talking
directly to me and to my crew in a friendly voice.  That's very
important when you're from a foreign planet.  We like books that are
painless, fun to read, and contain good Martian humor.  We were
apprehensive at first about objects.  Here at Mars, we're still
trying to figure out how to use client/server, and then here comes
this new technology called distributed objects.  As it turns out,
the timing was perfect.  We now believe that objects are the only
way to build our intergalactic client/server webs.  Yes, we will be
connected to the Internet.  Hopefully, our CORBA-compliant
components will be able to talk to yours.

We really like this component stuff--we want our objects to be smart
from the very start and play in suites.  We were disappointed to
find out that you earthlings are still at war with each other over
component technologies.  Can't you have a single infrastructure?
All this CORBA/OpenDoc versus COM/OLE stuff can really be confusing.
Which component standard should we build on?  This Survival Guide
provides a very complete, in-depth coverage of CORBA, OpenDoc, and
COM/OLE.  We haven't seen anything like it in your earthling
bookstores.  We appreciated its coverage of other object
technologies--including OpenStep, Taligent, and Newi.  We like to
fully understand our options.

This latest Survival Guide is another masterpiece from the authors.
The Soapboxes really helped us understand the issues and what the
latest earthling debates are all about.  We like to hear strong
opinions instead of just sterilized information.  The artwork and
cartoons are absolutely wonderful.  I like to see pictures of myself
in books (and especially on the cover).  The ubiquitous scenarios
show how objects really interact with each other.  It's not that
inert boring stuff you read in the textbooks.  It makes objects come
to life.

In summary, this Survival Guide gave us a comprehensive tour of
distributed object technology and components.  We now have a better
idea of how to use this technology in practical Martian situations.
The personal touch was great; it felt like we had our own private
tour.  I cannot recommend this book enough to my fellow Martians.
Through this foreword, I highly recommend this book to you
Earthlings.  If I can understand components, so can you.


                         Zog



---------------------- Preface ----------------------------------------


Objects: A Revolution Within the Revolution

Client/server computing has created a deep paradigmatic shift in our
industry.  It's replacing monolithic mainframe applications with
applications split across client and server lines.  The client--
typically a PC--provides the graphical interface, while the server
provides access to shared resources--typically a database.
Distributed objects are a paradigm shift within a paradigm shift--
they're a new client/server revolution within the client/server
revolution.  Objects break-up the client and server sides of an
application into smart components that can play together and roam
across networks.


Why Another Revolution?

So why is there another client/server revolution when the first one
is still in full swing?  The answer--as usual--is newer and better
hardware and the demand for applications that match the new hardware.
The first client/server revolution was driven by new hardware--PCs
and Ethernet LANs forever changed the way we interact with our
applications.  Gone are the green-screen uglies associated with
terminal-attached mainframes.  Instead, we have GUIs.  There's no
way to turn back the clock.

The second client/server revolution is also being fueled by advances
in hardware.  This time, Wide Area Networks (WANs) are breaking the
proximity barriers associated with Ethernet LANs.  Millions of us
are getting a firsthand taste--thanks to the Internet, CompuServe,
and America Online--of the joys of intergalactic networking.  We will
soon want a lot more.  We won't be satisfied with just navigating
through information and chatting;  we will want to conduct our
business on these networks.  Money will start changing hands.  People
will either transact directly or through their electronic agents.
In the age of intergalactic transactions, there's no going back to
single-server, departmental client/server LANs.  Mosaic has changed
that forever.

So, the second era of client/server is being driven by very high
speed, low-cost, wide-area bandwidth.  The telephone companies and
WAN providers are getting ready to unleash almost unlimited
bandwidth--they're wiring the entire planet for fiber optic speeds.
In addition, network-ready PCs running commodity multi-threaded
operating systems--such as OS/2 Warp Connect and Windows 95--are now
capable of running as both clients and servers.

This means that we may soon have millions of servers interconnected
across the planet at ten times LAN speeds.  This is the good news.
The bad news is that our existing client/server infrastructure is
geared for single-server departmental LANs; it cannot cope with the
new intergalactic demands--millions of servers and applications that
can spawn trillions of distributed transactions.  Distributed
objects are our only hope for dealing with the new client/server
infrastructure requirements.


Why Distributed Objects?

A distributed object is essentially a component.  This means it's a
blob of self-contained intelligence that can interoperate across
operating systems, networks, languages, applications, tools, and
multivendor hardware.  Without stealing the punchline from this
Survival Guide, we can say that distributed objects--when packaged
as components--provide the only middleware that can make
client/server computing really work at an intergalactic level.

This Survival Guide is not an academic exercise on the wonders of
objects.  For the first time in the 22-year history of objects, we
have true intergalactic standards for building object components
that are interoperable, transactional, secure, and self-managing.
We also have standards that allow these components to play in
suites--on the desktop or across the enterprise.  The industry even
has two "standards" to choose from: COM/OLE from Microsoft and CORBA
from the OMG (augmented by OpenDoc from CI Labs).  And we are
starting to see applications and products that build on these
standards.


Building Applications With Components

Distributed objects and components will change the way we architect,
develop, package, distribute, license, and maintain our software.
The component is a unit of packaging, distribution, and maintenance.
It's also a unit of deployment on the intergalactic network.  A
component does not operate in a vacuum.  It lives on a distributed
object bus--for example, CORBA or COM.  The component derives its
system smarts from the bus.  It is architected to work with other
components from the very start.  In fact, the object buses are now
adding new services that -components can inherit at build time or
even at run time to achieve higher levels of collaboration with other
independent components.

This intelligent infrastructure makes it easier to develop and
assemble independent components.  It lowers the barriers to entry
and changes the economics of software.  Components bring the fun
back to software development.  Smaller ISVs will find it easier to
create components for the functions they do best without having to
reinvent the entire infrastructure.  The object bus provides a
unified systems architecture that can be of tremendous help to IS
shops and system integrators.  Finally, components will help lower
the costs of software development and maintenance for regular
software houses.  Consumers also win because they can control when
to upgrade their software with add-on components to get more
customized systems.

The beauty of all this is that a single object bus can support
components that run in the same process as well as components that
run across an intergalactic network.  It's one bus that really
scales.  You can use it for both standalone applications and
intergalactic ones.  In addition, the applications we can create are
unlike any we've seen before.   Component agents will watch for
network events and act on their own to submit transactions or gather
data.  Components will come together in real time to create a
one-time application tailored for a particular customer.  New
applications--some yet to be imagined--will generate millions of new
transactions daily.  These include electronic travel agencies,
health-care portfolio managers, financial agents, shopping mavens,
and career managers.  These applications can transact for you in all
kinds of intergalactic electronic bazaars that specialize in every
known form of trading.


What This Survival Guide Covers

This book explains distributed objects and components in depth.  It
consists of six parts--each one can almost be read independently.
We'll give you a short description of what the parts cover.  If you
find the terminology too foreign, then by all means read the book
to find out what it all means.



-  Part 1 starts with an overview of what objects can do for
   client/server.  We compare distributed objects with competing
   client/server application environments--including SQL databases,
   TP Monitors, and Groupware.  If you come from a client/server
   background, this discussion will help you understand what the
   distributed object fuss is all about.  In this part, we also
   explain what objects are and when an object is a component.  We
   provide a very comprehensive description of the benefits of
   components and their attributes.  Components do more than just
   client/server--they change the nature of computing, especially on
   the desktop.

-  Part 2 covers the CORBA object bus and system-level object services
   in great detail.  If you're not interested in all the low-level
   details, the first chapter provides a birds-eye view of CORBA.

-  Part 3 covers business objects and application-level frameworks--
   including CORBA frameworks, OpenDoc, OLE, Taligent, OpenStep, and
   Newi.  Of course, the most important of these frameworks are
   currently OLE and OpenDoc.  But the rest of the frameworks also
   have important features that you should know about.   Many of
   these features may eventually be merged with either OLE or OpenDoc.

-  Part 4 covers OpenDoc in depth.  We go over all the features of
   its compound document application-level framework.

-  Part 5 covers COM/OLE in depth.  We cover both OLE's object bus--
   called COM--and its compound document application-level framework.

-  Part 6 helps you narrow down your options.  We try and bring it
   all together and speculate on where it's all going.


This book contains a detailed overview of CORBA, OpenDoc, and
COM/OLE.  If this is not enough, we include a bibliography and
pointers on where to go for more information.


How to Read This Book

As we recommend in all our books, the best way to approach this
Survival Guide is to ask your boss for a one-week, paid sabbatical
to go sit on a beach and read it.  Tell him or her that it's the
cheapest way to revitalize yourself technically and find out all
there is to know about distributed objects, components, OpenDoc,
CORBA, OLE, Taligent, and OpenStep.  Once you sink into that
comfortable chair overlooking the ocean, we think you'll find the
book a lot of fun--maybe even downright relaxing.  You won't get
bored; but if you do, simply jump to the next part until you find
something you like.  You can jump to any part of the book and start
reading it.  We recommend, however, that you carefully go over the
cartoons so that you have something to tell the boss back at the
office.


What Are the Boxes For?

We use shaded boxes as a way to introduce concurrent threads in the
presentation material.  It's the book version of multitasking.  The
Soapboxes introduce strong opinions or biases on some of the more
controversial topics of distributed object computing (see the next
Soapbox).  Because the discipline is so new and fuzzy, there's lots
of room for interpretation and debate--so you'll get lots of Soapboxes
that are just another opinion (ours).  The Briefing boxes give you
background or tutorial type information.  You can safely skip over
them if you're already familiar with a topic.  The  Detail boxes
cover some esoteric area of technology that may not be of interest
to the general readership.  Typically, the same readers that skip
over the briefings will find the details interesting (so you'll still
get your money's worth).  Lastly, we use Warning boxes to let you
know where danger lies--this is, after all, a Survival Guide.


Who Is This Book For?

This book is for anybody who's associated with the computer industry
and needs to understand where it's heading.  Within three years we
will all be involved with objects and components in some form or
another--as users, assemblers, integrators, system developers, and
component developers.  All new software will be built using
components.

If you have very little time to spare (or little interest in the
technical details), we suggest that you take the scenic route.  It
includes all of Part 1, the first chapter of Part 2, and all of Parts
3 and 6.  Look for the scenic route signs at the beginning of these
chapters and in the Table of Contents.  This will let you postpone
reading the more technical chapters, but you will still have a solid
overview of distributed objects and components, their standards, and
the key products.


How Does This Survival Guide Compare With Our Previous Book?

Our previous book, the Essential Client/Server Survival Guide
(Wiley, 1994) provides an overview of the entire field of
client/server computing--including NOSs, SQL databases, TP Monitors,
groupware, system management, tools, and distributed objects.  This
Survival Guide starts out where the other one leaves off.  It focuses
entirely on distributed objects and components.  We felt there was
a lot more to say about distributed objects than we could cover in
the previous Survival Guide.  If you read our previous book, you'll
notice that we borrowed about 50 pages from it to make this one stand
on its own.  If you did not read the previous Survival Guide, Chapter 1
reviews the main ideas we developed there.

Some of the ideas in this Survival Guide appeared in articles we
published over the last 10 months in major trade publications--
including BYTE, Datamation, Object Magazine, Dr. Dobb's Journal, and
others.  We're grateful to the senior editors of these magazines for
providing us a forum to develop our ideas.  However, we felt we could
not tell the distributed components story--including CORBA, OpenDoc,
and OLE--in articles that average 10 pages or less.  These component
technologies are like a giant tidal wave that's heading our way to
reshape our industry.  They deserve a bit more scrutiny than what
you read in a fast-paced magazine article.  So we finally decided
we had to write this Survival Guide to get this story off our chests.
We wrote it.  Now it's in your hands--totally unabridged.

We hope you enjoy the reading, the cartoons, and the Soapboxes.  Drop
us a line if you have something you want to "flame" about.   We'll
take compliments too.  We're relying on word-of-mouth to let people
know about the book, so if you enjoy it, please spread the word.
Finally, we want to thank you, as well as our Martian friends, for
trusting us to be your guides.



     ======== Soapbox: Putting Our Biases on the Table ========

The world will always be divided into two groups.  You're never
going to have just a total solution.  The world will never be
totally OLE, and probably never totally CORBA.

                     -- Colin Newman, Marketing Director
                        Iona
                        (March, 1995)

Welcome to your first Soapbox!  We decided to confess right from
the start that we have strong biases on how we view this object
business (you can still get a refund after reading this).  Unless
you spent the last year hiding on some deserted island, you
probably know that there's a full-fledged object war going on.
This war is being fought in the press, on the Internet, in industry
conferences, and with white papers.  What's at stake is the future
of the software industry and client/server.  On one side is
Microsoft, with its COM/OLE component infrastructure and object
bus--it's the de facto object standard.  On the other side is the
rest of the industry, with its support of OMG's CORBA as the
object bus--it's the de jure object standard.  In addition, there's
the OpenDoc consortium that provides an "open" compound document
infrastructure based on CORBA.

In this Beta versus VHS war for component standards, you may have
to take sides--unless you have enough resources to support both
standards.  For us, just writing a Survival Guide that fully
covers both standards was a huge effort.  And it takes a lot more
effort to develop and support code that runs on two standards.
Our industry can at most support two standards.  But, we briefly
cover Taligent, Newi, and OpenStep just to give you an idea of
what else is happening in distributed objects.  We also show how
these highly creative "alternate standards" are starting to merge
with the big two.  However, the emphasis in this
book is on the "big two":  CORBA/OpenDoc and COM/OLE.  Both of
these standards are here to stay.  Neither will disappear soon.
And we may have to live with both for a very long time; but it
won't be easy.

We believe that CORBA is much better than COM/OLE, at least
technically.  We also feel more comfortable with a de jure
standard that's not controlled by a single company.  Microsoft--
like the old IBM--is trying to single-handedly control standards.
It believes it can define a homogeneous world where all the
important standards will be theirs.  But we believe that this
single-system view of the world just doesn't work in the case of
components, which--by definition--must be heterogeneous,
multiplatform, open, interoperable, and supported by multiple
vendors.  It's best to do this with de jure and open standards.
OLE may become "Microsoft's SAA."

You may hear from naysayers that CORBA--with its 500+ members--is
"designed by committee" and that it may be best to have a single
vendor do the whole design.  This is not the case.  Some standard
bodies have rightfully acquired a bad name.  However, CORBA is
almost a labor of love by some of the best object technologists
in the business.  The CORBA standards move fast and are very
creative.  As you'll see in this Survival Guide, CORBA compromises
typically give us the best of two technologies.  Let's face it:
Objects are still an art form.  It takes a lot of collective brain
power to figure out how to build an infrastructure for
heterogeneous distributed components.

We challenge the naysayers to say that OLE is better technically
than CORBA.  On the contrary, CORBA is at least two years ahead
of OLE/COM in creating a heterogeneous, distributed, component
infrastructure.  And OpenDoc is better than OLE as a compound
document framework.  Microsoft has just too many legacy APIs to
bring forward.  You'll be able to judge these things for yourself
when you read this book.

Despite our CORBA bias, this Survival Guide contains one of the
most complete technical descriptions of COM/OLE anywhere.  We
tried very hard to keep our opinions in Soapboxes (like this one).
Also, we believe that OLE is here to stay because of its close
integration with Windows.  So you might as well learn it.  This
Survival Guide contains over 160 pages on COM/OLE--including many
comparisons with CORBA and OpenDoc.

In addition to our own opinions, we also include lots of quotes
from industry people on this object war.  It seems everybody has
something to say about this important issue.  So we wanted you
to hear from them, too.  The bad news is that we have fewer quotes
this time from non-industry people such as Bob Dylan and Lao Tzu.
So now that we got our biases out on the table, let's move forward
with this Survival Guide.

     ==================== end box =============================



---------------------- Acknowledgements -------------------------------


It's impossible to thank all the hundreds of people that helped us
with this book.  But, we'll give it a try:

To Cynthia McFall and Cliff Reeves for giving Bob and Dan a home
with the object group in Austin, even though we work from the San
Francisco Bay Area.  Cynthia was there when we needed her.  We
also thank Dave Brandt and Dell Rieth for their ongoing support.

-  To the technical people in different companies who helped us make
   some sense out of this difficult topic--including Mike Blevins,
   Kathy Bohrer, Grady Booch, Kraig Brockschmidt, Frank Campagnoni,
   Guylaine Cantin, Rick Cattell, Dan Chang, Phil Chang, Ed Cobb,
   Mike Conner, Bill Culman, Richard Finkelstein, Ira Forman, Jim
   Gray, Jed Harris, Pete Homan, Ivar Jacobson, Ralph Johnson,
   Johannes Klein, Charly Kleissner, Wilfried Kruse, Christina Lau,
   Kevin Leong, Geoff Lewis, Mary Loomis, Hari Madduri, Tom Mowbray,
   Annrai O'Toole, Mark Phillips, Kurt Piersol, Mike Potel, Tony
   Rego, John Rymer, Harold Sammer, Roger Sessions, Oliver Sims,
   Richard Soley, Chris Stone, Bruce Tate, David Taylor, Lou
   Thomason, John Tibbetts, Robert Tycast,  Robert Vasaly, Don Vines,
   John Vlissides, Sara Williams, Tony Williams, and Dave Wilson.

-  To the senior editors in the major trade publications who gave us
   a chance to develop an early version of this story--including Dick
   Conklin, Marie Lenzi, Kevin Strehlo, Jon Udell, Ray Valdes, and
   Alan Zeichick.  Some of these editors wrote their own distributed
   object story.

-  To the marketing directors and product managers who fed us with
   up-to-the-minute information on their latest and greatest
   products--including Michael Barton, Lydia Bennett, Anthony Brown,
   Dianne Copenhaver, Scott Hebner, Chris Hyrne, Larry Perlstein,
   and Keith Wescourt.

-  To Dave Pacheco for creating the wonderful technical illustrations
   in this book (the cartoons are still by Jeri).

-  To our tireless copy editor, Larry Mackin.

-  To the people at Wiley that had to deal with our pickiness--including
   Terry Canela, Frank Grazioli, Terri Hudson, Bob Ipsen, Ellen
   Reavis, and Katherine Schowalter.  We also thank our previous
   editor Diane Littwin.

-  To the more than 100,000 readers who read our previous books.
   Without your continued support we couldn't write these books.



--------------------------- Notices -----------------------------------


The authors and publishers of this book have used their best efforts
in preparing this book.  The authors and publisher make no warranty of
any kind, expressed or implied, with regard to the documentation
contained in this book.  The authors and publishers shall not be liable
in any event for incidental or consequential damages in connection with,
or arising out of the use of the information in this book.

The product descriptions are based on the best information available
at the time of publication.  Product prices are subject to change
without notice.  Contact the product suppliers for the latest pricing
and product information.

Some illustrations incorporate clip art from Corel Systems
Corporation's Corel Draw 4.0 clip art library.

All the views expressed in this book are solely the Authors' and
should not be attributed to IBM or Tandem Computers, or any other IBM
or Tandem employee.  The three authors contributed equally to the
production of this book and are amazed to find themselves still alive
to see it published.



---------------------- Contents at a Glance ---------------------------


Part 1. Client/Server With Distributed Objects                        1
Part 2. CORBA: The Distributed Object Bus                            43
Part 3. Frameworks for Business Objects and Components              217
Part 4. OpenDoc Under the Hood                                      339
Part 5. OLE/COM Under the Hood                                      425
Part 6. Component Nirvana: Client/Server With Parts                 533



---------------------------- Contents --------------------------------------


Foreword                                                                  ix
Preface                                                                   xi


Part 1. Client/Server With Distributed Objects                             1
____________________________________________________________________________

Scenic Concept
Chapter 1. Objects: The Next Client/Server Revolution                      3
   Intergalactic Client/Server Computing                                   4
      What Client/Server Software Is Needed?                               5
   Who Will Lead the Next Client/Server Revolution?                        6
      Client/Server With SQL Databases                                     7
      Client/Server With TP Monitors                                       9
      Client/Server With Groupware                                        12
      Client/Server With Distributed Objects                              15

Scenic Concepts
Chapter 2. From Distributed Objects To Smart Components                   21
   Objects and Distributed Objects                                        22
      Distributed Objects                                                 23
      Object Magic                                                        23
      Encapsulation                                                       24
   Components: The Grand Prize of Objects                                 28
      The Driving Force Behind Components                                 29
      Components to the Rescue                                            30
      When Can We Expect These Components?                                32
      So, What Exactly Is a Component?                                    34
      So, What Is a Supercomponent?                                       36
      Business Objects: The Ultimate Components                           38
      Your Guide to the Symbols Used in This Survival Guide               39
      The Component Road Map                                              42


Part 2. The Distributed Object Bus                                        43
____________________________________________________________________________

Scenic Concept
Chapter 3. CORBA: A Bird's Eye View                                       47
   Distributed Objects, CORBA Style                                       49
      What Is a CORBA Distributed Object?                                 49
      Everything Is in IDL                                                50
      CORBA Components: From System Objects To Business Objects           52
   OMG's Object Management Architecture                                   53
      The Object Request Broker (ORB)                                     54
      Object Services                                                     57
      Object Services: Build-to-Order Middleware                          59
      Object Services: The Roll-Out Road Map                              60
      Common Facilities                                                   61
      Application/Business Objects                                        62

Concepts
Chapter 4. CORBA 2.0: The Intergalactic Object Bus                        67
   What Exactly Is a CORBA 2.0 ORB?                                       68
      The Anatomy of a CORBA 2.0 ORB                                      69
      CORBA Method Invocations: Static Versus Dynamic                     72
      CORBA Static Method Invocations: From IDL to Interface Stubs        74
      CORBA Dynamic Method Invocations: A Step-By-Step Guide              76
      The Server Side of CORBA                                            78
      What's an Object Adapter?                                           78
      BOA and Other Object Adapters                                       80
      BOA Shared Server                                                   81
      BOA Unshared Server                                                 81
      BOA Server-per-Method                                               82
      BOA Persistent Server                                               83
      CORBA 2.0 Initialization--Or How Does a Component Find Its ORB?     83
   CORBA 2.0: The Intergalactic ORB                                       85
      CORBA 2.0: The Inter-ORB Architecture                               85
      CORBA 2.0: ORB-to-ORB Bridging                                      87
      Federated ORBs                                                      88

Concepts
Chapter 5. CORBA Metadata: IDL and Interface Repository                   91
   The CORBA IDL: A Closer Look                                           93
      What Does an IDL Contract Cover?                                    93
      The Structure of the CORBA IDL                                      94
      An IDL Example                                                      96
      Type Codes: CORBA's Self-Describing Data                            97
   The CORBA 2.0 Interface Repository                                     98
      What's an Interface Repository?                                     98
      Why Is an Interface Repository Needed Anyway?                       99
      Interface Repository Classes: The Containment Hierarchy             99
      The Interface Repository Class Hierarchy                           100
      Federated Interface Repositories                                   104
      What Does a Global Repository ID Look Like?                        105
      Conclusion                                                         107

Concepts
Chapter 6. CORBA Services: Naming, Events, and Life Cycle                109
   The CORBA Object Naming Service                                       110
      What's in a CORBA Object Name?                                     111
      How Does It Work?                                                  112
   The CORBA Object Trader Service                                       113
   The CORBA Object Life Cycle Service                                   114
      A Compound Life Cycle Example                                      115
      The Life Cycle Interfaces                                          115
      The Compound Life Cycle Interfaces                                 117
   The CORBA Event Service                                               119
      Suppliers and Consumers of Events                                  119
      The Event Channel                                                  121
      Conclusion                                                         121

Concepts
Chapter 7. CORBA Services: Transactions and Concurrency                  123
   The CORBA Object Transaction Service                                  124
      What Is a Transaction?                                             124
      Object Transaction Service: Features                               127
      The Elements of the Object Transaction Service                     128
      The OTS Interfaces                                                 129
      An Object Transaction Scenario                                     132
   The CORBA Concurrency Control Service                                 134
      The Concurrency Control Service and Transactions                   134
      Locks                                                              135
      Locksets                                                           135
      Nested Transactions and Locking                                    135
      The Concurrency Control Interfaces                                 136
      Conclusion                                                         137

Concepts
Chapter 8. CORBA Services: Persistence and Object Databases              139
   The CORBA Persistent Object Service (POS)                             140
      What Is POS?                                                       140
      Single-Level Stores Versus Two-Level Stores                        142
      POS: The Client's View                                             142
      POS: The Persistent Object's View                                  143
      The Elements of POS                                                144
      POS Protocols: The Object-PDS Conspiracy                           146
      The POS Interfaces                                                 149
      The POS CLI Interfaces                                             150
   Object Database Management Systems                                    151
      What's an ODBMS?                                                   152
      What's an ODBMS Good For?                                          154
      ODBMS Client/Server Implementations                                157
      ODMG-93: The Lingua Franca for ODBMS                               159

Concepts
Chapter 9. CORBA Services: Query and Relationships                       165
   The CORBA Query Service                                               165
      Federated Queries                                                  166
      Collections for Manipulating Query Results                         167
      Query Service: The Collection Interfaces                           167
      Query Service: The Query Interfaces                                168
      A Simple Query Scenario                                            169
      A More Complex Query Scenario                                      171
   The CORBA Collection Service                                          172
   The CORBA Relationship Service                                        173
      Why a Relationship Service?                                        173
      What Exactly Is a Relationship?                                    174
      Levels of Relationship Service                                     176
      Relationship Service: The Base Interfaces                          176
      Relationship Service: Graphs of Related Objects                    178
      Relationship Service: The Containment and Reference Relationships  179
      Conclusion                                                         181

Concepts
Chapter 10. CORBA Services: System Management and Security               183
   The CORBA Externalization Service                                     184
      Stream Power                                                       184
      Externalization Service: The Base Interfaces                       185
      A Stream Scenario                                                  186
   The CORBA Object Licensing Service                                    188
      What Does the Licensing Service Do?                                189
      Licensing Service Interfaces                                       189
      A Licensing Scenario                                               191
   The CORBA Object Property Service                                     192
      Property Service Interfaces                                        192
   The CORBA Object Time Service                                         194
   The CORBA Object Security Service                                     195
      What Is ORB-Based Security?                                        198
      Authentication: Are You Who You Claim to Be?                       198
      Authorization: Are You Allowed to Use This Resource?               199
      Audit Trails: Where Have You Been?                                 200
      Non-Repudiation: Was This Message Tampered With?                   200
      Other Security Issues                                              200
   The CORBA Object Change Management Service                            201
      Conclusion                                                         202

Product
Chapter 11. CORBA Commercial ORBs                                        203
   Iona's Orbix                                                          204
      Orbix Architecture                                                 205
      Orbix 2.0's Current CORBA Support                                  205
      Orbix's CORBA Support in Early 1996                                205
      Orbix's CORBA Extensions                                           206
   Digital's ObjectBroker                                                206
      ObjectBroker Architecture                                          207
      ObjectBroker 2.5's Current CORBA Support                           207
      ObjectBroker's CORBA Support in 1996                               207
   IBM's SOM                                                             208
      SOM Architecture                                                   208
      SOM's Object Model Extensions and Other Features                   209
      SOM 2.1's Current CORBA Support                                    209
      SOM's CORBA Support in 1996                                        210
   Expersoft's XShell                                                    210
      XShell 3.5's Current CORBA Support                                 211
      XShell (or PowerBroker): CORBA Support in 1996                     211
   Sun's Distributed Objects Everywhere (DOE)                            211
      Sun's Current CORBA Support                                        212
      Sun's CORBA Support in 1996                                        212
   HP's ORB Plus                                                         212
      HP's CORBA Support in 1996                                         212
   Who Did We Leave Out?                                                 213
   Conclusion and Some Parting Comments                                  213


Part 3. Frameworks for Business Objects and Components                   217
____________________________________________________________________________

Scenic Concept
Chapter 12. Object Frameworks: An Overview                               221
   Frameworks Overview                                                   222
      What Are Object Frameworks?                                        223
      How Frameworks Work                                                224
      Key Benefits of Object Frameworks                                  226
      Frameworks, APIs, or Class Libraries?                              227
      Procedural Frameworks: Look Ma, No Objects                         229
   Frameworks for Business Objects and Components                        231
      Meet the Players                                                   231
      Types of Frameworks                                                231
      Frameworks and Design Patterns                                     233
      Quiz: Framework or White Box Component?                            235
      Class Libraries, Frameworks, and Components                        236
      Conclusion                                                         237

Scenic Concept
Chapter 13. CORBA's Frameworks and Business Objects                      239
   Business Objects                                                      240
      So What Is a Business Object Anyway?                               240
      Cooperating Business Objects                                       242
      The Anatomy of a Business Object                                   243
      The Anatomy of a Client/Server Business Object                     245
   CORBA's Common Facilities                                             246
      What Are CORBA Common Facilities?                                  247
      The CORBA User Interface Common Facility                           248
      The CORBA Information Management Common Facility                   249
      The CORBA System Management Common Facility                        250
      The CORBA Task Management Common Facility                          255
      The CORBA Vertical Market Common Facilities                        258
      When Can You Expect These Common Facilities?                       259
      Conclusion                                                         260

Scenic Concept
Chapter 14. Compound Documents: The Desktop Framework                    261
   Compound Documents: Why All the Fuss?                                 262
      The Borderless Desktop                                             262
      Documents Come in All Shapes                                       262
      A Home for All Data Types                                          263
      In-Place Editing                                                   264
      Shippable Documents                                                264
   The Compound Document Framework                                       266
      Document Layout                                                    267
      Structured Storage                                                 267
      Scripting and Automation                                           268
      Uniform Data Transfer                                              269
      Conclusion                                                         269

Scenic Product
Chapter 15. The OpenDoc Component Model                                  271
   Parts: Components, OpenDoc Style                                      272
      OpenDoc Meets CORBA                                                272
   OpenDoc's Constituent Technologies                                    272
      SOM                                                                273
      Bento                                                              274
      Uniform Data Transfer                                              274
      Compound Document Management                                       275
      Open Scripting Architecture                                        275
   OpenDoc: Who Ships What?                                              277
   ComponentGlue: OpenDoc Becomes OLE and Vice Versa                     278
   What OpenDoc Does for Client/Server Systems                           279
      Client/Server, OpenDoc Style                                       279
      How OpenDoc Enhances CORBA                                         280
      Conclusion                                                         281

Scenic Product
Chapter 16. OLE/COM: The Other Component Standard                        283
   OLE for the Enterprise                                                284
   What Is OLE?                                                          284
      OLE: A Short History                                               285
      OLE Is OLE                                                         285
      The Vision: The Framework Is Windows                               286
      OLE: Interfaces Everywhere                                         286
      So, What Is an OLE Component?                                      287
   OLE's Constituent Technologies                                        288
      The Component Object Model (COM)                                   289
      OLE's Automation and Scripting Services                            290
      OLE's Uniform Data Transfer                                        291
      OLE's Structured Storage and Persistence Services                  291
      OLE's Compound Document Service                                    292
   OLE Tools and Foundation Classes                                      293
      Microsoft Foundation Classes (MFC)                                 293
      Microsoft Visual C++                                               294
      Conclusion                                                         294

Scenic Product
Chapter 17. Taligent's CommonPoint: Frameworks Everywhere                297
   Integrated Frameworks                                                 298
      So What's an Application System Anyway?                            299
      Frameworks Everywhere                                              300
   People, Places, and Things                                            302
      How the New Metaphor Works                                         302
      Places                                                             303
      People                                                             305
      Things                                                             306
   Compound Documents, CommonPoint Style                                 307
      Shared Documents                                                   307
      The Taligent Compound Document Model                               308
      Taligent/OpenDoc Interoperability                                  308
      Conclusion                                                         312

Scenic Product
Chapter 18. NeXT's OpenStep and Portable Distributed Objects             313
   Who Is Doing What With OpenStep?                                      314
      OpenStep in the Unix World                                         314
      OpenStep in the Windows World                                      314
   What Is OpenStep?                                                     315
      PDO and Objective C                                                315
      The Application Framework                                          319
      Display PostScript                                                 319
      Application Development Tools                                      319
      The Enterprise Objects Framework                                   320

Scenic Product
Chapter 19. Newi: Cooperative Business Objects                           325
   Newi's Business Objects                                               326
      What Is a CBO?                                                     327
      CBOs Versus Compound Document Components                           327
   The Newi ORB and Business Object Framework                            329
      The Newi ORB: Message-Time Binding                                 329
      Newi's Dynamic Object Hierarchies                                  331
      Newi's Model/View Separation                                       332
      View Layout Files                                                  334
      Other Newi Frameworks and Tools                                    335
      Newi, OpenDoc, and SOM/CORBA                                       335
      Conclusion                                                         337


Part 4. OpenDoc Under the Hood                                           339
____________________________________________________________________________

Product
Chapter 20. OpenDoc and SOM: The Object Model                            343
   What SOM Brings to the Party                                          344
      OpenDoc and SOM                                                    344
      SOM: A Technology for Packaging Parts                              345
   The OpenDoc Programming Model                                         346
      ODPart: The Part Editor Class                                      346
      The OpenDoc Class Hierarchy                                        347
      How Part Editors Find OpenDoc Objects                              350
      How Intrusive Is the OpenDoc Programming Model?                    351
      OpenDoc Frameworks and Tools                                       352

Product
Chapter 21. OpenDoc: The Compound Document Model                         357
   Binding: Creating the OpenDoc Environment                             358
      The Document Shell: OpenDoc's Run-Time Manager                     359
      Factories and Reference-Counted Objects                            359
      Binding: How Part Data Finds Part Editor                           360
   Layout and Geometry Management                                        361
      OpenDoc Container Parts                                            361
      Frames, Facets, and Canvases                                       362
      Drawing, OpenDoc Style                                             365
      Views: A Part Is a Part                                            366
      Part Windows                                                       366
      Controls                                                           367
   Event Distribution and Arbitration                                    368
      Arbitration With Focus Sets                                        368
      Inside-Out Part Activation                                         369
      Sharing Menus                                                      370

Product
Chapter 22. OpenDoc: Bento and Storage Units                             373
   The Bento Storage System                                              375
      The Storage Containment Hierarchy                                  376
   OpenDoc Storage Units                                                 377
      Properties With Multiple Values                                    377
      Just What Is a Storage Unit Anyway?                                377
      Navigating Through Storage Units                                   378
      Persistent References and Cloning                                  380
      The Persistent Elements                                            382
      Standard Properties                                                382
      A Day in the Life of a Storage Unit                                383
   Conclusion                                                            385

Product
Chapter 23. OpenDoc: Uniform Data Transfer                               387
   Drag-and-Drop Transfers                                               389
   Clipboard Transfers                                                   391
   Linked Data Transfers                                                 394
      OpenDoc's Link-Related Objects                                     394
      Advertising a Link                                                 396
      Scenario: Data Interchange Via Links                               396
   Conclusion                                                            398

Product
Chapter 24. OpenDoc: Automation and Semantic Events                      399
   The Brave New World of OpenDoc Scripting                              401
      New Age Scripting                                                  401
      Roaming Agents                                                     402
      Disposable Applications                                            405
      Client/Server Component Suites                                     406
   The OpenDoc Extension Mechanism                                       407
      Why Are Extensions Needed?                                         407
      How Extensions Work                                                408
   Semantic Events                                                       410
      What's a Semantic Event?                                           410
      An Example                                                         411
      Object Specifiers Unleashed                                        411
      How Semantic Events Work                                           412
      Setting Up the Environment                                         415
      Scenario: A Semantic Message At Work                               416
      A Quick Review                                                     418
   Scripting and Automation                                              418
      Beyond Just Scriptability                                          420
      Scriptability                                                      420
      Tinkerability                                                      421
      Recordability                                                      421
      Scripting Systems                                                  423
   Conclusion                                                            424


Part 5. OLE/COM Under the Hood                                           425
____________________________________________________________________________

Product
Chapter 25. COM: OLE's Object Bus                                        429
   COM: The Object Bus                                                   431
      Looking at COM Through CORBA Eyes                                  431
      COM Style Interfaces                                               432
      So, What's a COM Object?                                           433
      What's a COM Server?                                               436
      Server Flavors: In-Process and Out-Of-Process                      437
      Creating Custom Interfaces                                         439
   COM Object Services                                                   441
      The Ubiquitous IUnknown Interface                                  442
      Interface Negotiations Using QueryInterface                        442
      Life Cycle Management With Reference Counts                        444
      IClassFactory2: Object Creation and Licensing                      445
      A COM Object Creation Scenario                                     446
      Connectable Objects: COM's Event Service                           448
      COM Style Inheritance: Aggregation and Containment                 449

Product
Chapter 26. OLE: Automation, Scripting, and Type Libraries               453
   Automation, OLE Style                                                 454
      How the Pieces Work Together                                       455
      What's an OLE Automation Server?                                   455
      OLE Guidelines for Automation Objects                              456
      The Structure of an OLE Automation Server                          457
      Collection Objects                                                 458
      Automation Controllers: Visual Basic and DispTest                  460
   Building OLE Automation Servers                                       461
      What's a Dispinterface?                                            461
      The IDispatch Interface                                            462
      What Does an IDispatch Client Do?                                  463
   How OLE Creates and Manages Type Information                          464
      The Object Description Language                                    465
      Building Type Libraries: The Hard Way                              467
      Building Type Libraries: The Easy Way                              468
      Registering a Type Library                                         469
      Finding and Loading a Type Library                                 470
      So, How Do I Get Information Out of a Type Library?                470
      A Type Library Navigation Scenario                                 471
      Getting Information From IProvideClassInfo                         472
      Conclusion                                                         473

Product
Chapter 27. OLE: Uniform Data Transfer                                   475
   OLE's Data Transfer Model                                             476
      Data Transfer: Formats and Structures                              477
      The IDataObject Interface                                          477
   Clipboard Transfers, OLE Style                                        479
      Delayed Transfers                                                  479
      A Clipboard Data Transfer Scenario                                 479
   Drag-and-Drop Transfers                                               481
      Drag-and-Drop: Who Does What?                                      481
      A Drag-and-Drop Data Transfer Scenario                             482
   Linked Data Transfers                                                 484
      What's an Advise Sink?                                             485
      A Parting Scenario                                                 486
   Conclusion                                                            487

Product
Chapter 28. OLE: Structured Storage and Monikers                         489
   OLE's Structured Storage: Compound Files                              490
      The Structure of a Compound File                                   491
      The IStorage Interface                                             492
      Transactional Storage                                              493
      The IStream Interface                                              494
      A Storage Access Scenario                                          495
   Persistent Objects                                                    497
      How Persistent Is Your Object?                                     497
      The IPersist Interfaces                                            498
      A Persistent Object Scenario                                       499
   Monikers: Persistent, Intelligent Names                               501
      So, What Exactly Is a Moniker?                                     501
      Monikers As Persistent Objects                                     502
      The IMoniker Interface                                             502
      Types of Monikers                                                  503

Product
Chapter 29. OLE: Compound Documents and OCXs                             507
   The OLE Compound Document Model                                       508
      Will the Real Container/Server Please Stand Up?                    509
      Linking versus Embedding                                           509
   The Minimalist Container/Server                                       511
      The Minimalist Container                                           512
      The Minimalist Server                                              513
      A Container/Server Scenario                                        515
   The Maximalist Container/Server                                       516
      Linking and Embedding Interfaces                                   518
      So, How Does Linking Work?                                         520
      In-Place Editing                                                   520
      Miscellaneous Interfaces                                           521
   OLE Custom Controls (OCXs)                                            523
      So What's an OCX?                                                  524
      Container Meets OCX                                                524
      How OCXs and Containers Use Automation                             527
      OCX-Generated Events                                               527
      Connectable Objects: COM's Event Service                           528
      An OCX Connectable Object Scenario                                 530
      Conclusion                                                         532


Part 6. Component Nirvana: Client/Server With Parts                      533
____________________________________________________________________________

Scenic Concept
Chapter 30. Which Component Model?                                       535
   Should You Bet on COM/OLE or CORBA/OpenDoc?                           536
      OLE/COM Versus CORBA/OpenDoc: The Object Models                    536
      OLE/COM Versus CORBA/OpenDoc: The Object Buses                     538
      OLE/COM Versus CORBA/OpenDoc: Higher-Level Language Bindings       539
      OLE/COM Versus CORBA/OpenDoc: The System Services                  540
      OLE/COM Versus CORBA/OpenDoc: Compound Document Frameworks         541
      So, the Winner Is...                                               543
   COM/OLE and CORBA/OpenDoc: Can We Interoperate?                       543
      Gateways Come in All Shapes                                        543
      ComponentGlue: The Deep Gateway Approach                           544
      The COM/CORBA Interworking RFP: The Generic Gateway Approach       546
      Conclusion                                                         549

Scenic Concept
Chapter 31. Client/Server With Component Suites                          551
   Client/Server With Component Suites                                   552
      Suites: The Sum Is More Than the Total of the Parts                552
      Suites of Pluggable Places                                         552
      Suites of Client/Server Parts                                      553
      Cafeteria-Style Suites                                             553
   The Component Market Infrastructure                                   554
      The Open Component Market Vision                                   554
      Getting Ready for Client/Server With Components                    559
      It's Time to Say Farewell                                          561


Where to Go for More Information                                         563
Trademarks                                                               573
Index                                                                    575



-------------------------- List of Boxes ------------------------------


Briefing:       The World's Shortest Tutorial on Objects                  24
Briefing:       ORB Versus RPC                                            56
Soapbox:        Is 1996 "The Year of the ORB"?                            62
Briefing:       CORBA 2.0 Global Repository IDs                           70
Details:        What's an Object Reference?                               73
Briefing:       GIOP: Interoperable Object References                     87
Soapbox:        Is It CORBA Versus DCE?                                   89
Details:        The Interface Repository: A Closer Look                  102
Details:        Pragmas That Help You Create Repository IDs              106
Briefing:       What's a Nested Transaction?                             126
Soapbox:        How Standards Are Really Created                         143
Briefing:       The Direct Attribute "Conspiracy"                        147
Soapbox:        The Future of Database: Object or Relational?            163
Briefing:       Are Distributed Objects Less Secure?                     196
Soapbox:        Disposable Components                                    232
Briefing:       The Business Process Object Is the News                  245
Soapbox:        System Management: Why Objects Are the Answer            253
Briefing:       Objects and Everyday Things                              265
Soapbox:        OpenDoc: Looks Are Everything                            276
Soapbox:        Questions to Ask Your OpenDoc Providers                  282
Soapbox:        Would You Bet on Taligent?                               310
Soapbox:        Dear Steve, Please Drop the Plumbing                     323
Soapbox:        Are We Ready for a New World Infrastructure?             336
Briefing:       When CORBA Meets OpenDoc                                 345
Briefing:       To IDL or Not To IDL                                     347
Details:        Inside ODPart                                            349
Soapbox:        What to Look for in an OpenDoc Tool                      353
Details:        How OpenDoc Reconstructs a Document                      364
Soapbox:        Why OpenDoc?                                             371
Details:        Storage Units: An Inside Look                            379
Soapbox:        Can OpenDoc Perform General Magic-like Magic?            403
Details:        How Object Specifiers Are Resolved                       414
Details:        The OSA Script-System Encapsulator                       423
Details:        COM Interfaces and C++ Vtables                           434
Briefing:       What?  An Object With No ID?                             435
Briefing:       COM IDL Versus COM ODL                                   439
Soapbox:        Is This Really Version Control?                          443
Soapbox:        The Multiple Inheritance Thing                           451
Details:        So, What Makes a Collection Object?                      459
Warning:        Check Your OLE Technical Reference First                 467
Details:        What Are LockBytes?                                      492
Warning:        Architecture Does Not Mean Product                       495
Soapbox:        Monikers and the Rest of Us                              505
Soapbox:        How Much Diversity Can Components Tolerate?              510
Soapbox:        In-Place Editing: OLE Versus OpenDoc                     522
Soapbox:        The OLE Camp: So What?                                   542
Soapbox:        How to Achieve This Component Vision                     555



-------------------------- Chapter 2 ---------------------------------------


Chapter 2. From Distributed Objects To Smart Components

General industry consensus is that the ultimate goal is to have
component-based systems capable of operating in distributed
heterogeneous computing environments.  Loosely bound and highly
configurable components will be able to accommodate continuous
changes such as the rapid creation and destruction of virtual
enterprises.

                         -- Richard Barnwell, Architect
                            Software 2000, Inc.
                            (June, 1995)

A "classical" object--of the C++ or Smalltalk variety--is a blob of
intelligence that encapsulates code and data.  Classical objects
provide wonderful code reuse facilities via inheritance and
encapsulation.  However, these classical objects only live within a
single program.  Only the language compiler that creates the objects
knows of their existence.  The outside world doesn't know about these
objects and has no way to access them.  They're literally buried in
the bowels of a program.

In contrast, a distributed object is a blob of intelligence that can
live anywhere on a network.  Distributed objects are packaged as
independent pieces of code that can be accessed by remote clients
via method invocations.  The language and compiler used to create
distributed server objects are totally transparent to their clients.
Clients don't need to know where the distributed object resides or
what operating system it executes on; it can be on the same machine
or on a machine that sits across an intergalactic network.
Distributed objects are smart pieces of software that can message
each other transparently anywhere in the world.  Distributed objects
can interrogate each other--"tell me what you do."  Distributed
objects are very dynamic--they come and go and move around.

When we talk about distributed objects, we're really talking about
independent software components.  These are smart pieces of software
that can play in different networks, operating systems, and tool
palettes.  A component is an object that's not bound to a particular
program, computer language, or implementation.  Objects built as
components provide the right "shapes" for distributed applications.
They are the optimal building blocks for creating the next generation
of distributed systems.  In this chapter, we first explain what an
object is.  Then we go over the attributes that make components out
of ordinary objects.


Objects and Distributed Objects

Everybody can resonate with objects--managers, 3-year olds, and
superprogrammers.  Object-oriented technology appeals to all
these different camps...

                         -- Jim Gray
                            (February, 1995)

Objects has to be one of the most bastardized, hackneyed, and
confusing terms in the computer industry.  Everyone claims to
have them.

                         -- Kraig Brockschmidt, Author
                            Inside OLE 2, Second Edition
                            (Microsoft Press, 1995)

By now, anybody associated with computers knows that objects are
wonderful--we simply can't live without them.  Smalltalk can be used
to create GUI front-ends, C++ is the only way to write code, and the
literature is full of articles on the wonders of encapsulation,
multiple inheritance, and polymorphism.  Objects for the last 20
years have been promising us code reuse and higher levels of software
productivity.  Software methodologists tell us objects can cure
almost any software ill--as long as we faithfully follow "the
methodology du jour."  Note that traditional methodologies treat
functions and data as separate; object methodologies, on the other
hand, view them as an integrated whole.  An object describes both
the behavior and information associated with an entity.

More recently, objects have become the darling of the Business
Process Reengineering (BPR) crowd.  These folks discovered that
objects map very well to the way businesses are organized.  They use
objects to simulate, describe, and analyze the business process.
Finally, these folks also discovered that business objects can
naturally emulate their real-world counterparts in different
domains.

As a result of all this interest, objects are starting to boom.
Datapro estimates the general object marketplace to be growing at
67% annually; it expects it to become a $4 billion market by 1997.
But there's still more to this story.


Distributed Objects

The potential of distributed objects is what causes your authors to
"resonate," as Jim Gray would put it.  We are particularly interested
in how object technology can be extended to deal with the complex
issues that are inherent in creating robust, single-image,
client/server systems.  The key word is systems--or how objects work
together across machine and network boundaries to create
client/server solutions.  We're not going to rehash the marvels of
Object-Oriented Programming (OOP) methodologies, Smalltalk, and C++
because we assume you've heard about them all before.  We're moving
on to the next step: objects in client/server systems.  This is the
area where objects will realize their greatest potential and growth;
in the process, they will become the new "mainstream computing
model."  Distributed objects are in the fortunate position of being
able to build on the strong language and methodological foundations
of classical objects.  But distributed objects introduce a whole new
ball game.  They have the potential of creating a $50 billion
software industry by the turn of this century (especially when
components are factored in).


Object Magic

Most people involved in the computer industry believe objects to be
a "good thing."  An object is an encapsulated chunk of code that has
a name and an interface that describes what it can do.  Other
programs can invoke the functions the interface describes or simply
reuse the function itself.  Objects should let you write programs
faster by incorporating large chunks of code from existing objects--
this is called inheritance.  In addition, an object typically manages
a resource or its own data.  You can only access an object's resource
using the interface the object publishes.  This means objects
encapsulate the resource and contain all the information they need
to operate on it.

Objects let you package software capabilities into more manageable
(and useful) chunks.  You can scale objects by composing them from
other objects.  Eventually, you can create objects that model
real-world entities--called business objects.  The basic concepts of
object technology are the same, regardless of the level of
abstraction an object provides.  System objects and business objects
all provide three magical properties: encapsulation, inheritance,
and polymorphism.  These are the properties that provide the behavior
and benefits you typically associate with an object.  You must
understand these three magical properties in order for objects (and
their component extensions) to make sense.  The next Briefing box provides
the world's shortest tutorial on objects.



     ====== Briefing: The World's Shortest Tutorial on objects =====

If you want to shrink something, you must first allow it to
expand.  If you want to take something, you must first allow
it to be given.  This is called the subtle perception of the
way things are.

                         -- Lao Tzu

An object is a piece of code that owns things called attributes
and provides services through methods (also called operations or
functions).  Typically, the methods operate on private data--also
called instance data or object state--that the object owns.  A
collection of like objects make up a class (sometimes called a
type).  A class acts as a template that describes the behavior
of sets of like objects.  Technically speaking, objects are
run-time instances of a class.  An object is identified by a
unique ID (also known as a reference).

This all sounds pretty straightforward, so why all the fuss about
objects?  First, they provide a better programming model for
representing the world.  We can create intelligent software
objects that mirror the things around us.  Second, objects have
three magical properties that make them incredibly useful:
encapsulation, inheritance, and polymorphism.  In our previous
books, we call them "the three pillars of object-oriented
programming."  They allow us to create reusable objects.  They
form the essence what Lao Tzu calls "the subtle perception of the
way things are."


Encapsulation

One of the fundamental principles of object technology is that
the internals of an object are private to that object and may not
be accessed or even examined from outside the object.

                         -- David Taylor, Author
                            Business Engineering with Object Technology
                            (Wiley, 1995)

Encapsulation means "don't tell me how you do it; just do it."
The object does this by managing its own resources and limiting
the visibility of what others should know.  In this sense, objects
are self-contained atoms.  An object publishes a public interface
that defines how other objects or applications can interact with
it (see Figure 2-1).  An object also has a private component that
implements the methods.  The object's implementation is
encapsulated--that is, hidden from the public view.  Instance data
can be declared private--usually, the default--or public.  Private
instance data can only be accessed by methods of the class.
Public instance data, on the other hand, is part of the published
external interface.  The public methods and instance data are the
permanent interface between the object and the outside world.
Old methods must continue to be supported when an object changes.
The public interface is a binding contract between the class
providers and their clients.

Figure 2-1.  The First Pillar of OO Wisdom: Class Encapsulation.


Polymorphism

A true living object can be replaced.

                         -- Christine Comaford,
                            Columnist
                            PC Week

Polymorphism is a high-brow way of saying that the same method
can do different things, depending on the class that implements
it.  Looking at Figure 2-2, you can see polymorphism in action
(hit the accelerator on a Corvette and on a Volvo, and then
compare notes).  Objects in different classes receive the same
message yet react in different ways.  The sender does not know
the difference; the receiver interprets the message and provides
the appropriate behavior.  Polymorphism lets you view two similar
objects through a common interface; it eliminates the need to
differentiate between the two objects.  Polymorphism is the
underlying principle behind the object-style user interfaces.
You can click on any visual object or drag-and-drop it.
Polymorphism is also the mechanism that allows subclasses (see
next paragraph) to override an inherited method--and "do their own
thing"--without affecting the ancestor's methods.

Figure 2-2.  The Second Pillar of OO Wisdom: Polymorphism.

Overloading is a variant of polymorphism that lets you define
different versions of a method, each with different parameter
types.


Inheritance

Children classes can enhance the behavior of their parents.
And if parental behavior is enhanced, it is to the benefit of
the children.

                         -- Steve Jobs, CEO
                            NeXT
                            (February, 1995)

Inheritance is the mechanism that allows you to create new child
classes--known as subclasses or derived classes--from existing
parent classes.  Child classes inherit their parent's methods and
data structures.  You can add new methods to a child's class or
override--that is, modify--inherited methods to define new class
behaviors.  The parent's method is not affected by this
modification.  You use inheritance to extend objects; it means
"everything in that object plus...."

Some object models support single inheritance--a class has exactly
one parent class.  Others support multiple inheritance--a class
can have more than one direct parent.  Abstract classes are
classes whose main purpose is to be inherited by others.  Mixins
are classes whose main purpose is to be multiply inherited by
others.  They're typically partial classes that cannot stand
alone.  Mixins must be combined with other classes in order to
function.  If you do it carefully, multiple inheritance can help
you reuse code very effectively.  Together, abstract classes and
mixins are sometimes known as base classes--this means other
classes inherit from them.  As in real-life family inheritances,
class inheritances are controlled by the parents.  This means
that providers of base classes can establish the rules about what
aspects of their classes they will let their children inherit.

Figure 2-3 shows a typical class hierarchy tree--start with a
generic "car" class and derive from it Volvos or Corvettes.  Note
that the arrows in the class hierarchy

point upward from a class to its parent class--the idea is that
classes  must know their parent class, but not vice versa.  A
class hierarchy can introduce many levels of hierarchy.  If the
hierarchy becomes too deep, you may have to restructure it (object
people call it refactoring the hierarchy).  To eliminate code
redundancy, you should move common functions to the top of the
class hierarchy.  You do this by simply moving common code from
the derived classes into a common ancestor class.

Figure 2-3.  The Third Pillar of OO Wisdom: Inheritance and Subclassing.


Frameworks and Class Libraries

The three pillars of OO provide the foundation for creating,
assembling, and reusing objects.  The first generation of OO
relied on class libraries to package objects for reusability.  A
more promising approach is to use object frameworks.  These are
preassembled class libraries that are packaged to provide
specific functions.  Frameworks will make it easier to assemble
objects; they raise the level of abstraction.  We cover frameworks
in more detail in Part 3.


Object Binding

Binding refers to the linking of the software interface between
two objects.  If the binding is static both client and server
have an interface that is determined at compile or build time.
Dynamic binding--also known as late binding--occurs when a message
is sent.  It requires objects to have an agreed-upon way of
determining the shape of the interface at send time.  Late binding
lets you create very flexible systems with code you can select
at run time.  This lets you
replace code dynamically and introduce new functions without
recompiling existing software.


Object Relationships

According to David Taylor, objects relate to each other in one
of three basic ways: 1) specialization, in which classes are
defined as special cases of each other; 2) collaboration, in which
objects send messages to each other to request services; and 3)
composition, in which objects are constructed out of other
objects.  Taylor's list provides a good start.  We will also be
seeing other patterns of collaboration throughout this book.  Note
that an object that contains other objects is called a composite
object.  A composite object holds references to the objects it
contains instead of containing the object itself.  An object can
be contained in multiple composite objects.

     ================== End Box ===================================


Components: The Grand Prize of Objects

Object technology failed to deliver on the promise of
reuse...What role will object-oriented programming play in the
component-software revolution that's now finally under way?

                         -- Jon Udell, Senior Technical Editor
                            BYTE Magazine
                            (May, 1994)

Components are standalone objects that can plug-and-play across
networks, applications, languages, tools, and operating systems.
Distributed objects are, by definition, components because of the
way they are packaged.  In distributed object systems, the unit of
work and distribution is a component.  The distributed object
infrastructure must make it easier for components to be more
autonomous, self-managing, and collaborative.  However, note that
not all components are objects.  Nor are they all distributed.  For
example, an OLE custom control (or OCX) is a component that is
neither an object nor distributed.

Component technology--in all its forms--promises to radically alter
the way software systems are developed.  For example, distributed
objects allow us to put together complex client/server information
systems by simply assembling and extending components.  The goal of
object components is to provide software users and developers the
same levels of plug-and-play application interoperabilty that are
available to consumers and manufacturers of electronic parts or
custom integrated circuits.


The Driving Force Behind Components

It's really getting harder and harder for us to keep up with the
amount of resources needed to develop applications today.  Up
to 80% of application resources go into capabilities that are
ancillary to what really makes our product stand out.

                         -- Randell Flint, President
                            Sundial Systems
                            (January, 1995)

The component revolution is being driven from the desktop, where
vendors are realizing that to be profitable, they must quickly
rearchitect their existing applications and suites into components.
Today's desktop applications are monolithic and over-bloated.  They
contain every possible feature you might use--whether or not you
really want them.  Most of us use less than 10% of an application's
features--the rest of the features simply add complexity and bulk.
We must wait--it seems forever--to get the new features we really need
in the form of new upgrades or replacements.  This is because vendors
must bring forward all the hundreds of product features with every
new release, leading to long and costly development cycles.  Vendors
take the "shotgun" approach because they don't know which features
you need, and they try to be all things to all people.

These feature-heavy, bloated, monolithic applications are very
costly for vendors to upgrade and maintain.  Each change challenges
the fragile integrity of the monolith and requires long regression
cycles (and resources).  Maintaining these applications is no picnic
either.  The smaller Independent Software Vendors (ISVs) face these
same problems but even more acutely.  They have much more limited
resources to throw at them.

To give you an idea of the magnitude of the problem, consider that
it took WordPerfect just under 14 developer years to upgrade their
product from version 3 to version 4.  However, it took 250 developer
years to move the same product from version 5 to version 6.  If
things continue at this rate, it could cost them as many as 4,464
developer years to move the product to version 8.  WordPerfect
realized that the monolithic approach to application development is
simply no longer feasible; it is now rearchitecting the product using
OLE and OpenDoc components.  Microsoft is experiencing the same
phenomenon.  For example, the size of Excel went from 4 MBytes in
1990, to over 16 MBytes today.  Microsoft is looking at OLE
components to improve the situation.  Lotus has a similar story.  It
shipped 1-2-3 shipped on one floppy in 1982; today 1-2-3, requires
11 MBytes of disk space to install.  Lotus is looking at both OLE
and OpenDoc to fix the problem.


Components to the Rescue

Objects have been freed from the shackles of a particular
language or platform.  Programmers have been liberated from the
confines of one compiler or family of class libraries.  Objects
can be everywhere, working together and delivering a new world
of opportunity to the next generation of systems architectures.

                         -- Martin Anderson, Chairman
                            Integrated Objects
                            (June, 1995)

Object-oriented programming has long been advanced as a solution to
the problems we just described.  However, objects by themselves do
not provide an infrastructure through which software created by
different vendors can interact with one another within the same
address space--much less across address spaces, networks, and
operating systems.  The solution is to augment classical objects
with a standard component infrastructure.

OpenDoc and OLE are currently the leading component standards for
the desktop; CORBA provides a component standard for the enterprise.
CORBA and OpenDoc complement each other--OpenDoc uses CORBA as its
object bus.  These new component standards will change the economics
of software development.  Monolithic applications--both on the
desktop and in the enterprise--will be replaced with component
suites.  Here's how this new technology will affect you:

-  Power users will find it second nature to assemble their own
   personalized applications using off-the-shelf components.  They
   will use scripts to tie the parts together and customize their
   behavior.

-  Small developers and ISVs will find that components reduce expenses
   and lower the barriers to entry in the software market.  They can
   create individual components with the knowledge that they will
   integrate smoothly with existing software created by larger
   development shops--they do not have to reinvent all the functions
   around them.  They can get fine-grained integration instead of
   today's "band-aid" integration.  In addition, they get faster
   time to market because the bulk of an application is already there.

-  Large developers, IS shops, and system integrators will use
   component suites to create (or assemble) enterprise-wide
   client/server applications in record time.  Typically, about 80%
   of the function they need will be available as off-the-shelf
   components.  The remaining 20% is the value-added they provide.
   The client/server systems may be less complex to test because of
   the high reliability of the pretested components.  The fact that
   many components are black boxes reduces the overall complexity
   of the development process. Components--especially of the CORBA
   variety--will be architected to work together in intergalactic
   client/server networks (Parts 2 and 3 provide more details).

-  Desktop vendors will use components to assemble applications that
   target specific markets (for example, "WordPerfect for Legal
   Firms").  Instead of selling monster suites--packed with everything
   but the kitchen sink--at rock-bottom prices, they will be able to
   provide their consumers with what they really need.  Increased
   customization and more malleable products will create new market
   segments.  Consumers will not be at the mercy of the long product
   release cycles to get new functions.  They can buy add-on
   functions--in the form of components--when they need it.

Figure: Testimony Cartoon


In summary, components reduce application complexity, development
cost, and time to market.  They also improve software reusability,
maintainability, platform independence, and client/server
distribution.  Finally, components provide more freedom of choice
and flexibility.


When Can We Expect These Components?

The transition to component-based software will change the way
we buy and build systems and what it means to be a software
engineer.

                         -- Dave Thomas, President
                            Object Technology International
                            (March, 1995)

By 1997, most new software will be developed (or assembled) using
components.  According to Strategic Focus, 25% of developers are
already building component software today.  This number climbs
abruptly to include 66% of all developers by the end of 1996.  This
means that in less than two years, two out of three developers will
have adopted the component approach (see Figure 2-4).

Figure 2-4.  When Developers Plan to Start Developing With Components
             (Source: Strategic Focus, January 1995).

If this forecast is correct, then the software industry is now at
the same point where the hardware industry was about 23 years ago.
At that time, the first integrated circuits (ICs) were developed to
package discrete functions into hardware.  ICs were wired together
on boards to provide more complex functions.  These boards were
eventually miniaturized into ICs.  These new and more powerful ICs
were wired together on new boards, and so on.  We should experience
the same spiral with software.  A component is what Brad Cox calls
a software IC.  Frameworks are the boards we plug these components
into.  The object bus provides the backplane.  Families of software
ICs that play together are called suites.  You should be able to
purchase your software ICs--or components--through standard part
catalogs.  According to Gartner Group, components will foster the
emergence of three new markets: 1) the component market itself, 2)
a market for component assembly tools, and 3) a market for custom
applications developed using components.

So, the million-dollar question is: Why didn't this happen any
sooner?  Why did we have to wait 23 years to follow the footsteps
of our cousins, the hardware engineers?  Yes, it's true that for
almost 20 years the software industry has been talking about reuse,
objects, and methodologies that would get us out of the crises of
the day.  The difference this time is that we have two standards to
choose from: OpenDoc/CORBA and OLE/COM.  Without standards, you
cannot have components.  So, it didn't happen sooner because our
industry did not have the right component infrastructure or
standards.  We now have both.


So, What Exactly Is a Component?

A component is a piece of software small enough to create and
maintain, big enough to deploy and support, and with standard
interfaces for interoperability.

                         -- Jed Harris, President
                            CI Labs
                            (January, 1995)

Components interoperate using language-neutral client/server
interaction models.  Unlike traditional objects, components can
interoperate across languages, tools, operating systems, and
networks.  But components are also object-like in the sense that
they support inheritance, polymorphism, and encapsulation.  Note
that some components--Ivar Jacobson calls them black box components--
cannot be extended through inheritance.  OLE components fall into
the black box category.  However, both CORBA and OpenDoc components
support inheritance.  As a result, they let you build either white
box or black box components.  A white box component is a component
that behaves like a classical object.

Because components mean different things to different people, we
will define the functions a minimal component must provide.  In the
next section, we expand our definition to include features that
supercomponents must provide.  Our definition of a component is a
composite of what CORBA, OpenDoc, and OLE provide.  Most of the
earlier definitions of components were based on wish lists.  Now
that we have standards, we can use them to derive a definition.  So,
a minimalist component has the following properties:

-  It is a marketable entity.  A component is a self-contained,
   shrink-wrapped, binary piece of software that you can typically
   purchase in the open market.

-  It is not a complete application.  A component can be combined
   with other components to form a complete application.  It is
   designed to perform a limited set of tasks within an application
   domain.  Components can be fine-grained objects--for example, a
   C++ size object; medium-grained objects--for example, a GUI
   control; or coarse-grained objects--for example, an applet.

-  It can be used in unpredictable combinations.  Like real-world
   objects, a component can be used in ways that were totally
   unanticipated by the original developer.  Typically, components
   can be combined with other components of the same family--called
   suites--using plug-and-play.

-  It has a well-specified interface.  Like a classical object, a
   component can only be manipulated through its interface.  This
   is how the component exposes its function to the outside world.
   A CORBA/OpenDoc component also provides an Interface Definition
   Language that you can use to invoke the component or inherit and
   override its functions.  Note that the component's object-like
   interface is separate from its implementation.  A component can
   be implemented using objects, procedural code, or by encapsulating
   existing code.

-  It is an interoperable object.  A component can be invoked as an
   object across address spaces, networks, languages, operating
   systems, and tools.  It is a system-independent software entity.

-  It is an extended object.  Components are bona fide objects in the
   sense that they support encapsulation, inheritance, and
   polymorphism.  However, components must also provide all the
   features associated with a shrink-wrapped standalone object.
   These features will be discussed in the next section.

In summary, a component is a reusable, self-contained piece of
software that is independent of any application.


So, What Is a Supercomponent?

If the components come with a bad reputation, no one will use
them. Therefore components must be of an extraordinary quality.
They need to be well tested, efficient, and well
documented...The component should invite reuse.

                         -- Ivar Jacobson, Author
                            Object-Oriented Software Engineering
                            (Addison-Wesley, 1993)

Supercomponents are components with added smarts.  The smarts are
needed for creating autonomous, loosely-coupled, shrink-wrapped
objects that can roam across machines and live on networks.
Consequently, components need to provide the type of facilities that
you associate with independent networked entities--including:

-  Security--a component must protect itself and its resources from
   outside threats.  It must authenticate itself to its clients, and
   vice versa.  It must provide access controls.  And it must keep
   audit trails of its use.

-  Licensing--a component must be able to enforce licensing policies
   including per-usage licensing and metering.  It is important to
   reward component vendors for the use of their components.

-  Versioning--a component must provide some form of version control;
   it must make sure its clients are using the right version.

-  Life cycle management--a component must manage its creation,
   destruction, and archival.  It must also be able to clone itself,
   externalize its contents, and move from one location to the next.

-  Support for open tool palettes--a component must allow itself to
   be imported within a standard tool palette.  An example is a tool
   palette that supports OLE OCXs or OpenDoc parts.  A component
   that abides by an open palette's rules can be assembled with other
   components using drag-and-drop and other visual assembly
   techniques.

-  Event notification--a component must be able to notify interested
   parties when something of interest happens to it.

-  Configuration and property management--a component must provide an
   interface to let you configure its properties and scripts.

-  Scripting--a component must permit its interface to be controlled
   via scripting languages.  This means the interface must be
   self-describing and support late binding.

-  Metadata and introspection--a component must provide, on request,
   information about itself.  This includes a description of its
   interfaces, attributes, and the suites it supports.

-  Transaction control and locking--a component must transactionally
   protect its resources and cooperate with other components to
   provide all or nothing integrity.  In addition, it must provide
   locks to serialize access to shared resources.

-  Persistence--a component must be able to save its state in a
   persistent store and later restore it.

-  Relationships--a component must be able to form dynamic or permanent
   associations with other components.  For example, a component can
   contain other components.

-  Ease of use--a component must provide a limited number of operations
   to encourage use and reuse.  In other words, the level of
   abstraction must be as high as possible to make the component
   inviting to use.

-  Self-testing--a component must be self-testing.  You should be able
   to run component-provided diagnostics to do problem
   determination.

-  Semantic messaging--a component must be able to understand the
   vocabulary of the particular suites and domain-specific
   extensions it supports.

-  Self-installing--a component must be able to install itself and
   automatically register its factory with the operating system or
   component registry.  The component must also be able to remove
   itself from disk when asked to do so.


This list should give you a pretty good idea of the level of quality
and functionality we expect from our components.  The good news is
that both OpenDoc/CORBA and OLE/COM already provide quite a few of
these functions.  Typical OpenDoc/CORBA implementations let you add
this behavior to ordinary components via mixins at build time.  Some
CORBA implementations--for example, SOM--even let you insert this
system behavior into binary components at run time.  OLE lets you
add the behavior at build time by composing components that consist
of multiple interfaces; an outer component can then call the
appropriate interfaces via a reuse technique called aggregation.


Business Objects: The Ultimate Components

Components will help users focus on tasks, not tools, just as
a well-stocked kitchen lets you focus on preparing and enjoying
great food and not on the brand of your ingredients.

                         -- Dave LeFevre, Novell/WordPerfect
                            (January, 1995)

Distributed objects are by definition components.  The distributed
object infrastructure is really a component infrastructure.
Programmers can easily get things to collaborate by writing code for
the two sides of the collaboration.  The trick, however, is to get
components that have no previous knowledge of each other to do the
same.  To get to this point, you need standards that set the rules
of engagement for different component interaction boundaries.
Together, these different interaction boundaries define a
distributed component infrastructure.

At the most basic level, a component infrastructure provides an
object bus--the Object Request Broker (ORB)--that lets components
interoperate across address spaces, languages, operating systems,
and networks.  The bus also provides mechanisms that let components
exchange metadata and discover each other.  At the next level, the
infrastructure augments the bus with add-on system-level services
that help you create supersmart components.  Examples of these
services include licensing, security, version control, persistence,
suite negotiation, semantic messaging, scripting, transactions, and
many others.

The ultimate goal is to let you create components that behave like
business objects.  These are components that model their real-world
counterparts in some application-level domain.  They typically
perform specific business functions--for example, a customer, car,
or hotel.  These business objects can be grouped into visual suites
that sit on a desktop but have underlying client/server webs.

So the ultimate Nirvana in the client/server components business are
supersmart business object components that do more than just
interoperate--they collaborate at the semantic level to get a job
done.  For example, roaming agents on a global network must be able
to collaborate to conduct negotiations with their fellow agents.
Agents are examples of business objects.  The infrastructure
provides application-level collaboration standards in the form of
application frameworks.  These frameworks enforce the rules of
engagement between independent components and allows them to
collaborate in suites.

Figure 2-5 shows the evolution of components from interoperability
to collaboration.  This evolution corresponds to the service
boundaries of the component infrastructure.  The component bus gives
you simple interoperability; the system services give you supersmart
components; and the application frameworks provide the
application-level semantics for components to collaborate in suites.

Figure 2-5.  Component Evolution and Infrastructure Boundaries.


Your Guide to the Symbols Used in This Survival Guide

This section gives you a quick guide to the notation we use in this
book.  We're not trying to invent a new OO notation--Booch diagrams
are just fine with us.  However, we did take a few artistic liberties
to make the notation more fun and intuitive for people that are
looking at objects for the first time.  So here's your quick guide
to the symbols we use.


Objects and OLE Interfaces

Figure 2-6 shows the three symbols we use to denote objects and OLE
interfaces.  The ball-like icon denotes an object usually in some
type of relationship--for example, an object on a bus.  The second
symbol shows an object and its methods; sometimes we group methods
in categories.  The third symbol denotes an OLE object consisting
of multiple interfaces.  The symbol for an interface is a plug-in
jack; it is really a grouping for a collection of methods.

Figure 6.  Objects and OLE Objects.


A Class Hierarchy

Figure 2-7 shows a two-level class hierarchy.  In this case, the
object inherits its methods from two parent classes and adds a few
of its own.  We show the inheritance relationship as a thin arrow
pointing from an object to its parent.

Figure 7.  A Class Hierarchy and Inheritance.


Icons for Components, Frameworks, and ORBs

Figure 2-8 shows a miscellaneous set of icons we use for components,
frameworks, and object buses.  You'll see these icons everywhere.
The component icon is the component person.  Component people--they
come in different genders, ages, and roles--are very social and they
make great cartoon characters.  The icon for a framework looks like
a hardware board with a puzzle piece.  The board is the framework;
the puzzle piece is the extension you add to the framework.  The
object bus looks like a hardware bus; we use it to show an ORB or
any medium that objects use to interoperate.  The little balls are
objects that hang off the bus.

Figure 8.  Miscellaneous Icons: Component, Framework, and Object Bus.


Object Interaction Diagrams

An object-oriented program's run-time structure often bears
little resemblance to its code structure.  The code is frozen at
compile-time; it consists of classes of fixed inheritance
relationships.  A program's run-time structure consists of rapidly
changing networks of communicating objects.  Trying to understand
one from the other is like trying to understand the dynamism of
living ecosystems from the static taxonomy of plants and animals,
and vice versa.

                         -- Erich Gamma et al., Authors
                            Design Patterns
                            (Addison Wesley, 1994)

We use object interaction diagrams to trace the execution of a
scenario that shows a run-time collaboration between objects (see
Figure 2-9).  An object is represented by its icon and a vertical
line that drops down from it.  The thick horizontal arrows denote
method invocations between objects.  We use thin arrows to denote
other types of interactions; for example, creating an object.  The
numbers denote the sequence of events; you will usually find an
explanation in the text that goes along with a number (if it's very
obvious, we skip the explanation).  Note that time elapses from the
top moving down.

Figure 9.  An Object Interaction Diagram for Object Scenarios.


The Component Road Map

The clearer the view of our dreams, the greater our cohesion.

                         -- Carlos Castaneda
                            The Art of Dreaming

Now that we've developed a common vocabulary around objects and
components, let's revisit the plan for this book.  Our road map
follows the component evolution path shown in Figure 2-5.  Part 2
covers the CORBA object bus and system-level object services in great
detail.  Part 3 covers application-level frameworks--including CORBA
frameworks and business objects, OpenDoc, OLE, Taligent, OpenStep,
and Newi.  Part 4 covers OpenDoc in depth.  We go over all the
features of its compound document application-level framework.  Part
5 covers OLE/COM in depth.  This part covers both OLE's object bus--
called COM--and its compound document application-level framework.
Part 6 helps you narrow down some of your options.  We compare the
component infrastructures, look at how they interoperate, and
speculate on where it's all going.



---------------------- Trademarks --------------------------------------


Apple Computer, Inc.--Apple; AppleScript; AppleTalk;
Bedrock; Bento; MacApp; Macintosh; MacOS; ODF; Open Scripting
Architecture (OSA); OpenDoc; System 7

American Telephone and Telegraph--AT&T

Black and White Software--UIX/MX

Borland International, Inc.--Application FrameWorks;
dBase; Delphi; FoxPro; OWL; Paradox

Cahners Publishing--Datamation

Candle Corp.--Candle

Canopus Research--Canopus Research

Club Med Sales, Inc.--Club Med

Component Integration Laboratories--CI Labs

CompuServe, Inc.--CompuServe

Digital Equipment Corp.--Common Object Model (COM); DECnet

Digital--ObjectBroker

General Magic--General Magic; Telescript

Groupe Bull--Groupe Bull

Expersoft--XShell

Hewlett-Packard Corp.--Hewlett-Packard; HP; HP-UX;
ORB Plus (ORB+); HyperDesk; DOMS

Informix, Inc.--Informix; INFORMIX; ILOG; BROKER

Integrated Objects--Newi

Intel--Pentium

Iona--Orbix

IBM Corp.--AIX; AS/400; CICS; CPI-C; CSet++; CUA'91; IBM;
ICLUI; MVS; NetBIOS; OS/2; OS/2 Warp; OS/400; Presentation Manager; SOM;
SOMobjects; VisualAge; VisualAge C++; Win-OS/2; Workplace Shell; cc:Mail;
DataLens; dBASE; Lotus; Lotus Link; Lotus 1-2-3; Lotus Notes; Lotus VIP

MaGraw-Hill--BYTE Magazine

Massachusetts Institute of Technology--Kerberos; X Window

MetaWare--MetaWare

Microsoft Corp.--AppWizard; Component Object Model (COM);
ClassWizard; MS DOS; Microsoft; Object Linking and Embedding; MFC; OCX;
ODBC; OLE; OLE DB; OLE for the Enterprise; OLE Team Development;
OLE Transactions; Visual Basic; Visual C++; Windows 95; Windows;
Windows for Workgroups; Windows NT; Windows NT Advanced; Win32; XENIX

Miller-Freeman Publishing--Dr. Dobb's Journal

NEC--NEC-ORB; NetLinks, Inc.; ORBitize

Novell, Inc.--NetWare; NetWare Management System;
NetWare for UNIX; Novell; UnixWare; WordPerfect

Object Design, Inc.--Object Design; ObjectStore

Object Management Group--CORBA; Object Management Architecture

Open Software Foundation, Inc.--DCE; Motif; OSF; OSF/1;
Oracle, Inc.

ORACLE--Oracle8

PostModern Computing--ORBeline

Santa Cruz Operations, Inc.--SCO UNIX

Silicon Graphics, Inc.--IRIX

Sun Microsystems Inc.--DOE; ONC-RPC; RPC; SUN; SPARC

Sunsoft, Inc.--Distributed Object Mangement; Network File System;
Network Information System; OpenLook; Open Network Computing; Solaris

Sybase, Inc.--Sybase; Sybase SQL Server; Transact-SQL

Symantec--Symantec

Taligent, Inc.--CommonPoint; People, Places, and Things;
Taligent

Tandem Computers--NonStop SQL; NonStop Guardian; Pathway;
Serverware

Time-Warner, Inc.--Time Magazine

Tivoli Systems Inc.--Tivoli Management Environment

Transarc Corp--Transarc

University of California at Berkeley--Berkeley Software
Distribution; BSD; UNIX International, Inc.; UI; UI-Atlas

UNIX Systems Laboratories, Inc.--OpenLook; Tuxedo; UNIX

Visual Edge--Visual Edge

Watcom--Watcom

Xerox Corp.--ethernet

XVT Software, Inc.--XVT

X/Open Corp.--X/Open


---------------------- END OF EXCERPT --------------------------------------
