home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / object-faq / part3 < prev    next >
Text File  |  1996-04-03  |  52KB  |  1,208 lines
  1. Newsgroups: comp.object,comp.answers,news.answers
  2. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!hookup!news.join.ad.jp!news.imnet.ad.jp!usenet.seri.re.kr!news.cais.net!news.jsums.edu!gatech!newsfeed.internetmci.com!ncar!uchinews!news
  3. From: Bob Hathaway <rjh@geodesic.com>
  4. Subject: Comp.Object FAQ Version 1.0.9 (04-02) Part 3/13
  5. X-Nntp-Posting-Host: ford.uchicago.edu
  6. Message-ID: <Dp9q6u.A00@midway.uchicago.edu>
  7. Followup-To: comp.object
  8. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  9. Sender: news@midway.uchicago.edu (News Administrator)
  10. Organization: Geodesic Systems
  11. References: <Dp9prv.92t@midway.uchicago.edu>
  12. Date: Wed, 3 Apr 1996 04:08:54 GMT
  13. Approved: news-answers-request@MIT.Edu
  14. Lines: 1191
  15. Xref: senator-bedfellow.mit.edu comp.object:46837 comp.answers:17912 news.answers:68444
  16.  
  17. Archive-name: object-faq/part3
  18. Last-Modified: 04/02/96
  19. Version: 1.0.9
  20.  
  21. Contact Person: Richard Soley (technical director) soley@omg.com
  22.  
  23. FTP Sites: 
  24.   omg.org:pub/*
  25.   omg.org:pub/NEC_DII/93-1-2.tar...            *CORBA (DII) (corba.ps.Z)
  26.   omg.org:pub/OMG_IDL_CFE_1.2/bin*              idl.SunOS4.x, idl.Solaris2.x
  27.   claude.ifi.unizh.ch:under pub/standards/spec  CORBA Spec
  28.   WWW:
  29.     http://www.omg.org/
  30.     http://conf4.darpa.mil/corba-ada/ORBs.html
  31.     http://www.acl.lanl.gov/sunrise/DistComp/Objects/corba.html
  32.     http://www.cs.wustl.edu/~schmidt/corba.html
  33.     http://www.dstc.edu.au/AU/research_news/omg/corba.html
  34.  
  35. Headquarters:                            Marketing Office:
  36.   492 Old Connecticut Path                 3823 Birchwood Drive
  37.   Framingham, MA 01701                     Boulder, CO  80304
  38.   Tel: 508-820-4300                        Tel: 303-444-8129
  39.   Fax: 508-820-4303                        Fax: 303-444-8172
  40.  
  41.  
  42. 3.8.2  OMG Summary
  43. __________________
  44.  
  45. From: soley@emerald.omg.ORG (Richard Mark Soley)
  46. Subject: OMG
  47.  
  48. In answer to your general question about the OMG, here's a brief overview.
  49. Feel free to call, fax or email for more information.
  50.  
  51.         -- Richard Soley
  52.            Vice President & Technical Director
  53.            Object Management Group, Inc.
  54.            and coincidentally, MIT '82, SM '85, PhD '89 (EECS)
  55.  
  56. The Object Management Group (OMG) is an international software industry
  57. consortium with two primary aims:
  58.  
  59. (*) promotion of the object-oriented approach to software engineering
  60.     in general, and
  61.  
  62. (*) development of command models and a common interface for the development
  63.     and use of large-scale distributed applications (open distributed
  64.     processing) using object-oriented methodology.
  65.  
  66. In late 1990 the OMG published its Object Management Architecture
  67. (OMA) Guide document. This document outlines a single terminology for
  68. object-oriented languages, systems, databases and application
  69. frameworks; an abstract framework for object-oriented systems; a set
  70. of both technical and architectural goals; and an architecture
  71. (reference model) for distributed applications using object-oriented
  72. techniques.  To fill out this reference model, four areas of
  73. standardization have been identified:
  74.  
  75. 1) the Object Request Broker, or key communications element, for
  76.    handling distribution of messages between application objects in
  77.    a highly interoperable manner;
  78.  
  79. 2) the Object Model, or single design-portability abstract model for
  80.    communicating with OMG-conforming object-oriented systems;
  81.  
  82. 3) the Object Services, which will provide the main functions for
  83.    realising basic object functionality using the Object Request Broker -
  84.    the logical modeling and physical storage of objects; and
  85.  
  86. 4) the Common Facilities will comprise facilities which are useful in
  87. many application domains and which will be made available through OMA
  88. compliant class interfaces.
  89.  
  90. The OMG adoption cycle includes Requests for Information and
  91. Proposals, requesting detailed technical and commercial availability
  92. information from OMG members about existing products to fill
  93. particular parts of the reference model architecture.  After passage
  94. by Technical and Business committees to review these responses, the
  95. OMG Board of Directors makes a final determination for technology adoption.
  96. Adopted specifications are available on a fee-free basis to members and
  97. non-members alike.
  98.  
  99. In late 1991 OMG adopted its first interface technology, for the Object
  100. Request Broker portion of the reference model.  This technology, adopted
  101. from a joint proposal (named "CORBA") of Hewlett-Packard, NCR Corp.,
  102. HyperDesk Corp., Digital Equipment Corp., Sun Microsystems and Object
  103. Design Inc. includes both static and dynamic interfaces to an inter-
  104. application request handling software "bus."
  105.  
  106. Unlike other organizations, the OMG itself does not and will not
  107. develop nor sell software of any kind.  Instead, it selects and promulgates
  108. software interfaces; products which offer these interfaces continue to be
  109. developed and offered by commercial companies.
  110.  
  111. In order to serve OMG membership interested in other object-oriented systems
  112. arenas besides the distributed system problem, the Group supports Special
  113. Interest Groups for discussion of possible standards in other areas.  These
  114. groups at present are:
  115.  
  116.         1) Object Oriented Databases;
  117.         2) OO Languages;
  118.         3) End-User Requirements;
  119.         4) Parallel Processing;
  120.         5) Analysis & Design Methodologies;
  121.         6) Smalltalk; and
  122.         7) Class Libraries.
  123.  
  124. Any company, university/research institution or individual, whether
  125. end-user or vendor, can become a member of this body.  Administrative
  126. details are given at the end of this paper.
  127.  
  128.  
  129. 3.8.3  Mail Server Access
  130. _________________________
  131.  
  132. Information via Mail Server:
  133.   Send the following commands in a letter to the mail server.
  134.  
  135. mail omg_server@omg.org
  136. help                             (how to use file server)
  137. index                            (return a list of all available files)
  138. get <file>                       (get files returned by  index)
  139. log <info>                       (logs info on server)
  140. address <e-mail address)         (use this address instead of sender)
  141. list <directory> [match]         (index a directory, pattern 'match' files)
  142. size <segment size>              (max file size to send)
  143.  
  144. list mail
  145. list docs
  146. get docs/doclist.txt             
  147. get docs/91-12-1.ps               CORBA spec [although it looks a little old]
  148.  
  149.  
  150. Recommended (from the net):
  151.  
  152. mail omg_server@omg.org
  153. Subject: 
  154. help
  155. index
  156. list
  157. list mail
  158. list docs
  159. get docs/doclist.txt
  160.  
  161.  
  162. 3.8.4  OMG Publications
  163. _______________________
  164.  
  165. Below is from omg.org:pub/CORBA
  166.  
  167.  
  168. > First Class (Bi-Monthly Newsletter)
  169.  
  170. First Class is OMG's non-commercial bi-monthly 28-page
  171. newsletter. First Class provides current information on Object
  172. Technology developments, both technically and commercially. First
  173. Class offers an open editorial forum on numerous Object
  174. Technology topics and issues.  This publication features
  175. commentaries from software industry leaders, informative user
  176. case histories, OT training information and the latest object-
  177. oriented product announcements.  All OMG activities and the
  178. ongoing development of the Object Management Architecture are
  179. regularly reported.
  180.  
  181.  
  182. > Object Management Architecture Guide (OMA)
  183.  
  184. The members of the OMG have a shared goal of developing and using
  185. integrated software systems.  These systems should be built using
  186. a methodology that supports modular production of software;
  187. encourages reuse of code; allows useful integration across lines
  188. of developers, operating systems and hardware; and enhance long-
  189. range maintenance of that code.  As an organization, OMG believes
  190. that the object-oriented approach to software construction best
  191. supports their goals.  The OMA publication outlines the
  192. groundwork for technology response to Request for Proposals (RFP)
  193. and the adoption of specifications.
  194.  
  195.  
  196. > The Common Object Request Broker: Arch. and Spec. (Corba)
  197.  
  198. The CORBA, as defined by the OMG's Object Request Broker (ORB),
  199. provides the mechanisms by which objects transparently make
  200. requests and receive responses. The ORB provides interoperability
  201. between applications on different machines in heterogeneous
  202. distributed environments and seamlessly interconnects multiple
  203. object systems. The Common Object Request Broker Architecture and
  204. Specification described in this published document is a self-
  205. contained response to the Request for Proposals (RFP) issued by
  206. the ORB Task Force of the OMG.
  207.  
  208. > Pricing
  209.  
  210. [Here's why you don't see the specifications posted to the net or available via
  211.  ftp!  These are from the list of literature and periodicals listed in
  212.  omg.org:pub/CORBA]
  213.  
  214. o I would like a one year subscription to First Class
  215.     ______ for $40 U.S.,  ______ for $50 outside U.S.
  216.  
  217. o I would like to order  ______ copy(s) of the Object Management
  218.   Architecture (OMA) Guide for $50 each.
  219.  
  220. o I would like to order  ______ copy(s) of the CORBA for $50 each.
  221.  
  222. o [Combinations]
  223.  
  224. Contact documents@omg.org or omg_documents@omg.org for more of the same...
  225.  
  226.  
  227. 3.8.5  Implementations (Brief)
  228. ______________________________
  229.  
  230. > DEC ObjectBroker Version 2.5  (Version 2.1 was ACA)
  231.   Full implementation of OMG CORBA 1.1.  Digital's ObjectBroker is a 100 %
  232.   compliant implementation of CORBA and is available on these  platforms:
  233.   IBM AIX, IBM MVS(port in progress), HP-UX, Macintosh, MS-Windows 3.1, NT,
  234.   OSF/1, SunOS, ULTRIX, Digital  VAX/VMS, Digital OpenVMS
  235. Contact:
  236.   Andrew Comas
  237.   comas@nyo.dec.com  (212) 856-2507
  238.   Digital Equipment Corporation.
  239.   ObjectBroker
  240.   110 Spit Brook Road
  241.   Nashua, New Hampshire  03062-2698
  242.  
  243. > DOME - The C++ Object Request Broker
  244.     runs on VAX/VMS, Unix, PC
  245.     http://www.octacon.co.uk/onyx/external/oot.co.uk
  246.     Anon ftp: ftp.octacon.co.uk/external/oot/domedemo.exe; also from http.
  247.  
  248. > HP ORB Plus and HP Distributed Smalltalk
  249.    Full implementation of the OMG CORBA 1.1 Object Request Broker. Also DOMF.
  250.    Hewlett-Packard
  251.    Distributed Computing Group
  252.    19447 Pruneridge Avenue
  253.    Cupertino, CA 95014-9974 (USA)
  254.    Ian Fuller ian@cup.hp.com (408) 447-4722
  255.  
  256. > HyperDesk (Westborough MA) HD-DOMS, rich_fraser@hyperdesk.com
  257.    Runs on SPARC, HP/UX, IBM RS-6000, Data General Aviion, MS-Windows (client
  258.    API only), NetWare (planned, Novell owns part of HyperDesk).
  259.  
  260. > IBM SOM (System Object Model)
  261.    Available on AIX and OS/2.  See Distributed Computing Monitor, March 93 for
  262.    a detailed review.
  263.  
  264. > ILU (free, see APPENDIX E entry 59)
  265.    Object RPC compatible with OMG CORBA 1.2 spec (will compile OMG IDL and
  266.    generate OMG compliant code for OMG-specified languages).
  267.    parcftp.parc.xerox.com:/pub/ilu/ilu.html
  268.  
  269. > IONA Technologies, Dublin Orbix, info@iona.ie
  270.   First full and complete implementation of OMG's CORBA.
  271.  
  272. > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation
  273.   (1) C++ ORB toolkit consisting of over 300 C++ classes and runtime libraries
  274.   (2) CORBA 1.1 toolkit
  275.  
  276. > ORBELINE - The SMART Object Request Broker - PostModern Computing
  277.   Complete implementation of CORBA.  Free academic; com. eval licence avail.
  278.   SunOS 4.x, Solaris 2.3, and OSF/1 versions of ORBeline available; will
  279.   consider making other platforms available if enough interest. See Appendix E.
  280.   http://www.pomoco.com/
  281.  
  282. > ROLSCH CONSULTING (RC-ORB)
  283.   Implements ORB spec, DOS/Windows 3.1, 12 user license: $99.
  284.   Ref: Datamation, LOOK AHEAD Section, August 1.  German Company.
  285.  
  286.  
  287. > SUITESOFTWARE (SuiteDOME)
  288.  - an open system, standards compliance, object-oriented architecture,
  289.    support for heterogeneous environments, support for Remote Data Access
  290.   (RDA), Remote Procedure Calls (RPC), Message-Oriented Middleware (MOM),
  291.   and Object Request Broker (ORB).
  292.  
  293. > Sun DOE
  294.  
  295. > Tivoli
  296.  
  297. > CS Dept. University of Zurich, Switzerland.  maffeis@ifi.unizh.ch
  298.     The ELECTRA Toolkit (not finished)
  299.  
  300.  
  301. 3.8.6  Implementation Descriptions
  302. ___________________________________
  303.  
  304. The OMG also has a (Corporate) Membership list and "known CORBA supporters"
  305. list with their info package.
  306.  
  307.  
  308. > The ELECTRA Toolkit
  309.  
  310. CS Dept. University of Zurich, Switzerland.  maffeis@ifi.unizh.ch
  311. The ELECTRA Toolkit
  312.  
  313. Subject: ORB Implementations
  314. Date: Tue, 4 May 1993 13:12:36 +0200 (MET DST)
  315. From: Silvano Maffeis <maffeis@ifi.unizh.ch>
  316.  
  317.   something like an Object Broker, but it is *not* CORBA compatible (yet).
  318.   Electra is a research project and not available yet.
  319.  
  320.   Its a toolkit for building failure resilient, distributed applications
  321.   in C++. It supports object-groups, virtual synchrony, multithreading
  322.   etc. Electra is based on the HORUS toolkit (which is "the new ISIS
  323.   implementation" developed at Cornell, Ithaca NY.)
  324.   An overview paper to electra is available from:
  325.   ftp.ifi.unizh.ch: pub/techreports/electra.ps.Z
  326.  
  327.  
  328. > HD_DOMS
  329.  
  330. HD-DOMS (HyperDesk Distributed Object Management System).  A
  331. CORBA-compliant DOMS.  Includes a GUI API driver for prototyping and
  332. exercising objects, a bundled object database for persistent object
  333. storage, a Kerberos-based authentication service, a location service, a
  334. set of base classes to speed development, and a test script language.
  335. Revision 1.0 has been shipping since beginning of '92.  Revision 1.1
  336. (which includes support for CORBA's static client interface) is available
  337. now, and a NetWare version is in the works.  Submitted a C++ language
  338. mapping for IDL to the OMG recently.
  339.  
  340. HyperDesk Corporation
  341. 2000 West Park Drive
  342. Westboro, MA 01581
  343. (508)366-5050
  344.  
  345.  
  346. > HP ORB Plus and HP Distributed Smalltalk
  347.  
  348.   ============================================================================
  349.   SUBJECT:  HP INTRODUCES DISTRIBUTED-COMPUTING SOLUTION FOR BUILDING
  350.             SCALABLE, OBJECT-ORIENTED APPLICATIONS
  351.   DATE:     September 27, 1993
  352.   ----------------------------------------------------------------------------
  353.  
  354.    PALO ALTO, Calif.--(BUSINESS WIRE) via First! -- Hewlett-Packard Company
  355.  today introduced a distributed-computing solution for building scalable,
  356.  object-oriented applications.
  357.  
  358.    With HP ORB Plus, programmers can develop scalable, object-based
  359.  applications that can be distributed throughout the enterprise.  HP also
  360.  introduced an enhanced version of HP Distributed Smalltalk.
  361.  
  362.    HP ORB Plus and HP Distributed Smalltalk are major components of HP's
  363.  overall distributed-computing strategy, which is designed to give customers
  364.  integrated, desktop access to enterprise-wide information and resources in
  365.  distributed heterogeneous systems environments.  Of all computer companies,
  366.  HP believes it is best positioned to help customers take advantage of
  367.  distributed computing. HP provides a wide variety of distributed-computing
  368.  products, understands how to help customers adopt new technology for maximum
  369.  business benefit, and offers worldwide support and training programs,
  370.  ranging from analysis and design to deployment.
  371.  
  372.    HP ORB PLUS:  CORBA AND DCE COMBINED
  373.  
  374.    HP ORB Plus is the only environment that combines the complete CORBA 1.1
  375.  specification from the Object Management Group with the DCE standard from
  376.  the Open Software Foundation(tm) as its transport mechanism.  DCE is
  377.  designed to let developers write one application and then deploy it --
  378.  without modification -- on any other system that supports DCE.  HP ORB Plus
  379.  reduces the complexity of developing distributed applications so programmers
  380.  can concentrate on the application itself without needing to know multiple
  381.  operating systems, networking protocols or where application objects are
  382.  stored.
  383.  
  384.    The DCE (Distributed Computing Environment) standard provides an
  385.  integrated set of services that can be used separately or together to
  386.  provide a distributed computing environment that's easy to administer.  The
  387.  CORBA (common-object-request-broker architecture) specification provides a
  388.  standard for how objects (in applications, repositories or class libraries)
  389.  make requests and receive responses across a distributed network.
  390.  
  391.    HP ORB PLUS DETAILS
  392.  
  393.    HP ORB Plus consists of several components: the Distributed Object
  394.  Management Facility (DOMF), object services, developers' and administrative
  395.  tools, and sample applications.  HP's DOMF provides a location-transparent
  396.  object-communication mechanism across heterogeneous networks by using the
  397.  DCE standard.  This object- enabling technology specification was jointly
  398.  developed with SunSoft. By following a common specification, HP and SunSoft
  399.  have made it easier for their customers to port applications between their
  400.  platforms.
  401.  
  402.    In addition, HP is working with IBM to integrate HP's DOMF with IBM's
  403.  System Object Model with extensions for distribution.  This integration will
  404.  eventually provide users with complete scalability, portability and
  405.  interoperability of distributed applications across HP and IBM platforms.
  406.  This is part of the companies' planned approach toward a standards-based,
  407.  "plug-and-play"  object-oriented environment.  This will give developers,
  408.  system administrators and end users language-neutral, enterprise-wide,
  409.  heterogeneous support for building, managing and using distributed object-
  410.  oriented applications.
  411.  
  412.    "We're so convinced of the value of object technology that we're staking
  413.  our entire company on it,"  said Richard Tanler, president and chief
  414.  executive officer of Information Advantage, Inc.  "Our object-based
  415.  applications for retailers provide the means to a competitive business edge.
  416.  We plan to use HP ORB Plus to develop new object-based products that
  417.  retailers can distribute to end users throughout headquarters, all chain
  418.  stores, and warehousing and distribution operations."
  419.  
  420.    HP DISTRIBUTED SMALLTALK 2.0
  421.  
  422.    In a related announcement, HP introduced Version 2.0 of HP Distributed
  423.  Smalltalk.  This toolset works with VisualWorks from ParcPlace Systems to
  424.  provide programmers with a rapid development environment for creating and
  425.  running distributed applications.  These applications can use object
  426.  databases (currently OpenODB from HP and Gemstone from Servio) as their
  427.  storage mechanism to facilitate the reuse of objects.
  428.  
  429.    Applications built using HP Distributed Smalltalk currently run without
  430.  modification on HP, Sun and IBM UNIX(R) system-based workstations.  They
  431.  also will run on Apple Macintosh computers and on any PC running the Windows
  432.  3.1 or Windows NT operating systems from Microsoft(R) Corp., once
  433.  VisualWorks 2.0 is released (expected within two months.)
  434.  
  435.    New HP Distributed Smalltalk 2.0 features include the following:
  436.  
  437.    --  easier deployment, with the ability to run multiple HP
  438.        Distributed Smalltalk-based applications on a single system;
  439.    --  up to 400 percent increased performance, through quicker
  440.        sending and receiving of remote messages, and reusable
  441.        object libraries;
  442.    --  run-time version, for full production deployment; and
  443.    --  easier development, with remote object browsing so
  444.        developers can find and use objects more quickly.
  445.  
  446.    TECHNICAL DETAILS AND AVAILABILITY
  447.  
  448.    HP's DOMF includes the object request broker, interface- definition-
  449.  language compiler, static and dynamic invocation interface and interface
  450.  repository.  In addition to these OMG-specific features, most developers
  451.  writing distributed, object-oriented applications require additional
  452.  interfaces to use objects effectively.  So developers don't need to create
  453.  their own, HP has supplied several object-service interfaces for developers
  454.  to use. That's why HP ORB Plus includes OMG interfaces and implementations
  455.  for properties, life cycle, associations, event notification and naming.
  456.  
  457.    HP's limited release of HP ORB Plus to key developers is designed so that
  458.  customer input can be incorporated into the product early in its development
  459.  cycle.  The initial version will work with the C++ programming language.
  460.  For the generally available Developer's Kit, C++, C and Smalltalk
  461.  interoperability is planned so objects written in different languages can be
  462.  combined into one application.  The Developer's Kit is scheduled to be
  463.  available mid- 1994; prices will be announced then.  HP ORB Plus runs on the
  464.  HP Apollo 9000 Series 700 workstations and HP 9000 Series 800 business
  465.  servers.
  466.  
  467.    Hewlett-Packard Company is an international manufacturer of measurement
  468.  and computation products and systems recognized for excellence in quality
  469.  and support.  The company's products and services are used in industry,
  470.  business, engineering, science, medicine and education in approximately 110
  471.  countries.  HP has 94,900 employees and had revenue of $16.4 billion in its
  472.  1992 fiscal year.
  473.  
  474.  EDITORIAL CONTACTS:
  475.     Hewlett-Packard Company
  476.     Lynne Hanson, 408/447-1415, Cupertino, Calif.
  477.     Jill Kramer, 408/447-4275, Cupertino, Calif.
  478.  
  479.  ==================
  480.    For more information about HP ORB Plus, contact Kathy Litch
  481.    (litch_k@apollo.hp.com).
  482.  
  483.    For more information about HP Distributed SmallTalk, contact
  484.    Jerry Boortz (jerry_boortz@hp4000.desk.hp.com).
  485.  
  486.  
  487. > Iris RDOM
  488.  
  489. From: rcbc@cs.cornell.edu (Robert Cooper)
  490. Subject: Re: DCE vs. CORBA
  491. Reply-To: rcbc@isis.com
  492. Product: Isis Reliable Distributed Object Manager(tm) (RDOM)
  493. Company: Isis Distributed Systems, Inc., Ithaca NY, USA.
  494.  
  495. Isis RDOM(tm) is a fault tolerant distributed ORB platform for reliable
  496. multi-lingual object-oriented applications. RDOM provides an "object group"
  497. paradigm for constructing complex applications out of collections of
  498. cooperating objects. RDOM is built on top of the Isis Distributed
  499. Toolkit(tm). RDOM provides interfaces from Smalltalk (Parcplace),
  500. Objective-C, and C++, and runs on most Unix workstations. RDOM is currently
  501. not CORBA compliant, but will be brought to compliance during 3Q93.
  502.  
  503. Status: 
  504.  
  505. RDOM has been at beta test sites since January. General release of
  506. the Smalltalk and Objective-C language interfaces is expected in June.
  507. The C++ interface in August. Customers include AMD, Consilium and Swiss
  508. Bank Corp).  
  509.  
  510. > Object-Oriented Technologies DOME
  511.  
  512. Product:  DOME - Distributed Object Management Environment
  513.  
  514. Company:  Enquiries: info@oot.co.uk     
  515.       Object Oriented Technologies Ltd,
  516.       1st Floor, Lawrence House, 1A Morrell St, Leamington Spa, England CV32 5SZ
  517.       Telephone: +44 (0) 1926 833488 Fax: +44 (0) 1926 883370.
  518.  
  519. Short Description:
  520.         DOME provides heterogenous distribution across many platforms
  521.         and networks, including:
  522.             UNIX, Windows, Windows NT, OS/2, OSF/1 (AXP), OpenVMS, 
  523.             SunOs, Solaris, HP-UX, SGI Unix, Stratus FTX,
  524.             TCP/IP, NetBIOS, XTI
  525.         As a fully peer-to-peer product DOME can be used to build systems
  526.         using any combination of the above.
  527.  
  528. Long Description:
  529.         DOME is an ORB toolkit for the production of user-configured
  530.         ORBs and servers. It is a multi-threaded high performance ORB
  531.         suitable for use in large scale commercial systems and embedded 
  532.         real-time systems.
  533.  
  534.         DOME is non-intrusive, meaning that the application development
  535.         is separated from the means of distribution and the problem of
  536.         distributed object management; this allows the application to
  537.         be built and tested on a single machine using local resources.
  538.         Existing software can also be incorporated easily, providing
  539.         integration for legacy systems.
  540.  
  541.         DOME is constructed as a C++ class library, from which ORBs
  542.         can be configured and constructed to best suit the runtime
  543.         environment. This provides great flexibility since new classes
  544.         can be derived from existing ones and the resulting configurations 
  545.         implemented to user-specific requirements.
  546.  
  547.         Database distribution can be as simple persistent files, 
  548.         RDBMSs, OODMS, or a combination of these.
  549.  
  550.         DOME has a CORBA-conformant interface, and is CORBA 1.0 compliant
  551.         with the following divergences -
  552.         additions:
  553.         - full C++ binding,
  554.         - integral support for GUI development,
  555.         - network monitoring & analysis,
  556.         - transaction management,
  557.         - location broking,
  558.         - enhanced security;
  559.         ommissions:
  560.         - dynamic invocation, which is seen as detrimental to performance 
  561.           and network security; however, DOME does allow stream operators 
  562.           to perform the same function.
  563.  
  564.         DOME was first released in August 1993; version 2 in May 1994.
  565.  
  566.  
  567. > ORBELINE - The SMART Object Request Broker
  568.  
  569. ORBeline is a complete implementation of OMG's Common Object Request
  570. Broker Architecture (CORBA).  ORBeline goes beyond the standard 
  571. specification to provide a SMART communication framework allowing
  572. you to easily develop large distributed applications that are robust,
  573. scalable, flexible and maintainable.  ORBeline incorporates PostModern's
  574. proven communication framework that links thousands of nodes.
  575.  
  576. See Appendix E:65 for a complete description and anon FTP info.
  577.  
  578.  
  579. > Orbix
  580.  
  581. Orbix
  582. Iona Technologies Ltd.
  583. 8-34 Percy Place
  584. Dublin 4
  585. Ireland
  586.  
  587. The latest release of Orbix, Version 1.2, includes an Object Loader function 
  588. for the first time, as well as an upgraded Interface Repository, a new
  589. approach to filtering, and more code examples to guide programmers. 
  590.  
  591. Orbix was launched in June 1993 as the first full and complete implementation 
  592. of the Object Management Group's (OMG's) Common Object Request Broker
  593. Architecture (CORBA) standard.  With Orbix, programmers can develop
  594. distributed, object oriented applications following a consistent and
  595. straightforward, standards-based model. 
  596.  
  597. With Orbix Version 1.2 IONA has added the ability to dynamically load objects 
  598. at runtime through its Object Loader function. This enables developers to more 
  599. easily integrate Orbix applications with existing data stores be they 
  600. traditional flat file databases, relational databases or object oriented
  601. databases. 
  602.  
  603. The improved Interface Repository is an integral part of IONA's CORBA 
  604. implementation. The Interface Repository operates as a dynamic browser which is
  605. populated with all objects or services available at runtime keeping programmers
  606. informed of the functions, attributes and characteristics of objects and 
  607. services. 
  608.  
  609. In version 1.2 IONA has also extended the whole approach to filtering of 
  610. requests, and has made it easier for users to integrate Orbix with their
  611. security systems providing for improved reliability of distributed systems
  612. built using Orbix. IONA has also extensively extended the number, and scope, of
  613. code examples it ships with the product to help developers learning how to use
  614. the system. 
  615.  
  616. IONA released Orbix for SunSoft Solaris and SunOS at the Object World 
  617. exhibition in San Francisco, Calif., June 1993.  Since then it has rolled
  618. out versions of Orbix for Microsoft Windows NT,  Silicon Graphics IRIX  and
  619. HP/UX. IONA demonstrated a version of Orbix for Microsoft Windows 3.1 at
  620. Object World in London, England last October.  Orbix for Microsoft Windows
  621. 3.1 is now in beta.  In January 1994, IONA and SunSoft Inc. signed an
  622. agreement to align their implementations of CORBA. The two companies
  623. demonstrated interoperability between IONA's Orbix running on Microsoft
  624. Windows 3.1 and SunSoft's Distributed Objects Everywhere (DOE) on Solaris.
  625.  
  626. In addition Orbix-TP, integration with Tuxedo for transaction processing, has 
  627. just entered beta testing. Work is underway on Orbix-FT, integration with
  628. the Isis distributed system, will deliver a fault-tolerant ORB.
  629.  
  630. Paul Hickey,                                        tel: +353-1-6686522
  631. Iona Technologies Ltd.,                             fax: +353-1-6686573
  632. 8-34 Percy Place,                                   email: pth@iona.ie
  633. Dublin 4
  634. Ireland
  635.  
  636. Availability
  637. ------------
  638.  
  639. The full Orbix availability and release schedule looks like:
  640.  
  641. Operating System    C++ Compiler        Release
  642.                         Date 
  643. -------------------------------------------------------
  644. SunOS 4.1             SPARCompiler 2.1    NOW
  645. SunOS 4.1             SPARCompiler 3.0.2  NOW
  646. SunOS 4.1             Lucid 3.1           NOW
  647. SunOS 4.1             GNU 2.5.8           NOW
  648. Solaris 2.x           SPARCompiler 3.0.2  NOW
  649. Solaris 2.x           SPARCompiler 4.0    NOW
  650. Solaris 2.x           GNU 2.5.7           NOW
  651. IRIX 4.0.5H           Native              NOW
  652. IRIX 5.x              Native              NOW
  653. HP-UX                 Native              NOW
  654. Microsoft Windows NT  Visual C++          NOW
  655. Microsoft Windows NT  Borland             NOW
  656. Microsoft Windows 3.1 Visual C++          In Beta
  657. IBM AIX               C Set++             4th Qtr
  658. OSF/1                 DEC C++             4th Qtr
  659. SCO                   Native              4th Qtr
  660. UnixWare              Computer Innovations 4th Qtr
  661. Ultrix                DEC C++             4th Qtr
  662.  
  663. Release of Orbix on OS/2 is also imminent.
  664.  
  665. Documents Available from IONA
  666. -----------------------------
  667.  
  668.     electronic mail server     - server@iona.ie
  669.     anonymous ftp file server  - ftp ftp.iona.ie
  670.     World Wide Web             - http://www.iona.ie/
  671.  
  672.  
  673. > NCR 'Cooperative Frameworks' -- a Distributed Object Foundation
  674.  
  675. From: Randy Volters <randy.volters@columbiasc.ncr.com>
  676. Subject: re-post: NCR Cooperative Frameworks (new phone no.)
  677.  
  678. November 19, 1993
  679.  
  680. NCR ANNOUNCES BETA AVAILABILITY
  681. OF 'Cooperative Frameworks' -- 
  682. a Distributed Object Foundation
  683.  
  684. Product Background -
  685. NCR Cooperative Frameworks(TM) were first released for sale 
  686. in 10/1991 as "the frameworks" part of the NCR COOPERATION(TM) 
  687. product, and are based on NCR's submission to OMG.  
  688. Cooperative Frameworks release 3.0 makes the product 
  689. available apart from COOPERATION. 
  690.  
  691. Product Description -
  692. Cooperative Frameworks is a distributed object foundation 
  693. for building computing applications and services on networks 
  694. of heterogeneous computers.
  695.  
  696. Cooperative Frameworks consists of an integrated suite of 
  697. C++ class libraries that:
  698.  
  699.     -    defines and implements a comprehensive enterprise 
  700.         architecture and methodology for creating 
  701.         distributed implementations of C++ classes over 
  702.         networks
  703.  
  704.     -    allows customers to build and use object services 
  705.         over a network 
  706.  
  707.     -    supports TCP/IP, NetBIOS, Lan Manager NetBEUI and 
  708.         OSI protocols, X.25
  709.  
  710. NCR Cooperative Frameworks currently has two portable ORB 
  711. toolkits (others are planned for future release) -- 
  712. (1) C++ ORB toolkit consisting of over 300 C++ classes and 
  713.     runtime libraries
  714.  
  715. (2) CORBA 1.1 toolkit  Both are for:
  716.  
  717.     -    wrapping existing databases and legacy 
  718.         applications for improved availability
  719.         and maintainability on systems of heterogeneous 
  720.         computers, operating systems and networks
  721.  
  722.     -    building next-generation, object-oriented, 
  723.         distributed computing applications for
  724.         networks of heterogeneous computers, operating 
  725.         systems and network operating systems
  726.  
  727. Cooperative Frameworks come with predefined object services 
  728. for implementing distributed systems:
  729.  
  730.     -    Naming - network implementation of X.500 directory 
  731.         provides object naming service
  732.  
  733.     -    Logging - provides local and server based error 
  734.         logging
  735.  
  736.     -    Fine-grain Data Management - class libraries are 
  737.         designed around fine grained objects, developers can 
  738.         build distributed objects as large or as small as 
  739.         needed
  740.  
  741.     -    Persistence - the same object stream model for 
  742.         communication between internal ORB functions is used to 
  743.         support object persistence.  Persistent objects can be 
  744.         files, relational or object databases
  745.  
  746.     -    Dynamic Service Location - provides a mechanism for 
  747.         registering services and entities in a distributed 
  748.         system and invoking targeted services based on service 
  749.         characteristics -- rather than names
  750.  
  751.     -    Dynamic Service Activation - provides a mechanism for 
  752.         object activation when method invocations are required, 
  753.         and deactivation when not needed
  754.  
  755.     -    Event Service (Release 3.1) - Implements an OMG/JOSS 
  756.         compliant event service
  757.  
  758.     -    Network Configuration Tools - simplifies creation of 
  759.         directory entries required for cross domain operation 
  760.         in a multiple domain heterogeneous network.
  761.  
  762. NCR Cooperative Frameworks run on multiple UNIX platforms, 
  763. including HP-UX, Sun Solaris, NCR 3000 UNIX and NCR 
  764. StarServer UNIX SVR4; and on MS Windows 3.1.  Cooperative 
  765. Frameworks has been demonstrated on Novell NetWare v3.11, 
  766. and was originally developed on MS OS/2 v1.x.  Development 
  767. environments supported include CFRONT and C++ Workbench from 
  768. NCR, HP Softbench Sun SPARCworks and Borland IDE.
  769.  
  770. Implementation - implementation is for client/server system 
  771. architectures as a set of DLL and shared libraries
  772.  
  773. Languages used for IDL mapping - IDL bindings for C, (or 
  774. object services can be implemented directly in C++)
  775.  
  776. Release date - Release 3.0 is available now to early 
  777. developers with general availability set for December, 1993; 
  778. Release 3.1 will be available to early developers 1Q 1994 
  779. with general availability set for 2Q 1994
  780.  
  781. Product interoperability - Full interoperability between NCR 
  782. Cooperative Framework implementations on supported platforms 
  783. is available now; interoperability with selected CORBA 1.1 
  784. ORBs and CORBA 2.0 ORBs is planned
  785.  
  786. Company Name -
  787. NCR Corporation (An AT&T Company)
  788.  
  789. Address --    Software Products Division-Columbia
  790.             3245 Platt Springs Road
  791.             West Columbia SC 29170
  792.  
  793.             Phone
  794.             (803) 939-7500
  795.             FAX
  796.             (803) 939-7745
  797.             Contact Name
  798.             Randy Volters, Sr. Product Manager
  799.             Cooperative Frameworks
  800.             Email: Randy.Volters@ColumbiaSC.NCR.COM
  801.             Ext. 7774
  802.  
  803. Company Description -
  804. NCR, AT&T's computer business, brings computing and 
  805. communications solutions together to provide people easy 
  806. access to information and to each other -- anytime, 
  807. anywhere.
  808.  
  809.  
  810. > SUITESOFTWARE (SuiteDOME)
  811. Overview
  812. Variety may make life more interesting, but it only complicates the
  813. task of connecting employees with the information they need. In a
  814. world of heterogeneous, distributed computer systems, it's an ongoing
  815. struggle to provide easy access to data while maintaining and
  816. updating a collection of incompatible hardware platforms, operating
  817. systems, applications, databases, network protocols, and the like.
  818. To simplify the technical challenges, reduce the time and effort
  819. required, and still be able to exploit all of an organization's
  820. on-line data, information technology (IT) managers are turning to
  821. middleware - run-time system software that is layered between an
  822. application program and the operating system and that, in a
  823. distributed, heterogeneous environment, supplies the functions that
  824. would have been provided by the application's native operating
  825. system.
  826.  
  827. To do this effectively, middleware must be able to interpret the
  828. differences between operating systems, network protocols, databases,
  829. and file systems; access and distribute data; guarantee system
  830. security; and scale up to accommodate even the largest systems. When
  831. middleware achieves this, it makes enterprise computing a reality.
  832. As a result, middleware is quickly emerging as the best solution for
  833. overcoming system incompatibilities, and middleware such as
  834. SUITESOFTWARE's Distributed Object Management Environment (DOME)
  835. Software System makes it possible for organizations to build large
  836. scale, heterogeneous, distributed systems that can run virtually any
  837. application in the enterprise, accessing virtually any data.
  838. DOME - Covering the Enterprise
  839. The DOME Software System is comprehensive middleware that provides
  840. all of the essential services necessary to unify distributed
  841. applications and data into a single system. With DOME, companies can
  842. develop applications on any platform they choose and then easily
  843. distribute them across heterogeneous environments throughout the
  844. enterprise.
  845.  
  846. The DOME system can accomplish this complex task because it offers:
  847.         - an open system
  848.         - standards compliance
  849.         - object-oriented architecture
  850.         - support for heterogeneous environments
  851.         - and support for Remote Data Access (RDA), Remote Procedure
  852. Calls (RPC), Message-Oriented Middleware (MOM), and Object Request
  853. Broker (ORB).
  854. o       Open System
  855. DOME is an open system that provides an interface between all of a
  856. customer's applications, making it possible to share information
  857. between new and legacy applications. DOME provides a solution today
  858. and its open platform structure accommodates future technologies.
  859. o       Standards Compliant
  860. DOME is compliant with the following standards:
  861. - OMG/CORBA
  862. - SAG
  863. - MOMA
  864. - ISO
  865. - OLE Microsoft
  866. - CCITT X.500
  867. - Kerberos 5.4 (Security)
  868. DOME allows message transfer from one object to another object,
  869. provides the ability to find an object, register an object, register
  870. the message interface to an object, and dynamically invoke an object.
  871. DOME also provides object services beyond the Object Request Broker
  872. (ORB) and contains a directory and name service that provides more
  873. functionality than specified by the X.500 standard. Because DOME goes
  874. beyond what many of the standards require, it makes the task of
  875. creating distributed applications, especially in very large
  876. distributed environments, even easier.
  877. SUITESOFTWARE is a member of various standards groups and conforms
  878. its products to industry standards as they are adopted.
  879. o       Object-Oriented Architecture
  880. Because DOME's architecture is object-oriented, there are significant
  881. benefits.
  882. -       True messaging for workflow management and EDI
  883. -       Queue- and bus-based (rather than send-based) design provides
  884. store-and-forward, broadcasting, and subscribing functionality
  885. -       Full recovery capabilities
  886. -       Different levels of messaging service for positive/negative
  887. acknowledgment and start-on-demand
  888. -       Hierarchical namespace with true domains for complete
  889. scalability
  890. -       Concern registration and event notification
  891. -       Logical name translation for true aliasing
  892. -       Kerberos 5.4 compatible security/authentication and access
  893. control
  894. -       Implementation of additional protocols through a
  895. communications layer
  896. -       Co-existence of multiple development and/or production
  897. environments on a single node
  898. -       Platform independent time services and exception handling
  899. These beneficial functions have resulted in measurable time and labor
  900. savings while freeing systems personnel to concentrate on critical
  901. issues.
  902. o       Support for Heterogeneous Environments
  903. DOME runs on the major UNIX platforms as well as in other interactive
  904. computing environments, such as OS/2 and Windows.
  905. DOME Software System Components
  906. The DOME software system is composed of the core DOME product, DOME
  907. SecurityTM, DOMEshellTM scripting and prototyping language, and the
  908. DOME Data Manager (DDMTM) database access manager.
  909.  
  910. [...]
  911.  
  912. The DOME Data Manager is a complete relational DBMS engine that
  913. provides access to distributed data.
  914. Features
  915. DDM provides autonomy for distributed data sites, but it also
  916. supplies the means for consolidating data for specific applications.
  917. It can read and write data across numerous DBMSs, and it makes
  918. distributed data management transparent, so that the user never needs
  919. to know the physical location of data, the server of access, or the
  920. underlying vendor in order to process requests. From the user's
  921. perspective, the enterprise is a single logical database located in
  922. its entirety on the local machine. This is possible because DDM maps
  923. the application's logical view of the environment into the
  924. enterprise's physical environment of multiple nodes, disparate
  925. operating systems, and multiple DBMSs.
  926. DDM can manipulate data across a large number of databases and data
  927. locations, and it is also interoperable. By conforming to the SQL
  928. Access Group's Call Level Interface standard, DDM can interoperate
  929. with any number of third-party GUI and CASE tools. Among the GUIs are
  930. Powerbuilder,, Visual Basic,, and Uniface,. Among the CASE tools are
  931. ERwin,, Popkin,, and Knowledgeware,.
  932.  
  933. ? 1995 SUITESOFTWARE
  934. DOME, DOMEshell, DOME Security, DOME Data Manager, and DDM are
  935. trademarks of SUITESOFTWARE. All other products and product names are
  936. copyrighted by, trademarks of, or registered trademarks of their
  937. respective owners.
  938. Support and Deliverables
  939. Customer Support
  940. SUITESOFTWARE places particular emphasis on support and continuing
  941. education. The broad technical and business systems background of our
  942. staff of fully trained professionals ensures "real world" responses
  943. to problems. SUITESOFTWARE `s support staff is available by
  944. telephone, FAX, and e-mail to help customers maximize the use of the
  945. DOME Software System and obtain quick resolutions to problems.
  946. Deliverables
  947. Optical or magnetic media containing all files required to load and
  948. execute DOME plus PostScriptTM versions of DOME documentation.
  949. Hardcopy versions of all DOME documentation are available for a
  950. nominal additional cost.
  951. Configuration Requirements
  952. Disk space and memory requirements are dependent on the installation
  953. platform. SUITESOFTWARE sales representatives are available to help
  954. determine configuration requirements for particular computer systems.
  955.  
  956. SUITESOFTWARE
  957. 801 East Katella Ave., Suite 210,
  958.  
  959. Anaheim, CA 92805
  960. Telephone: (714) 938-8850
  961.  
  962. FAX: (714) 978-1840
  963. E-mail: customer_support@suite.com
  964.  
  965.  
  966.  
  967. 3.8.7  Books, Articles, And Literature
  968. --------------------------------------
  969.  
  970. This section is expected to grow considerably in the future.
  971.  
  972. "Distributed Object Computing With CORBA", C++ Report, July/August 1993
  973.  
  974. The Object Database Standard: ODMG-93
  975. edited by: R.G.G. Cattell
  976. published by Morgan Kaufmann Publishers, San Mateo, California
  977. [Covers CORBA standards with respect to OODBs]
  978.  
  979.  
  980. 3.9)  Why is Garbage Collection A Good Thing?
  981. -------------------------------------------------------------------------
  982.  
  983. There are two entries on garbage collection, the first is an excellent entry
  984. written for the FAQ by Paul Johnson and the second is from the FAQ author's
  985. company on the necessity of garbage collection for object-oriented programming
  986. and technique.
  987.  
  988.   From: Paul Johnson (paj@gec-mrc.co.uk)
  989.  
  990. Garbage collection (GC) is a facility in the run-time system associated with a
  991. language which will automatically reclaim objects which are no longer used.
  992. OO Languages which require garbage collection include Eiffel, Smalltalk and
  993. CLOS.  C and C++ can have garbage collection retrofitted (see [3] and [4]
  994. below).  [Ada has switchable GC, too -bob]
  995.  
  996. Without GC programmers must explicitly deallocate dynamic storage when
  997. it is no longer needed (in C this is done by a call to free(3)).
  998. There are a number of problems with this:
  999.  
  1000. 1: Bugs due to errors in storage deallocation are very hard to find,
  1001.    although products are available which can help.
  1002.  
  1003. 2: In some circumstances the decision about whether to deallocate
  1004.    storage cannot be made by the programmer.  Drawing editors and
  1005.    interpreters often suffer from this.  The usual result is that the
  1006.    programmer has to write an application-specific garbage collector.
  1007.  
  1008. 3: An object which is responsible for deallocating storage must be
  1009.    certain that no other object still needs that storage.  Thus many
  1010.    modules must co-operate closely.  This leads to a tight binding
  1011.    between supposedly independent modules.
  1012.  
  1013. 4: Libraries with different deallocation strategies are often
  1014.    incompatible, hindering reuse.
  1015.  
  1016. 5: In order to avoid problems 3 and 4, programmers may end up copying
  1017.    and comparing whole objects rather than just references.  This is a
  1018.    particular problem with temporary values produced by C++ overloaded
  1019.    operators.
  1020.  
  1021. 6: Because keeping track of storage is extra work, programmers often
  1022.    resort to statically allocated arrays.  This in turn leads to
  1023.    arbitrary restrictions on input data which can cause failure when
  1024.    the assumptions behind the chosen limits no longer apply.  For
  1025.    instance many C compilers limit expression nesting, identifier
  1026.    length, include file nesting and macro stack depth.  This causes
  1027.    problems for programs that generate C.
  1028.  
  1029. One partial solution to a lack of GC is reference counting.  In this
  1030. scheme each object keeps a count of references to it.  When this count
  1031. drops to zero the object is automatically deallocated.  However this
  1032. is inefficient (swapping two references will result in three
  1033. decrements, three increments and six comparisons) and cannot reclaim
  1034. circular data structures.  Two systems that use a reference count GC
  1035. are the Interviews C++ graphics library and the Unix file system (the
  1036. link count).
  1037.  
  1038. Opponents of GC reply that it introduces an overhead which is
  1039. unacceptable in some applications.  However the overhead of manual
  1040. storage deallocation is probably as high as GC.  GC algorithms are
  1041. also available with good real-time behaviour.
  1042.  
  1043. [Further, GC can perform compaction improving locality of reference.]
  1044.  
  1045. Further Reading:
  1046.  
  1047. [1] "Object-Oriented Software Construction" by Meyer puts the argument
  1048. for GC.
  1049.  
  1050. [2] "Uniprocessor Garbage Collection Techniques," by Paul R. Wilson,
  1051. in Memory Management (proceedings of 1992 Int'l Workshop on Memory 
  1052. Management, Sept. 1992, St. Malo, France, Yves Bekkers and Jacques Cohen, 
  1053. eds.), Springer Verlag Lecture Notes in Computer Science #637.
  1054.  
  1055. This is an excellent summary of the state of the art in GC algorithms.  This
  1056. and other papers about garbage collection are available in PostScript via
  1057. anonymous ftp (cs.utexas.edu:pub/garbage/gcsurvey.ps.  [See APPENDIX E]
  1058.  
  1059. [3] "Garbage Collection in an Uncooperative Environment" by Boehm and
  1060. Weiser.  Software --- Practise and Experience vol 18(9), pp 807-820.
  1061. Sept 1988.  This describes GC in C and C++.
  1062. ftp://parcftp.xerox.com/pub/gc/gc.html
  1063.  
  1064. [4] Geodesic Systems provides GC for C and C++.  See http://www.geodesic.com
  1065.   and Appendix G.
  1066.  
  1067.  
  1068. 3.9b) Why is Garbage Collection Necessary for Object-Oriented Programming?
  1069. --------------------------------------------------------------------------
  1070.               Michael Spertus 
  1071.               Geodesic Systems
  1072.               mps@geodesic.com
  1073.  
  1074. There are several reasons why true object-oriented programming requires garbage
  1075. collection. 
  1076.  
  1077. 1. Manual Memory Management Breaks Encapsulation.
  1078.  
  1079.   Program components frequently need knowledge of an entire program to
  1080.   determine the last use of an object and provide deletion.  This makes reuse
  1081.   of the component nearly impossible. For example, methods and functions
  1082.   taking a container as an argument need to know of or make assumptions 
  1083.   about the rest of the program to determine ownership of the objects in the 
  1084.   container.
  1085.  
  1086.   Attempts to encapsulate memory management with reference counting, the "poor 
  1087.   man's garbage collector", are usually misguided. Reference counting has worse
  1088.   performance than GC, awkward syntax, and poor semantics, which typically 
  1089.   include failure to reclaim cycles, inability to handle stack and static 
  1090.   objects, lack of polymorphism, and problems with interior pointers (e.g. 
  1091.   arrays and multiple inheritance). Intensive research [1] in garbage
  1092.   collection has completely solved the above problems and made reference
  1093.   counting an inadequate substitute for true GC.
  1094.  
  1095. 2. Implementation Hiding is not Compatible with Manual Memory Management
  1096.  
  1097.   Implementation hiding is a pillar of object-oriented programming,
  1098.   but explicit memory management requires implementation-dependent
  1099.   low-level knowledge of how memory is structured. For example, programmers
  1100.   often use "copy on write" to efficiently implement pass-by-value semantics.
  1101.   However, to manage memory explicitly, a program has to know if it has a copy
  1102.   of an object or the object itself. Programmers sometimes use reference 
  1103.   counting to encapsulate copy-on-write memory management. However, this only
  1104.   works well in simple cases like strings where the data is not polymorphic
  1105.   and does not contain pointers.
  1106.  
  1107. 3. Message Passing Leads to Dynamic Execution Paths
  1108.  
  1109.    Manual memory management must make assumptions about a program's order of
  1110.    execution to make a compile-time determination of the last user of an
  1111.    object. While this is often possible in procedural languages, the object-
  1112.    oriented paradigm of objects sending messages to each other (possibly from
  1113.    different threads) makes it impossible to statically determine the last user
  1114.    of an object. For example, event driven GUI programs frequently have no
  1115.    clear order of execution. Other dynamic control structures, such as
  1116.    exceptions, also make static analysis of memory usage at compile-time
  1117.    impossible.
  1118.  
  1119. 4. Differing Memory Management Schemes Hinder Reuse
  1120.  
  1121.   Because no memory management scheme is universal enough for all applications,
  1122.   manually managed components and libraries often use incompatible memory
  1123.   management schemes. For example, there are common container libraries using 
  1124.   each of the following schemes:
  1125.  
  1126.   a) Doubly specified empty and remove methods with one including a memory
  1127.      delete, placing the memory management burden on the client, who must call
  1128.      the appropriate method.
  1129.      
  1130.   b) Switches indicating deletion. Many applications must clear the switch to
  1131.      support long-lived data and keep track of ownership of data shared by
  1132.      multiple containers, leaving many memory management issues unaddressed.
  1133.  
  1134.   c) Value semantics store objects rather than references, inhibiting data
  1135.      sharing and carrying expensive performance costs when complex objects are
  1136.      copied by value.
  1137.  
  1138.   d) Reference counting, which was already discussed.
  1139.      
  1140.   Any components or libraries that use containers with different memory 
  1141.   management strategies are difficult to use with each other.
  1142.  
  1143.  
  1144. 5. Garbage Collection Works
  1145.  
  1146.   It is not enough to merely find fault with manual memory management. One also 
  1147.   has to show that garbage collection provides a better alternative. Early 
  1148.   versions of garbage collection were merely crude implementations of 
  1149.   mark-and-sweep that left much to be desired. However, garbage collection has 
  1150.   advanced as rapidly as most computer-related technologies and is now a robust, 
  1151.   mature technology.[1] Many object-oriented languages specify garbage
  1152.   collection for all or part of their memory. Even C and C++ have at least one
  1153.   commercially supported garbage collector that can transparently and
  1154.   compatibly manage both new and existing programs. [2] 
  1155.  
  1156.   Garbage collected programs are usually as fast and responsive as
  1157.   their manually managed brethren. [3] In fact, multi-media programmers
  1158.   sometimes choose treadmill collectors [4] over hand-management because of its
  1159.   superior real-time performance as manual management usually has difficulty
  1160.   scheduling destructor calls smoothly. Of course, garbage collected programs
  1161.   are generally more reliable and easier to develop, maintain, and reuse than
  1162.   manually managed programs. Finally, garbage collection can be mixed with
  1163.   manual management to provide the programmer with the broadest set of tools,
  1164.   and garbage collection is much too important a tool to be absent from any
  1165.   object-oriented programmer's toolbox.
  1166.  
  1167. References
  1168. [1] Paul R. Wilson, "Uniprocessor Garbage Collection Techniques", 1992
  1169.   International Workshop on Memory Management, Springer-Verlag Lecture Notes in
  1170.   Computer Science series.
  1171.  
  1172. [2] Geodesic Systems, Great Circle(TM) Automatic Memory Management System.
  1173.   http://www.geodesic.com/GreatCircle/index.html.
  1174.  
  1175. [3] Detlefs, Dosser, and Zorn, "Memory Allocation Costs in Large C and C++
  1176.   Programs".  ftp://cs.colorado.edu/pub/techreports/zorn/CU-CS-665-93-ps.Z.
  1177.  
  1178. [4] Henry Baker, "The Treadmill: Real-Time Garbage Collection without Motion
  1179.   Sickness".  ftp://ftp.netcom.com/pub/hb/hbaker/NoMotionGC.html
  1180.  
  1181.  
  1182. 3.10)  What Can I Do To Teach OO To The Kids?
  1183. ---------------------------------------------
  1184.  
  1185. Smalltalk (in its original 1972 version) was initially intended to make
  1186. computer programming easy enough for children.  The idea was that manipulating
  1187. objects was something more intuitive and natural than coding procedures.
  1188.  
  1189. Other entries or suggestions are welcome, please send to the author of the FAQ.
  1190.  
  1191.  
  1192. 3.11) What Is Available On Object-Oriented Testing?
  1193. ---------------------------------------------------
  1194.  
  1195. [This entry was donated by Doug Shaker and is certainly a FAQ]
  1196.  
  1197. Testing of Object-Oriented Programming (TOOP) FAQ/Resource Summary
  1198.  
  1199. Posted to comp.object, comp.lang.c++, comp.lang.smalltalk and
  1200. comp.software.testing.
  1201.  
  1202. Last revised on 93.10.27.  The most notable change is in the additions
  1203. to the Software section.  Also a couple of articles added to the
  1204. Written Material section.
  1205.  
  1206.  
  1207. > What?
  1208.