home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / object-faq / part5 < prev    next >
Encoding:
Text File  |  1995-07-25  |  58.7 KB  |  1,575 lines

  1. Subject: Comp.Object FAQ Version 1.0.7 (10-27) Part 5/10
  2. Newsgroups: comp.object,comp.answers,news.answers
  3. From: Bob Hathaway <rjh@geodesic.com>
  4. Date: 29 Oct 1994 11:42:21 GMT
  5.  
  6. Archive-name: object-faq/part5
  7. Last-Modified: 10/27/94
  8. Version: 1.0.7
  9.  
  10. o  Visual Program Designer -- The Visual Program Designer allows developers
  11.    to visually create and modify the behavior of an application without
  12.    having to write code. Programs are created by connecting visual program
  13.    blocks to field blocks drawn from the forms created in the Forms
  14.    Designer. A large collection of predefined program blocks is provided
  15.    with GeODE, and users can extend the catalog in any of a number of
  16.    simple ways. Code-based programming can be integrated routinely.
  17.  
  18. o  Developer Class Library - GeODE comes standard with more than 480
  19.    classes and thousands of methods, and is easily extended for handling
  20.    specialized applications. In a team environment, some programmers can
  21.    develop visual applications while others write new methods that are
  22.    encapsulated into visual program blocks for easy reuse.
  23.  
  24. o  Developer Tools -- GeODE includes tools for debugging, browsing and
  25.    inspecting applications. Included in this set of tools are several
  26.    debuggers, browsers, inspectors, an object clipboard, an image editor,
  27.    and a code profiler for performance analysis.
  28.  
  29.  
  30.  ==============================================================================
  31.  
  32. PLATFORMS
  33.  
  34. GemStone release 3.2 and GeODE 2.0 and all language interfaces are
  35. available for UNIX workstations and servers from SUN, HP, IBM, Sequent, and
  36. DEC. Client-only support is available in a number of languages for Windows
  37. 3.1, OS/2 and Macintosh. Servio is an active member in the Object
  38. Management Group and the ANSI Smalltalk standardization committee. Servio
  39. supports SUN ODMG, ANSI C++ and intends to comply fully with the emerging
  40. standards.
  41.  
  42.  ==============================================================================
  43.  
  44. REFERENCES
  45.  
  46.   [Maier, et al. 84] D. Maier, J. Stein, A. Otis, A. Purdy, ``Development
  47.   of an object-oriented DBMS'' Report CS/E-86-005, Oregon Graduate Center,
  48.   April 86 - ACM 0-89791-204-7/86/0900-0472
  49.  
  50.   R.G.G. Cattell: Object Data Management - Object-Oriented and Extended
  51.   Relational Database Systems; Addison-Wesley. ISBN 0-201-53092-9
  52.  
  53.   Robert Bretl, David Maier, Allen Otis, Jason Penney, Bruce Schuchardt,
  54.   Jacob Stein, E. Harold Williams, Monty Williams. "The GemStone Data
  55.   Management System." Chapter 12 of "Object-Oriented Concepts, Databases
  56.   and Applications", by Kim and Lochovsky.
  57.  
  58.  
  59.  ==============================================================================
  60.  
  61. CONTACTS
  62.  
  63.  === Headquarters - San Jose ====
  64.  
  65. Servio Corporation
  66. 2085 Hamilton Avenue
  67. Suite 200
  68. San Jose  CA  95125
  69.  
  70. Tel: 800-243-9369
  71. Tel: 408-879-6200
  72. Fax: 408-369-0422
  73.  
  74.  === Chicago ====
  75.  
  76. Servio Corporation
  77. 8410 Bryn Mawr
  78. Suite 400
  79. Chicago  IL  60631
  80.  
  81. Tel: 312-380-1310
  82. Fax: 312-380-1308
  83.  
  84.  ===  New York ====
  85.  
  86. Servio Corporation
  87. 1120 Avenue of the Americas
  88. 4th Floor
  89. New York  NY  10036
  90.  
  91. Tel: 212-626-6680
  92. Fax: 212-626-6684
  93.  
  94.  === Dallas ====
  95.  
  96. Servio Corporation
  97. 14875 Preston Road
  98. Suite 550
  99. Dallas  TX  75240
  100.  
  101. Tel: 214-980-7073
  102. Fax: 214-980-2949
  103.  
  104.  === Europe/UK ====
  105.  
  106. Servio UK
  107. Criterion House
  108. Beauchamp Court, Victors Way
  109. Barnet  EN5 5TZ  England
  110.  
  111. Tel: +44 81 447-0800
  112. Fax: +44 81 447-0577
  113.  
  114.  === Japan ====
  115.  
  116. Servio Corporation
  117. Daito-Eiwa Building, 7F
  118. 5-11 Nihonbashi-Hakozakicho
  119. Chuo-ku  Tokyo 103  Japan
  120.  
  121. Tel: +81 3 3660-1910
  122. Fax: +81 3 3663-3287
  123.  
  124.  =====================
  125.  === Distributors ====
  126.  =====================
  127.  
  128.  === Germany, Austria, Switzerland ====
  129.  
  130. ObjectOriented System Technologies
  131. Baroper Str. 337
  132. Dortmund  50  W-4600
  133. Germany
  134.  
  135. Tel: +49 231 975 990
  136. Fax: +49 231 975 99-20
  137.  
  138.  === Japan ====
  139.  
  140. Japan Information Processing Service Co., Ltd.
  141. 2-4-2 Toyo , Koto-ku
  142. Tokyo, 135, JAPAN
  143.  
  144. Tel: +81 3 5690 3268
  145. Fax: +81 3 5690 3390
  146.  
  147. --------------------
  148.  
  149. Nexus Technology K.K.
  150. Suite 901
  151. Botan 3-11-1
  152. Koto-ku  Tokyo 135  Japan
  153.  
  154. Tel: +81 3 3660-1910
  155. Fax: +81 3 3663-3287
  156.  
  157.  === Taiwan ====
  158.  
  159. Anco Technologies
  160. 11-1F, 76 Tun Hwa S. Road, Sec. 2
  161. Taipei
  162. Taiwan, R.O.C.
  163.  
  164.  === Italy ====
  165.  
  166. Etnoteam S.P.A.
  167. Via Adelaide Bono Cairoli 34
  168. Milano  20127  Italy
  169.  
  170. Tel: +39 2 261 621
  171. Fax: +39 2 261 10755
  172.  
  173.  === England ====
  174.  
  175. AI International Ltd.
  176. 1 Parkview Road
  177. Berkhamsted
  178. Herts  HP4 2EY  England
  179.  
  180. Tel: +44 442 876 722
  181. Fax: +44 442 877 997
  182.  
  183.  ==== Mexico ====
  184.  
  185. TEIX, Sistemas de Informacion
  186. Estrategica S.A. de C.V.
  187. Antonio M. Anza No. 43
  188. Col Roma  Mexico D.F.  06700
  189.  
  190. Tel: +52 5 564-7146
  191.  
  192.  
  193. > ITASCA
  194.                        ITASCA ODBMS V2.2
  195.  
  196.                       Itasca Systems, Inc.
  197.                        7850 Metro Parkway
  198.                       Minneapolis, MN 55425
  199.                         sales@itasca.com
  200.                          (612) 851-3155
  201.  
  202.                           Sandy Miezwa
  203.                          (612) 851-3169
  204.  
  205. Introduction
  206.  
  207. Itasca Systems develops, markets, and supports ITASCA, a distributed 
  208. active object database management system and related tools. The initial 
  209. research work for ITASCA occurred in the Object-Oriented and Distributed 
  210. Systems Lab at the Microelectronics and Computer Technology 
  211. Corporation (MCC) in Austin, Texas. The research was known as the 
  212. ORION prototypes. 
  213.  
  214. The ITASCA Distributed ODBMS is a language neutral, full-featured, active 
  215. object database that supports data access from various object
  216. languages. ITASCA allows clients to transparently access data that is
  217. distributed among multiple servers.  ITASCA supports full dynamic schema
  218. modification that can be performed during any phase of the software
  219. lifecycle.  Applications written in dissimilar and incompatible languages,
  220. such as C++ and CLOS, share objects through ITASCA. ITASCA stores methods
  221. inside the database, promoting reusability and maintainability.  The only
  222. commercial ODBMS based upon the MCC Orion technology, ITASCA is considered
  223. by many to be the most feature-rich ODBMS on the market today.
  224.  
  225. This overview describes release 2.2 of the ITASCA Distributed Object 
  226. Database Management System. It describes how ITASCA functions, 
  227. outlines its implementation features, and explains some of the system 
  228. benefits. 
  229.  
  230.  
  231. History of ITASCA
  232.  
  233. ITASCA is based on a series of object database research prototypes. Work 
  234. on these prototypes began in 1985 at the Microelectronics and Computer 
  235. Technology Corporation (MCC) Object-Oriented and Distributed Systems 
  236. Laboratory. MCC released the first prototype, ORION-1, in May, 1987, as 
  237. a single-user system. MCC extended ORION-1 to the ORION-1SX 
  238. prototype system and released it to the shareholder companies in April, 
  239. 1988. ORION-1SX was a multi-user system with a multi-client, single 
  240. server architecture. The third prototype, ORION-2, introduced a distributed, 
  241. object-oriented architecture for a multi-user environment. MCC released 
  242. the third prototype to shareholder companies in July, 1989. ORION-2 has a 
  243. multi-client, multi-server architecture. Having met its objectives, MCC 
  244. stopped all work on ORION at that time. Over five million dollars was spent
  245. for the three generations of prototypes.
  246.  
  247. The ITASCA product is an extension and commercialization of the ORION-2
  248. prototype from MCC. Itasca Systems has added major enhancements and
  249. features, improved the performance, and strengthened the code. It now runs
  250. on UNIX systems from multiple vendors. ITASCA is an industrial-strength,
  251. documented product, fully supported by Itasca Systems, Inc. Itasca Systems
  252. continues to develop tools and other products to work with ITASCA.
  253.  
  254.  
  255. Overview
  256.  
  257. ITASCA employs a distributed architecture with private and shared objects 
  258. spread across UNIX-based computers on a local-area network. The 
  259. ITASCA model follows the object-oriented view that uniformly models any 
  260. real-world entity as an object. Each object has a unique identifier along with 
  261. a state and behavior. Attributes represent the state of an object. Methods 
  262. (code) define the behavior of an object. A class object collects objects that 
  263. share the same set of attributes and methods. Subclasses derive from 
  264. existing classes. The resulting schema, or database definition, is a class 
  265. hierarchy. Each subclass inherits all the attributes and methods of its 
  266. superclasses. ITASCA supports multiple inheritance. A subclass may derive 
  267. from more than one superclass. 
  268.  
  269. One of the breakthroughs of object-oriented technology is the reusability of 
  270. code. ITASCA allows for the active management of both reusable code and 
  271. data in an integrated system. Developers may write applications in C++,
  272. CLOS, C or Common Lisp. This means ITASCA is language neutral. Objects 
  273. stored using one programming language can be accessed by other 
  274. programming languages. It also means an application program need not be
  275. written in an object-oriented language. 
  276.  
  277. The ITASCA database management system has features belonging to most any 
  278. database system. This includes persistent storage for data and schema, 
  279. concurrency control and locking, transaction management, multiple 
  280. security levels, and logging and recovery for both CPU and disk media 
  281. failure. Additional features of ITASCA include dynamic schema 
  282. modification, long-duration transactions, shared and private databases, 
  283. distributed version control, distributed transaction management, distributed 
  284. query management, distributed change notification, object migration, and 
  285. an extensible architecture.
  286.  
  287. Shared and private databases exist in a distributed environment in ITASCA. 
  288. The shared database is distributed across workstations (sites) in a network. 
  289. An ITASCA server controls the partition of the shared database at each site. 
  290. ITASCA clients provide transparent access to the various partitions of the 
  291. shared database. The architecture allows any number of private databases at 
  292. each distributed database site. Data can move between private and shared 
  293. databases. Private databases allow private data that is not shared with other 
  294. users of the database.
  295.  
  296. ITASCA stores the schema redundantly at each site to improve 
  297. performance. The schema storage also includes code in the form of 
  298. methods. Management of schema updates is automatic for all sites. This 
  299. includes sites that were off-line during any changes. Automatic distribution 
  300. of schema changes, including method code changes, simplifies database 
  301. administration.
  302.  
  303. ITASCA stores each instance of data in one site. The system or a user may 
  304. move the data from one site to another to improve data locality. Access to 
  305. moved data remains transparent. There is no need for a user or application 
  306. to know the specificlocation of data in the ITASCA distributed database. 
  307. ITASCA will automatically find the location of the data. This simplifies 
  308. distributed application development. The developer can rely on ITASCA 
  309. finding data in the distributed database.
  310.  
  311. No single site acts as a master site, thus ITASCA's architecture has no 
  312. single point of failure. ITASCA has neither a central data server nor a 
  313. central name server. This is important for maintaining a database system 
  314. with high availability in a networked workstation environment.
  315.  
  316. ITASCA supports dynamic schema modification to create a flexible 
  317. environment for changing or customizing a database system. Authorized 
  318. users can add and remove attributes or change the subclass/superclass 
  319. relationship at any time. Authorized users can also add or remove partitions 
  320. of the shared database at any time. All this can be done interactively without 
  321. affecting other parts of the ITASCA database at the time changes occur to 
  322. the schema. There is no need to "bring the system down" or off-load/reload 
  323. data to restructure the database. Dynamic schema modification can 
  324. significantly reduce maintenance costs. It also is useful in environments 
  325. where change to data definitions are normal or relatively frequent.
  326.  
  327. ITASCA has a sophisticated security authorization technique tied to the 
  328. class hierarchy. It supports both positive and negative authorizations at any 
  329. level in the class hierarchy. For example, granting access to all objects but 
  330. one requires only two authorizations: a global grant followed by a specific 
  331. denial. Authorization extends to classes, instances of classes, attributes, 
  332. and methods. Also, inheritance of authorization reduces the work of database 
  333. administration. 
  334.  
  335. Long-duration transactions allow users to check objects out of the shared, 
  336. distributed database into their private databases. Users can then change the 
  337. objects in the private databases without affecting the shared database or 
  338. other users. These changes can be committed to the private database. Then, 
  339. at any later time, the user can check the updated object or objects back into 
  340. the shared database.
  341.  
  342. ITASCA supports version control of objects. A new version of an object 
  343. promotes the original or parent object to restrict further changes to the 
  344. parent. ITASCA also supports alternate versions such that multiple versions 
  345. can have the same parent. Promoting an object version to a released status 
  346. restricts any deletion of the object. ITASCA uses generic versions to 
  347. dynamically reference the most recent or default version of an object 
  348. without any intervention by a user or application.
  349.  
  350. Change notification in ITASCA is either flag-based or message-based. 
  351. Flag-based notification will identify an updated object upon querying the 
  352. object for such information. It is a passive notification scheme. Message-
  353. based notification, on the other hand, is an active notification scheme. It 
  354. will execute a method (or code) upon an update or other change to an object. 
  355. Such methods can send mail messages or invoke other methods or 
  356. programs. 
  357.  
  358. Memory management in ITASCA uses both page and object buffers. 
  359. ITASCA has a traditional database page buffer scheme that contains pages 
  360. with multiple objects. Desired objects move from the page buffer to an 
  361. object buffer. The object buffer then provides ITASCA with enhanced in-
  362. memory performance because it contains only frequently-referenced 
  363. objects. 
  364.  
  365.  
  366. > Matisse
  367.  
  368. OODBMS FEATURES LIST:
  369.  
  370. An Industrial Strength Open Semantic Object Database
  371.  
  372. Performance
  373. -       Symmetric, Fine Grain, Multi-Threaded Architecture
  374. -       Parallel and Asynchronous Disk I/O
  375. -       Automatic Disk Optimization through Dynamic Clustering
  376. -       High Speed OLTP Environment
  377. Reliability
  378. -       24 Hour - Mission Critical Operation
  379. -       Media Fault Tolerant (Object Replication)
  380. -       Transparent On-line Recovery
  381. Database Administration
  382. -       Full On-line Administration (No Down Time)
  383. -       On-line Incremental or Full Back-Up
  384. -       Dynamically Increase Database Size -   On-line
  385. -       Full On-line Monitoring
  386. Data Management and Consistency
  387. -       Dynamic Schema Evolution
  388. -       Consistent Database Reads without Locking
  389. -       Historical Versioning, both Schema and Data Objects
  390. -       Built-in Enforced Referential Integrity
  391. -       Object Level Implicit or Explicit Locking
  392. Scalability
  393. -       Hundreds of Concurrent On-line Users
  394. -       Hundreds of Gigabytes Per Database
  395. -       From Few Bytes to Four Gigabytes for Each Object
  396. -       Up to Four Giga-objects Per Database
  397. Object Model
  398. -       Full Object Oriented Model
  399. -       User Extensible Object Meta-Schema
  400. -       Support for Complex, Highly Dynamic, Variable Sized Objects
  401. -       Multiple Inheritance
  402. Intelligent Objects
  403. -       Triggers at Object, Attribute, or at Relationship Level
  404. -       Consistency Rules at Object, Attribute, or at Relationship Level
  405. -       Customizable Intelligent Object Indexing
  406. -       Automatic Inverse Relationships
  407. Open Systems
  408. -       Open C, C++ API
  409. -       Supports Any Commercial Development Tool and Language
  410. -       No Proprietary Tool Required
  411. -       Heterogeneous Cross Platform Client/Server Architecture
  412.  
  413. For Information on MATISSE, Contact one of the following offices:
  414.  
  415. USA:
  416. ODB, an Intellitic International Company
  417. 238 Broadway
  418. Cambridge, MA  02139
  419. Phone:(617) 354-4220
  420. Fax: (617) 547-5420
  421. email:  info@odb.com
  422.  
  423. EUROPE:
  424. INTELLITIC INTERNATIONAL
  425. 12-14 rue du Fort de Saint-Cyr
  426. Montigny-le-Bretonneux
  427. 78182 Saint Quentin en Yvelines Cedex France
  428. Phone:   33(1) 30.14.54.30
  429. Fax:    33 (1) 30.14.54.40
  430.  
  431. JAPAN:
  432. SGN CO. LTD.
  433. Urban Toranomon Building
  434. 16-4 Toranomon
  435. Minato-Ku Tokyo 105 Japan
  436. Phone:   81 (3) 3593.34.31
  437. Fax:   81 (3) 3593.34.32
  438.  
  439.  
  440. > NeoAccess
  441.  
  442. A cross-platform object-oriented database engine based on C++. It allows
  443. developers to embed the power of a fully-functional object-oriented database
  444. system into their applications. All of the data contained in the database,
  445. including indices, can be in a single file, so users can treat a database
  446. file as they would a standard document file. The programming model is
  447. designed to keep visible complexity to a minimum while providing a
  448. feature-rich foundation on which to build and enhance applications.
  449.  
  450. NeoAccess has taken a different approach toward the issues surrounding object
  451. persistence than have other solutions that have been offered. We believe that
  452. objects should be viewed as having a set of properties with a pliable state.
  453. With NeoAccess persistent objects are provided with persistence and sharing
  454. properties. These properties allow objects to maintain an association with a
  455. file. This association, which can be built and broken freely, allowing
  456. objects to migrate freely between disk and memory. The API to these
  457. properties address issues such as adding or deleting the object from a file,
  458. sorting and indexing, locating and later freeing the object in memory, object
  459. sharing, and maintaining relationships between objects.
  460.  
  461. NeoAcces
  462. s with has been fully integrated into standard application frameworks such as
  463. Borland's ObjectWindows and MacApp 3.0 and the THINK Class Library on the
  464. Macintosh. A single source tree can be used to build the engine in all
  465. development environments. Database files are binary-compatible across
  466. platforms so users on different types of machines can share data without
  467. conversion.
  468.  
  469. Contact:
  470. Bob Krause
  471. NeoLogic Systems
  472. 1373 Third Avenue
  473. San Francisco, CA 94122
  474. (415) 566-9207
  475.  
  476.  
  477. > O2 (INRIA/O2 Technology)
  478.  
  479. This is an entry on schema evolution.  General papers on O2 are included.
  480.  
  481. We have implemented in O2 schema updates in our first release but
  482. without NO IMPACT on the database (we have a design to implement
  483. deferred update, but it is a paper design). However, users manage to
  484. convert their instances by hand, using their O2 programs written
  485. themselves, and with the aid of the following tools:
  486.  
  487. 1- There is a set of predefined classes whose instances contain
  488.    objects representing a schema (i.e., a Meta-schema). These classes
  489.    may be used in a conversion program, they may even be extended by
  490.    the programmer.
  491.  
  492. 2- There is a save-restore program that allows to take an O2 database,
  493.    save it on a file or a tape in a logical way (i.e., independent of
  494.    the physical format of objects on disk), and restore it again on a
  495.    (perhaps new release) of the system, in an empty database.
  496.    Currently, when saving a database its schema is also saved. The
  497.    next extension to this save/restore program will be to save the
  498.    database without saving its schema, and then restore the database
  499.    on a new version of that schema. The restore program will be able
  500.    to perform automatically some conversions like "add attribute" or
  501.    "delete attribute".
  502.  
  503.  
  504. Schema updates with impact on the database will be implemented in future 
  505. releases.
  506.  
  507. [Fernando Velez <fernando@o2tech.fr>]
  508.  
  509.  
  510. For more information on O2, consult the following REFERENCES:
  511.  
  512.         Francois Bancilhon, Claude Delobel, Paris
  513.         Kanellakis.  "Building an Object-Oriented Database
  514.         System: The Story of O2".  Morgan Kaufmann Series
  515.         in Data Management Systems, San Mateo, Calif., 1992.
  516.         
  517.         F. Bancilhon, G. Barbette, V. Benzaken, C. Delobel,
  518.         S. Gamerman, C. Lecluse, P. Pfeffer, P. Richard,
  519.         and F. Velez.  "The Design and Implementation of
  520.         O2, and Object-Oriented Database System".
  521.         Advances in Object-Oriented Database Systems,
  522.         Springer Verlag. (Lecture Notes in Computer Science
  523.         series, Number 334.)
  524.  
  525.         C. Lecluse, P. Richard, and F. Velez. "O2, an
  526.         Object-Oriented Data Model".  Proceedings of
  527.         SIGMOD88.  Also appears in Zdonik and Maier,
  528.         "Readings in Object-Oriented Database Systems",
  529.         Morgan Kaufmann, 1990.
  530.  
  531.  ==== Corporate headquarters:
  532. O2 Technology
  533. 7 Rue du Parc de clagny
  534. 78035 Versailles Cedex
  535. France
  536. tel : 33 1 30 84 77 77
  537. fax : 33 1 30 84 77 90
  538.  
  539. [They have many other contacts worldwide]
  540.  
  541.  
  542. > Objectivity/DB (Objectivity)
  543.  
  544. Introduction:
  545.  
  546. Objectivity/DB has a fully distributed client/server architecture that
  547. transparently manages objects distributed across heterogeneous environments and
  548. multiple databases.  It provides an application interface that uses transparent
  549. indirection to ensure integrity and provides a single logical view of all
  550. information, with all operations working transparently on any database on the
  551. network, with scalable performance as users and objects increase.  A
  552. higher-level Object Definition Language (ODL) is available as well as a C
  553. functional interface, integrated C++ interface, and SQL++.
  554.  
  555.  
  556. Objectivity/DB
  557.  
  558. Objectivity/DB [Reference:  Technical Overview, Objectivity, 1993], a product
  559. of Objectivity, Inc. of Menlo Park, CA, provides an integrated C++ programming
  560. interface with an emphasis on the DBMS engine for robustness and scalability
  561. from workgroups to enterprise-wide production applications.  In production use
  562. today with more than 50,000 end users licensed, it supports a fully
  563. distributed, rather than central-server, architecture, with all operations
  564. working transparently over a mixture of multiple databases, schemas, users, and
  565. computers, and over heterogeneous hardware, operating systems, and networks. 
  566. The language interface includes a C++ class library interface, soon to be ODMG;
  567. a C function library; and SQL++, supporting query predicates with either SQL or
  568. C++ syntax, interactively or programmatically.  Over forty administrative and
  569. GUI tools provide both an interactive and programmatic interface, and a
  570. messaging backplane allows third party tools integration at four different
  571. levels, with a list of partners at all levels.
  572.  
  573. One of the key architectural concepts of Objectivity/DB is an object reference
  574. mechanism that ensures data integrity.  Unlike traditional ODBMSs that use
  575. direct pointers, which become invalid after commit and hence lead to crashes
  576. and corrupt databases, Objectivity/DB uses an indirection to guarantee safe
  577. reference.  Transparent to the user, this indirection requires an extra test
  578. and pointer dereference, or a couple of cycles, which is not measurable in most
  579. applications.  However, it ensures integrity of all references, even across
  580. transaction boundaries, resulting in production quality robustness.  Also, it
  581. provides object level granularity for the object manager, allowing it to move,
  582. cluster, and swap objects as necessary, one of the keys required for
  583. scalability in objects and users.  Finally, it allows object-level granularity
  584. for current features, such as heterogeneity and versioning, and future
  585. extensions, such as object-level security.
  586.  
  587. A higher-level Object Definition Language (ODL) is provided that allows
  588. declaration of modeling concepts such as bi-directional associations, behavior
  589. of associations between objects as they version (move, copy drop), and
  590. propagation of methods across associations.  These then result in automatically
  591. generated methods and declarations for both C++ and C.  The standard C++ API
  592. allows application programmers to work with any standard compilers and
  593. debuggers, with no extra pre-processors, providing ODBMS capabilities via
  594. overloading C++ operators (new, ->, etc.), and declarations via provided
  595. classes (for references, etc.).
  596.  
  597. Workgroup through enterprise-wide and cross-enterprise computing is supported
  598. via a distributed client/server architecture that provides a single logical
  599. view over multiple databases on heterogeneous machines.  The user sees a
  600. logical view of objects connected to objects and need not worry that one object
  601. is in a database on a Sun workstation, while another may be in a database under
  602. Windows or VMS.  All operations work transparently across this environment,
  603. including atomic transactions with two-phase commit, propagating methods, and
  604. versioning.  Objects may be moved between databases and platforms without
  605. affecting working applications or requiring changes to the applications. 
  606. Multiple schemas may be created, without affecting other users or databases,
  607. and may be used simultaneously with shared schemas, allowing local groups to
  608. define their own models but still connect to other groups.  Databases may be
  609. detached from this shared environment (federated database) and used on portable
  610. devices, reconnected or moved to different (compatible) environment, or
  611. distributed as parts or image libraries.  Gateways to RDBMSs are provided via
  612. third-party integration with Persistence Software, and more generally to any
  613. foreign data store, as long as the user installs the appropriate access
  614. methods, extending the single-logical-view to include read/write access to
  615. arbitrary foreign data stores.  Together, these allow delegation of
  616. responsibilities to the appropriate users, integration with existing systems,
  617. and gradual migration toward full enterprise-wide sharing.
  618.  
  619. The on-demand object manager directly and automatically manages object access
  620. and buffering, rather than relying on system facilities such as virtual memory
  621. or user manual get/put calls.  Mechanisms used include multiple buffer pools
  622. locally and remotely, b-trees, hashing, scoped names, keys, and iterators, with
  623. distributed catalogues for schemas and databases.  A direct connection is
  624. established between the user and the objects used, so that users do not
  625. conflict unless and until they are competing for the same objects, thus
  626. avoiding the traditional central-server bottleneck.  Short transactions are
  627. based on traditional (transient) locks, owned by the process, and group
  628. together an arbitrary set of operations.  Long transactions are based on
  629. persistent locks, owned by the user, and provide the same arbitrary grouping. 
  630. Default concurrency is two-phase locking and serialization, but extensions
  631. available include MROW, or multiple-readers concurrent with one-writer, and
  632. allow users to lock with or without wait or with timed waits, to implement more
  633. sophisticated mechanisms.
  634.  
  635. Objects may be modeled using C++ structures augmented by classes provided such
  636. as strings, dictionaries, and relationship management, as well as some
  637. particular domain libraries.  A simple object is a C++ class (or C structure)
  638. with associated access methods.  A complex object may include multiple varrays,
  639. each being a dynamically varying sized array of arbitrary structure.  A
  640. composite object is any network of related objects that acts as a single
  641. object, both structurally and behaviorally, via propagation of behaviors to
  642. component objects.  Any number of composite objects may be contained in
  643. composite objects, and a single object may participate in any number of
  644. composites.  The relationship mechanism supports uni- and bi-directional
  645. relationships, one-to-one, one-to-many, and many-to-many.  Versioning is
  646. supported at object granularity, may be turned on or off at any time for each
  647. object, may be restricted to linear or allow branching with multiple writers. 
  648. References to versioned objects may be to a specific version or to the default
  649. version, which may be separately specified by a method and may allow multiple
  650. defaults.  Schema and object evolution are supported via versioning of the
  651. type-defining objects.  Each time a type definition is changed, its defining
  652. object is versioned, allowing arbitrary changes.  Objects may then be instances
  653. of the old or new type version.  Object evolution or upgrading to the new type
  654. version is supported  by the user writing conversion methods which are
  655. installed and invoked by the system.
  656.  
  657. ANSI SQL query is supported in the SQL++ product.  Predicate syntax may be
  658. either C++ or SQL.  The ODBC and SQL Access Group (SAG) protocols are
  659. supported.  Queries may be invoked programatically or interactively, with ad
  660. hoc support.  Access to object features is available via methods and traversal
  661. of relationships.
  662.  
  663. Over forty administrative and developer tools are provided, each with both an
  664. interactive and programmatic interface.  These include GUI object and type
  665. browsers, query browsers, report generator, tools to examine and force short
  666. and long locks, to move objects and databases, etc.  On-line incremental backup
  667. provides a consistent network-wide snapshot, including referential integrity
  668. across all databases, and runs incremental and full database backups with no
  669. need to acquiesce the databases and no interference with active applications. 
  670. All tools are built around a messaging backplane, which supports four levels of
  671. integration with user and third-party tools.  Integrated products include HP
  672. SoftBench (full operational level), CenterLine's ObjectCenter (tool level), 
  673. Persistence RDBMS gateway, PTech and ProtoSoft Design and Analysis (language
  674. level), and XVT and UIM/X (compatibility level).
  675.  
  676. Objectivity/DB is resold by Digital Equipment Corporation as DEC Object/DB,
  677. providing a multi-billion-dollar second source vendor.  Over 50,000 end users
  678. are licensed in production use, with applications including real-time
  679. telecommunications, aerospace, defense, case, CAD/CAM, CIM, manufacturing, oil
  680. & gas, process control, transportation, multi-media, case, document management,
  681. financial analysis, and corporate information management.  Platform support
  682. includes all Sun, all DEC (including VMS, alpha, OSF-1), HP/9000 series (both
  683. 68xxx and PA-RISC), IBM RS/6000, NCR 3300, SGI, Windows 3.1, and Windows NT.
  684.  
  685. On Schema Evolution (from original survey):
  686. In the just-released Version 2.0 (shipping Oct 92), schema evolution
  687. is supported via dynamic versioning of type-defining objects [ie.
  688. class versions -- SMC], and via a step-by-step approach that allows
  689. conversion of instance data via user-provided conversion methods.
  690. Also, a full dynamic type manager interface is available for doing
  691. fancier things.
  692.  
  693. Contact:
  694.  
  695. Drew Wade
  696. Objectivity, Inc.
  697. 800 El Camino Real
  698. Menlo Park, CA  94025 USA
  699. drew@objy.com
  700. 1(415)688-8000 voice
  701. 1(415)325-0939 fax
  702. admin ass't:  Vickie Clements (vickie@objy.com)
  703. information:  info@objy.com
  704.  
  705.  
  706. > ObjectStore Object Database System From Object Design, Inc.
  707.  
  708.  
  709. Product Description    
  710.  
  711. ObjectStore[TM] is a high performance ODBMS designed for ease of use in
  712. development of sophisticated applications using object-oriented
  713. development techniques.  It offers a tightly-integrated language
  714. interface to a complete set of traditional DBMS features including
  715. persistence, transaction management (concurrency control and
  716. recovery), distributed access, associative queries over large amounts
  717. of data, and database administration utilities.  ObjectStore's data
  718. management facilities combined with popular development tools create a
  719. high productivity development environment for implementing
  720. object-oriented applications.
  721.  
  722. Key Features:
  723.  
  724.    - Transparent interface designed for popular C and C++ programming
  725.      environments. 
  726.  
  727.    - Concurrent access to large amounts of persistent data. 
  728.  
  729.    - Distribution of objects over networks using a variety of popular
  730.      network protocols.
  731.  
  732.    - Access to persistent data at the same speed as transient data.
  733.  
  734.    - Extensible data modeling capabilities for applications requiring
  735.      complex data structures.
  736.  
  737.    - Easy migration path for existing C and C++ applications.
  738.  
  739.    - Class libraries for version and configuration management.
  740.  
  741.    - Class libraries for managing collections of objects.
  742.  
  743.    - A fully distributed (multi-server/multi-database) ad hoc query
  744.      capability.
  745.  
  746.    - An interactive Browser to inspect objects and object
  747.      descriptions.
  748.  
  749.    - Interoperable with ObjectStore servers running on other operating
  750.      systems and hardware environments.
  751.  
  752.    - Complete schema evolution for an application's metadata and
  753.      existing object instances.
  754.  
  755.    - Full online backup for continuous processing environments.
  756.  
  757.    - Meta object protocol with programmatic access to schema
  758.      information. 
  759.  
  760.    - Dynamic Type creation for extending existing class definitions
  761.      during program execution.
  762.  
  763.  
  764. System View
  765.  
  766. ObjectStore supports cooperative access through its flexible
  767. client/server software architecture, which allows users to make the
  768. take advantage of the computational power that exists on the desktop.
  769. ObjectStore's client/server implementation allows one server to
  770. support many client workstations, each workstation to simultaneously
  771. access multiple databases on many servers, and a server to be resident
  772. on the same machine as a client.  ObjectStore's distributed
  773. architecture supports several network environments for
  774. interoperability among popular workstations and PC's and includes
  775. support for TCP/IP, Novell IPX/SPX, other popular network protocols.
  776.  
  777.  
  778. Application Interface
  779.  
  780. Access to ObjectStore is provided through a library based application
  781. interface compatible with popular C and C++ compilers and programming
  782. environments.  The ObjectStore application interface provides support
  783. for C++ compilers -- such as those from workstation suppliers -- and
  784. development environments from independent software vendors such as
  785. Visual C++ from Microsoft, ObjectCenter from CenterLine Software, Inc.
  786. and Energize from Lucid, Inc.  The application interface provides
  787. powerful high-level function calls which enable the programmer to
  788. create multi-user application which share large amounts of data.
  789. These functions include:
  790.  
  791.    - Relationship Management
  792.    - Version Management
  793.    - Collection Management
  794.    - Storage Management
  795.    - Associative Queries
  796.    - Object Iteration
  797.    - Transaction Management 
  798.    - Index Management
  799.    - Clustering
  800.  
  801. Applications developed using ObjectStore library calls are
  802. source-level compatible with ObjectStore applications developed for
  803. other operating systems on other hardware platforms.
  804.  
  805. Platforms
  806.  
  807. ObjectStore is available on the following major platforms:
  808.     
  809. Unix Workstation Platforms
  810.  
  811.    - DEC MIPS Ultrix 
  812.    - HP 700 Series HP-UX
  813.    - HP 800 Series HP-UX 
  814.    - IBM RS/6000 AIX
  815.    - NCR 3000 
  816.    - Olivetti LSX-50xx SVR4
  817.    - Silicon Graphics IRIX 5.x
  818.    - SunSoft Intel Solaris 2
  819.    - SunSoft SPARC Solaris 1 SunOS 4
  820.    - SunSoft SPARC Solaris 2 SunOS 5
  821.    - Univel UnixWare
  822.  
  823. PC Platforms
  824.  
  825.    - Windows 3.1 (Win32s)
  826.    - Windows NT (Intel)
  827.    - OS/2 Release 2.0 and 2.1
  828.    - Novell Netware Release 3.1 and 4.0 (server only)
  829.  
  830. The Company
  831.  
  832. ObjectStore[TM], Object Design's object-oriented database management
  833. system, is currently used by more than 500 companies.  The company
  834. targets end-user customers in major corporations and governments
  835. through its direct sales force, and also focuses on independent
  836. software developers, systems integrators and international
  837. distributors to license its products.  In the systems software market,
  838. Object Design has already licensed object storage technology to
  839. SunSoft that will be embedded in the Solaris(r) (Project DOE)
  840. environment.  Through this relationship Hewlett Packard also has rights
  841. to the technology for use in HP/UX(r) (DOMF).
  842.  
  843. In April 1993, IBM Corporation became one of the company's leading
  844. investors as part of a far-reaching strategic relationship involving
  845. an equity investment, internal use and joint development agreements.
  846.  
  847. Object Design's Support Services group provides extensive support
  848. services tailored to meet each customer's specific needs.  A regularly
  849. scheduled series of training courses are offered, either at Object
  850. Design facilities across North America, select international locations
  851. or at customer sites, that reduce the learning curve for
  852. object-oriented development.  The training courses include
  853. "Introduction to Object-Oriented Programming and C++," "Designing
  854. Object-Oriented Database Applications" and "Building High Performance
  855. Applications with ObjectStore."  To further assist its customers,
  856. Object Design makes its team of experts available to provide a wide
  857. range of training, support and consulting services.
  858.  
  859. The company distributes its products through a direct sales and
  860. telesales force in the North America, wholly-owned subsidiaries in
  861. Australia (61-2-212-2766), Germany (49-611-39707-0), Japan
  862. (81-3-3251-2882), and the United Kingdom (44-793-486111) as well as
  863. through distributors in 15 countries.
  864.  
  865. The US headquarters are located in Burlington, Mass., the company
  866. maintains regional or district offices in Atlanta; Chicago; Los
  867. Angeles; New York; Portland; San Mateo, Calif.; and Washington, DC.
  868.  
  869. You may obtain information about ObjectStore or Object Design by any
  870. of the following methods:
  871.  
  872. Address:
  873.  
  874.     Object Design, Inc.
  875.     25 Burlington Mall Road
  876.     Burlington, MA 01803
  877.  
  878. Telephone:
  879.  
  880.     Call toll-free 1-800-962-9620 in the USA or 617-674-5000 and
  881.     ask for telemarketing.
  882.  
  883. Internet:
  884.  
  885.     Send email requests to info@odi.com.
  886.  
  887.     You can also download public information from our ftp server,
  888.     ftp.odi.com (198.3.16.17).  Login as "anonymous", and use your
  889.     mail address (username@site) as your password.  Major files of
  890.     interest include:
  891.  
  892.     /pub/docs/techsum-net.ps    Technical Summary (postscript)
  893.     /pub/docs/techsum.net        Technical Summary (FrameMaker)
  894.     /pub/oo7/results.ps        OO7 Benchmark Results (postscript)
  895.  
  896. CompuServe:
  897.  
  898.     GO ODIFORUM, section 1.
  899.  
  900. International distributors contact information follows:
  901.  
  902. GERMANY
  903.  
  904. Patzschke + Rasp 
  905. Software und Systeme
  906. Bierstadter StraBe 7
  907. D-65189 Wiesbaden Germany
  908. 011-49-611-17-310
  909. 011-49-611-17-3131 FAX
  910.  
  911. SPAIN, PORTUGAL
  912.  
  913. DyM
  914. Diseno y Metodologia, SA
  915. Francisco Gervas, 17, 5.0 G
  916. Madrid, Spain 28020011-34-1-571-3123 or 571-3880
  917. 011-34-1-571-3942 FAX
  918.  
  919.  
  920. SWEDEN, NORWAY, DENMARK, FINLAND
  921.  
  922. ENEA Data
  923. Box 4150
  924. S-203 12 Malmo
  925. Sweden
  926. 011-46-40-70930
  927. 011-46-40-230240 FAX
  928.  
  929. SWITZERLAND
  930.  
  931. UNISYS (Schweiz) AG
  932. Zucherstrasse 59-61
  933. A-8800 Thalwill
  934. Switzerland
  935. 011-411-723-3366
  936. 011-411-720-3737 FAX
  937.  
  938. ITALY
  939.  
  940. AIS S.p.a.
  941. Via Rombon, 11-20134
  942. Milano, Italy
  943. 011-39-226-40197
  944. 011-39-2 2641-0744 FAX
  945.  
  946. ISRAEL
  947.  
  948. TACTLINE, Ltd.
  949. Beit-Oved 76800
  950. Israel
  951. 011-972-840-4898
  952. 011-972-840-6927 FAX
  953.  
  954. JAPAN
  955.  
  956. Mitsui Engineering & Shipbuilding Co., Ltd.(MES)
  957. 6-4 ,Tsukiji 5-chome
  958. Chuo-ku,Tokyo, 104 
  959. 011-81-3-3544-3355
  960. 011-81-3-3544-3036FAX
  961.  
  962. Stan Systems Corporation
  963. Sumitomo Higashi Shinbashi Bldg.
  964. 1-1-11 Hamamatsucho
  965. Minato-Ku, Tokyo 105 Japan
  966. 011-81-3-5472-5515
  967. 011-81-3-5472-5544 FAX
  968.  
  969.  
  970. System Network Corporation:
  971. Tohto Bldg. 6F
  972. 5-1-4 Toranomon, Minato-ku, 
  973. Tokyo  105 Japan
  974. Phone#:   +81-3-3437-4081
  975. Fax#:       +81-3-3437-4060
  976.  
  977. Toyo Information Systems Co.,Ltd.
  978. Nihonbashi Toyo Bldg. 4F
  979. 2-7-24 Nihonbashi
  980. Chuo-Ku, Tokyo 103 Japan
  981. 011-81-3-3271-7681
  982. 011-81-3-3271-7685 FAX
  983.  
  984. TAIWAN, R.O.C.
  985.  
  986. Exartech International Corp 
  987. 10F, 82, Chung-Cheng S. RD.
  988. Sanchung, Taipei, Taiwan, ROC
  989. 011-886-2-977-6828
  990. 011-886-2-977-6829 FAX
  991.  
  992. SOUTH AFRICA
  993.  
  994. Realtime Computer Services (Pty) Ltd.
  995. 4th Floor, 35 Wale Street
  996. Cape Town 8001
  997. South Africa
  998. 011 27 21 24 4350
  999. 011 27 21 221507 FAX
  1000.  
  1001.         
  1002. > Ontos [formerly VBase] (Ontologic)
  1003.  
  1004. Entry on schema evolution only:
  1005.  
  1006. *Ontos provides schema evolution. It allows any class to be modified.
  1007. *The major drawback is that data does not migrate ie., instances are
  1008. *not modified to adopt to the new class definition. So schema changes
  1009. *can be done only on classes that do not contain instances and do not
  1010. *have sub classes that contain instances.
  1011. *[h.subramanian@trl.OZ.AU]
  1012.  
  1013. *As a system for experiments, we are currently using ONTOS from
  1014. *Ontologic Inc.  Unfortunately, there is no transparent concept of
  1015. *schema evolution for populated database. Thus, we still investigate
  1016. *how it works.
  1017.  
  1018. ONTOS has a version of ONTOS for OS/2.  Approximately $11K. Others I don't know
  1019.  
  1020.  
  1021. > Odapter/OpenODB (Hewlett-Packard)
  1022.  
  1023. Odapter is HP's new object/relational adapter which
  1024. enables object-oriented developers to share a common
  1025. object model stored in the ORACLE7 relational database
  1026. management system (RDBMS).  Odapter is also available with
  1027. HP's ALLBASE/SQL RDBMS.  The combination of Odapter
  1028. and ALLBASE/SQL is called OpenODB.
  1029.  
  1030. Odapter 
  1031. Technical Data 
  1032. Object/Relational Adapter 
  1033.   
  1034. A Productivity Tool for Scalable Object-Oriented 
  1035. Applications 
  1036.   
  1037. Odapter is a tool for developers writing scalable 
  1038. object-oriented applications requiring the 
  1039. integration of new objects and legacy information. 
  1040. Odapter is valuable because it: 
  1041. * accelerates application development 
  1042. * reduces the cost of keeping applications current 
  1043. * enables applications to scale 
  1044.   
  1045. Odapter delivers the productivity of object 
  1046. technology while adhering to your data management 
  1047. standards. 
  1048.   
  1049. Consider Odapter if you need to be able to do one 
  1050. or more of the following: 
  1051. * develop object-oriented applications and 
  1052. store objects in a relational database 
  1053. * easily access legacy data and existing 
  1054. applications from your new system 
  1055. * support a large number of end-users who will 
  1056. be simultaneously accessing information 
  1057. * store large amounts of  complex information 
  1058.   
  1059. The following are examples of applications well- 
  1060. suited for Odapter: 
  1061. * a customer billing application written in 
  1062. Smalltalk combining data stored in DB2 with new 
  1063. objects. (Telecommunications) 
  1064. * a network management application written in C 
  1065. using Odapter as the object manager, able to scale 
  1066. to millions of objects (Manufacturing) 
  1067. * a complex Oil and Gas industry standard model 
  1068. automatically generated from an Express analysis 
  1069. and design tool. 
  1070. (Oil & Gas) 
  1071. * a medical application using Odapter to 
  1072. combine heterogeneous components of patient 
  1073. records. (Healthcare) 
  1074.   
  1075. Odapter provides authorized access to sharable 
  1076. objects, including existing data and business 
  1077. processes. By bringing object-oriented capabilities 
  1078. to heterogeneous systems environments, Odapter 
  1079. delivers increased functionality while leveraging 
  1080. the stability of existing RDBMSs and legacy 
  1081. information. 
  1082.   
  1083. Odapter Object Model 
  1084.   
  1085. The Odapter object model is based on three key 
  1086. concepts - objects, types and functions. 
  1087. * Objects are a combination of data and 
  1088. behavior (functions). Figure 2 is an example of an 
  1089. object. 
  1090. * Types are dynamic templates allowing you to 
  1091. group together similar components or objects. 
  1092. * Functions define the attributes, 
  1093. relationships and behavior of objects. Odapter 
  1094. supports four types of user-defined functions: 
  1095.   
  1096. Stored functions define attributes and 
  1097. relationships that are stored in the database. In 
  1098. Figure 2, flightno is a stored function. The 
  1099. functions aircraft and crew are also stored 
  1100. functions with user-defined results. 
  1101.   
  1102. SQL-based functions allow you to access existing 
  1103. relational tables with Odapter's object-oriented 
  1104. model. In Figure 2, citypair is an SQL-based 
  1105. function accessing values from an existing 
  1106. relational table. 
  1107.   
  1108. OSQL-based functions define attributes and 
  1109. relationships that are derived or calculated with 
  1110. OSQL statements. In Figure 2, delay and depart are 
  1111. OSQL-based functions. Delay calculates changes in 
  1112. arrival and departure times based upon events that 
  1113. disrupt the schedule; depart handles the update of 
  1114. functions related to departure and transitions the 
  1115. flight from OnGround to InAir. 
  1116.   
  1117. External functions are a reference to code or data 
  1118. stored outside of Odapter. In Figure 2, cancel is 
  1119. an external function that executes code outside of 
  1120. Odapter to free up resources no longer assigned to 
  1121. the flight. 
  1122.   
  1123. Odapter Language 
  1124.   
  1125. The Odapter language can be combined with functions 
  1126. implemented in C++, Smalltalk or C. You create and 
  1127. manipulate objects, types and functions using 
  1128. Odapter's object-oriented structured query language 
  1129. (OSQL). OSQL is a functional language that is a 
  1130. semantic superset of SQL, the structured query 
  1131. language for relational databases. OSQL is a 
  1132. computationally complete language with statements 
  1133. allowing you to define and manipulate information 
  1134. in your Odapter enhanced relational database, 
  1135. specify authorization for individuals or groups, 
  1136. define transactions, embed program logic within 
  1137. functions, and administer the database. 
  1138.   
  1139. OSQL includes programming flow statements, such as 
  1140. IF/THEN/ELSE, FOR and WHILE. This procedural 
  1141. language allows Odapter functions to model complex 
  1142. behavior, simplifying your application code. By 
  1143. decoupling behavior from the applications, multiple 
  1144. applications can share information with benefits 
  1145. such as consistency, security and integrity. See 
  1146. Table 5 for a list of all OSQL statements. 
  1147.   
  1148. Odapter Object Storage 
  1149.   
  1150. Odapter objects are stored in the developer's 
  1151. choice of relational databases. Odapter interfaces 
  1152. to the underlying RDBMS through an SQL command 
  1153. interface. Currently, developers can choose to 
  1154. store their objects in ORACLE7 or HP ALLBASE/SQL. 
  1155.   
  1156. The choice of RDBMS is made when a particular 
  1157. database is created. The users are only limited by 
  1158. the number of Odapter concurrent user licenses 
  1159. purchased. This flexibility allows database 
  1160. administrators to continue using their existing 
  1161. administration procedures and keeps the group from 
  1162. having to choose yet another database management 
  1163. system. 
  1164.   
  1165. During the initial development of an application, 
  1166. developers can make rapid progress without 
  1167. knowledge of the underlying relational database. 
  1168. Optimization of the objects and how they are stored 
  1169. in the underlying relational database is best 
  1170. done during the deployment phase. 
  1171.   
  1172. Odapter Development Environments 
  1173.   
  1174. Odapter developers have a choice of development 
  1175. environments. Whether Smalltalk, C++ or more 
  1176. traditional C and C-linkable languages are used, 
  1177. Odapter enables object storage in a scalable and 
  1178. robust relational database. In fact, objects can be 
  1179. shared between different applications, allowing 
  1180. different projects to employ the best tools for the 
  1181. job! 
  1182.   
  1183. Odapter and Smalltalk 
  1184.   
  1185. Odapter provides Smalltalk developers with 
  1186. transparent access to information stored in the 
  1187. underlying relational database. 
  1188.   
  1189. Odapter's Smalltalk Class Builder utility 
  1190. automatically generates ParcPlace Smalltalk 
  1191. compatible classes and methods based upon an 
  1192. Odapter object model. The developer can select 
  1193. specific Odapter types and functions, resulting in 
  1194. a corresponding set of Smalltalk classes and 
  1195. methods. Once the Smalltalk schema is generated, 
  1196. the Smalltalk developer can transparently access 
  1197. the underlying relational database, as shown in 
  1198. Figure 3. 
  1199.   
  1200. printFlight 
  1201.    |allFlightObjects| 
  1202.    allFlightObject:=Flight allObjects. 
  1203.    AllFlightObjects do: [:aFlight| 
  1204.       Transcript show :aFlight flightno value; cr]. 
  1205. Figure 3 
  1206.   
  1207.   
  1208. Figure 3 shows how to access the flight objects 
  1209. shown in Figure 2 through Smalltalk. This example 
  1210. retrieves all flight object identifiers and prints 
  1211. the flight# for each one of the flight objects. 
  1212.   
  1213. All Smalltalk classes and methods which result in 
  1214. the access of Odapter structures are italicized. 
  1215. Flight is a Smalltalk class that corresponds to the 
  1216. Odapter type Flight. The Smalltalk methods 
  1217. allObjects and flightno map to Odapter calls that 
  1218. access data from the relational database storage 
  1219. manager. 
  1220.   
  1221. Odapter and C++ 
  1222.   
  1223. For C++ developers, once the corresponding C++ 
  1224. model is created, Odapter provides the abilility to 
  1225. manage C++ objects stored in the underlying 
  1226. relational database, as shown in Figure 4. 
  1227.   
  1228. void printFlight() 
  1229.    int i; 
  1230.    ODBType Flight ("Flight"); 
  1231.    ODBBag allFlights=Flight.allObjects(); 
  1232.    ODBFunc flightno("flighno"); 
  1233.   
  1234.    for(i=0;i<allFlights.size();i++){ 
  1235.       cout<<flightno(allFlights[i]); 
  1236.    } 
  1237. Figure 4 
  1238.   
  1239. Figure 4 shows a C++ version of the Smalltalk 
  1240. example in Figure 3. That is, Figure 4 shows how to 
  1241. access all the flight objects shown in Figure 2 and 
  1242. prints the flight number associated with each 
  1243. flight object. 
  1244.   
  1245. The Odapter C++ library includes a set of classes 
  1246. (e.g. ODBType, ODBClass, ODBFunc, ODBBag) and 
  1247. corresponding member functions (e.g. allObjects). 
  1248. User-defined classes (Flight) and member functions 
  1249. (flightno) are also shown. In Figure 4, all Odapter 
  1250. calls are in italics. 
  1251.   
  1252. Odapter and C-linkable Languages 
  1253.   
  1254. For traditional developers using C, or any 
  1255. languages linkable with C, the object-oriented 
  1256. features are provided by Odapter. Odapter objects 
  1257. are manipulated by embedding OSQL statements in the 
  1258. C program, similar to the db.execosql call shown in 
  1259. Figure 4. In addition, the C interface requires the 
  1260. conversion of data types from Odapter to C. 
  1261.   
  1262. By embedding Odapter calls in a C program, the C 
  1263. language becomes object-oriented. 
  1264.   
  1265. Features and Benefits 
  1266.   
  1267. Accelerates Application Development 
  1268.   
  1269. Odapter accelerates application development by 
  1270. integrating with familiar development environments 
  1271. and by providing a robust object-oriented model. 
  1272.   
  1273. Odapter's choice of development environments 
  1274. includes those which support the Smalltalk, C++ and 
  1275. C languages. 
  1276.   
  1277. Odapter's robust object model enables the 
  1278. integration of legacy data and business processes 
  1279. in the context of one sharable business object 
  1280. model, shielding the developer from the data 
  1281. storage complexity. 
  1282.   
  1283. The following Odapter features accelerate 
  1284. application development: 
  1285.   
  1286. Automatic mapping of objects to relational 
  1287. databases 
  1288. The application developer is shielded from the task 
  1289. of converting complex object models to two 
  1290. dimensional relational tables. 
  1291.   
  1292. Smalltalk Class Builder 
  1293. Once an OSQL schema is created, whether using 
  1294. available analysis and design tools or manually, 
  1295. Odapter's Smalltalk Class Builder can generate 
  1296. corresponding Smalltalk classes and methods. The 
  1297. developer can select the relevent part of the 
  1298. Odapter schema to generate. As the Odapter object 
  1299. model changes, developers can also incrementally 
  1300. update the Smalltalk classes. 
  1301.   
  1302. Object Identity 
  1303. Each object manipulated by Odapter has a unique, 
  1304. system-provided handle called an object identifier 
  1305. (OID). OIDs eliminate the need for creating unique 
  1306. keys to identify stored information. Additionally, 
  1307. OIDs reduce duplication of information when several 
  1308. attributes would be needed to uniquely identify 
  1309. information in the database. OIDs are also a 
  1310. powerful way to tune data access and performance. 
  1311.   
  1312. Inheritance 
  1313. Odapter objects can use functions defined on parent 
  1314. types in the type hierarchy. For example, as shown 
  1315. in Figure 5, a subtype of Employee called Pilot 
  1316. could inherit functions from Employee like hire and 
  1317. name, while defining unique functions like 
  1318. hoursflown and status. 
  1319.   
  1320.   
  1321. Multiple Inheritance 
  1322. Functions defined on a type can be inherited by one 
  1323. or more subtypes. In Figure 5, functions accessible 
  1324. by the type ManagingPilot are inherited from its 
  1325. parents, namely all functions defined on Employee, 
  1326. Pilot and Manager. By inheriting rather than 
  1327. redefining functions, you can easily add 
  1328. functionality to your application. 
  1329.   
  1330. OSQL 
  1331. If you already know SQL, you can quickly be 
  1332. productive using Odapter's OSQL. Both query 
  1333. languages are set-based, that is they retrieve sets 
  1334. of information based upon queries. Thus, OSQL does 
  1335. not require users to navigate through the database 
  1336. chasing pointers or object references. 
  1337.   
  1338. Encapsulation 
  1339. Odapter protects end-user applications from changes 
  1340. to the internal definition of objects. Since 
  1341. Odapter only allows access to data through 
  1342. functions with well defined arguments and results, 
  1343. your applications are protected from changes to the 
  1344. function body and you have control over how 
  1345. information is used. 
  1346.   
  1347. Aggregate Types 
  1348. Aggregates are used to represent collections, such 
  1349. as crew members (maybe several pilots, flight 
  1350. attendants and a mechanic) for a particular flight, 
  1351. or the employees reporting to a particular manager. 
  1352. Aggregates are not required to have a predetermined 
  1353. size. Odapter manages the memory associated with 
  1354. aggregates, relieving your application of this 
  1355. work. 
  1356.   
  1357. User-defined Data Types 
  1358. You can construct user-defined data types in 
  1359. Odapter, such as a type called Flight, Employee or 
  1360. Aircraft, as shown in Figure 6. Functions defined 
  1361. on these types can manipulate data stored within 
  1362. the current object, within other related objects or 
  1363. outside of Odapter. User-defined types maximize 
  1364. flexibility and lead to more manageable, clearer 
  1365. code. 
  1366.   
  1367. Complex Objects 
  1368. With Odapter you can construct complex objects from 
  1369. simpler objects. For example, Figure 6 shows the 
  1370. relationships between the types Flight, Aircraft 
  1371. and Employee.  Complex objects relieve applications 
  1372. from managing such relationships. 
  1373.   
  1374.   
  1375. Reduces the Cost of Keeping Applications Current 
  1376.   
  1377. Odapter supports a server-centric business model 
  1378. which means the business logic and associated data 
  1379. is sharable by multiple applications. By separating 
  1380. out business objects (data and processes), from the 
  1381. application development environment, your company's 
  1382. business can be modified without impacting the 
  1383. applications. These changes can be immediately 
  1384. leveraged by the calling applications without 
  1385. recompilation 
  1386.   
  1387. The following features make applications easier to 
  1388. keep current: 
  1389.   
  1390. External Functions 
  1391. Using external functions, you can access 
  1392. distributed data and code stored outside of the 
  1393. relational database used by Odapter for storage, 
  1394. regardless of location or data format. Examples of 
  1395. external data sources include IMS, DB2 as well as 
  1396. custom databases and flat files. Odapter acts as an 
  1397. integrator so your application can manipulate 
  1398. information as recognizable business objects. This 
  1399. not only allows transparent migration of data over 
  1400. time, it accelerates developer productivity by 
  1401. hiding the complexity of a diverse data storage 
  1402. environment. 
  1403.   
  1404. Overloaded Functions 
  1405. Multiple functions can have the same name with 
  1406. different implementations. An application calls a 
  1407. function (e.g. salary) and Odapter determines at 
  1408. run-time which code (salary for Manager or salary 
  1409. for Pilot) to execute, based upon the type of the 
  1410. object against which the function is invoked. The 
  1411. application is simplified since the conditional 
  1412. logic for determining which function to execute is 
  1413. now in Odapter. 
  1414.   
  1415. Dynamic Schema Modification 
  1416. Odapter object models can be modified while the 
  1417. database is running. Developers can add new 
  1418. functions and types, as well as change the 
  1419. implementation of functions. This capability is 
  1420. particularly valuable to applications with high 
  1421. availability requirements. 
  1422.   
  1423. Dynamic Typing 
  1424. You can change the type of an object without 
  1425. destroying and recreating the object. An object can 
  1426. also belong to more than one type. As shown in 
  1427. Figure 7, once a Flight leaves the ground, it would 
  1428. change state from being an OnGround to an InAir 
  1429. Flight. OnGround functions such as maintenancecrew 
  1430. and availableseats would no longer be needed. An 
  1431. InAir object would need certain functions like 
  1432. bestroute and delay to calculate the most time 
  1433. efficient route and to calculate a projected delay 
  1434. based current weather conditions. Dynamic Typing 
  1435. allows you to represent an object in Odapter which 
  1436. transforms itself over time and, therefore, changes 
  1437. capabilities and attributes. 
  1438.   
  1439. Late Binding 
  1440. Odapter supports functions that are resolved at 
  1441. runtime. Late binding allows you more flexibility 
  1442. in application development and gives you the full 
  1443. power of overloaded functions as described earlier. 
  1444. On the other hand, Odapter will precompile or do 
  1445. early binding to improve performance. However, when 
  1446. types and functions changes at runtime, impacting a 
  1447. particular function, late binding occurs and the 
  1448. application automatically takes advantage of the 
  1449. new implementation of the function when it is 
  1450. called. 
  1451.   
  1452. Referential Integrity 
  1453. Since Odapter manages the relationships between 
  1454. objects, it can manage referential integrity on 
  1455. your behalf. That is, if an object referenced by 
  1456. other objects is deleted, the system removes all 
  1457. dependencies.  Your application code is simplified 
  1458. since Odapter is able to keep the logical business 
  1459. model intact automatically. 
  1460.   
  1461. Multimedia 
  1462. Odapter allows you to manage large, unformatted 
  1463. data in binary format and treat that data as an 
  1464. attribute of an object. For example, you may want 
  1465. to create a function called diagram to show the 
  1466. sections and seating for an Aircraft object. 
  1467. Multimedia information can include graphics, images 
  1468. and voice. You can also define functions in Odapter 
  1469. to manipulate this multimedia information. For 
  1470. example, you can create a function called showexits 
  1471. that adds information to the diagram. Thus, various 
  1472. applications can share these complex functions. 
  1473.   
  1474. Import Facility 
  1475. The Odapter Import facility allows developers to 
  1476. update existing Odapter functions with data from 
  1477. external files such as spreadsheets or other 
  1478. databases. This is an object-oriented version of 
  1479. the relational "bulk load" functionality. 
  1480.   
  1481. Enables Applications to Scale 
  1482.   
  1483. Odapter makes applications more scalable by storing 
  1484. objects in a choice of RDBMSs, like ORACLE7. As a 
  1485. result, applications can access large volumes of 
  1486. data, be used by a large numbers of users, and 
  1487. perform on-line backup. In addition, Odapter 
  1488. protects against unauthorized access from users in 
  1489. a distributed environment. 
  1490.   
  1491. Odapter, with the help of the underlying relational 
  1492. storage manager, ensures the integrity and security 
  1493. of your data while maximizing the availability of 
  1494. that data for end users. 
  1495.   
  1496. The following features enable applications to 
  1497. scale: 
  1498.   
  1499. Indexing 
  1500. Indexes are automatically generated when you create 
  1501. types and functions in Odapter. You can also define 
  1502. your own indexes using B-tree and hashing 
  1503. algorithms. Indexes make end user access to 
  1504. information faster. 
  1505.   
  1506. Clustering 
  1507. Related functions and objects which have the same 
  1508. value for a function can be stored close to each 
  1509. other. This ability to influence how objects are 
  1510. stored allows you to tune the performance of the 
  1511. database based on how the information will be 
  1512. accessed by applications. 
  1513.   
  1514. Transaction Management 
  1515. Odapter ensures the logical and physical integrity 
  1516. of your database by giving you complete control 
  1517. over the unit of work to be performed within a 
  1518. single transaction. With this control, you can save 
  1519. or rollback a transaction (throw away temporary 
  1520. work) at your discretion. Savepoints are also 
  1521. supported so that you can rollback parts of a 
  1522. transaction. 
  1523.   
  1524. Multi-user Concurrency Control 
  1525. Odapter is designed to support hundreds of users 
  1526. accessing the same information while guaranteeing 
  1527. the integrity of that information. 
  1528.   
  1529. Authorization 
  1530. You can control access to an Odapter enhanced 
  1531. database at the database and function levels based 
  1532. on individuals or groups of users. For example, 
  1533. authorization statements can provide read access to 
  1534. a large group of users while limiting write or 
  1535. delete access. 
  1536.   
  1537. High Availability 
  1538. Because Odapter actually stores objects in an 
  1539. RDBMS, Odapter can leverage RDBMS features to 
  1540. maximize the availability of your information by 
  1541. providing: 
  1542. * on-line backup of the database, to backup the 
  1543. database while it is being accessed 
  1544. * dual logging, to ensure the integrity of your 
  1545. log file 
  1546. * switch log, to automatically switch to a 
  1547. second log file if the original log file becomes 
  1548. full 
  1549. * dynamic file expansion, to expand the size of 
  1550. your database as it becomes full 
  1551.   
  1552. Odapter will also take advantage of other available 
  1553. features of the underlying relational database 
  1554. management system such as replication or "warm 
  1555. standby". 
  1556.   
  1557. Recovery 
  1558. Odapter uses the robust logging and recovery 
  1559. facilities of the RDBMS. In case of a failure, you 
  1560. can rollback work or perform rollforward recovery 
  1561. to a particular time, using the log file to 
  1562. recreate saved work. 
  1563.   
  1564. Odapter  Software Components 
  1565.   
  1566. Odapter uses a client/server architecture, enabling 
  1567. you to efficiently utilize your computing power. 
  1568. Clients use the object application call interface 
  1569. (OACI) to communicate with the server over the 
  1570. network. The clients and server components can also 
  1571. reside on the same machine. 
  1572.  
  1573.