OS/2 Shareware BBS: 16 Announce

home *** CD-ROM | disk | FTP | other *** search

/ OS/2 Shareware BBS: 16 Announce / 16-Announce.zip / doguide.zip / DOGUIDE.TXT

Wrap

Text File | 1995-09-21 | 122KB | 2,395 lines

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