Thomas J. Mowbray 0 Ron Zahavi
`
`Systéms Integration Using
`Distributed Objects
`
`SAP 1009 (Part 1 of 3)
`CBM ofU.S. Patent No. 8,037,158
`
`1
`
`

`
`
`
`The Essential CORBA:
`Systems Integration
` Using Distributed Objects
`
`
`
`
`2
`
`

`
`The Essential CORBA:
`
`Systems Integration
`
`Using Distributed Objects
`
`Thomas J. Mowbray, PhD
`
`Ron Zahavi
`
`John Wiley & Sons, Inc.
`
`New York - Chichester - Brisbane ° Toronto ~ Singapore
`
`-
`
`3
`
`

`
`Publisher: Katherine Schowalter
`
`Editor: Robert Elliott
`
`Managing Editor: Micheline Frederick
`
`Text Design & Composition: Integre Technical Publishing Co., Inc.
`
`Figures 6.1- 6.4 are reprinted courtesy of Microsoft Press from Inside OLE2 by Kraig
`Brockschmidt, © 1994, Microsoft Press, Redmond, WA.
`
`Figure 9.1 appears courtesy of IEEE. IEEE Micro, Vol. 13, No. 6 Camp Development:
`The Art ofBuilding a Market Through Standards by Chris Halliwell, 1993.
`
`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 © 1995 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.
`
`ISBN 0-471-10611-9
`
`Printed in the United States of America
`
`109876
`
`4
`
`

`
`This book is dedicated to our
`
`lovely Wives and lifelong friends:
`Susan Zahavi and Kate Mowbray, C.P.A.
`
`Let us raise a standard to which the honest and brave will repair.
`—George Washington
`
`5
`
`

`
`6
`
`

`
`
`
`Preface
`
`Both of us have had a number of systems integration experiences before we
`started working together on a project called DISCUS (Data Interchange and
`Synergistic Collateral Usage Study) at The MITRE Corporation. We had the
`good fortune of working for a program management team that gave us the
`freedom to draw on our past experiences and develop a well thought out
`"approach to a challenging problem: general application interoperability.
`These ideas were based on the need for a carefully designed,_ well-
`documented software architecture, one that was designed with simplicity,
`extensibility, and cost implications in mind. We discovered through talking
`to our colleagues that these ideas, which seemed obvious to us, were not part
`oftheir training or backgrounds. In fact, these approaches are not adequately
`covered in the literature and not generally understood, even by experienced
`computer scientists. To transfer this knowledge, we put together this book,
`including a full coverage of the required background material, design ap-
`proach, and implementation techniques.
`Our approach builds on the standards foundations created by the Object
`Management Group (OMG). Our technical goals and the OMG goals are very
`much in sync. The OMG has made truly remarkable progress in generating
`vii
`
`7
`
`

`
`viii
`
`PREFACE
`
`quality standards and cultivating acceptance for its standards across indus-
`try, standards groups, and consortia. We want to see this vision realized even
`faster; hence, this book transfers our knowledge and approach for successful
`systems integration.
`
`T.J.M.
`R.Z.
`
`McLean, Virginia
`January 1995
`
`8
`
`

`
`Acknowledgments T
`
`Although this book was written on our own time, we must thank our project
`management for their visionary support, in particular: Webster Anderson,
`Dwight Brown, Steve Brown, Tim Daniel, Jeff Fleisher, Dolly Greenwood,
`Diane Haberstich, Gene Jarboe, Geoff Lipsey, John Polger, John Robusto,
`and Bill Ruh.
`
`We sincerely appreciate the help and contributions provided by our
`friends and colleagues, including: Howard Cohen, Donna Cornwell, Jonathan
`Doughty, Ray Emami, Julie Gravalesse, ’I‘om Herron, Michael Josephs, Mel-
`ony Katz, Paul Klinker, Dr. Fred Kuhl, Raphael Malveau, Emanuel Mamatas, John
`Marsh, Diane Mularz, Chibuike Nwaeze, Craig Prall, Bill Quigley, Andy Reho, Jeff
`Rogers, Hank Seebeck, Lisa Strader, Shel Sutton, John Tisaranni, Doug
`Vandermade, Sheryl Veazy-Rudy, and Kendall White.
`The Object Management Group has been essential to the publication
`of this work, thanks to Cheryl Bissonnette, Bill Hoffman, Kelly Kassa, Jon
`Siegel, John Slitz, Dr. Richard Soley, Geoff Speare, Chris Stone, and Lydia
`Thomas.
`-
`
`Special thanks to Steve Black, Mark Bramhall, David Chappell, Reg-
`gie Counts, Joe Croghan, John Eaton, Norman Eko, Alan Ewald, Charlie
`Green, Jim Green, Jed Harris, Jack Hassall, Ellis Horowitz, Andrew Hutt,
`Ole Jacobsen, Neil Jacobson, I-Iuet Landry, Eric Leach, John Leary, Marie
`Lenzi, Jacob Levy, Geoff Lewis, Denise Lynch, Cliff Mauton, Todd Pelfrey,
`ix
`
`9
`
`

`
`ACKNOWLEDGMENTS
`
`Marty Polluconi, Michael Powell, Richard Probst, Yllona Richardson, Bob
`' Rockwell, Mark Roy, Mark Ryland, John Rymer, Dave Seres, Cathy Sloan,
`Craig Thompson, Fred Waskhewicz, Andrew Watson, Dave Zenie, and all
`the others who helped us in our quest for understanding. These people gave
`us inspiration, motivation, and important ideas.
`'
`-
`Finally, We wish to thank our Wives and families for their patience, love,
`and unconditional support While writing this book.
`
`10
`
`10
`
`

`
`Con
`
`tents
`
`Executive Summary .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`Prob1emDefinition
`CORBA—The Basis for a Solution .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`Systems Integration Using CORBA—The Opportunity .
`A Framework for Change .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Synopsis of the Book .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`1
`
`1
`2
`
`2
`2
`3
`
`.
`
`.
`.
`.
`
`PART I THE PRINCIPLES OF SYSTEMS INTEGRATION
`
`1
`
`Introduction .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`7
`
`Issues in Computing: Technology, Market,
`9
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`and Organizations .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`9
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Stovepipe Systems .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. 11
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Proprietary Lock—In .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Inconsistencies between Design and Implementation . 13
`Standards Issues .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`. 16
`
`Lack of Tools for Creating Effective Abstractions .
`Lack of Security Facilities .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Heterogeneous Systems Integration .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Vision for Systems Integration .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`. 17
`. 18
`. 18
`. 19
`
`xi
`
`11
`
`11
`
`

`
`xii
`
`CONTENTS
`
`The Role of CORBA .
`Comments .
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`Standards Strategy .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`Standards Background .
`Benefits of Standardization .
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`Selecting a Standards Strategy .
`Standards Reference Models and Profiles .
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`. 21
`.
`‘23
`
`.
`
`.
`
`.
`
`. 25
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`. 26
`. 28
`
`. 29
`. 31
`
`. 32
`. 34
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`Implementing a Standards Strategy .
`Comments .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`An Introduction to CORBA .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`Object Management Architecture .
`. f .
`.
`.
`.
`.
`Object Request Broker .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Interface Definition Language .
`.
`Implementing OMG IDL Specifications .
`.
`Dynamic Invocation Interface .
`.
`.
`.
`.
`.
`.
`.
`.
`ObjectAdapters .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`CORBA Acceptance .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Product Availability .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Underlying CORBA .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`CORBA 2.0 .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Object Services .
`.
`.
`.
`Object Naming Service .
`.
`.
`.
`Object Event Service .
`.
`.
`Object Relationship Service .
`Common Facilities .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Comments .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`Software Architecture Design .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`.
`Establishing Architectural Vision .
`Role of CORBA in Software Architecture .
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`
`Architecture Process Compared to Methodology .
`Integration Capability Maturity Model .
`.
`.
`.
`.
`.
`.
`Software Architecture Design Process .
`.
`.
`.
`.
`.
`.
`The Mining Process .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`The Farming Process .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Composing and Refinement
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Prototyping and Lessons Learned .
`.
`.
`.
`.'
`.
`L
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`. 35
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`
`. 36
`. 37
`. 37
`. 40
`. 42
`. 43
`. 44
`. 44
`. 45
`. 45
`
`. 47
`. 48
`. 50
`. 51
`. 51
`. 53
`
`.
`
`.
`
`.
`
`.
`
`55
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`. 57
`. 57
`
`. 61
`. 61
`., 64
`. 66
`. 69
`. 70
`. 71
`
`12
`
`12
`
`

`
`CONTENTS
`
`xiii
`
`Interface Design Trade—ofi"s Using OMG IDL .
`Software Achitecture Design Principles .
`.
`.
`.
`Abstraction/ Simplicity .
`.
`.
`.
`.
`.
`.
`.
`.» .
`.
`.
`.
`Interoperability versus Extensibility .
`.
`.
`.
`Symmetry .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Component Isolation .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Metadata .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`. .. .
`Separation of Hierarchies
`Software Architecture Patterns .
`.
`Basic Architecture Patterns .
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`Advanced Architecture Pattern: Separation
`of Facilities .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`._
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Other Architecture Patterns .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Comments .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`Security .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`The Need for Security .
`.
`.
`.
`.
`.
`.
`.
`.
`Security Issues .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Basic Security Terminology .
`.
`.
`.
`.
`.
`.
`.
`Data Confidentiality .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Data Integrity .
`.
`.
`.
`.
`.
`.
`Identification and Authentication .
`Access Control
`.
`.‘
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`I
`.
`
`. 72
`. 75
`. 76
`. 77
`. 81
`. 83
`. 83
`
`. 86
`. 86
`. 87
`
`. .100
`.
`. 103
`. .106
`
`.
`
`.
`
`.
`
`. 109
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`:
`.
`.
`
`. 110
`.
`. 111
`.
`. 112
`.
`. 112
`.
`. .113
`.
`. 113
`. .113
`
`. .113
`. .113
`.
`. 114
`. .114
`. .114
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Auditing .
`Communication Security .
`Security Administration .
`Non-Repudiation .
`.
`.
`.
`.
`.
`Assurance .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Security Policies .
`.
`.
`.
`.
`.
`.
`Survey of Related Standards .
`ISO 7498-2 Security Architecture .
`TCSEC .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Other Criteria Initiatives .
`.
`.
`.
`.
`.
`.
`
`Survey of Related Technologies .
`Kerberos .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`Trusted Computing .
`GSS-API .
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`
`.
`.
`
`.
`
`Security in the CORBA Environment .
`Comments .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.'
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`. .114
`.
`. 115
`.
`. 115
`. .115
`.
`. 116
`
`. 117
`.
`. .117
`
`. .118
`. .121
`
`. 128
`.
`. .126
`
`13
`
`13
`
`

`
`xiv
`
`CONTENTS
`
`PART II THE PRACTICE OF SYSTEMS INTEGRATION
`
`6
`
`Framework Examples .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`Fresco .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`Object Linking and Embedding (OLE2)
`.
`.
`.
`.
`Technical Description of OLE2 .
`.
`.
`Comparison of OLE/ COM and CORBA .
`The OpenDoc Framework .
`.
`.
`.
`.
`.
`.
`._ .
`.
`.
`.
`.
`OpenDoc User Interface .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`OpenDoc Technology and CI Labs .
`.
`.
`.
`.
`The OpenDoc Architecture .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Autonomous Land Vehicle
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Comments .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`
`. 131
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`. .132
`
`. 135
`.
`. 136
`.
`. 139
`.
`. .150
`. .151
`.
`. 154
`.
`. 156
`.
`. 162
`. .164
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.'
`.
`
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`In-Depth Example: The DISCUS Framework .
`
`.
`
`.
`
`.
`
`. 167
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Framework Concepts .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Application Objects .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`The Core Framework Operations .
`OMG IDL Specifications for Application Objects .
`« Data and Table Objects
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Data Objects .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`OMG IDL Specifications for Data Objects .
`.
`.
`.
`.
`.
`.
`.
`Data Object Properties .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Table Objects .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Factory Object
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Factory Concept .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`OMG IDL Specifications for Factory Objects .
`.
`.
`.
`Managing Data and Table Objects .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Framework Services .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`The Trader Service and Metadata Objects .
`Conversion Service .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Public Folder .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Object Gateway .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`DISCUS Implementation .
`Clients and Object Implementations .
`Exceptions .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`CORBA Compliance .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Asynchronous Support .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Convenience Functions .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`
`. 168
`.
`. 172
`.
`. 172
`.
`. 175
`.
`. 188
`.
`. .188
`.
`. 191
`.
`. 195
`.
`i 196
`. .201
`. .201
`.
`. 203
`. .205
`.
`. 206
`
`. .206
`. .208
`.
`. 210
`
`. .211
`. .212
`. .212
`. .214
`. .214
`. .215
`. .220
`
`14
`
`14
`
`

`
`CONTENTS
`
`xv
`
`DISCUS Issues and Futures .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`Specializations of the Framework .
`Scalability .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Security .
`.
`.
`.
`.
`.
`.
`- .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`DISCUS Futures .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Comments .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`Object Wrapper Techniques .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`.
`
`. .225
`
`. .225
`. .226
`. .227
`. .228
`.
`. 228
`
`.
`
`.
`
`.
`
`.
`
`. 231
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Integrating Legacy Systems .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Types of Wrapping .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`I.
`.
`.
`.
`.
`.
`Wrapping Examples .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with Remote Procedure Calls .
`.
`.
`.
`.
`Wrapping with Files .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`V.
`.
`.
`.
`Wrapping with Sockets
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with a C API .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Integration with Common Lisp .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Integration with Smalltalk .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with Scripts .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with Events .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with Shared Memory .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with Dynamic Queries .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with IPC .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with Macros
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Wrapping with Header Files .
`.
`.
`.
`.
`.
`.
`.
`.
`Implementation Trade-Offs for Object Wrapping .
`Comments .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`«.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`. .232
`.
`. 232
`. .238
`. .241
`. .244
`. .246
`. .249
`. .252
`. .253
`.
`. 253
`. .254
`.
`. 254
`. .258
`. .259
`.
`. 259
`. .261
`. .262
`.
`. 265
`
`.
`
`.
`
`.
`
`. 269
`
`Systems Integration Guidance .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`The Importance of Software Architecture .
`Architecture Relation to Cost
`.
`.
`.7 .
`.
`.
`.
`CORBA Relation to Architecture .
`.
`.
`.
`.
`
`.
`.
`.
`.
`CORBA Reengineering Process .
`Market and Standards-Based Decisions .
`
`.
`.
`.
`Making Objective Decisions .
`Standards and Technology Cycle .
`Leading Edge Awareness .
`.
`.
`.
`.
`.
`Mainstream Awareness .
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`Impacting the Standards Process .
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`_ .
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`. .269
`. .271
`.
`. 271
`
`. 271
`.
`. .272
`
`. 272
`.
`. .272
`.
`. 274
`. .276
`
`. .276
`
`15
`
`15
`
`

`
`xvi
`
`CONTENTS
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Product Independence .
`.
`How to Depend on the Standard .
`.
`Using OMG IDL .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Quality Software Architecture .
`.
`.
`.
`.
`Key Architecture Qualities: Stability
`and Cost Minimization .
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`Iterative Design .
`Systems Integration Priorities .
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`
`.
`
`. .278
`. .278
`.
`. 278
`. .279
`
`. .280
`
`. .281
`.
`. 281
`
`.
`
`.
`
`.
`
`.
`
`. 283
`
`Acronyms .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. 285
`
`Appendix: ORB Products .
`
`.
`
`.
`
`.
`
`.
`
`SunSoft Distributed Objects Everywhere (DOE)
`Static Interfaces .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Fine-Grain Objects .
`.
`.
`.
`.’
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Threads .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`.
`Object Services .
`.
`.
`.
`.
`Digital Equipment ObjectBroker .
`Experience with DEC ObjectBroker .
`IONA Technologies’ Orbix .
`.
`.
`.
`.
`.
`.
`.
`.
`.
`IBM System Object Model (SOM)
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`.
`.
`.
`.
`
`.
`.
`.
`.
`.
`
`. .287
`. .288
`. .289
`. .291
`
`. .292
`.
`. 293
`.
`. 293
`. .295
`.
`. 296
`
`.
`
`.
`
`.
`
`.
`
`. 305
`
`Bibliography .
`
`Index .
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`. 309
`
`16
`
`16
`
`

`
`Executive Summary
`
`In this book, we introduce the theory and practice of systems integration us-
`ing standard object technology, Common Object Request Broker Architecture
`(CORBA). The purpose of systems integration is to provide interoperability
`between software components and to provide for system adaptability as the
`system evolves. This book goes beyond the basics of systems integration and
`CORBA to show readers how to maximize the benefits of these technologies
`and practices throughout the system life cycle.
`
`PROBLEM DEFINITION
`
`Today’s software systems comprise islands of automation. Each software
`component performs some limited range of useful functions, but components
`T do not interoperate effectively. The integration that exists is insufficient and
`does not evolve gracefully with the component technologies. The scale of this
`problem ranges from the the user’s desktop, to interuser, interdepartment,
`and interorganizational levels. Key consequences of poor systems integration
`include:
`
`0
`
`Stovepipe systems. These systems are poorly integrated systems that
`have ad hoc or proprietary integration solutions. Poorly integrated sys-
`tems have high maintenance costs, resist adaptation to changing user
`requirements, and cannot evolve with commercial technology.
`0 Organizational productivity impacts. Poor integration leads to substan-
`tial organizational inefficiencies, such as redundant data entry, mul-
`tistep data conversion, and ad hoc file transfers. These processes are
`
`1
`
`17,
`
`17
`
`

`
`2
`
`EXECUTIVE SUMMARY
`
`costly, time consuming, and error prone. Poor systems integration re-
`quires users to be knowledgeable about multiple disparate applications.
`Users trained on one system cannot transfer skills to other systems.
`
`CORBA — THE BASIS FOR A SOLUTION
`
`CORBA is an industry standard technology infrastructure for systems inte-
`gration. Some of its key benefits include:
`
`1. CORBA simplifies distributed computing and application integration. It
`is easier to use than other distributed computing and integration mech-
`anisms; therefore, it saves time and reduces software costs. CORBA also
`provides many useful new flexibilities compared to other mechanisms.
`2. CORBA is object oriented. This means that architects and developers
`can improve their software structure, make their software more flexi-
`ble, reuse software, seamlessly integrate legacy software, and develop
`new capabilities rapidly. CORBA provides a uniform layer encapsulating
`other forms of distributed computing and integration mechanisms.
`3. CORBA is a stable technology supported by a growing coalition of com-
`mercial software vendors. CORBA is a standard from the world’s largest
`software consortium, the Object Management Group (OMG), and sup-
`ported by X/Open, the Open Software Foundation (OSF), the Common
`Open Software Environment (COSE), CI Labs, X/Consortium, and oth-
`ers. The core elements of CORBA have been stable since 1991. With
`
`CORBA, OMG has reengineered the standards process to allow suppli-
`ers and end users to create new standards for interoperability efficiently.
`
`SYSTEMS INTEGRATION USING CORBA — THE OPPORTUNITY
`
`CORBA is an enabling technology. Bad systems integration practices can
`lead to stovepipe systems regardless of whether CORBA is used. This book
`is a guide on how to follow good architecture principles that utilize CORBA
`for maximum benefits.
`
`Key benefits of our approach to CORBA-based systems integration in-
`clude: faster system delivery, enhanced software reuse, increased system
`adaptability, reduced maintenance costs, focused research activities, en-
`hanced system interoperability, enterprise systems integration, andother
`benefits.
`
`A FRAMEWORK FOR CHANGE
`
`In Chapter 4 we define an integration capability model, which enables orga-
`nizations to assess their current systems integration practices. This model
`allows organizations to discover the substantial benefits of improved sys-
`
`18
`
`18
`
`

`
`SYNOPSIS OF THE BOOK
`
`3
`
`tems integration compared to current practices. The integration capability
`model includes the following levels:
`
`Level 6. Standard Architectures
`Level 5. Frameworks
`
`Level 4. Distributed Objects (CORBA)
`Level 3. Mature Remote Procedure Calls (OSF DCE)
`Level 2. Miscellaneous Mechanisms
`Level 1. Commercial Off-the-Shelf Solutions
`
`The capabilities range from organizations that do no value-added inte-
`gration (level 1) to organizations that drive industry standards (level 6). Most
`organizations today practice systems integration at levels 2 and 3. When an
`organization first adopts CORBA, it begins at level 4. Substantial benefits
`result from level 5 practices, and technology leadership is demonstrated at
`level 6. This book teaches readers how to perform systems integration in
`order to achieve level 5 and 6 benefits. The capability model is described in
`detail in Chapter
`
`SYNOPSIS OF THE BOOK
`
`Chapter 1, “Introduction,” introduces the paradigm shift that motivates the
`increasing role of systems integration. It provides a detailed introduction to
`systems integration problems including commercial technology integration,
`legacy systems integration, and other key issues. It establishes a vision for
`the organizational use of good systems integration practices and CORBA.
`Chapter 2, “Standards Strategy,” defines what standards mean and how
`they are used effectively. It provides guidance for understanding and ex-
`ploiting available standards and shows how an organization can leverage
`the work of government organizations and standards groups to define a
`comprehensive standards strategy.
`Chapter 3, “An Introduction to CORBA,” provides essential tutorial in-
`formation about OMG standards: CORBA, OMG’s Interface Definition Lan-
`‘ guage (OMG IDL), CORBAservices (Common Object Service Specifications),
`and CORBAfacilities (OMG Common Facilities).
`Chapter 4, “Software Architecture Design,” includes the foundational
`theories of systems integration. It describes the integration capability model
`and defines architecture and framework concepts. It establishes an inte-
`grated software architecture design process and defines details of how to
`use OMG IDL for controlling design trade-offs. It also compares the archi-
`tectural patterns that support the theory and shows the quantitative impact
`of each architectural approach.
`Chapter 5, “Security,” discusses one of the most challenging aspects of
`systems integration. This chapter surveys key security technologies that
`
`19
`
`19
`
`

`
`EXECUTIVE SUMMARY
`
`contribute to an overall security solution and establishes a vision for how
`they will interact in future systems constructed with OMG standards.
`Chapter 6, “Framework Examples,” describes Microsoft Object Linking
`and Embedding (OLE), OpenDoc, and X11R6 Fresco. These are some of
`the key commercial software architectures that will impact future systems
`integration.
`.
`Chapter 7, “ln—Depth Example: The DISCUS Framework,” discusses
`DISCUS, one of the most mature CORBA~based application architectures.
`It is presented here as a detailed example of systems integration practices.
`DISCUS incorporates many useful design examples, techniques, and lessons
`that can be transferred to new system designs and implementations.
`Chapter 8, “Object Wrapper Techniques,” discusses object wrapping, the
`core competency in systems integration for developers. This chapter is an
`essential tutorial about wrapping techniques for architects and developers.
`The chapter gives examples of object wrapping for the most commonly oc-
`curring integration challenges.
`Chapter 9, “Systems Integration Guidance,” summarizes the whole book
`in terms of six key guidelines.
`Appendix, “ORB Products,” contains product overviews of some of the
`major CORBA Object Request Brokers: Digital Equipment Corporation’s
`ObjectBroker, SunSoft’s DOE, IONA’s Orbix, and IBM’s System Object Model
`(SOM).
`
`20
`
`20
`
`

`
`THE PRINCIPLES
`OF SYSTEMS
`
`INTEGRATION
`
`21
`
`21
`
`

`
`22
`
`

`
`Introduction
`
`i
`
`In this introductory chapter, we identify the key issues that motivate this
`book. In particular, we wish to heighten the contradictions in current sys-
`tems integration practice. In this Way, We can summarize all of the key
`technical and related nontechnical issues. In the balance of the book, we
`Will explain Object Management Group (OMG) standards and other key
`concepts needed for successful systems integration. OMG’s core standard,
`the Common Object Request Broker Architecture (CORBA), provides many
`technical benefits. We provide added value by addressing howto use the
`OMG standards effectively in systems integration. This chapter focuses on
`systems integration issues prior to the adoption of CORBA and prior to the
`application of the techniques presented in this book.
`While most of the book focuses on the technical issues, this chapter will
`identify some of the factors outside the technical realm that influence sys-
`tems integration. For example, software architectures often mirror our or-
`ganizational structures, and systems integration success is dependent upon
`organizational support for the architects and developers.
`Not long ago, a stand-alone program comprising a command-line inter-
`face and a few specialized functions Was sufficient for a successful software
`application. Since then, end users’ expectations have changed dramatically;
`the scope of requirements also has changed. Today it is expected that soft-
`ware systems will have graphical user interfaces; software systems will
`incorporate complex data types such as imagery, graphics, and multimedia;
`and software systems will have integrated database capabilities. Hetero-
`geneous computing environments are a reality in most organizations where
`differences between platforms reinforce the need for rnultivendor integration
`solutions.
`
`23
`
`23
`
`

`
`8
`
`INTRODUCTION
`
`Systems integration requirements will become even more challenging in
`the near future. For example, universal data interchange between applica-
`tions will be expected; applications will need to support computer-assisted
`human collaboration, and these capabilities will be needed in mobile dis-
`tributed environments, supported on a wide range of platforms and net-
`works. Standards support will be a key software product discriminator for
`end users; however these standards might not guarantee interoperability.
`For most organizations, it is not feasible to build systems of this scope
`using custom software. As a result, the practice of building systems has
`changed from custom programming to systems integration from preexisting
`components. Custom applications have a role in meeting highly specialized
`needs, such as organization-specific user interfaces. As the diversity and
`capabilities of commercial software increase, the need for custom software
`decreases. For complex functions, it is usually more cost effective to reuse
`existing software than to create custom software. The majority of software
`in future systems will be preexisting, obtained from commercial vendors and
`other sources. Systems integration has a role in providing interapplication
`interoperability and system customization beyond the off-the-shelf capabil-
`ities; design and development of this custom software is a key focus of this
`book.
`
`The growing supply of preexisting software is displacing the need for
`custom software. Preexisting software sources include in-house software,
`commercial software, public domain software, freeware, and shareware. In-
`house software can include legacy systems software, prototype software, and
`software designed for in-house reuse, such as class libraries. Commercial
`software is available directly from suppliers, retail outlets, industry confer-
`ences, and other advertising events and media. Public domain software is
`freely available software that is not copyrighted and can be used without
`restrictions. Freeware is similar, except that it carries a copyright notice.
`Shareware is software that is available for a nominal fee and also carries a
`
`copyright. Copyright can restrict the reselling of freeware and shareware,
`but the copyrights generally allow the usage of the software in end-user sys-
`tems. Public domain, freeware, and shareware can be obtained from users’
`groups, from vendors, and from public networks (including the Internet and
`commercial computer networks).
`The practice of systems integration can range from informal ad hoc
`programming to formal structured methodologies. In many organizations
`these practices coexist: the formal practices creating the documentation and
`the informal practices creating the working system.
`The difficulties of integrating preexisting components create a need for
`highly creative programmers. Many successful programmers are masters of
`scrounging software components and integrating components in ingenious
`Ways. These skills are essential to virtually every software engineering ac-
`tivity; ad hoc integration is expedient and leads to demonstrable results.
`
`24
`
`24
`
`

`
`ISSUES IN COMPUTING
`
`9
`
`Often these integration solutions are brilliant, but these achievements are
`seldom sustainable. Ad hoc integration usually produces undocumented brit-
`tle syst