home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk1.iso / answers / object-faq / part4 < prev    next >
Encoding:
Internet Message Format  |  1994-09-17  |  60.3 KB

  1. Path: bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  2. From: Bob Hathaway <rjh@geodesic.com>
  3. Newsgroups: comp.object,comp.answers,news.answers
  4. Subject: Comp.Object FAQ Version 1.0.6 (9-15) Part 4/9
  5. Supersedes: <object-faq/part4_777166834@rtfm.mit.edu>
  6. Followup-To: comp.object
  7. Date: 17 Sep 1994 12:04:24 GMT
  8. Organization: Geodesic Systems
  9. Lines: 1489
  10. Approved: news-answers-request@MIT.Edu
  11. Expires: 31 Oct 1994 12:03:01 GMT
  12. Message-ID: <object-faq/part4_779803381@rtfm.mit.edu>
  13. References: <object-faq/part3_779803381@rtfm.mit.edu>
  14. NNTP-Posting-Host: bloom-picayune.mit.edu
  15. Summary: Frequently Asked Questions (FAQ) List and Available Systems For Object-Oriented Technology
  16. X-Last-Updated: 1994/09/15
  17. Originator: faqserv@bloom-picayune.MIT.EDU
  18. Xref: bloom-beacon.mit.edu comp.object:12653 comp.answers:7312 news.answers:25852
  19.  
  20. Archive-name: object-faq/part4
  21. Last-Modified: 9/15/94
  22. Version: 1.0.6
  23.  
  24. The Montage object-relational database management system 
  25. includes the Montage Server(tm) database engine, the Montage 
  26. Viewer(tm) -- a new visualization tool that simplifies queries of 
  27. complex data -- and Montage DataBlades(tm), specialized modules 
  28. that extend the capabilities of the database for specific applications.  
  29. Montage represents the commercialization of the seven-year 
  30. POSTGRES research project.   
  31.  
  32. The Montage Server extends the relational database model through 
  33. its ability to handle complex information, and the inclusion of object-
  34. oriented facilities and capabilities.  It uses the familiar relational row-
  35. column metaphor for all data, so that text, numbers and complex data 
  36. are all viewed, managed, manipulated and queried the same way.   
  37. The relational metaphor is extended to allow data of any size and 
  38. complexity to be stored and accessed in the way that is most 
  39. effective.   SQL, used to access and manage data, is extended with 
  40. SQL3-based capabilities to allow the definition of user data types and 
  41. functions.
  42.  
  43. The Montage Viewer uses visualization technology to organize 
  44. information in visual terms -- by location, shape, color and intensity, 
  45. for example.  Similar to a "flight simulator," the Montage Viewer allows 
  46. the user to visually navigate through data, refining each step by 
  47. "panning" and "zooming" with a mouse.  
  48.  
  49. A DataBlade is a combination of data types and functions that are 
  50. designed to support a specific application.   Text, Spatial, and Image 
  51. are the first of many DataBlades that will comprise a full-range of 
  52. industry-specific products created by Montage, third parties and 
  53. users based upon their own expertise.    
  54.  
  55. o     The Text DataBlade expands the database's functionality by 
  56. adding new data types and functions that manage text and document 
  57. libraries, as well as a providing a new access method (Doc-Tree) 
  58. which provides exceptional search performance for text.  
  59.  
  60. o     The Image DataBlade supports image conversion, storage, 
  61. manipulation, enhancement and management of more than 50 image 
  62. formats, and performs automatic conversion of formats at the user's 
  63. discretion.  
  64.  
  65. o     Points, lines, polygons and their spatial relationships are now 
  66. supported in the relational model with the Spatial DataBlade.  The 
  67. DataBlade defines nine basic spatial types and makes over 200 SQL 
  68. functions available for use on spatial data, as well as supports the 
  69. R-Tree access method for high speed navigation of spatial data.    
  70.  
  71. Montage Software was co-founded by Gary Morgenthaler of 
  72. Morgenthaler Ventures and Dr. Michael Stonebraker of the University 
  73. of California, Berkeley, .  Morgenthaler is Montage Software's 
  74. chairman of the board and Stonebraker serves as the company's 
  75. chief technology officer.    Morgenthaler and Stonebraker co-
  76. founded Ingres Corporation (then called Relational Technology, 
  77. Inc.), in 1980.    
  78.  
  79. FOR ADDITIONAL INFORMATION:
  80.  
  81. Montage Software Inc. can be contacted at:
  82.  
  83. email:                        sales@montage.com
  84. phone:                        (510) 652-8000
  85. fax:                          (510) 652-9688
  86.  
  87. Mailing Address:
  88.  
  89. Montage Software, Inc.
  90. 2000 Powell Street, Suite 1405
  91. Emeryville, CA  94608
  92.  
  93. OO DATA MODEL
  94. -------------
  95.  
  96. Research Systems
  97. ________________
  98.  
  99. > AVANCE (SYSLAB)
  100.  
  101. An object-oriented, distributed database programming language.  Its
  102. most interesting feature is the presence of system-level version
  103. control, which is used to support schema evolution, system-level
  104. versioning (as a way of improving concurrency), and objects with their
  105. own notion of history.  System consists of programming language (PAL)
  106. and distributed persistent object manager. 
  107.  
  108. REFERENCES: 
  109.         Anders Bjornerstedt and Stefan Britts. "AVANCE: An
  110.         Object Management System".  Proceedings of OOPSLA88.
  111.  
  112.  
  113.  
  114. > CLOSQL (University of Lancaster)
  115.  
  116. Status:-
  117. CLOSQL is a research prototype OODB designed primarily for prototyping 
  118. various schema evolution and view mechanisms based on class versioning.
  119. The system is built using CommonLISP. It would really only be of interest
  120. to other parties as a research tool.
  121.  
  122. Requirements:-
  123. Common LISP including CLOS standard. The Graphical user interface requires
  124. the Harlequin LispWorks Tool-kit. The system was built on a Sun4 and
  125. has not been tested on any other platform.
  126.  
  127. Features:-
  128. As a prototype, CLOSQL is not robust enough to sell. The system is single
  129. user and does not properly support persistence - that is, the data has to
  130. be loaded and saved explicitly. The query language is quite good 
  131. making good use of the functional nature of the environment. 
  132. Methods (LISP and query language only), class versioning and
  133. multiple inheritance are all supported in the data model. Type checking
  134. information is held in the database, but is NOT enforced at present. The
  135. GUI is notable for its support for schema evolution, but otherwise rather
  136. ordinary.
  137.  
  138. Availability:-
  139. Probably freely available, but as the project was part funded by an
  140. industrial partner, some consultation with them would be necessary before
  141. the system could be released.
  142.  
  143. References:-
  144. [1]  Monk, S. R. and I. Sommerville, "A Model for Versioning of Classes 
  145. in Object-Oriented Databases", Proceedings of BNCOD 10, Aberdeen. 
  146. pp.42-58. 1992.
  147.  
  148. [2]  Monk, S. "The CLOSQL Query Language". Technical report No. SE-91-15. 
  149. Computing Dept, Lancaster University, Lancaster, LA1 4YR, UK. 1991.
  150.  
  151. [3]  Monk, S., "A Model For Schema Evolution In Object-Oriented Database 
  152. Systems", PhD thesis, Dept of Computing, Lancaster University, Lancaster
  153. LA1 4YR, UK. 1992.
  154.  
  155. On Schema evolution (from original survey):
  156. CLOSQL implements a class versioning scheme (like ENCORE), but employs a
  157. conversion adaptation strategy.  Instances are converted when there is a
  158. version conflict, but unlike ORION and GemStone, CLOSQL can convert instances
  159. to older versions of the class if necessary.
  160.  
  161.         Aberdeen, Scotland. July, 1992.
  162.  
  163. Contacts;
  164. Simon Monk:      srm@computing.lancaster.ac.uk
  165. Ian Sommerville: is@computing.lancaster.ac.uk 
  166.  
  167.  
  168. > ConceptBase - A Deductive Object Manager for Meta Data Bases
  169.  
  170. ConceptBase is a multi-user deductive object manager mainly 
  171. intended for conceptual modeling and the coordination of design 
  172. environments. The system implements a dialect of Telos which 
  173. amalgamates properties of deductive and object-oriented languages. 
  174.  
  175. Key features are 
  176.  
  177.    hybrid representation with frame-like objects, 
  178.    semantic nets and logical specifications 
  179.  
  180.    unlimited extensibility by metaclass 
  181.    hierarchies (useful for IRDS, schema evolution etc.) 
  182.  
  183.    deductive rules & integrity constraints 
  184.  
  185.    queries as classes with membership constraints 
  186.  
  187.    persistent object management with the ability to interrogate 
  188.    past states of the database 
  189.  
  190. ConceptBase follows a client-server architecture. Client programs 
  191. can connect to the ConceptBase server and exchange data via 
  192. interprocess communication. The X11-based ConceptBase user 
  193. interface offers a palette of graphical, tabular and textual tools 
  194. for editing and browsing the object base. The ConceptBase 
  195. programming interface allows the users to create their own 
  196. client programs in C or Prolog. 
  197.  
  198. The system can be obtained for free from ftp.informatik.rwth-aachen.de in 
  199.       /pub/CB/CB_3.2.4 (released 26-Apr-1994 for Sun/SPARC, SunOS 4.1.3) 
  200.       /pub/CB/CB_3.3 (released 26-Apr-1994 for Sun/SPARC, Solaris 2.3) 
  201. Both versions are functionally equivalent. They only differ in the 
  202. operating system platform.Please read file /pub/CB/doc/InstallationGuide 
  203. (resp. /pub/CB/doc/InstallationGuide_3.2.4) before downloading the software. 
  204. For running the ftp version you must ask for a key by email.
  205.  
  206. Contact
  207. ConceptBase-Team
  208. RWTH Aachen - Informatik V
  209. D-52056 Aachen - Germany
  210.  
  211. Tel./Fax: +49-241 80 21 501 / +49-241-8888321
  212. email: CB@picasso.informatik.rwth-aachen.de 
  213. href="http://www.informatik.rwth-aachen.de/I5/CBdoc/cbflyer.html"
  214.  
  215.  
  216. > COOL/COCOON (Ulm Universitaet)
  217.  
  218. The COCOON project was intended to extend the concepts and the
  219. architecture of relational database management systems (DBMSs) beyond
  220. nested relational to object-oriented ones. Based upon the nested
  221. relational DBMS kernel DASDBS, we have built a prototype implementation
  222. of the COCOON model. Key characteristics of COCOON are: generic,
  223. set-oriented query and update operators similar to relational algebra
  224. and SQL updates, respectively; object-preserving semantics of query
  225. operators, which allows for the definition of updatable views; a
  226. separation of the two aspects of programming language "classes": type
  227. vs. collection; predicative description of collections, similar to
  228. "defined concepts" in KL-One--like knowledge representation
  229. languages; automatic classification of objects and views (positioning
  230. in the class hierarchy); physical clustering of subobjects via the use
  231. of nested relations as the internal storage structures; support for the
  232. optimization of both, the physical DB design and query transformation,
  233. by corresponding optimizers.
  234.  
  235. Project goals are:
  236.  
  237. - to develop a general formal framework for investigations of all
  238.   kinds of schema changes in object-oriented database systems
  239.   (including schema design, schema modification, schema tailoring, and
  240.   schema integration);
  241. - to find implementation techniques for evolving database schemas,
  242.   such that changes on the logical level propagate automatically to
  243.   adaptations of the physical level (without the need to modify all
  244.   instances, if possible).
  245.  
  246. In their current paper [see below], schema evolution is used as
  247. example of a general framework for change in OODBs, supporting change
  248. on three levels of database objects: data objects, schema objects, and
  249. meta-schema objects.
  250.  
  251. Contact: Markus Tresch <tresch@informatik.uni-ulm.de>
  252.  
  253.  
  254. REFERENCES:
  255.         M. Tresch and M.H. Scholl. "Meta Object Management
  256.         and its Application to Database Evolution."  In
  257.         _Proceedings of the Eleventh International
  258.         Conference on the Entity-Relationship Approach",
  259.         Karlsruhe, Germany, Oct 1992.  Springer Verlag (to
  260.         appear).
  261.  
  262.  
  263.  
  264. > Encore (Brown University)
  265. email:bpe@browncs.brown.edu
  266.  
  267. Encore is an object-oriented database system targeted at large scale
  268. software engineering applications which are involved in data modeling.
  269. It was developed at Brown University in the late 1980s.  It is notable
  270. for its special support for long-lived (ie. cooperative) transactions,
  271. popular in design applications, and its support for class versioning.
  272. Objects are never converted, rather, classes are versioned, and the
  273. user can specify filters to make old-style instances appear as new
  274. instances to new applications (and vice versa).
  275.  
  276.  
  277. References/Additional Information:
  278.  
  279.  [] Mary F. Fernandez. OBSERVER: A storage system
  280.     object-oriented applications. Technical Report CS-90-27,
  281.     Brown University, Providence, RI, 1990.
  282.  
  283.  [] Mark F. Hornick and Stanley B. Zdonik. A shared, segmented
  284.     memory system for an object-oriented database. ACM
  285.     Transactions on Office Information Systems, 5(1):70--95,
  286.     January 1987.
  287.  
  288.  [] Andrea H. Skarra and Stanley B. Zdonik. Type evolution in an
  289.     object-oriented database. In Research Directions in
  290.     Object-Oriented Programming, MIT Press Series in Computer
  291.     Systems, pages 393--415. MIT Press, Cambridge, MA, 1987. An
  292.     early version of this paper appears in the OOPSLA '86
  293.     proceedings.
  294.  
  295.  [] Andrea H. Skarra and Stanley B. Zdonik. Concurrency control
  296.     for cooperating transactions in an object-oriented database.
  297.     In Won. Kim and Frederick H. Lochovsky, editors,
  298.     Object-Oriented Concepts, Databases and Applications.
  299.     Addison-Wesley, Reading, MA, 1989.
  300.  
  301. FTP: Complete source can be found in wilma.cs.brown.edu/pub/encore.tar.Z
  302. See also APPENDIX E.
  303.  
  304.  
  305. > Exodus (University of Wisconsin)
  306.  
  307. EXODUS is a DBMS from the University of Wisconsin.  An overview,
  308. excerpted from the abstract of [CDG+90] reads:
  309.  
  310.     EXODUS,   an   extensible database    system  project that is
  311.     addressing  data management problems  posed  by  a variety of
  312.     challenging new applications.  The  goal of the project is to
  313.     facilitate   the   fast    development of   high-performance,
  314.     application-specific  database  systems.     EXODUS  provides
  315.     certain  kernel facilities,   including  a versatile  storage
  316.     manager.  In addition, it provides an architectural framework
  317.     for building  application-specific database systems; powerful
  318.     tools   to  help  automate the  generation   of such systems,
  319.     including  a   rule-based query optimizer generator    and  a
  320.     persistent  programming  language;  and libraries  of generic
  321.     software components (e.g., access methods) that are likely to
  322.     be useful for many application domains.
  323.  
  324. The programming language is called E, an extension of C++. [RC89]
  325.  
  326. REFERENCES:
  327. (see "ftp.cs.wisc.edu:exodus/bibliography" for a complete list)
  328.  
  329. [CDG+90] Michael J. Carey, David J. DeWitt, Goetz Graefe,
  330.          David M. Haight, Joel E. Richardson, Daniel T. Schuh,
  331.          Eugene J. Skekita, and Scott L. Vandenberg. The EXODUS
  332.          extensible DBMS project:  An overview. In Stanley B.
  333.          Zdonik and David Maier, editors, Readings in
  334.          Object-Oriented Database Systems, Data Management
  335.          Series. Morgan Kaufmann, San Mateo, CA, 1990. Also
  336.          available as WISC-CS-TR 808.
  337.  
  338. [CDRS89] Michael J. Carey, David J. DeWitt, Joel E. Richardson,
  339.          and Eugene J. Skekita. Storage management for objects
  340.          in EXODUS. In Won. Kim and Frederick H. Lochovsky,
  341.          editors, Object-Oriented Concepts, Databases and
  342.          Applications, chapter 14. Addison-Wesley, Reading, MA,
  343.          1989. After Carey et al. Object and File Management in
  344.          the EXODUS Database System, Proceedings of the Twelveth
  345.          International Conference on Very Large Data Bases,
  346.          1986.
  347.  
  348. [GD87]   G. Graefe and D. DeWitt. The EXODUS optimizer
  349.          generator. In U. Dayal and I. Traiger, editors,
  350.          Proceedings of the SIGMOD International Conference on
  351.          Management of Data, San Francisco, CA, May 1987.
  352.  
  353. [RC89]   Joel E. Richardson and Michael J. Carey. Persistence in
  354.          the E language:  Issues and implementation. Software --
  355.          Practice and Experience, 19(12):1115--1150, December
  356.          1989.
  357.  
  358.  
  359. FTP: source code, documentation and a complete bibliography can be
  360.      found at ftp.cs.wisc.edu:exodus/
  361.  
  362. See also APPENDIX E.
  363.  
  364.  
  365. On Schema Evolution (from original survey):
  366. No solution for the problem of schema evolution is provided.
  367. Emulation is rejected by the authors, who claim that the addition of a
  368. layer between the EXODUS Storage Manager and the E program would
  369. seriously reduce efficiency.  Automatic conversion, whether lazy or
  370. eager, is also rejected, as it does not mesh well with the C++ data
  371. layout.  To implement immediate references to other classes and
  372. structures, C++ embeds class and structure instances within its
  373. referent.  The resulting change in the size of the object might
  374. invalidate remote pointer references.
  375.  
  376.         Joel E.  Richardson and Michael J.  Carey.  "Persistence
  377.         in the E language: Issues and Implementation."  Appeared
  378.         in "Software -- Practice and Experience",
  379.         19(12):1115-1150, December 1989.
  380.  
  381.  
  382. > Machiavelli (University of Pennsylvania)
  383.  
  384. Machiavelli is a statically-typed programming language developed
  385. at the University of Pennsylvania. Its most outstanding innovation 
  386. is the use of conditional typing scheme in its type inference system. 
  387. It does not address type evolution.
  388.  
  389. [communication with limsoon@saul.cis.upenn.edu]
  390.  
  391. [Note: Machiavelli is included in this summary because it
  392.        previously incorporated persistence in its data model.]
  393.  
  394.  
  395.  
  396. > MOOD4-PC: Material's/Miniature Object-Oriented Database Prototype for
  397.              NEC/IBM-PC
  398.  
  399. is an object-oriented database system(OODBS) program developed in the
  400. course of our research project MOOD. The aim of the project MOOD is to
  401. develop a material database system to handle raw material data which
  402. are produced and accumulated in materials research and referred to by
  403. material experts when they face scientific or engineering problems
  404. where the expected behavior of particular materials in particular
  405. environments are crucial importance. We all know that the conventional
  406. database systems do not fulfill this requirement, though they serves
  407. well for bibliographic databases or fact databases which deals with
  408. the standard properties of standard materials.
  409.  
  410. MOOD4-PC is written in Arity/Prolog and available in source and
  411. executable form via anonymous ftp from:
  412.  
  413.    ~/pub/mood/mood4
  414.    at mood.mech.tohoku.ac.jp [130.34.88.61]
  415.    
  416.     ~/pub/database/mood
  417.     at ftp.uu.net [192.48.96.9]
  418.  
  419.     ~/pub/computing/databases/mood
  420.     at src.doc.ic.ac.uk [146.169.2.1]
  421.  
  422. Although it is true enough to say that MOOD4 is a general purpose
  423. OODBS, it may be appropriate to point out that MOOD4 is significantly
  424. different from what is generally meant by the term, the
  425. Object-Oriented Database System.
  426.  
  427. That is, OODBSs, in general, consist of two parts:
  428.  
  429.    (1) Disk storage manager
  430.    (2) Database language to define and manipulate data objects to
  431.        be stored to and retrieved from the disk.
  432.  
  433. The database language of OODBS is akin to the object-oriented
  434. programming language such as Smalltalk or C++. You can enjoy the full
  435. versatility of these general purpose programming language in writing
  436. application programs with the database language.
  437.  
  438. As apparent from these, OODBSs, in general, are for programmers who
  439. write application programs which serve end users' needs. MOOD, on the
  440. other hands, is not; it is for end users. It is provided with a user
  441. interface named the object editor or OE in short. With OE, we can;
  442.  
  443.   (1) Edit class definition objects and save them. This replaces the
  444.       data definition language.
  445.  
  446.   (2) Edit data objects and save them.
  447.  
  448.   (3) Create query objects, let the system select data objects which
  449.       match the queries, and browse them.
  450.  
  451. In the other words, we can do everything necessary to manage and use
  452. database with OE. MOOD, therefore, needs no programming language and,
  453. in fact, has none. In this regard, MOOD may better be categorized to
  454. the OODBS application.
  455.  
  456. The architecture of MOOD as such is the consequence of the nature of
  457. information to be dealt with in material database. If we describe the
  458. nature with a single word, "variety" will be the one most appropriate. 
  459. No fixed data structure can handle a handful of material data because
  460. their contents differ from one to another. The feature of OODBS
  461. relevant here is not the intimacy with programming languages but the
  462. flexibility of data structure which allows us to construct data
  463. objects with a variety of structures which match the variety in the
  464. information to be dealt with. Upon inputting and retrieving data
  465. objects, end users are forced to face this variety in data structure
  466. since significant information is born in the structures of individual
  467. representations.
  468.  
  469. Yet, we say that MOOD is a general purpose OODBS. This is not in the
  470. sense that we can develop application programs on it, but in the
  471. sense that it generally supports the essential capabilities of OODBS;
  472.  
  473.   (1) The abstract data type.
  474.  
  475.   (2) The nesting of structured data objects.
  476.  
  477.   (3) The class hierarchy.
  478.  
  479.   (4) The inheritance of attributes along the hierarchy.
  480.  
  481.   (5) Matching between objects along their structures with the
  482.       knowledge of the class hierarchy.
  483.  
  484. For additional features of MOOD4, please consult its manual available
  485. with the program. Although they are biased to the processing of
  486. material data (or, more generally, scientific and technical data),
  487. MOOD with these capabilities can be used in any application domain at
  488. least by the stage where you are to examine how well the pieces of
  489. information of interest are represented in OODBS and how well specific
  490. items of interest are discriminated out from the database as such.
  491.  
  492. Questions and suggestions on this software which are ever welcome
  493. indeed may be addressed to;
  494.  
  495.      Noboru Ono                                             
  496.      Dept. of Machine Intelligence and Systems Engineering, 
  497.      Faculty of Engineering, Tohoku University.            
  498.      Tel:++22-216-8111,
  499.      Fax:++22-216-8156,
  500.      E-mail:ono@mood.mech.tohoku.ac.jp
  501.  
  502.  
  503.  
  504. > OBST/STONE (Forschungszentrum Informatik [FZI], Karlsruhe, Germany)
  505.  
  506. Version: OBST3-3.5
  507. Date:    2/2/94
  508.  
  509. The OBject system of STONE --- OBST
  510. -----------------------------------
  511.  
  512. The persistent object management system OBST was developed by
  513. Forschungszentrum Informatik (FZI) as a contribution to the STONE
  514. project (supported by grant no. ITS8902A7 from the BMFT, i.e. the
  515. German Ministry for Research).
  516.  
  517. OBST was originally designed to serve as the common persistent
  518. object store for the tools of an software engineering environment.
  519.  
  520.  
  521. Data Model
  522. ---------
  523.  
  524. The OBST data model can be characterized by the following properties:
  525.  
  526.  * Schema definition language syntactically similar to C++
  527.  * Support of multiple inheritance
  528.  * Generic classes
  529.  * Abstract classes and methods
  530.  * Distinction between public, protected, and private methods
  531.  * Redefinition of methods
  532.  * Overloading of methods
  533.  
  534. Schemas and Containers
  535. ----------------------
  536.  
  537. Schemas are compiled by the OBST schema compiler. The compilation
  538. results are instances of classes of the meta schema. From these
  539. instances in a next step interfaces to different programming languages
  540. can be generated. At present the C++ language binding is implemented.
  541.  
  542. Objects are stored in so-called containers. The container an object
  543. belongs to is determined at the time of object creation and fixed
  544. throughout the object's lifetime. Containers are the units of 
  545. clustering, synchronization, and recovery. Objects can be referenced
  546. by other objects across container boundaries.
  547.  
  548. Incremental Loading
  549. -------------------
  550.  
  551. OBST provides a mechanism to incrementally load methods. This enables
  552. programs to deal with objects whose type is defined after the program 
  553. itself has been developed. This is useful in systems that provide for 
  554. inheritance and it supports schema evolution. We used it e.g. for
  555. programs that interpret the object base and call methods of the
  556. found objects (for example the below mentioned browser).
  557.  
  558. Prototype
  559. ---------
  560.  
  561. Since end 1990 the first prototype of OBST is available and is shipped
  562. to interested universities and research institutions. The current
  563. version is publicly available via FTP (see below) since March '92.
  564. There is a mailing list (see below) with >>100 subscribers.
  565.  
  566. The system comes with the schema compiler, a library of predefined
  567. classes (like Set<Entity>, List<Entity>, String, ...), a graphical
  568. object browser (more a shell than a browser), the structurer and
  569. flattener (STF), tclOBST, and all manuals. For STF and
  570. tclOBST see below.
  571.  
  572. Structurer and Flattener
  573. ------------------------
  574.  
  575. This is a tool to build objects from bytestrings and flatten objects
  576. down to bytestrings. It is intended to be used when coupling UNIX
  577. tools to the object management system. The user defines a grammar that
  578. describes her objects. Afterwards, the structurer parses an ascii 
  579. text according to the given grammar and creates an OBST object
  580. structure that represents the corresponding parse tree.
  581. The flattener does the inverse transformation, that means it generates
  582. an ascii text from a given OBST object structure according to the given
  583. grammar.
  584.  
  585. tclOBST
  586. -------
  587.  
  588. tclOBST is a library which provides an embedding of OBST into the
  589. interactive tool command language tcl, developed by John Ousterhout
  590. at the University of Berkeley.
  591. Based on the standard tcl shells, which are also comprised in the
  592. tclOBST distribution, tclOBST offers interactive access to the complete
  593. functionality modelled by OBST schemata.
  594.  
  595.  
  596. System Requirements
  597. -------------------
  598.  
  599. For the prototype's installation a C++ compiler
  600. (GNU g++ 2.3.3/2.4.5/2.5.7 or AT&T 2.0/2.1/3.01) and the
  601. X-Windows system (currently X11R4 or X11R5) for the graphical tools
  602. are required.
  603. Installation is well-tried on SUN Sparc stations and should be no
  604. problem on other UNIX machines, too. You can find a more detailed
  605. description of the supported platforms in the README.install.OBST*.
  606.  
  607. --------------------------------------------------------------------
  608.  
  609. For more information please mail to:
  610.  
  611.                 Forschungszentrum Informatik (FZI)
  612.                        OBST Projekt
  613.                  Haid-und-Neu-Strasse 10-14
  614.                      D-76131 Karlsruhe
  615.                           Germany
  616.  
  617. or email to:  obst@fzi.de
  618.  
  619. Phone:        ++49-721-9654-601
  620. Fax:          ++49-721-9654-609
  621. Teletex:      721 190 fziKA
  622.  
  623. The OBST system is available via anonymous FTP from
  624. ftp.fzi.de [141.21.4.3].
  625.  
  626. The system as well as some overview papers, documentation
  627. (User's Guide, Language Reference Manual, Tutorial, ...),
  628. and lots of manual pages can be found in the directory /pub/OBST.
  629.  
  630. There are mailing lists for announcing OBST enhancements,
  631. new versions, porting hints, etc. as well as for exchanging experiences
  632. with other OBST users.
  633.  
  634. Send a mail with content 'LONGINDEX' to obst-listserv@fzi.de to learn about
  635. the mailing lists which are currently installed:
  636.     echo LONGINDEX | mail obst-listserv@fzi.de
  637.  
  638. The mailing lists are maintained by an automatic list processor.
  639. Use 'HELP' to learn about the commands understood by this processor:
  640.     echo HELP | mail obst-listserv@fzi.de
  641.  
  642. Bug reports should contain a small example program with which the
  643. bug can be reproduced, or at least a detailed description of the
  644. observed phenomenon. They should also mention:
  645.      o OBST version 
  646.      o configuration parameters for your OBST version
  647.        (from file config.status)
  648.      o kind and version of C++ compiler 
  649.      o machine
  650.      o operating system
  651.  
  652. Besides bug reports we are strongly interested in all experiences
  653. our users make with OBST (e.g. sufficiency of data model, performance,
  654. ...) and in our users' application areas and the applications as
  655. well. So, please don't hesitate to send us a short note.
  656.  
  657. Best regards and happy OBST programming.
  658.  
  659.    The OBST Team,
  660.  
  661.     Boris Boesler, Dirk Eichberg, Frank Fock, Axel Freyberg,
  662.     Michael Gravenhorst, Ingolf Mertens, Michael Pergande, Christian Popp,
  663.     Bernhard Schiefer, Dietmar Theobald, Axel Uhl, Walter Zimmer
  664.  
  665. ---
  666.  
  667. BTW "Obst" is the German word for "fruit",
  668.     so have a fruitful time with OBST!
  669.  
  670.  
  671.  
  672. > Ode
  673.  
  674.                                  Ode 2.0
  675.                        An Object-Oriented Database
  676.  
  677.        C++ Compatible, Fast Queries, Complex Application Modeling,
  678.        Multimedia Support, and more
  679.  
  680. See APPENDIX E, Databases, for description.
  681.  
  682.  
  683. > Oggetto, University of Lancaster, UK.
  684.  
  685. Developed at the University of Lancaster, UK.  Summary NYI.
  686.  
  687. "Oggetto: An Object Oriented Database Layered on a Triple Store",
  688. J.A. Mariani, The Computer Journal, V35, No 2, pp108-118, April 1992.
  689.  
  690.  
  691. > ORION (Now marketed as ITASCA)
  692.  
  693. ORION was a prototype OODBMS developed at MCC, an American consortium by Won
  694. Kim and his group.  Won Kim has left MCC and formed a new company, UniSQL, in
  695. Austin, with a new product of the same name.
  696.  
  697. See also entry under "ITASCA".
  698.  
  699. REFERENCES:
  700.  
  701. I have found nearly a dozen papers published by the ORION folks.
  702. Overviews at various stages in its development and commercialization
  703. can be found in:
  704.  
  705. [KBGW91] Won Kim, N. Ballou, J.F. Garza, and D.; Woelk. A
  706.          distributed object-oriented database system supporting
  707.          shared and private databases. ACM Transactions on
  708.          Information Systems, 9(1):31--51, January 1991.
  709.  
  710. [KGBW90] W. Kim, J.F. Garza, N. Ballou, and D. Woelk.
  711.          Architecture of the orion next-generation database
  712.          system. IEEE Transactions on Knowledge and Data
  713.          Engineering, 2(1):109--24, March 1990.
  714.  
  715. [KBCG89] Won Kim, Nat Ballou, Hong-Tai Chou, and Darrell Garza,
  716.          Jorge F. Woelk. Features of the ORION object-oriented
  717.          database system. In Won. Kim and Frederick H.
  718.          Lochovsky, editors, Object-Oriented Concepts, Databases
  719.          and Applications, chapter 11. Addison-Wesley, Reading,
  720.          MA, 1989.
  721.  
  722. [KBC+88] Won Kim, N. Ballou, Hong-Tai Chou, J.F. Garza,
  723.          D. Woelk, and J. Banerjee. Integrating an
  724.          object-oriented programming system with a database
  725.          system. In Proceedings of the ACM Conference on
  726.          Objected-Oriented Programming:  Systems, Languages and
  727.          Applications (OOPSLA), pages 142--152, San Diego, CA,
  728.          September 1988. Published as ACM SIGPLAN Notices
  729.          23(11).
  730.          [Pointers to the previous papers documenting each of the
  731.           advanced features listed above are cited therein.]
  732.  
  733.  
  734. The paper most relevant to the issue of schema evolution is the
  735. following:
  736.  
  737. [BKKK87] J. Banerjee, W. Kim, H-J. Kim, and H.F. Korth.
  738.          Semantics and implementation of schema evolution in
  739.          object-oriented databases. In U. Dayal and I. Traiger,
  740.          editors, Proceedings of the SIGMOD International
  741.          Conference on Management of Data, San Francisco, CA,
  742.          May 1987.
  743.  
  744.  
  745. You might also like to look at Kim's book, which provides a good
  746. introduction to OODBMS, while focusing on the ORION work:
  747.  
  748. [Kim90]  Won Kim. Introduction to Object-Oriented Databases.
  749.          Computer Systems. MIT Press, Cambridge, MA, 1990.
  750.  
  751.  
  752. > OTGen (Carnegie Mellon University/UMass Amherst)
  753.  
  754. OTGen is a design for a system to support schema evolution in
  755. object-oriented databases.  The chief contribution of OTGen is support
  756. for programmer extensibility of transformation functions to allow a
  757. system to support a wide range of schema changes, not just those that
  758. can be easily automated.  While OTGen was never implemented, it is
  759. based on the implementation of TransformGen, a system to support the
  760. evolution of the specialized databases used by Gandalf programming
  761. environments.  For more information on OTGen and TransformGen, please
  762. see: 
  763.  
  764. Barbara Staudt Lerner and A. Nico Habermann, "Beyond Schema Evolution
  765.     to Database Reorganization", in Proceedings of the Joint ACM 
  766.     OOPSLA/ECOOP '90 Conference on Object-Oriented Programming:
  767.     Systems, Languages, and Applications, Ottawa, Canada, October
  768.     1990, 67-76. 
  769.  
  770. Barbara Staudt, Charles Krueger, and David Garlan, TransformGen:
  771.     Automating the Maintenance of Structure-Oriented Environments, 
  772.     Computer Science Department Carnegie-Mellon University, Technical 
  773.     Report CMU-CS-88-186, November 1988.
  774.  
  775. David Garlan, Charles W. Krueger, and Barbara J. Staudt, "A Structural
  776.     Approach to the Maintenance of Structure-Oriented Environments",
  777.     in Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
  778.     Symposium on Practical Software Development Environments, Palo
  779.     Alto, California, December 1986, 160-170.
  780.  
  781. Contact:
  782. Barbara Lerner
  783. blerner@cs.umass.edu
  784.  
  785.  
  786. > VODAK
  787.  
  788. Research in the framework of VODAK focuses on an extensible data
  789. model and database programming language, an advanced transaction
  790. model, object-oriented query language, and support for multimedia data.
  791.  
  792. The VODAK Data Model Language VML
  793.  
  794. Usually database models lack mechanisms for extending them with
  795. additional modeling primitives. This limitation does not allow the
  796. adaptation of the models for specific application needs, e.g. database
  797. integration, multimedia document handling, hypertext modeling, etc.
  798.  
  799. The VODAK Model Language VML  homogeneously integrates the concept of
  800. metaclasses and the separation of types and classes with other
  801. object-oriented concepts such as properties, methods, inheritance, and
  802. object identity. Complex nested data structures can be defined using
  803. the set, array, tuple, and dictionary type constructors. VML supports
  804. its own programming language for implementing methods, specifying
  805. transactions and an ad hoc query language.
  806.  
  807. In VML classes are used to organize a set of objects corresponding to
  808. real world entities and relationships between them. Object types define
  809. the structure of objects and the operations defined on these
  810. structures.  They are associated with classes in order to determine the
  811. structure and behavior of the class' instances. Metaclasses are first
  812. class objects whose instances are classes. Metaclasses are associated
  813. with three object types: an (optional) own-type extending their own
  814. behavior, an instance-type specifying the behavior of their instances
  815. (which are classes), and an  instance-instance-type specifying the
  816. behavior of the instances of their instances.  Metaclasses can be
  817. organized in an instantiation hierarchy of arbitrary depth.
  818.  
  819. This approach leads to an open, adaptable data model which provides for
  820. the specification of additional modeling primitives at a meta layer of
  821. the database schema. The concept of metaclasses and the separation of
  822. classes and types allow to determine the structure and behavior of
  823. objects and the individual inheritance behavior via semantic
  824. relationships between arbitrary objects already at the meta layer
  825. independently from the specifications given at the application layer
  826. for the application specific classes.
  827.  
  828.  
  829. The VODAK Transaction Model
  830.  
  831. In VODAK, we focus on two specific problems of transaction management.
  832.  
  833. 1. Operations to read and edit (hyper)documents are typically complex,
  834. interactive and of long duration. A high degree of concurrency is
  835. required to reduce the number and length of times a transaction is
  836. blocked.
  837.  
  838. 2. A publication environment has to handle existing database systems
  839. for using and modifying remote information and documents.  Transaction
  840. managers of existing systems, i.e. concurrency control and recovery,
  841. have to be integrated in a transparent way utilizing the functionality
  842. of existing managers.
  843.  
  844. Our transaction model is based on open nested transactions. Compared to
  845. conventional flat transactions, nested transactions allow more
  846. concurrency and are more flexible for recovery.  A nested transaction
  847. is a tree-like structure, dynamically built up by the call of
  848. subtransactions until a bottom implementation level is encountered.
  849.  
  850. We extended the open nested model from a fixed calling hierarchy of
  851. operations in a layered system (multi-level transactions) to an
  852. arbitrary calling hierarchy of operations in an object-oriented system.
  853. Commutativity of operations is applied to system defined VODAK methods,
  854. and to methods of user defined object types.  For the second type of
  855. operations, we developed a framework to specify commutativity and
  856. inverse operations in VML.
  857.  
  858. Query Processing
  859.  
  860. Although nearly all object-oriented data models proposed so far include
  861. behavioral aspects, most object-oriented query languages, algebras and
  862. query optimization strategies simply adapt relational concepts since
  863. they focus on the complex structures of objects and neglect the
  864. behavior. We claim that this approach is not sufficient since it does
  865. not reflect the much richer semantics methods can carry which have to
  866. be taken into account for really efficient query processing. The quite
  867. straightforward approach we consider is to integrate methods in an
  868. algebraic framework for query processing and to make there partial
  869. knowledge about methods available in the form of equivalences. We
  870. integrate algebraic set operators with methods defined in database
  871. schemas within an object-oriented data model. We investigate the impact
  872. on the architecture of the query processor when the algebra becomes an
  873. extendible component in query processing.
  874.  
  875. Multimedia Support
  876.  
  877. The V3 Video Server was built as a demonstration showing a multimedia
  878. application developed on top of the VODAK database management system.
  879. The V3 Video Server allows a user to interactively store, retrieve,
  880. manipulate, and present analog and short digital video clips. A video
  881. clip consists of a sequence of pictures and corresponding sound.
  882. Several attributes like author, title, and a set of keywords are
  883. annotated.
  884.  
  885. In the future, the VODAK DBMS will be enhanced with new built-in
  886. functionality for multimedia datatypes. Therefore, existing components
  887. of VODAK must be changed and new ones must be added to support time
  888. dependencies, high data volumes, and user interaction.
  889.  
  890. Query Processing
  891.  
  892. Although nearly all object-oriented data models proposed so far include
  893. behavioral aspects, most object-oriented query languages, algebras and
  894. query optimization strategies simply adapt relational concepts since
  895. they focus on the complex structures of objects and neglect the
  896. behavior. We claim that this approach is not sufficient since it does
  897. not reflect the much richer semantics methods can carry which have to
  898. be taken into account for really efficient query processing. The quite
  899. straightforward approach we consider is to integrate methods in an
  900. algebraic framework for query processing and to make there partial
  901. knowledge about methods available in the form of equivalences. We
  902. integrate algebraic set operators with methods defined in database
  903. schemas within an object-oriented data model. We investigate the impact
  904. on the architecture of the query processor when the algebra becomes an
  905. extendible component in query processing.
  906.  
  907. The VODAK Prototype
  908.  
  909. The system architecture consists of a central database environment and
  910. several external database environments to which the user wants to have
  911. integrated access. Each of these environments consists of an object
  912. manager, a message handler, a transaction manager, and a communication
  913. manager. In addition to these components an external database
  914. environment includes a database interface module which realizes the
  915. access to an external database system.
  916.  
  917. The DBMS components are currently built on top of DAMOKLES and will be
  918. in the near future on top of ObjectStore.
  919.  
  920. A first version of a C++ based prototype of VODAK is available for Sun
  921. Sparc Stations under certain conditions.  It implements all the
  922. features specified in including e.g. metaclasses, transactions, and
  923. remote message execution.
  924.  
  925. References
  926.  
  927. P. Muth, T. Rakow, W. Klas, E. Neuhold:  A Transaction Model for an
  928. Open Publication Environment.  A. K. Elmagarmid (Ed.): Database
  929. Transaction Models for Advanced Applications. Morgan Kaufmann
  930. Publishers, San Mateo, Calif., 1992.
  931.  
  932. Wolfgang Klas, Karl Aberer, Erich Neuhold Object-Oriented Modeling for
  933. Hypermedia Systems using the VODAK Modeling Language (VML) to appear
  934. in: Object-Oriented Database Management  Systems, NATO ASI Series,
  935. Springer Verlag Berlin Heidelberg, August 1993.
  936.  
  937. Karl Aberer, Gisela Fischer Object-Oriented Query Processing: The
  938. Impact of Methods on Language, Architecture and Optimization
  939. Arbeitspapiere der GMD No. 763, Sankt Augustin, July 1993.
  940.  
  941. T.C. Rakow, P. Muth The V3 Video Server: Managing Analog and Digital
  942. Video Clips, Sigmod 93, Washington, DC.
  943.  
  944. For further information contact
  945.  
  946. {aberer,muth,rakow,klas}@darmstadt.gmd.de
  947.  
  948.   GMD-IPSI                                             
  949.   Dolivostr. 15                                                           
  950.   D-64293 Darmstadt
  951.   GERMANY    
  952.                                     
  953.   FAX: +49-6151-869 966   
  954.  
  955.  
  956. Commercial Systems
  957. __________________
  958.  
  959. > ArtBASE  (Object-Oriented Data Model)
  960.  
  961. by:     ArtInAppleS Ltd.
  962.         Kremelska 13
  963.         845 03 Bratislava
  964.         SLOVAKIA
  965.         Phone: x42-7-362-889
  966.         fax:   x42-7-777 779
  967.         EMail: artbase.support@artinapples.cs
  968.  
  969. Distributor for Germany:
  970.         ARS NOVA Software GmbH
  971.         Stettener Strasse 32/3
  972.         73732 Esslingen a.N.
  973.         Germany
  974.         Phone: x49-711 3704001
  975.         Fax:   x49-711 3704001
  976.         EMail: info@arsnova.stgt.sub.org
  977.  
  978. Languages: Objectworks\Smalltalk by ParcPlace Systems, Inc.
  979.  
  980. Platforms: Unix, PC Windows, Macintosh
  981.  
  982. Features:
  983. - Fully implemented in Objectworks\Smalltalk
  984.   (ArtBASE is delivered with source code)
  985.  
  986. - ArtBASE extents Smalltalk of persistency. Persistent objects are handled the
  987.   same way as transient objects.
  988.  
  989. - Optimistic and pessimistic concurrency control.
  990.  
  991. - Transactions, including long lived transactions
  992.  
  993. - User concept with access restrictions
  994.  
  995. - storing of classes and methods in the database - entire applications 
  996.   may be stored in an ArtBASE database, including the data AND the 
  997.   application classes
  998.  
  999. - Currently, a single user version is available. The Distributed Multi User Server Version
  1000.   will be presented at the OOPSLA'93 at Washington D.C. in September 1993 for Unix
  1001.   environments and PCs.
  1002.  
  1003. - Existing applications can be turned to database applications very easily using ArtBASE
  1004.  
  1005.  
  1006. > EasyDB (Objective Systems, Sweden)
  1007.  
  1008. EasyDB features a (programming language independent) Data Definition
  1009. Language (DDL) for the definition of schemas.  It relies on the
  1010. Entity-Attribute-Relationship model.  Data Manipulation Languages
  1011. (DML) include a Navigational Query language (NQL) embedded in a host
  1012. language (C available now, Ada in January '93), and a generic C++
  1013. class library.
  1014.  
  1015. On Schema Evolution (from original survey):
  1016. The schema may be freely extended with new items (types, domains,
  1017. attributes, entities, relationships etc.). Deletion of items is not
  1018. allowed.
  1019.  
  1020. Data created with an older schema may co-exist with newer data. Old
  1021. applications need not be recompiled when the schema is updated.
  1022. Attempts by newer applications to access `older' data in an
  1023. inconsistent way are detected and reported via an exception handling
  1024. system.
  1025.  
  1026. [Tomas Lundstrom <tomas@os.se>]
  1027.  
  1028. Objective Systems SF AB (Ericsson)
  1029. Box 1128
  1030. S-164 22 Kista, Sweden
  1031. tel : +46-8-703-4591
  1032. fax : +46-8-750-8056
  1033. contact: Jaan Habma, jaan@os.se
  1034.  
  1035.  
  1036. > GemStone (Servio)
  1037.  
  1038. First introduced in 1987, Servio's GemStone is the oldest commercial ODBMS
  1039. available today. GemStone is particularly well suited for use in complex
  1040. multi-user, multi-platform client/server applications. It supports
  1041. concurrent access from multiple external languages, including Smalltalk-80,
  1042. Smalltalk/V, C++ and C. GemStone also provides a dialect of Smalltalk as an
  1043. internal DML, which can execute methods or entire applications in the
  1044. database.
  1045.  
  1046. Servio also offers GeODE (GemStone Object Development Environment), an
  1047. object database application development environment which allows developers
  1048. to build complete object applications visually, without writing code. With
  1049. GeODE's visual programming tools, programming an application is a matter of
  1050. wiring together graphical representations of encapsulated code blocks. A
  1051. simple extension mechanism promotes the re-use of code, thereby increasing
  1052. the speed of program development. Also, association of application user
  1053. interface elements with database objects is established through simple
  1054. graphical tools. GeODE applications are stored and run in the GemStone
  1055. database, and so are both self-porting and network-aware, and can be
  1056. accessed externally from any of the GemStone language interfaces. Because
  1057. of GemStone's network architecture, Geode applications can operate easily
  1058. in a client/server environment.
  1059.  
  1060.  
  1061.  ==============================================================================
  1062.  
  1063. GEMSTONE
  1064.  
  1065. GemStone is a highly scalable client-multiserver database for commercial
  1066. applications. GemStone's features include:
  1067.  
  1068. o  Active Database -- GemStone allows database application developers to
  1069.    write methods which are stored and executed directly in the database.
  1070.    These methods can be accessed either internally, or from external client
  1071.    applications. This can significantly reduce network traffic and allow
  1072.    applications to take advantage of the superior compute power of the
  1073.    server. This also eliminates the need to rebuild and re-deploy
  1074.    applications whenever application or business processing rules change.
  1075.    This in turn allows for centralized code development and management,
  1076.    architecture-independent code that ports itself to new platforms,
  1077.    reduced network usage, and true client/server applications that share
  1078.    compute load between client and server machines.
  1079.  
  1080. o  Concurrent Support for Multiple Languages -- GemStone provides
  1081.    concurrent support for applications developed in Smalltalk, C++, C or
  1082.    GeODE. All applications, regardless of language, can have simultaneous
  1083.    access to the same database objects.
  1084.  
  1085. o  Flexible multi-user transaction control -- Multiple users can
  1086.    operate in the database simultaneously, with a variety of transaction
  1087.    control modes available.
  1088.  
  1089. o  Object-level security -- Authorization control can be applied to any
  1090.    object in the database, allowing for fine tuning of object security.
  1091.  
  1092. o  Dynamic schema and object evolution -- GemStone supports schema
  1093.    modification through class versioning and allows full migration of
  1094.    objects between versions of their classes with a simple message send.
  1095.    Migration is fully customizable and is undoable.
  1096.  
  1097. o  Production Services -- GemStone delivers the full suite of features
  1098.    required in any production-ready networked database including online
  1099.    backup, rapid recovery, referential integrity, sophisticated concurrency
  1100.    control, and event signals and notifiers.
  1101.  
  1102. o  Scalability -- In a recent independent benchmark, GemStone scaled to
  1103.    support more than 1,000 simultaneous log-ins and 100 concurrent active
  1104.    users on a mid-sized SMP server.
  1105.  
  1106. o  Legacy Gateways -- GemStone incorporates gateways or data bridges
  1107.    that allow object applications to integrate legacy data, whether in SQL,
  1108.    IMS, VASM or other formats. The level of integration between GemStone
  1109.    and legacy data and applications can range from simple query access to
  1110.    extensive read-write interoperability.
  1111.  
  1112.  
  1113.  ==============================================================================
  1114.  
  1115. GEODE
  1116.  
  1117. GeODE is a comprehensive environment for rapidly designing, building and
  1118. deploying production-quality commercial object applications. Its design
  1119. promotes code reuse in a team programming environment for increased
  1120. productivity. GeODE consists of six main elements:
  1121.  
  1122. o  Visual Application Manager -- Provides centralized management
  1123.    of each application and its component parts, and a namespace for
  1124.    addressing known objects.
  1125.  
  1126. o  Visual Schema Designer -- Allows the development of database schema
  1127.    visually, making the process more interactive and intuitive than with
  1128.    object-oriented programming languages. It also provides analysis tools
  1129.    for examining an existing schema.
  1130.  
  1131. o  Visual Forms Designer -- The Forms Designer reads GemStone class
  1132.    definitions and an associated data dictionary to automatically create
  1133.    default forms suitable for simple data entry. These forms can be rapidly
  1134.    customized, using a wide selection of user interface components and
  1135.    field types, which include image and sound support, and a large set of
  1136.    form design aids. The list of field types can be extended interactively.
  1137.  
  1138. o  Visual Program Designer -- The Visual Program Designer allows developers
  1139.    to visually create and modify the behavior of an application without
  1140.    having to write code. Programs are created by connecting visual program
  1141.    blocks to field blocks drawn from the forms created in the Forms
  1142.    Designer. A large collection of predefined program blocks is provided
  1143.    with GeODE, and users can extend the catalog in any of a number of
  1144.    simple ways. Code-based programming can be integrated routinely.
  1145.  
  1146. o  Developer Class Library - GeODE comes standard with more than 480
  1147.    classes and thousands of methods, and is easily extended for handling
  1148.    specialized applications. In a team environment, some programmers can
  1149.    develop visual applications while others write new methods that are
  1150.    encapsulated into visual program blocks for easy reuse.
  1151.  
  1152. o  Developer Tools -- GeODE includes tools for debugging, browsing and
  1153.    inspecting applications. Included in this set of tools are several
  1154.    debuggers, browsers, inspectors, an object clipboard, an image editor,
  1155.    and a code profiler for performance analysis.
  1156.  
  1157.  
  1158.  ==============================================================================
  1159.  
  1160. PLATFORMS
  1161.  
  1162. GemStone release 3.2 and GeODE 2.0 and all language interfaces are
  1163. available for UNIX workstations and servers from SUN, HP, IBM, Sequent, and
  1164. DEC. Client-only support is available in a number of languages for Windows
  1165. 3.1, OS/2 and Macintosh. Servio is an active member in the Object
  1166. Management Group and the ANSI Smalltalk standardization committee. Servio
  1167. supports SUN ODMG, ANSI C++ and intends to comply fully with the emerging
  1168. standards.
  1169.  
  1170.  ==============================================================================
  1171.  
  1172. REFERENCES
  1173.  
  1174.   [Maier, et al. 84] D. Maier, J. Stein, A. Otis, A. Purdy, ``Development
  1175.   of an object-oriented DBMS'' Report CS/E-86-005, Oregon Graduate Center,
  1176.   April 86 - ACM 0-89791-204-7/86/0900-0472
  1177.  
  1178.   R.G.G. Cattell: Object Data Management - Object-Oriented and Extended
  1179.   Relational Database Systems; Addison-Wesley. ISBN 0-201-53092-9
  1180.  
  1181.   Robert Bretl, David Maier, Allen Otis, Jason Penney, Bruce Schuchardt,
  1182.   Jacob Stein, E. Harold Williams, Monty Williams. "The GemStone Data
  1183.   Management System." Chapter 12 of "Object-Oriented Concepts, Databases
  1184.   and Applications", by Kim and Lochovsky.
  1185.  
  1186.  
  1187.  ==============================================================================
  1188.  
  1189. CONTACTS
  1190.  
  1191.  === Headquarters - San Jose ====
  1192.  
  1193. Servio Corporation
  1194. 2085 Hamilton Avenue
  1195. Suite 200
  1196. San Jose  CA  95125
  1197.  
  1198. Tel: 800-243-9369
  1199. Tel: 408-879-6200
  1200. Fax: 408-369-0422
  1201.  
  1202.  === Chicago ====
  1203.  
  1204. Servio Corporation
  1205. 8410 Bryn Mawr
  1206. Suite 400
  1207. Chicago  IL  60631
  1208.  
  1209. Tel: 312-380-1310
  1210. Fax: 312-380-1308
  1211.  
  1212.  ===  New York ====
  1213.  
  1214. Servio Corporation
  1215. 1120 Avenue of the Americas
  1216. 4th Floor
  1217. New York  NY  10036
  1218.  
  1219. Tel: 212-626-6680
  1220. Fax: 212-626-6684
  1221.  
  1222.  === Dallas ====
  1223.  
  1224. Servio Corporation
  1225. 14875 Preston Road
  1226. Suite 550
  1227. Dallas  TX  75240
  1228.  
  1229. Tel: 214-980-7073
  1230. Fax: 214-980-2949
  1231.  
  1232.  === Europe/UK ====
  1233.  
  1234. Servio UK
  1235. Criterion House
  1236. Beauchamp Court, Victors Way
  1237. Barnet  EN5 5TZ  England
  1238.  
  1239. Tel: +44 81 447-0800
  1240. Fax: +44 81 447-0577
  1241.  
  1242.  === Japan ====
  1243.  
  1244. Servio Corporation
  1245. Daito-Eiwa Building, 7F
  1246. 5-11 Nihonbashi-Hakozakicho
  1247. Chuo-ku  Tokyo 103  Japan
  1248.  
  1249. Tel: +81 3 3660-1910
  1250. Fax: +81 3 3663-3287
  1251.  
  1252.  =====================
  1253.  === Distributors ====
  1254.  =====================
  1255.  
  1256.  === Germany, Austria, Switzerland ====
  1257.  
  1258. ObjectOriented System Technologies
  1259. Baroper Str. 337
  1260. Dortmund  50  W-4600
  1261. Germany
  1262.  
  1263. Tel: +49 231 975 990
  1264. Fax: +49 231 975 99-20
  1265.  
  1266.  === Japan ====
  1267.  
  1268. Japan Information Processing Service Co., Ltd.
  1269. 2-4-2 Toyo , Koto-ku
  1270. Tokyo, 135, JAPAN
  1271.  
  1272. Tel: +81 3 5690 3268
  1273. Fax: +81 3 5690 3390
  1274.  
  1275. --------------------
  1276.  
  1277. Nexus Technology K.K.
  1278. Suite 901
  1279. Botan 3-11-1
  1280. Koto-ku  Tokyo 135  Japan
  1281.  
  1282. Tel: +81 3 3660-1910
  1283. Fax: +81 3 3663-3287
  1284.  
  1285.  === Taiwan ====
  1286.  
  1287. Anco Technologies
  1288. 11-1F, 76 Tun Hwa S. Road, Sec. 2
  1289. Taipei
  1290. Taiwan, R.O.C.
  1291.  
  1292.  === Italy ====
  1293.  
  1294. Etnoteam S.P.A.
  1295. Via Adelaide Bono Cairoli 34
  1296. Milano  20127  Italy
  1297.  
  1298. Tel: +39 2 261 621
  1299. Fax: +39 2 261 10755
  1300.  
  1301.  === England ====
  1302.  
  1303. AI International Ltd.
  1304. 1 Parkview Road
  1305. Berkhamsted
  1306. Herts  HP4 2EY  England
  1307.  
  1308. Tel: +44 442 876 722
  1309. Fax: +44 442 877 997
  1310.  
  1311.  ==== Mexico ====
  1312.  
  1313. TEIX, Sistemas de Informacion
  1314. Estrategica S.A. de C.V.
  1315. Antonio M. Anza No. 43
  1316. Col Roma  Mexico D.F.  06700
  1317.  
  1318. Tel: +52 5 564-7146
  1319.  
  1320.  
  1321. > ITASCA
  1322.                        ITASCA ODBMS V2.2
  1323.  
  1324.                       Itasca Systems, Inc.
  1325.                        7850 Metro Parkway
  1326.                       Minneapolis, MN 55425
  1327.                         sales@itasca.com
  1328.                          (612) 851-3155
  1329.  
  1330.                           Sandy Miezwa
  1331.                          (612) 851-3169
  1332.  
  1333. Introduction
  1334.  
  1335. Itasca Systems develops, markets, and supports ITASCA, a distributed 
  1336. active object database management system and related tools. The initial 
  1337. research work for ITASCA occurred in the Object-Oriented and Distributed 
  1338. Systems Lab at the Microelectronics and Computer Technology 
  1339. Corporation (MCC) in Austin, Texas. The research was known as the 
  1340. ORION prototypes. 
  1341.  
  1342. The ITASCA Distributed ODBMS is a language neutral, full-featured, active 
  1343. object database that supports data access from various object
  1344. languages. ITASCA allows clients to transparently access data that is
  1345. distributed among multiple servers.  ITASCA supports full dynamic schema
  1346. modification that can be performed during any phase of the software
  1347. lifecycle.  Applications written in dissimilar and incompatible languages,
  1348. such as C++ and CLOS, share objects through ITASCA. ITASCA stores methods
  1349. inside the database, promoting reusability and maintainability.  The only
  1350. commercial ODBMS based upon the MCC Orion technology, ITASCA is considered
  1351. by many to be the most feature-rich ODBMS on the market today.
  1352.  
  1353. This overview describes release 2.2 of the ITASCA Distributed Object 
  1354. Database Management System. It describes how ITASCA functions, 
  1355. outlines its implementation features, and explains some of the system 
  1356. benefits. 
  1357.  
  1358.  
  1359. History of ITASCA
  1360.  
  1361. ITASCA is based on a series of object database research prototypes. Work 
  1362. on these prototypes began in 1985 at the Microelectronics and Computer 
  1363. Technology Corporation (MCC) Object-Oriented and Distributed Systems 
  1364. Laboratory. MCC released the first prototype, ORION-1, in May, 1987, as 
  1365. a single-user system. MCC extended ORION-1 to the ORION-1SX 
  1366. prototype system and released it to the shareholder companies in April, 
  1367. 1988. ORION-1SX was a multi-user system with a multi-client, single 
  1368. server architecture. The third prototype, ORION-2, introduced a distributed, 
  1369. object-oriented architecture for a multi-user environment. MCC released 
  1370. the third prototype to shareholder companies in July, 1989. ORION-2 has a 
  1371. multi-client, multi-server architecture. Having met its objectives, MCC 
  1372. stopped all work on ORION at that time. Over five million dollars was spent
  1373. for the three generations of prototypes.
  1374.  
  1375. The ITASCA product is an extension and commercialization of the ORION-2
  1376. prototype from MCC. Itasca Systems has added major enhancements and
  1377. features, improved the performance, and strengthened the code. It now runs
  1378. on UNIX systems from multiple vendors. ITASCA is an industrial-strength,
  1379. documented product, fully supported by Itasca Systems, Inc. Itasca Systems
  1380. continues to develop tools and other products to work with ITASCA.
  1381.  
  1382.  
  1383. Overview
  1384.  
  1385. ITASCA employs a distributed architecture with private and shared objects 
  1386. spread across UNIX-based computers on a local-area network. The 
  1387. ITASCA model follows the object-oriented view that uniformly models any 
  1388. real-world entity as an object. Each object has a unique identifier along with 
  1389. a state and behavior. Attributes represent the state of an object. Methods 
  1390. (code) define the behavior of an object. A class object collects objects that 
  1391. share the same set of attributes and methods. Subclasses derive from 
  1392. existing classes. The resulting schema, or database definition, is a class 
  1393. hierarchy. Each subclass inherits all the attributes and methods of its 
  1394. superclasses. ITASCA supports multiple inheritance. A subclass may derive 
  1395. from more than one superclass. 
  1396.  
  1397. One of the breakthroughs of object-oriented technology is the reusability of 
  1398. code. ITASCA allows for the active management of both reusable code and 
  1399. data in an integrated system. Developers may write applications in C++,
  1400. CLOS, C or Common Lisp. This means ITASCA is language neutral. Objects 
  1401. stored using one programming language can be accessed by other 
  1402. programming languages. It also means an application program need not be
  1403. written in an object-oriented language. 
  1404.  
  1405. The ITASCA database management system has features belonging to most any 
  1406. database system. This includes persistent storage for data and schema, 
  1407. concurrency control and locking, transaction management, multiple 
  1408. security levels, and logging and recovery for both CPU and disk media 
  1409. failure. Additional features of ITASCA include dynamic schema 
  1410. modification, long-duration transactions, shared and private databases, 
  1411. distributed version control, distributed transaction management, distributed 
  1412. query management, distributed change notification, object migration, and 
  1413. an extensible architecture.
  1414.  
  1415. Shared and private databases exist in a distributed environment in ITASCA. 
  1416. The shared database is distributed across workstations (sites) in a network. 
  1417. An ITASCA server controls the partition of the shared database at each site. 
  1418. ITASCA clients provide transparent access to the various partitions of the 
  1419. shared database. The architecture allows any number of private databases at 
  1420. each distributed database site. Data can move between private and shared 
  1421. databases. Private databases allow private data that is not shared with other 
  1422. users of the database.
  1423.  
  1424. ITASCA stores the schema redundantly at each site to improve 
  1425. performance. The schema storage also includes code in the form of 
  1426. methods. Management of schema updates is automatic for all sites. This 
  1427. includes sites that were off-line during any changes. Automatic distribution 
  1428. of schema changes, including method code changes, simplifies database 
  1429. administration.
  1430.  
  1431. ITASCA stores each instance of data in one site. The system or a user may 
  1432. move the data from one site to another to improve data locality. Access to 
  1433. moved data remains transparent. There is no need for a user or application 
  1434. to know the specificlocation of data in the ITASCA distributed database. 
  1435. ITASCA will automatically find the location of the data. This simplifies 
  1436. distributed application development. The developer can rely on ITASCA 
  1437. finding data in the distributed database.
  1438.  
  1439. No single site acts as a master site, thus ITASCA's architecture has no 
  1440. single point of failure. ITASCA has neither a central data server nor a 
  1441. central name server. This is important for maintaining a database system 
  1442. with high availability in a networked workstation environment.
  1443.  
  1444. ITASCA supports dynamic schema modification to create a flexible 
  1445. environment for changing or customizing a database system. Authorized 
  1446. users can add and remove attributes or change the subclass/superclass 
  1447. relationship at any time. Authorized users can also add or remove partitions 
  1448. of the shared database at any time. All this can be done interactively without 
  1449. affecting other parts of the ITASCA database at the time changes occur to 
  1450. the schema. There is no need to "bring the system down" or off-load/reload 
  1451. data to restructure the database. Dynamic schema modification can 
  1452. significantly reduce maintenance costs. It also is useful in environments 
  1453. where change to data definitions are normal or relatively frequent.
  1454.  
  1455. ITASCA has a sophisticated security authorization technique tied to the 
  1456. class hierarchy. It supports both positive and negative authorizations at any 
  1457. level in the class hierarchy. For example, granting access to all objects but 
  1458. one requires only two authorizations: a global grant followed by a specific 
  1459. denial. Authorization extends to classes, instances of classes, attributes, 
  1460. and methods. Also, inheritance of authorization reduces the work of database 
  1461. administration. 
  1462.  
  1463. Long-duration transactions allow users to check objects out of the shared, 
  1464. distributed database into their private databases. Users can then change the 
  1465. objects in the private databases without affecting the shared database or 
  1466. other users. These changes can be committed to the private database. Then, 
  1467. at any later time, the user can check the updated object or objects back into 
  1468. the shared database.
  1469.  
  1470. ITASCA supports version control of objects. A new version of an object 
  1471. promotes the original or parent object to restrict further changes to the 
  1472. parent. ITASCA also supports alternate versions such that multiple versions 
  1473. can have the same parent. Promoting an object version to a released status 
  1474. restricts any deletion of the object. ITASCA uses generic versions to 
  1475. dynamically reference the most recent or default version of an object 
  1476. without any intervention by a user or application.
  1477.  
  1478. Change notification in ITASCA is either flag-based or message-based. 
  1479. Flag-based notification will identify an updated object upon querying the 
  1480. object for such information. It is a passive notification scheme. Message-
  1481. based notification, on the other hand, is an active notification scheme. It 
  1482. will execute a method (or code) upon an update or other change to an object. 
  1483. Such methods can send mail messages or invoke other methods or 
  1484. programs. 
  1485.  
  1486. Memory management in ITASCA uses both page and object buffers. 
  1487. ITASCA has a traditional database page buffer scheme that contains pages 
  1488. with multiple objects. Desired objects move from the page buffer to an 
  1489. object buffer. The object buffer then provides ITASCA with enhanced in-
  1490. memory performance because it contains only frequently-referenced 
  1491. objects. 
  1492.  
  1493.  
  1494. > Matisse
  1495.  
  1496. OODBMS FEATURES LIST:
  1497.  
  1498. An Industrial Strength Open Semantic Object Database
  1499.  
  1500. Performance
  1501. -       Symmetric, Fine Grain, Multi-Threaded Architecture
  1502. -       Parallel and Asynchronous Disk I/O
  1503. -       Automatic Disk Optimization through Dynamic Clustering
  1504. -       High Speed OLTP Environment
  1505. Reliability
  1506. -       24 Hour - Mission Critical Operation
  1507. -       Media Fault Tolerant (Object Replication)
  1508. -       Transparent On-line Recovery
  1509.