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 / part6 < prev    next >
Encoding:
Text File  |  1995-07-25  |  58.4 KB  |  1,564 lines

  1. Subject: Comp.Object FAQ Version 1.0.7 (10-27) Part 6/10
  2. Newsgroups: comp.object,comp.answers,news.answers
  3. From: Bob Hathaway <rjh@geodesic.com>
  4. Date: 29 Oct 1994 11:42:24 GMT
  5.  
  6. Archive-name: object-faq/part6
  7. Last-Modified: 10/27/94
  8. Version: 1.0.7
  9.  
  10. Odapter is bundled with the following client and 
  11. server components, as shown in Figure 8: 
  12.   
  13. Client Components 
  14.   
  15. * Interactive Object-Oriented SQL (IOSQL) 
  16. This interface allows you to interactively enter 
  17. all Object-oriented SQL (OSQL) statements, 
  18. facilitating rapid prototyping and testing. IOSQL 
  19. provides query, administration and editing 
  20. capabilities. 
  21.   
  22. * Graphical Browser (GOSQL) 
  23. The Graphical Browser is a tool that allows you to 
  24. graphically explore your database schema and 
  25. contents, and execute any OSQL statement. This tool 
  26. is designed to assist application developers by 
  27. making it easier to view and manipulate your object 
  28. model stored in Odapter. 
  29.   
  30. * Windows OSQL (WINOSQL) 
  31. This PC-based interactive interface to OSQL allows 
  32. you to interactively enter all OSQL statements. 
  33.   
  34. * Object Application Call Interfaces (OACI) 
  35. Odapter provides client interface libraries for the 
  36. Smalltalk and C++ object-oriented programming 
  37. languages, allowing these languages to be tightly 
  38. coupled with Odapter. 
  39.   
  40. You can also write Odapter applications using any 
  41. programming language that can be linked with C 
  42. (such as Ada, COBOL, FORTRAN and Pascal). The 
  43. programmatic interface is similar to a "Dynamic 
  44. SQL" interface, and passes strings representing 
  45. OSQL statements to the Odapter server. No 
  46. preprocessors are required. 
  47.   
  48. Server Components 
  49.   
  50. * Odapter Object Manager 
  51. The Object Manager executes OSQL calls made by the 
  52. Odapter clients. The Object Manager processes 
  53. requests, and accesses data and code stored in the 
  54. Odapter enhanced relational data storage manager or 
  55. passes the request to a subsystem outside of 
  56. Odapter using Odapter External Functions. 
  57.   
  58. * External Functions 
  59. External functions allow you to access data and 
  60. code stored outside of Odapter, regardless of data 
  61. format or location. External functions can 
  62. automatically link to specific data sources using 
  63. the Odapter EDA-Objects class library and the 
  64. EDA/SQL product from Information Builder's, Inc. 
  65. (IBI). External functions can also be implemented 
  66. by you as subroutines written in general-purpose 
  67. programming languages and compiled outside of 
  68. Odapter. External functions can be called by any 
  69. OSQL statement, allowing you to manipulate this 
  70. remote data and application code like any other 
  71. Odapter object. For example, Figure 9 shows how 
  72. Odapter integrates diverse heterogeneous 
  73. information in an Oil and Gas environment. 
  74.   
  75. * EDA-Objects 
  76. HP and IBI have jointly developed an external 
  77. function library called EDA-Objects. Coupled with 
  78. IBI's EDA/SQL product, EDA-Objects provides 
  79. connections to over 50 commonly used databases on 
  80. 35 different platforms. The external function 
  81. library to connect to EDA/SQL is shipped with 
  82. Odapter; however, you must purchase other EDA/SQL 
  83. components from IBI directly to use the product. 
  84. EDA-Objects is one way to integrate external data 
  85. from multiple servers into a single business model 
  86. managed by Odapter. This is done without physically 
  87. moving the data or changing the applications which 
  88. are dependent on the data in its current form. 
  89.   
  90. Additional Products 
  91.   
  92. * Development Environments and Tools 
  93. Odapter allows you to use your favorite development 
  94. environments for application development. Some 
  95. tools are more tightly coupled with Odapter than 
  96. others. HP has recruited tools partners to address 
  97. all aspects of application development including 
  98. application design and analysis, data model 
  99. manipulation, fourth generation language 
  100. application development, report writing and legacy 
  101. data access. 
  102.   
  103. * Relational Database 
  104. Odapter uses a relational database as its storage 
  105. manager for the storage of Odapter objects. The 
  106. relational database performs physical file 
  107. management and database functions such as multi- 
  108. user concurrency, transaction management, and 
  109. recovery. The relational database allows you to 
  110. perform on-line backup and recovery, manage 
  111. physical distribution of files, maximize 
  112. availability and change database parameters. 
  113.   
  114. * COMPASS 
  115. COMPASS is a consulting product which includes the 
  116. Hewlett-Packard implementation of the 
  117. Petrotechnical Open Software Corporation (POSC) 
  118. Software Integration Platform (SIP) specification. 
  119. The SIP specification defines a data model and an 
  120. interface which allow users and applications to 
  121. access exploration and production data, independent 
  122. of the database engine technology. 
  123.   
  124. The COMPASS package is an add-on to Odapter and 
  125. includes: 
  126. * COMPASS specific consulting/training (1 day) 
  127. * POSC-based DAE interface library and documentation 
  128. * Interactive user interface called ixpres 
  129. * Archived copy of a pre-loaded Odapter 
  130. enhanced database with sample reference data 
  131. * Scripts for building a POSC-based Odapter 
  132. enhanced database 
  133. * Contributed software library (data loaders, 
  134. demonstration programs) 
  135.   
  136. COMPASS gives developers a 'jump start' on building 
  137. applications focused on petroleum exploration and 
  138. production. Other industries will find COMPASS an 
  139. inexpensive and useful approach for building 
  140. geographic information systems (GIS) and other 
  141. applications which can re-use of the cartography 
  142. (mapmaking) and geometric objects defined in the 
  143. model. 
  144.   
  145. POSC is a not-for profit organization created to 
  146. lower the costs associated with accessing and 
  147. integrating exploration and production data for the 
  148. oil and gas industry. 
  149.   
  150. System Environment 
  151.   
  152. Hardware       Operating    Memory      Disk Space 
  153. platform       System       (minimum)   (minimum)* 
  154.   
  155. HP 9000 S700   HP-UX 8.07   32MB        10MB + 
  156. S800           or later                 necessary 
  157.                                         swap space 
  158.   
  159. Sun            Solaris 1.0  32MB        10MB + 
  160.                (SunOS 4.3);             necessary 
  161.                Solaris 2.0              swap space 
  162.                (SunOS 5.2) 
  163.   
  164. IBM RS/6000    AIX 3.2.5    32MB        10MB + 
  165.                                         necessary 
  166.                                         swap space 
  167.   
  168. X Terminal                  6MB         none 
  169.   
  170. IBM PC         DOS 5.0,     4MB         1MB 
  171. compatible     MS-Windows 
  172.                3.1 or later 
  173. Table 1:  Odapter Client Environments 
  174.   
  175. * Swap space needed will depend on the complexity 
  176. of the application and the number of concurrent 
  177. users. Swap space will significantly increase the 
  178. necessary disc space. 
  179.   
  180. Hardware       Operating    Memory      Disk Space 
  181. platform       System       (minimum)   (minimum)* 
  182.   
  183. HP 9000 S700   HP-UX 9.0    64MB        15MB + 
  184. S800           or later                 necessary 
  185.                                         swap space 
  186. Table 2:  Odapter Server Environment 
  187.   
  188. * Additional memory may be required. Swap space 
  189. will significantly increase the necessary disc 
  190. space. The amount of memory and swap space depends 
  191. on the complexity of the application and the number 
  192. of concurrent users. 
  193.   
  194. Odapter Software Requirements 
  195.   
  196. To use Odapter, you will need one of the RDBMSs 
  197. listed below, TCP/IP transport and ARPA Berkeley 
  198. Services (for Unix systems), HP LAN Manager or 
  199. Microsoft LAN Manager (for the PC client) software. 
  200. To use the Odapter Graphical Browser, you will need 
  201. X11 X-Window support. 
  202.   
  203. Table 3: Relational Databases 
  204.   
  205.             Version          Memory      Disk Space 
  206.                              (minimum)   (minimum) 
  207.   
  208. ORACLE7     7.0.13 or later  refer to    refer to 
  209.             with "procedural Oracle      Oracle 
  210.             option" (PL/     manuals     manuals 
  211.             SQL), Pro*C, 
  212.             SQL*Plus & Oracle 
  213.             common libraries and 
  214.             utilities 
  215.   
  216. ALLBASE/SQL shipped with     64MB A/SQL  10MB 
  217.             OpenODB          and Odapter 
  218.   
  219. * ALLBASE/SQL is included with the Odapter 
  220. software. The combination of Odapter and 
  221. ALLBASE/SQL is known as OpenODB. 
  222.   
  223.   
  224. Ordering Information 
  225.   
  226. Software, training, consulting and support can be 
  227. purchased separately, as well as in bundles. 
  228. Pricing for the stand-alone software is based on 
  229. the number of user processes accessing a single 
  230. database server at the same time. Any number of 
  231. user licenses can be ordered. You must also order 
  232. the Odapter Media & Manuals product when ordering 
  233. the Developer's Bundle or the Concurrent User 
  234. License. HP standard support options are available 
  235. for all Odapter license and media products. 
  236. The OpenODB and Odapter products are sold together. 
  237. OpenODB is the combination of Odapter and 
  238. ALLBASE/SQL. You are only limited by the number of 
  239. concurrent licenses purchased for Odapter. 
  240.   
  241. Product Number and Product Description 
  242.   
  243. B3767BB  Odapter/OpenODB Concurrent User License 
  244. Software license only. Must order B3768BA to 
  245. receive software and manuals. Must specify number 
  246. of users. 
  247.   
  248. B3768BA  Odapter/OpenODB Media and Manuals  Must 
  249. choose media option. Includes software and one set 
  250. of manuals. Requires prior or concurrent purchase 
  251. of software license. 
  252.   
  253. B2470BA  Odapter/OpenODB Developer's Bundle 
  254. Includes 8 user software license, 5 days of on- 
  255. your-site consulting, one year of on-line support 
  256. and 2 passes to the Odapter/OpenODB Training Class. 
  257. Must order B3768BA to receive software and manuals. 
  258.   
  259. B3179A  Odapter/OpenODB Evaluator's Bundle 
  260. Includes a 40 user software license for 3 months, 
  261. media, documentation, 3 months of on-line support, 
  262. and 1 pass to the Odapter/OpenODB Training Class. 
  263.   
  264. B3184S  Odapter/OpenODB Training Class (5 days) 
  265.   
  266. B3185A  Odapter/OpenODB Reference Manuals  Includes 
  267. the Odapter/OpenODB Reference Manual and the 
  268. Odapter/OpenODB System Functions Manual. 
  269.   
  270. B3186A  Odapter/OpenODB Consulting  Customized 
  271. consulting in any of the following areas: COMPASS, 
  272. object-oriented analysis and design, schema design 
  273. and review, authorization/security design and 
  274. review, performance tuning, advanced usage, 
  275. Odapter/OpenODB application development planning 
  276. and review and implementation of access to legacy 
  277. data sources. 
  278.   
  279. To order these products, please contact your local 
  280. HP sales representative or one of the offices on 
  281. the back page of this document. 
  282.   
  283. Table 5. Odapter Features 
  284.   
  285. OBJECT-ORIENTED FEATURES 
  286. Aggregates (BAG, LIST, SET, TUPLE) 
  287. Complex Objects 
  288. Dynamic Schema Modification 
  289. Dynamic Typing 
  290. Encapsulation 
  291. External Functions 
  292. Functions (Stored Code or Methods) 
  293. Late Binding 
  294. Multiple Inheritance 
  295. Object Identity (OID) 
  296. Overloaded Functions 
  297. Type (Class) Hierarchy 
  298. User-defined Data Types 
  299. Versioning Primitives 
  300.   
  301. CLASS LIBRARIES 
  302. C++ 
  303. EDA-Objects 
  304. Smalltalk 
  305. Softbench 
  306.   
  307. CLIENT INTERFACES 
  308. Graphical Browser (GOSQL) 
  309. Import 
  310. Interactive OSQL 
  311. Object Application Call Interfaces (OACI): 
  312.   C++ 
  313.   SmallTalk 
  314.   C-linkable languages  (Ada, COBOL, FORTRAN, 
  315. Pascal) 
  316. Smalltalk Class Builder 
  317. Windows OSQL 
  318.   
  319. OSQL STATEMENTS 
  320. Add/Remove Type To/From Object 
  321. Add/Remove User 
  322. Begin/Commit/Rollback Work 
  323. Call Function 
  324. Change Owner 
  325. Change Password 
  326. Connect/Disconnect 
  327. Create/Delete Function 
  328. Create/Delete Index 
  329. Create/Delete Object 
  330. Create/Delete Type 
  331. Create/Delete User/Group 
  332. Declare/Delete variables 
  333. Grant/Revoke 
  334. If/Then/Else, While, For 
  335. Implement/Modify Function 
  336. Open/Fetch/Close Cursor 
  337. Raise Error 
  338. Security On/Off 
  339. Savepoint 
  340. Select 
  341. Store 
  342. Update 
  343.   
  344. PRIMITIVE DATA TYPES 
  345. Binary 
  346. Boolean 
  347. Character 
  348. Date 
  349. Datetime 
  350. Decimal 
  351. Floating Point 
  352. Integer 
  353. Interval 
  354. Small Integer 
  355. Time 
  356.   
  357. Sales Offices 
  358. For more information, call you local sales office 
  359. listed in your telephone directory or an HP 
  360. regional office listed below for the location of 
  361. your nearest sales office. 
  362.   
  363. United States: 
  364. 1-800-637-7740, extension 8521 
  365.   
  366. Canada: 
  367. Hewlett-Packard Ltd. 
  368. 6877 Goreway Drive 
  369. Mississauga, Ontario L4V 1M8 
  370. (416) 678-9430 
  371.   
  372. Japan: 
  373. Yokogawa-Hewlett-Packard Ltd. 
  374. 15-7, Nishi Shinjuku 4 Chome 
  375. Shinjuku-ku 
  376. Tokyo 160, Japan 
  377. (03) 5371-1351 
  378.   
  379. Latin America: 
  380. Hewlett-Packard 
  381. Latin American Region 
  382. Headquarters 
  383. 5200 Blue Lagoon 
  384. Suite 950 
  385. Miami, FL 33126 
  386. (305) 267-4220 
  387.   
  388. Australia New Zealand: 
  389. Hewlett-Packard Australia Ltd. 
  390. 31-41 Joseph Street 
  391. Blackburn, Victoria 3130 
  392. Australia (A.C.N. 004 394 763) 
  393. (03) 895 2805 
  394.   
  395. Asia Pacific: 
  396. Hewlett-Packard Asia Ltd. 
  397. 22/F Bond Centre, West Tower 
  398. 89 Queensway 
  399. Central, Hong Kong 
  400. (852) 848-7777 
  401.   
  402. Europe/Africa/Middle East: 
  403. Hewlett-Packard S.A. 
  404. 150, Route du Nant-d'Avril 
  405. CH-1217 Meyrin 2 
  406. Geneva, Switzerland 
  407. (22) 780 81 11 
  408.   
  409. Technical information in this document is subject 
  410. to change without notice. 
  411. All brand and product names appearing herewith are 
  412. registered trademarks or trademarks of their 
  413. respective holders. 
  414.   
  415. ` Copyright Hewlett-Packard Company 1994.  All 
  416. rights reserved.  Reproduction , adaptation, or 
  417. translation without prior written permission is 
  418. prohibited except as allowed under the copyright 
  419. law. 
  420. Printed in USA 7/94 
  421. 5963-2045E
  422.  
  423.  
  424. For more information, please send a message to 
  425. odapter@cup.hp.com with the subject of "index" or
  426. "help".  If you would like to speak with someone
  427. in person, please leave a voice mail message at
  428. the Odapter Support, Training and Consulting number,
  429. (408) 447-5051 and someone will get back to you
  430. as soon as possible.
  431.  
  432.  
  433. > POET <Persistent Objects and Extended Database Technology>  (BKS Software)
  434.  
  435. C++ Language Support
  436.  
  437. o    tight semantic integration with C++
  438. o    any C++ object or structure can be made persistent by adding the 
  439.      persistent keyword
  440. o    storing and reading a C++ object does not change its state or behavior
  441. o    full support for C++ encapsulation, object identity,  inheritance, and 
  442.      polymorphy
  443. o    C++ pointers and references are automatically converted to database 
  444.      references when storing objects
  445. o    database references are automatically converted to C++ pointers and 
  446.      references when reading objects
  447. o    all database definition is done through a small extension to C++ 
  448.      declaration syntax
  449.  
  450. Database Functionality
  451. navigation, queries, sorting, indexes, single-user operation, multi-user
  452. operation using client/server architecture, flexible locking for objects
  453. and sets, nested transactions, watch & notify for objects and sets,
  454. event handling, database size limited only by hard disk size
  455.  
  456. C++ Language Extensions
  457. persistence, indexes, transient data elements in persistent classes, sets,
  458. dependent objects
  459.  
  460. PTXX-Precompiler
  461. automatically converts extended C++ class declarations into ANSI 2.0 code,
  462. registers classes in the class dictionary, provides class versioning
  463.  
  464. Predefined C++ Classes
  465. date, time, strings, and BLOBS (binary large objects)
  466.  
  467. Portability
  468. all platforms are source-code compatible, any POET database may be read by
  469. any computer full support for heterogeneous networks
  470.  
  471. Platforms
  472. Available for MS-DOS / MS-Windows (Borland C++, Microsoft), 
  473. OS/2 (Borland C++), Novell, Macintosh MPW, and various Unix 
  474. systems, including NeXT (NeXTStep) and Sun OS (Sun C++).
  475.  
  476. How to Contact Us:
  477. BKS has offices in Santa Clara, Hamburg, and Berlin.  Silicon 
  478. River, Limited, is responsible for POET in the United Kingdom.  
  479.  
  480. Santa Clara:    (North America, Australia, Asia)
  481.  
  482. BKS Software
  483. 4633 Old Ironsides Drive  Suite 110
  484. Santa Clara, CA 95054
  485. Phone:  408 / 748 - 3403
  486. Fax:    408 / 748 - 9060
  487.  
  488. Contact Person: jrobie@netmbx.netmbx.de (Jonathan Robie)
  489.  
  490.  
  491. > Statice (Symbolics)
  492.  
  493. From: fischerm@darmstadt.gmd.de (Markus Fischer)
  494. Newsgroups: comp.databases.object,comp.lang.lisp
  495. Subject: Statice now runs on Unix
  496. Date: 15 Jun 93 14:55:48 GMT
  497.  
  498. Hi there,
  499.  
  500. since I've never seen 'Symbolics' or 'Statice' in
  501. comp.database.object, this might be interesting:
  502.  
  503. A few days ago, Symbolics announced the availability of a beta-
  504. release of their ODBMS 'Statice' on Unix platforms. It is quite
  505. powerful and tightly integrated within Common Lisp.
  506. Currently, Symbolics and LUCID are supported.
  507. People (like me) used to Symbolics' Genera development environment 
  508. can continue to use Statice there (where it has been already
  509. successfully employed in 'real world' applications)
  510. and now also use it on Unix Workstations.  (Those are the cheaper
  511. boxes, I guess). Both kinds of platforms can be freely intermixed
  512. in a network.
  513.  
  514. Statice is based on standards of Lisp: CLOS and CLIM 
  515. (Common Lisp Object System, resp. Common Lisp Interface Manager)
  516.  
  517. Here's the address of Symbolics in Germany; they're mostly 
  518. responsible for Statice on Unix:
  519.  
  520. Symbolics Systemhaus GmbH
  521. Mergenthalerallee 77
  522. 6236 Eschborn (til June 31)
  523. 65760 Eschborn (from July 1)
  524. Tel. (49) 6196-47220, Fax (49) 6196-481116
  525.  
  526. Contact person is Dr. Thomas Neumann (TN@symbolics.de).
  527.  
  528. Also:
  529.  
  530. "Update Database Schema" brings an existing database into conformance
  531. with a modified schema.  Changes are classified as either compatible
  532. (lossless, i.e., completely information-preserving) or incompatible
  533. (i.e., potentially information-losing in the current implementation).
  534. Basically, any change is compatible except for the following:
  535.  
  536.     -- If an attribute's type changes, all such attributes extant
  537.     are re-initialized (nulled out).  Note that Statice permits
  538.     an attribute to be of type T, the universal type.  Such an
  539.     attribute can then take on any value without schema
  540.     modification or information loss.
  541.  
  542.     -- If a type's inheritance (list of parents) changes, the
  543.     type must be deleted and re-created, losing all extant
  544.     instances of that type. This is Statice's most serious
  545.     current limitation.  The simplest workaround is to employ a
  546.     database dumper/loader (either the one supplied by Symbolics
  547.     or a customized one) to save the information elements and
  548.     then reload them into the modified schema.
  549.  
  550. [Lawrence G Mayka <lgm@IExist.ATT.COM>]
  551.  
  552.  
  553. > UniSQL
  554.  
  555. UniSQL offers a state-of-the-art suite of integrated object-oriented database
  556. systems and application development products which can be used separately or
  557. together to support complex development projects which use object-oriented
  558. development techniques, integrate sophisticated multimedia data, and require
  559. true multidatabase access to relational and object-oriented databases. The
  560. UniSQL product suite includes:
  561.  
  562.         UniSQL/X Database Management System;
  563.         UniSQL/M Multidatabase System; and
  564.         UniSQL/4GE Application Development Environment
  565.         User interfaces include: C++, C, Object SQL, SmallTalk, and ODBC
  566.         Database interfaces include: Ingres, Oracle, Sybase, UniSQL/X, and EDA/SQL
  567.  
  568. UniSQL offers:
  569.  
  570. - A wide selection of user interfaces including C++, SmallTalk, C, Microsoft's
  571.   ODBC, both embedded (static and dynamic) and interactive Object SQL, and UniSQL
  572.   and 3rd-party development tools.
  573.  
  574. - Mission-critical database features such as a high-level query language
  575.   (SQL/X), cost-based query optimization, automatic transaction management,
  576.   automatic concurrency control, dynamic schema evolution, dynamic authorization,
  577.   physical disk structuring options, and installation tuning parameters.
  578.  
  579. - The UniSQL Multimedia Framework which provides natural and uniform database
  580.   system support for all types of large unstructured data objects. The Multimedia
  581.   Framework also provides for seamless integration of multimedia devices such as
  582.   fax machines, CD jukeboxes, satellite feeds, image compression boards, etc.
  583.  
  584. - The UniSQL/M Multidatabase System enables developers to manage a collection
  585.   of multi-vendor databases -- Ingres, Oracle, Sybase, DB2, UniSQL/X, and others
  586.   -- as a single federated database system with full object-oriented
  587.   capabilities.
  588.  
  589. UniSQL has well over 150 customers around the world, the majority of which are
  590. using UniSQL database products for mission-critical applications which require
  591. object-oriented, multimedia, post-relational, and heterogeneous database
  592. capabilities.
  593.  
  594. A typical UniSQL customer is a Fortune 500 company, a commercial software
  595. developer, or government organization that is using UniSQL database products
  596. to:
  597.  
  598. - support mission-critical application development projects which are being
  599.   developed using object-oriented programming languages and development
  600.   techniques,
  601.  
  602. - support applications which must integrate many different types of corporate
  603.   data -- text and documents, tabular data, images and audio, engineering
  604.   drawings, GIS data, procedural data (programs), etc. -- into a single
  605.   application context.
  606.  
  607. - support the full object-oriented development paradigm using existing
  608.   relational database systems such as Ingres, Oracle, Sybase, and DB2.
  609.  
  610. - logically integrate one or more relational and object-oriented databases to
  611.   form a single, homogenized database server which supports both relational and
  612.   object-oriented facilities.
  613.  
  614. In September 1992, UniSQL was selected by the Petrotechnical Open Software
  615. Corporation (POSC) -- over more than 25 other industry vendors -- to provide
  616. database technology which is being used by POSC in their development of a new
  617. data management specification for the oil & gas industry. Also during 1992,
  618. because of its powerful multimedia capabilities, UniSQL was selected by the MIT
  619. AthenaMuse Consortium on multimedia as the consortium's multimedia database
  620. system.
  621.  
  622. During the DB/EXPO '93 Conference and Exhibition, UniSQL was chosen in
  623. competition with major industry database vendors as a finalist in the
  624. ``RealWare Awards''.  The ``RealWare Awards'' honor companies that have
  625. had a major impact in the user community.
  626.  
  627. UniSQL was founded in May 1990 by Dr. Won Kim, President and CEO, delivering
  628. the UniSQL/X DBMS in March of 1992. With its world-class database research and
  629. architectural team, UniSQL has perfected what the database industry has sought
  630. since the mid-1980s: a fully object-oriented data model that is a natural
  631. conceptual outgrowth of the popular relational model. Both the UniSQL/X DBMS
  632. and the UniSQL/M Multidatabase System represent the first of a powerful new
  633. generation of client-server database systems that support the full
  634. object-oriented paradigm yet retain all of the strengths and capabilities of
  635. relational database systems including support for ANSI-standard SQL.
  636.  
  637. UniSQL currently has 45 employees and is privately owned and managed by Dr.
  638. Kim. The company has secured long-term funding from NTT Data Communications
  639. Systems Corp. (NTT Data), a $2 billion company, which is Japan's foremost
  640. systems integrator and UniSQL's exclusive distributor in Japan.
  641.  
  642. For more information, contact:
  643.  
  644.         UniSQL, Inc.
  645.         9390 Research Blvd., II-200
  646.         Austin, Texas 78759-6544
  647.         Tel.: 512/343-7297
  648.         Tollfree: 800/451-DBMS
  649.         Fax.: 512/343-7383
  650.  
  651. And:
  652. From: jonh@unisql.UUCP (Jon Higby)
  653. Newsgroups: comp.databases,comp.databases.theory,comp.databases.object,comp.object
  654. Subject: Re: SQL3, Itasca, & UniSQL/X
  655. Message-ID: <6143@unisql.UUCP>
  656. Date: 10 Sep 93 14:26:04 GMT
  657. References: <CD1Ln5.9G3@dcs.glasgow.ac.uk>
  658. Organization: UniSQL, Inc., Austin, Texas, USA
  659.  
  660. >>...
  661. For UniSQL/X, feel free to contact me (email, snail-mail or phone).
  662.  
  663. UniSQL/X is a SQL compliant database with Object Oriented extensions
  664. (classes, inheritance, methods, etc).  We have an information packet
  665. available which includes a white-paper on our OORDMS approach.
  666.  
  667. Jon Higby
  668. Technical Services Consultant
  669.  
  670. UniSQL, Inc.
  671. 9390 Research II, Suite 200
  672. Austin, Texas  78759-6544
  673. (512) 343-7297
  674.  
  675. *****************************************************************************
  676. Standard disclaimer ... All opinions expressed are my own and not of my 
  677.                         employer.......................................
  678. *****************************************************************************
  679.  
  680.  
  681.  
  682. > Versant (Versant Object Technology)
  683.  
  684. Versant is a client/server object database management system (ODBMS) targeted at
  685. distributed, multi-user applications.  Versant runs on UNIX and PC platforms, 
  686. including Sun, IBM, HP, DEC, SGI, Sequent, OS/2, with support for Windows NT is 
  687. planned during 1993.
  688.  
  689. Versant provides transparent language interfaces from object-oriented 
  690. programming languages such as C++ and Smalltalk.  Versant also supports a C API.
  691.  
  692. Versant is built with an object-level architecture, which means that operations 
  693. are generally performed on the object (or group thereof) level.  Key Versant 
  694. features include:
  695.  
  696.  Performance
  697.  -----------
  698.  
  699. *  Object-level locking for fine granularity concurrency control
  700. *  Server-based query processing to reduce network I/O
  701. *  Dual caching to speed warm traversals
  702. *  Dynamic space reclamation and reuse
  703.  
  704.  Distribution
  705.  ------------
  706.  
  707. *  Immutable, logical object identifiers for data integrity
  708. *  Object migration (transparent relocation across nodes)
  709. *  Transparent cross-node references (distributed db)
  710. *  Automatic two-phase commit
  711.  
  712.  Other
  713.  -----
  714.  
  715. *  Schema evolution (online via lazy updates)
  716. *  Standard workgroup features (e.g., versioning, checkin/out)
  717. *  Detachable, personal databases
  718. *  DBA utilities
  719.  
  720.  
  721. Additional information available from
  722.  
  723. info@versant.com  (General information)
  724. davek@versant.com (Dave Kellogg)
  725.  
  726. Versant Object Technology 
  727. 1380 Willow Road
  728. Menlo Park, California  94025
  729.  
  730. 415-329-7500 phone.
  731. 415-325-2380 fax.
  732.  
  733.  
  734. On Schema Evolution (from original survey):
  735. We support run-time schema evolution.  It uses a lazy scheme, so
  736. schema operations are very fast.  Objects on disk may have an older
  737. `storage class' and they will be updated to the new schema when they
  738. are used.
  739.  
  740. In older releases schema evolution was allowed only on leaf classes
  741. (those with no subclasses).  In our new release 2 (going to beta test
  742. soon) you can do schema evolution on any class.
  743.  
  744. In the future we're working on more general view mechanisms so you can
  745. see a subset of the attributes in memory, or some more complicated
  746. transformation.  This goes together with support for multiple
  747. compilers and multiple languages.
  748.  
  749. [Joe Keane <osc!jgk@amd.com>]
  750.  
  751. Also: 1-800-Versant
  752.  
  753.  
  754.  
  755.  
  756. Other Models
  757. ------------
  758.  
  759. Research Systems
  760. ________________
  761.  
  762. > GRAS
  763.  
  764. --------------------------------------------------------------
  765. GRAS - A Graph-Oriented Database System for SE Applications
  766. Copyright (C) 1987-1993  Lehrstuhl Informatik III, RWTH Aachen
  767. --------------------------------------------------------------
  768.  
  769. See the GNU Library General Public License for copyright details.
  770.  
  771. Contact Adresses:
  772.  
  773.     Dr. Andy Schuerr 
  774.     Lehrstuhl fuer Informatik III,
  775.     University of Technology Aachen (RWTH Aachen),
  776.     Ahornstr. 55,
  777.     D-5100 Aachen
  778.  
  779. Email to
  780.  
  781.     andy@i3.informatik.rwth-aachen.de
  782.  
  783. GRAS is a database system which has been designed according
  784. to the requirements resulting from software engineering
  785. applications. Software development environments are composed
  786. of tools which operate on complex, highly structured data.
  787. In order to model such data in a natural way, we have selected
  788. attributed graphs as GRAS' underlying data model.
  789.  
  790. A first prototype of the GRAS (GRAph Storage) system - described
  791. in /BL 85/ - was already realized in 1985. Since this time
  792. gradually improving versions of the system have been used at
  793. different sites within the software engineering projects
  794. IPSEN /Na 90/, Rigi /MK 88/, MERLIN /DG 90/, and CADDY /EHH 89/.
  795. Based on these experiences, almost all parts of the original
  796. prototype have been redesigned and reimplemented.
  797.  
  798. Thus, nowadays a stable and efficiently working single-process
  799. version of the system GRAS with interfaces for the programming
  800. languages Modula-2 and C is available as free software for Sun
  801. workstations (the GRAS system itself is implemented in Modula-2
  802. and consists of many layers which might be reusable for the
  803. implementation of other systems):
  804.  
  805.   Via anonymous ftp from ftp.informatik.rwth-aachen.de
  806.   in directory /pub/unix/GRAS in file gras.<version-no>.tar.Z.
  807.  
  808.   There are several files containing documentation, sources, binaries,
  809.   application examples, and libraries. All binaries are for Sun/4
  810.   machines. Sun/3 binaries are shipped only if explicitly requested.
  811.  
  812.   You have to use the following sequence of operations for installing
  813.   the GRAS system at your site:
  814.  
  815.   1) 'ftp ftp.informatik.rwth-aachen.de' (with login name "anonymous"
  816.      and password equal to your mail address).
  817.   2) 'cd pub/unix/GRAS' (for changing the current directory).
  818.   3) 'binary' (command for changing ftp mode).
  819.   4) 'get gras.<version-no.>' (use 'ls' for finding the currently used
  820.       GRAS version nr.).
  821.   5) 'bye' (for exiting ftp).
  822.   6) 'uncompress gras.<version-no>.tar'.
  823.   7) 'tar xvf gras.<version-no>.tar' (creates a subdirectory GRAS_2 for
  824.      the Modula-2 implementation of GRAS including its C-interface).
  825.   8) Follow the instructions in file GRAS_2/README.
  826.  
  827.  
  828. The current version has programming interfaces for Modula-2 and C
  829. and supports:
  830.  
  831.   - the manipulation of persistent attributed, directed node- and
  832.     edge-labeled graphs (including the creation of very long
  833.     attributes and of attribute indexes).
  834.  
  835.   - the manipulation of temporary/volatile generic sets/relations/lists,
  836.  
  837.   - the coordination of graph accesses by different GRAS applications
  838.     (multiple-read/single-write access with graphs as lock units),
  839.  
  840.   - error recovery based on shadow pages and forward logs,
  841.  
  842.   - nested transactions and linear undo/redo of arbitrarily long
  843.     sequences of already committed graph modifying operations based
  844.     on forward and backward logs,
  845.  
  846.   - event-handling (with certain kinds of graph-modifications
  847.     as events and graph-modifying transactions as event-handlers),
  848.  
  849.   - primitives for version control comprising the capability
  850.     for efficiently storing graphs as forward/backward deltas to
  851.     other graphs,
  852.  
  853.   - and primitives for declaring graph schemes and for incremental
  854.     evaluation of derived attributes.
  855.  
  856. Furthermore, tools for (un-)compressing graphs and a X11R5-based
  857. graph browser are part of this release.
  858.  
  859. A multi-process version of the system GRAS supporting the inter-
  860. action of multiple client and multiple server processes within
  861. one local area network is nearby completion (version 6.0/0).
  862.  
  863. Thus, the GRAS system may be considered to be the core of a graph
  864. oriented DBMS environment. The development of such an environment
  865. based on a very high-level specifications language named PROGRES
  866. is under way (the underlying calculus of this specification language
  867. are so-called PROgrammed GRaph REwriting Systems).
  868.  
  869. This environment will comprise the following tools (a prerelease
  870. of this environment might be made available upon request):
  871.  
  872.   - a syntax-directed editor for graph schemes, graph rewrite rules,
  873.     and sequences of graph rewrite rules,
  874.  
  875.   - an incrementally working consistency checker,
  876.  
  877.   - an incrementally working compiler&interpreter translating
  878.     PROGRES specifications into sequences of GRAS procedure
  879.     calls (for C as well as for Modula-2),
  880.  
  881.   - and an "enhanced" graph (scheme) browser.
  882.  
  883.  
  884. References
  885. ----------
  886.  
  887. Refer to the following publications for further info about GRAS, PROGRES,
  888. and related topics:
  889.  
  890. /BL85/          Brandes, Lewerentz: A Non-Standard Data Base System within
  891.                 a Software Development Environment. In Proc. of the Workshop
  892.                 on Software Engineering Environments for Programming-in-the-
  893.                 Large, pp 113-121, Cape Cod, June 1985
  894.  
  895. /DHKPRS90/      Dewal, Hormann, Kelter, Platz, Roschewski, Schoepe: Evaluation
  896.                 of Object Management Systems. Memorandum 44, University
  897.                 Dortmund, March 1990
  898.  
  899. /Feye92/    Feye A.: Compilation of Path Expressions (in German), Diploma
  900.         Thesis, RWTH Aachen (1992)
  901.  
  902. /Hoefer92/    Hoefer F.: Incremental Attribute Evaluation for Graphs (in
  903.         German), Diploma Thesis, RWTH Aachen (1992)
  904.  
  905. /HPRS90/        Hormann, Platz, Roschweski, Schoepe: The Hypermodel Benchmark,
  906.                 Description, Execution and Results. Memorandum 53, University
  907.                 Dortmund, September 1990
  908.  
  909. /KSW92/ *       Kiesel, Schuerr, Westfechtel: GRAS, A Graph-Oriented Database
  910.                 System for (Software) Engineering Applications. Proc. CASE 93,
  911.         Lee, Reid, Jarzabek (eds.): Proc. CASE '93, 6th Int. Conf. on
  912.         Computer-Aided Software Engineering, IEEE Computer Society
  913.         Press (1993), pp 272-286
  914.         Also:  Technical Report AIB 92-44, 
  915.  
  916. /Klein92/    Klein P.: The PROGRES Graph Code Machine (in German), Diploma
  917.         Thesis, RWTH Aachen (1992)
  918.  
  919. /Kossing92/    Kossing P.: Modelling of Abstract Syntax Graphs for normalized
  920.         EBNFs (in German), Diploma Thesis, RWTH Aachen (1992)
  921.  
  922. /LS88/          Lewerentz, Schuerr: GRAS, a Management System for Graph-
  923.                 Like Documents. In Proceedings of the Third International
  924.                 Conference on Data and Knowledge Bases, Morgan Kaufmann
  925.                 Publ. Inc. (1988), pp 19-31
  926.  
  927. /Nagl89/        Nagl (ed.): Proc. WG'89 Workshop on Graphtheoretic Concepts
  928.                 in Computer Science, LNCS 411, Springer-Verlag (1989)
  929.  
  930. /NS91/          Nagl, Schuerr: A Specification Environment for Graph Grammars,
  931.                 in Proc. 4th Int. Workshop on Graph-Grammars and Their
  932.                 Application to Computer Science, LNCS 532, Springer-
  933.                 Verlag 1991, pp 599-609
  934.  
  935. /Schuerr89/     Schuerr: Introduction to PROGRES, an Attribute Graph Grammar
  936.                 Based Specification Language, in: /Nagl89/, pp 151-165
  937.  
  938. /Schuerr91a/ *  Schuerr: PROGRES: A VHL-Language Based on Graph Grammars,
  939.                 in Proc. 4th Int. Workshop on Graph-Grammars and Their
  940.                 Application to Computer Science, LNCS 532, Springer-
  941.                 Verlag 1991, pp 641-659
  942.         Also:  Technical Report AIB 90-16
  943.  
  944. /Schuerr91b/    Schuerr: Operational Specifications with Programmed Graph
  945.         Rewriting Systems: Theory, Tools, and Applications, 
  946.         Dissertation, Deutscher Universitaetsverlag (1991) (in German)
  947.  
  948. /SZ91/ *        Schuerr, Zuendorf: Nondeterministic Control Structures for
  949.                 Graph Rewriting Systems, in Proc. WG'91 Workshop in Graph-
  950.                 theoretic Concepts in Computer Science, LNCS 570, Springer-
  951.                 Verlag 1992, pp 48-62
  952.         Also: Technical Report AIB 91-17
  953.  
  954. /Westfe89/      Westfechtel: Extension of a Graph Storage for Software
  955.                 Documents with Primitives for Undo/Redo and Revision Control.
  956.                 Technical Report AIB Nr. 89-8, Aachen University of Technology,
  957.                 1989
  958.  
  959. /Westfe91/      Westfechtel: Revisionskontrolle in einer integrierten Soft-
  960.                 wareentwicklungsumgebung, Dissertation, RWTH Aachen, 1991
  961.  
  962. /Zuendorf89/    Zuendorf: Kontrollstrukturen fuer die Spezifikationssprache
  963.                 PROGRES, Diplomarbeit, RWTH Aachen, 1989
  964.  
  965. /Zuendorf92/ *  Zuendorf A.: Implementation of the Imperative/Rule Based
  966.                 Language PROGRES, Technical Report AIB 92-38, RWTH Aachen,
  967.                 Germany (1992)
  968.  
  969. /Zuendorf93/ *  Zuendorf A.: A Heuristic Solution for the (Sub-) Graph
  970.                 Isomorphism Problem in Executing PROGRES, Technical
  971.                 Report AIB 93-5, RWTH Aachen, Germany (1993)
  972.  
  973. * : All reports marked with an asterisk are available via anonymous ftp from
  974.     ftp.informatik.rwth-aachen.de in directory /pub/reports/... .
  975.  
  976. See also PROGRES documentation.
  977.  
  978. [See also APPENDIX E]
  979.  
  980.  
  981. > IRIS (HP Labs)
  982.  
  983. [Iris is a system out of HP Labs that began as a prototype and eventually
  984. became a commercial product.  I believe it was eventually incorporated into
  985. the new HP product, OpenODB. - clamen]
  986.  
  987. Long and short system summaries can be found in:
  988.  
  989. [FISH89] D.H. Fishman et. al. Overview of the Iris DBMS. In Won.
  990.          Kim and Frederick H. Lochovsky, editors,
  991.          Object-Oriented Concepts, Databases and Applications,
  992.          chapter 10, pages 219--250. Addison-Wesley, Reading,
  993.          MA, 1989.
  994.  
  995. [FBC+87] D.H. Fishman, D. Beech, H.P. Cate, E.C. Chow,
  996.          T. Connors, J.W. Davis, N. Derrett, C.G. Hock, W. Kent,
  997.          P. Lyngbaek, B. Mahbod, M.A. Neimat, T.A. Tyan, and
  998.          M.C. Shan. Iris:  An object-oriented database
  999.          management system. ACM Transactions on Office
  1000.          Information Systems, 5(1):48--69, January 1987.
  1001.  
  1002. The abstract of the latter (written early in the project) follows:
  1003.  
  1004.    The Iris database management system is a research prototype of
  1005.    a next-generation database management system intended  to meet
  1006.    the needs of new and emerging database applications, including
  1007.    office    automation and knowledge-based systems,  engineering
  1008.    test and measurement, and hardware  and software design.  Iris
  1009.    is exploring a rich set of  new database capabilities required
  1010.    by    these   applications,   including  rich    data-modeling
  1011.    constructs, direct  database support for inference,  novel and
  1012.    extensible data types, for example to  support graphic images,
  1013.    voice,    text,   vectors,  and  matrices,    support for long
  1014.    transactions   spanning  minutes  to  many  days, and multiple
  1015.    versions of data.  These capabilities are, in addition  to the
  1016.    usual support for  permanence   of data, controlled   sharing,
  1017.    backup and recovery.
  1018.  
  1019.    The   Iris   DBMS consists   of  (1) a  query   processor that
  1020.    implements  the   Iris object-oriented  data    model, (2)   a
  1021.    Relational Storage Subsystem (RSS) -like  storage manager that
  1022.    provides  access paths and  concurrency  control, backup   and
  1023.    recovery, and (3) a collection of programmatic and interactive
  1024.    interfaces.  The data   model supports  high-level  structural
  1025.    abstractions,  such  as  classification, generalization,   and
  1026.    aggregation, as  well  as behavioral    abstractions.      The
  1027.    interfaces to  Iris  include an  object-oriented extension  to
  1028.    SQL.
  1029.  
  1030.  
  1031. On Schema Evolution (from original survey):
  1032. Objects in the Iris system may acquire or lose types dynamically.
  1033. Thus, if an object no longer matches a changed definition, the user
  1034. can choose to remove the type from the object instead of modifying the
  1035. object to match the type.  In general, Iris tends to restrict class
  1036. modifications so that object modifications are not necessary.  For
  1037. example, a class cannot be removed unless it has no instances and new
  1038. supertype-subtype relationships cannot be established.
  1039.  
  1040.  
  1041. Commercial Systems
  1042. __________________
  1043.  
  1044.  
  1045. > IDL (Persistent Data Systems)
  1046.  
  1047. IDL is a schema definition language. Schema modifications are defined
  1048. in IDL, requiring ad-hoc offline transformations of the database, in
  1049. general.  A simple class of transformations can be handled by
  1050. IDL->ASCII and ASCII->IDL translators (i.e., integer format changes,
  1051. list->array, attribute addition).
  1052.  
  1053. [conversation with Ellen Borison of Persistent Data Systems]
  1054.  
  1055.  
  1056. ADDITIONAL REFERENCES:
  1057.         John R. Nestor. "IDL: The Language and Its
  1058.         Implementation". Prentice Hall. Englewood Cliffs,
  1059.         NJ., 1989.
  1060.  
  1061.  
  1062.  
  1063. > Kala
  1064.                          Kala Technical Brief
  1065.  
  1066. Summary
  1067.  
  1068. Kala(tm) is a Persistent Data Server managing distributed, shared,
  1069. arbitrarily complex and evolving persistent data. Kala is highly
  1070. efficient and secure. Kala manages the visibility of persistent data
  1071. elements to its clients, thus supporting any types of transactions,
  1072. versions, access control, security, configurations. Kala does not
  1073. restrict you to any particular model. Kala provides the mechanism, but
  1074. imposes no policy. Usable as either a link library communicating to a
  1075. server or as a standalone, Kala is compact and simple.
  1076.  
  1077. Kala is used for applications such as: kernel of DBMS products,
  1078. substrate for extended file systems, implementation of language
  1079. persistence, data manager for groupware applications as well as
  1080. applications which deal with large, complex, and changing volumes of
  1081. data (text databases, financial distributed transaction systems). Our
  1082. current customers use Kala in applications ranging from CASE
  1083. repositories to CAD systems, from document management for financial
  1084. institutions to OODBMS platforms, from real-time applications to
  1085. database research.  Kala is a component of broad reuse.
  1086.  
  1087.  
  1088. Motivation
  1089.  
  1090. The simplest persistent data storage available to you is the file
  1091. system on your disk drive. File systems have some attractive
  1092. characteristics; their performance is good, they can hold any data,
  1093. they're easy to use, and, of course, the price is right. Conversely,
  1094. files are unreliable.  They provide no mechanism for in maintaining
  1095. data consistency and only primitive data sharing facilities. Few file
  1096. systems offer version control and all require that you transform data
  1097. between "internal" and "external" forms all the time.
  1098.  
  1099. Unlike a file system, a true database management system provides
  1100. mechanisms for sharing data and for ensuring the integrity of the
  1101. data.  It supports transactions and version control, although the
  1102. specifics of these functions may not be exactly what your application
  1103. needs. Finally, a database system is scalable, and much more robust
  1104. than a file when your hardware or software fails.
  1105.  
  1106. The downside to a database system is that, compared to a file system,
  1107. it is slower by an order of magnitude or more. Also, a database system
  1108. generally confines you to dealing only with the kind of data that it
  1109. can handle. In addition, a database is usually very complicated,
  1110. difficult to learn and use, and expensive, both in terms of your cost
  1111. of operation and in the amount of system resources they consume.
  1112.  
  1113. Whether you choose a file system or a database manager, then, you
  1114. have to sacrifice either economy or performance. Is there a happy
  1115. medium?  Something with the speed and flexibility of files, the
  1116. reliability, shareability and robustness of databases, and at a cost
  1117. that won't break your wallet or the available hardware? Sure there is!
  1118. Kala is a first in a new breed of products, persistent data servers,
  1119. aimed squarely at the yawning gap between DBMSs and file systems.
  1120.  
  1121.  
  1122. Overview
  1123.  
  1124. Kala is *not* a DBMS. Instead, you use Kala whenever the few canned
  1125. combinations of DBMS features do not meet the needs of your
  1126. application. A DBMS product constrains you to accept *its* choice of
  1127. an end-user graphical interface, a query language binding, a specific
  1128. high level data or object model, a particular transaction model, a
  1129. single versioning scheme, etc. This either compromises your
  1130. application's functionality, or forces your to spend substantial
  1131. development effort and money to bridge the impedance mismatch to the
  1132. application.  Instead, Kala allows *you* to develop no more and no
  1133. less than the functionality you need. You build your domain specific
  1134. functionality our of a small set of primitives with very little code.
  1135. Your gains in productivity, efficiency, and flexibility are
  1136. substantial.
  1137.  
  1138. To sustain this level of flexibility and reuse, Kala manages any data
  1139. that you can represent in machine memory out of bits and references.
  1140. Examples include records, dynamically linked graphs and lists,
  1141. executable code, and object encapsulations.
  1142.  
  1143. Kala can handle data as small as one bit, and as large as the virtual
  1144. memory and more, while being totally unaware of the data's semantics.
  1145. Its stores and retrieves data efficiently, and compactly over a
  1146. distributed and dynamically reconfigurable set of Stores. Upon
  1147. retrieval, Kala dynamically relocates embedded references to retain
  1148. the original topological structure of the data, thus preserving
  1149. referential integrity. Kala also supports active data, physical store
  1150. management, and automatic archiving.
  1151.  
  1152. Kala repackages the fundamentals and universals of data management in
  1153. one reusable data server, separating them from the application domain
  1154. specific models and policies. Kala defines a low level interoperabi-
  1155. lity point for the data storage domain, just as X does for the display
  1156. domain and Postscript does for the printing domain.
  1157.  
  1158. Kala has matured through four successive versions to its present
  1159. industrial strength implementation and stable API. Kala is lean,
  1160. compact, and portable. Kala is a high performance, low overhead
  1161. system. We call it a Reduced Instruction Set Engine (RISE). Unlike
  1162. large, complex, and typically bulky DBMS products, Kala is small,
  1163. simple, and suitable for managing anywhere from a single diskette to
  1164. terabytes of distributed data.
  1165.  
  1166.  
  1167. Benefits
  1168.  
  1169. * For those who need functionality traditionally associated with
  1170.   databases, but cannot tolerate the overhead and complications DBMS
  1171.   products introduce, Kala offers a flexible, compact, performant,
  1172.   elegant, and simple alternative.
  1173.  
  1174. * For those whose application domain requires data models where the
  1175.   mapping to those offered by today's DBMS products is cumbersome,
  1176.   introduces development and execution overhead, and is not portable
  1177.   across multiple linguistic and environmental platforms, Kala offers
  1178.   a data model independent interface against any data model
  1179.   expressible in terms of bits and pointers can be easily built.
  1180.  
  1181. * For those who need DBMS functionality or qualities that no single
  1182.   DBMS product now has, Kala offers the opportunity to build that
  1183.   functionality now with little effort out of a simple set of
  1184.   primitives, and not wait for one vendor or another to deliver
  1185.   it later.
  1186.  
  1187. * For those who have determined that the only viable option for their
  1188.   application's persistent data needs is the file system, and have
  1189.   resined to the idea that they will have to build everything else
  1190.   they need from scratch, Kala offers an off-the-shelf implementation
  1191.   without loss of any of files' advantages.
  1192.  
  1193. * For those who need performance, size, portability, storage
  1194.   compactness, and industrial strength that no single DBMS product can
  1195.   now satisfy, Kala offers all of the above now.
  1196.  
  1197. * For those who realize that while object-level interoperability is a
  1198.   strong desideratum, the likelihood of a single, universal such model
  1199.   in the foreseeable future is quite low, Kala offers a solid, long
  1200.   term alternative. Data store interoperability that brings us beyond
  1201.   file systems is the best practical bet. Kala is the basis for data
  1202.   store interoperability now.
  1203.  
  1204. * Finally, for all of you who are concerned about the economics of
  1205.   software, and take the view that there are many elements that
  1206.   could contribute negatively to the soundness of your business, such
  1207.   as operational costs, software maintenance costs, software licensing
  1208.   costs, software development and learning costs, etc., you will find
  1209.   Kala an economically sound, sensible, and practical product.
  1210.  
  1211.  
  1212. Features
  1213.  
  1214. - The execution architecture is that of multiple (communicating)
  1215.   servers and multiple clients. Kala can also be configured in a
  1216.   standalone (single process) mode. Kala's IPC is built for maximum
  1217.   performance, portable to any given datagram protocol.
  1218.  
  1219. - The managed data elements are made out of uninterpreted bits and
  1220.   references. Data elements (named `monads') are universally uniquely
  1221.   identified. Bits are stored with no overhead. References,
  1222.   represented in memory as native machine pointers, are stored
  1223.   very compactly, introducing an average of 2.5 bytes overhead.
  1224.  
  1225. - Kala is a fully recoverable system, short of media damage. Recovery
  1226.   from hardware failures can be supported by the layer beneath Kala.
  1227.  
  1228. - The Kala primitives support arbitrary transaction models, including
  1229.   classic short transactions, long (persistent) transactions, nested
  1230.   transactions, shared transactions, pessimistic and optimistic
  1231.   policies, etc. Concurrency control is achieved through two locking
  1232.   mechanisms (short-term and long-term (persistent, shared) locking),
  1233.   with full support for atomicity of operations and two-phase commit.
  1234.  
  1235. - The Kala primitives support arbitrary versioning models, allowing
  1236.   versions to co-exist in split/rejoined networks, various version
  1237.   organization strategies (single-thread, tree, DAG, etc.). Kala
  1238.   primitives provide mechanisms for arbitrary access and update
  1239.   triggers, such as notifications, security checks upon access/update,
  1240.   etc. __ with no limitations on what the trigger code does. Kala
  1241.   provides protection measures against virus and other intruding
  1242.   executions.
  1243.  
  1244. - The Kala primitives support a wide range of access control, security
  1245.   and protection models, including revocable access rights, access
  1246.   control without the overhead of ACL management, arbitrary access
  1247.   validation routines, etc. Kala does not introduce any more security
  1248.   holes than the operating environment already has.
  1249.  
  1250. - Kala has primitives for physical store allocation and de-allocation
  1251.   management, for a wide spectrum of store administrative tasks, as
  1252.   well as licensing administration. The latter includes application-
  1253.   sensitive time-limited client-connect-based licensing, as well as
  1254.   metered (connect/load/store) usage. Kala can be set up to do
  1255.   automatic archiving and backup of its physical store.
  1256.  
  1257. - Kala provides a wide spectrum of licensing schemes, usable by
  1258.   platforms and applications built upon Kala to their customer base.
  1259.   Kala provides renewable licenses, perpetual licenses, full
  1260.   protection against duplication without hardware (hostid) support,
  1261.   metered (pay-by-use) usage, etc.
  1262.  
  1263. - And more ... not fitting on this page-long Technical Brief.
  1264.  
  1265.  
  1266. Availability
  1267.  
  1268. o Kala is available now on Sun platforms (SunOS / 68K & SPARC), as
  1269.   well as on 80x86/MS-DOS (both Microsoft and Borland compilers &
  1270.   runtimes supported) platforms. If you are interested in a port to
  1271.   your favorite platform, call us to discuss our Development and
  1272.   Porting Partnership Programme.
  1273.  
  1274. o Kala's interface is ANSI C, also callable from C++. If you are
  1275.   interested in an interface or a binding to your favorite programming
  1276.   language, please call us to discuss out Development Partnership
  1277.   Programme.
  1278.  
  1279. o For pricing and other information, please contact us by phone, fax
  1280.   or via e-mail at Info@Kala.com
  1281.  
  1282.  
  1283.  _     _     ____   _         ____ tm ____________________________________
  1284.  \\   /     |    \   \       |    \       \\\\ 
  1285.   \\ /__     \ __ \   \       \ __ \       \\\\ 
  1286.    \\    \    \    \   \       \    \       \\\\  
  1287.     \\    \    \    \   \       \    \       \\\\  No more than you need !!!
  1288.      \\'   \'   \'   \'  '____'  \'   \'      \\\\  No less than you want !!!
  1289.       ........................................................................
  1290.       Penobscot Development Corporation                 email: Info@Kala.com
  1291.        One Kendall Square Building 200 Suite 2200 Cambridge MA 02139-1564 USA
  1292.         voice +1-617-267-KALA fax +1-617-859-9597 tech support +1-201-539-7739
  1293.          ...............(5252) fax +1-617-577-1209.............................
  1294.  
  1295.  
  1296.  
  1297.      +---------------------------------------------------------------+
  1298.      |   Copyright (c) 1992-93, Penobscot Development Corporation.   |
  1299.      |   Kala is a Trademark of Penobscot Development Corporation.   |
  1300.      +---------------------------------------------------------------+
  1301.  
  1302. On Schema Evolution (from original survey):
  1303.  
  1304. Kala manages an untyped persistent store, implementing the semantics
  1305. of robust, distributed, secure, changing, and shareable persistent
  1306. data.  Layers built upon the Kala platform can implement the semantics
  1307. of objects with the same properties.
  1308.  
  1309. As it operates below the schema layer, Kala does not address schema
  1310. evolution directly. However, It supports the building of schema'ed
  1311. layers above it and below the application, and those layers can
  1312. provide for schema evolution conveniently using Kala primitives.
  1313. This parts-box approach requires extra work on the part of the developer
  1314. compared to out-of-the-box solutions, but provides power and
  1315. flexibility sufficient for relatively low cost solutions in
  1316. difficult environments (e.g. graph-structured data, dynamic classing) 
  1317. where no out-of-the-box solution is available.
  1318.  
  1319.  
  1320. Contacts:
  1321. Sergiu Simmel           sss@kala.com
  1322. Ivan Godard             ig@kala.com
  1323. general information     info@kala.com
  1324. subscription to moderated newsletter    forum-request@kala.com
  1325.  
  1326.  
  1327. REFERENCES:
  1328.         Segui S. Simmel and Ivan Godard. "The Kala Basket: A
  1329.         Semantic Primitive Unifying Object Transactions,
  1330.         Access Control, Versions, annd Configurations
  1331.  
  1332.  
  1333. > Pick
  1334.  
  1335. With Pick and its variants you only have problems if you want to
  1336. redefine an existing field.  Because of the way the data are stored
  1337. and the separation of the data and the dictionary you can define
  1338. additional fields in the dictionary without having to do anything to
  1339. the data - a facility which we have found very useful in a number of
  1340. systems.
  1341.  
  1342. There is no general facility to redefine an existing field - you just
  1343. make whatever changes are required in the dictionary then write an
  1344. Info Basic program to change the data.  We have seldom needed to do
  1345. this, but it has not been complicated to do.
  1346.  
  1347. If a field in the database is no longer used, it is often easiest
  1348. simply to delete the reference to that field in the dictionary, and
  1349. accept the storage overhead of the unused data.  In such cases, while
  1350. the data cannot be accessed through the query language, (Pick)Basic
  1351. programs can still access them.
  1352.  
  1353. [Geoff Miller <ghm@ccadfa.cc.adfa.oz.au>]
  1354.  
  1355.  
  1356.  
  1357. Interfaces
  1358. ----------
  1359.  
  1360.  
  1361. Research Systems
  1362. ________________
  1363.  
  1364.  
  1365. > Penguin (Stanford)
  1366.  
  1367. Penguin is an object-oriented interface to relational databases.
  1368. Penguin has its own simple language-independent object model with
  1369. inheritance for composite objects defined as views (called
  1370. view-objects) of a relational database.  These view-objects represent
  1371. data according to application requirements in such a way that multiple
  1372. applications can share overlapping, but different, sets of data.
  1373. Multiple applications may share data by having overlapping schemata
  1374. with differing composite objects and differing inheritance mappings.
  1375. We have a C++ binding, which supports multiple inheritance.  The
  1376. result is a framework for collaboration among multiple users, each
  1377. with differing perspectives about the system and its data.
  1378.  
  1379. For additional information, please contact ark@db.stanford.edu
  1380.  
  1381. References:
  1382.  
  1383. ``A C++ Binding for Penguin: a System for Data Sharing among
  1384. Heterogeneous Object Models,'' Arthur M. Keller, Catherine Hamon,
  1385. Foundations on Data Organization (FODO) 93, October 1993, Chicago.
  1386.  
  1387. ``Querying Heterogeneous Object Views of a Relational Database,''
  1388. Tetsuya Takahashi and Arthur M. Keller, Int. Symp. on Next Generation
  1389. Database Systems and their applications, Fukuoka, Japan, September
  1390. 1993, to appear.
  1391.  
  1392. ``Updating Relational Databases through Object-Based Views,'' by
  1393. Thierry Barsalou, Niki Siambela, Arthur M. Keller, and Gio Wiederhold,
  1394. ACM SIGMOD, Denver, CO, May 1991.
  1395.  
  1396. ``Unifying Database and Programming Language Concepts Using the Object
  1397. Model'' (extended abstract), Arthur M. Keller, Int. Workshop on
  1398. Object-Oriented Database Systems, IEEE Computer Society, Pacific
  1399. Grove, CA, September 1986.
  1400.  
  1401.  
  1402. Commercial Systems
  1403. __________________
  1404.   
  1405. >AllegroStore
  1406.  
  1407. See Databases & Development Sept. 5, 1994, p1. 
  1408.  
  1409. "Lisp, Smalltalk Languages Given Database Systems"
  1410.  
  1411. Quote:
  1412. Franz, based in Berkeley, Calif., is now shipping AllegroStore, which the
  1413. company calls the first object database system designed for object-oriented
  1414. Lisp.
  1415.  
  1416. [...] The database is based on the ObjectStore engine from Object Design, also
  1417. in Burlington.  It supports multiple clients and servers, [...]
  1418.  
  1419. Franz is at 800-333-7260 or 510-548-3600.
  1420.  
  1421.  
  1422. > Persistence
  1423.  
  1424.                 PERSISTENCE(TM): BRIDGING THE GAP BETWEEN OBJECT 
  1425.                     ORIENTED DEVELOPMENT AND RELATIONAL DATA
  1426.  
  1427. Persistence is an application development tool which provides object
  1428. oriented access to existing relational data.  Persistence uses an
  1429. automatic code generator to convert object models into C++ classes
  1430. which know how to read and write themselves to a relational database.
  1431.  
  1432. Leverage existing data
  1433.  
  1434. Persistence enables object oriented access to existing relational
  1435. databases. Applications built with Persistence can work side by side
  1436. with legacy systems.
  1437.  
  1438. Automate database access
  1439.  
  1440. By generating the methods to convert relational data into objects,
  1441. Persistence saves the developer from having to write literally hundreds
  1442. of lines of code per class.
  1443.  
  1444. Speed application development
  1445.  
  1446. With Persistence, major changes to the application object model can be
  1447. completed in minutes, not weeks.
  1448.  
  1449. Quality
  1450.  
  1451. Persistence generates tested, bug-free code. Using Persistence helps
  1452. ensure the reliability and reusability of your applications.
  1453.  
  1454. Performance
  1455.  
  1456. At Runtime, Persistence manages an object cache to enhance performance
  1457. while ensuring data integrity. The Persistence object cache can provide
  1458. a factor of ten performance improvement for data intensive
  1459. applications.
  1460.  
  1461. Portability
  1462.  
  1463. Code generated by Persistence is database independent. You can choose
  1464. which database to work with at link step, increasing application
  1465. portability.
  1466.  
  1467.                         TECHNICAL SPECIFICATIONS
  1468.  
  1469. The Persistence Database Interface Generator converts object schemas
  1470. into C++ classes.
  1471.  
  1472.                                                 Custom
  1473.                                                 Code
  1474.                                                    |
  1475.                                                    v
  1476.  
  1477. Object schema    --->   Persistence    ---->    Generated
  1478.                         Generator               Classes
  1479.                                                    ^
  1480.                                                    |
  1481.                                                    v
  1482.                                                 Persistence
  1483.                                                 Object Cache
  1484.                                                    ^
  1485.                                                    |
  1486.                                                    v
  1487.                                                 Legacy Data
  1488.  
  1489.  
  1490. Encapsulation
  1491.  
  1492. Each class generated by Persistence maps to a table or view in the database.
  1493. - Query using ANSI SQL or attribute values
  1494. - Add custom code to generated classes
  1495. - Preserve custom code when model changes
  1496.  
  1497. Inheritance
  1498.  
  1499. Persistence supports inheritance of attributes, methods and relationships.
  1500. - Propagate superclass queries to subclasses
  1501. - Use virtual methods for polymorphism
  1502.  
  1503. Associations
  1504.  
  1505. Persistence maps associations to foreign keys in the database. Each class has methods to access related classes.
  1506. - Ensure referential integrity between classes
  1507. - Specify delete constraints for associations
  1508.  
  1509. Object Caching
  1510.  
  1511. The Persistence Runtime Object Management System caches objects during
  1512. transactions and ensures data integrity. In the object cache,
  1513. Persistence "swizzles" foreign key attributes into in-memory pointers,
  1514. speeding object traversal.
  1515.  
  1516. Transactions
  1517.  
  1518. When a transaction is committed, Persistence walks through the object
  1519. cache and writes out changes to the database.
  1520.  
  1521. Environment
  1522.  
  1523. Platforms/Operating systems
  1524. Persistence will support all major Unix and Intel platforms
  1525. - Sun/SunOS 4.x, Solaris 2.x
  1526. - HP/HP-UX 8.0, 9.0
  1527. - IBM/AIX (planned 11/93)
  1528. - Intel/NT (planned 3/94)
  1529.  
  1530. Development Tools
  1531.  
  1532. Persistence supports all major C++ compilers and integrates with GE's
  1533. OMTool, allowing developers to go straight from an object model to a
  1534. running C++ application.
  1535. - Cfront 2.1: ObjectCenter 1.0, SPARCompiler, ObjectWorks
  1536. - Cfront 3.0: ObjectCenter 2.0, SPARCompiler, Softbench C++
  1537. - GE's OMTool
  1538.  
  1539. Databases
  1540.  
  1541. Persistence provides database independence. With our Objectivity
  1542. integration, we also provide a clear migration path to object
  1543. databases.
  1544. - Oracle V6, V7
  1545. - Sybase 4.x
  1546. - Ingres 6.x
  1547. - Objectivity ODBMS
  1548. - Informix (planned 9/93)
  1549. - ODBC (planned 3/94)
  1550.  
  1551.                             CUSTOMER QUOTES
  1552.  
  1553. "We wanted to use object technology while continuing to support our
  1554. legacy systems. Persistence made this feasible by automating over 30
  1555. percent of our development cycle." Steve Hunter, Sterling Software
  1556.  
  1557. "Persistence cut our development time by approximately 40%, because we
  1558. would have had to do all the mapping functions ourselves." Jim
  1559. Adamczyk, Partner, Andersen Consulting
  1560.  
  1561. "I'm convinced we'll save weeks or months of time because of
  1562. Persistence." Mike Kubicar, SunSoft Defect Tracking Team
  1563.  
  1564.