From: Anjula.Garg@newcastle.ac.uk (Anjula Garg (EDC))
Newsgroups: comp.databases,comp.object
Subject: OODBMSs results from survey
Summary: Survey Results
Keywords: OODBMSs
Date: 10 Apr 92 14:26:08 GMT
Distribution: comp
Organization: University of Newcastle upon Tyne, UK, NE1 7RU


THANKS TO EVERONE WHO REPLIED TO MY QUERIES WHICH ARE GIVEN BELOW, FOLLOWED BY THE RESPONSES:

================================== QUERY 1 ====================================================

I am doing a survey on OODBs for Application in Enginneering. We are an R&D centre running
a range of 15 projects which will eventually need to access large amounts of information stored
on various engineering products on this database.

We are interested in the experience of people in the use of OODBs. Experience with the following
is of particular interest:

        - Ontos
        - Versant
        - Objectivity
        - O2
        - GBase
        - or any other OODB that is sufficiently mature.

We would appreciate comments on:

        - Specific features
        - Limitations/ shortcomings
        - Interface to Object SQL
        - Interface to PDES/STEP standards
        - Any language bindings
        - Any Browsers/Debuggers and their quality
        - Initial purchase costs involved
        - Maintenance costs involved
        - Suitable hardware platforms (in UNIX workstation range)

A prompt response would be much appreciated.

Please reply to me directly. The findings of this survey will be summarised to the group asap.


Anjula Garg

RESPONSES:
==========

From brian Thu Feb 20 14:47:45 1992
To: anjula
Subject: SUMMARY: OODBMSs for Network Management Interfaces

In January 1992, Brian posted a query on the use of OODBMSs to build
network management interfaces (or network management servers).  
Below is the consolidation of responses he received.

--------------------------

From: exudjr@exu.ericsson.se (David Richard)
Subject: OODBMSs for Network Management Interfaces

Has anybody attempted to implement a network management
interface using an object-oriented database management
system? We're considering this, and so would like to hear
about your experiences.  In particular, did using an
OODBMS make it easier to implement/manage the interfaces?
And did performance suffer too much?

For those of you who speak OSI management (or TMN), a more
precise description of what we're interested in doing is
to use an OODBMS to build a management information base
(MIB) in a mediation system to an embeded system. We've
built (partway) an MIB from scratch, and so we would like
to know what we can gain from using an OODBMS.

I appreciate any life stories :-)  I'll email consolidated
summaries of what I receive to anyone who's interested.

By the way, is there any mailing lists or newsgroups
devoted to the discussion of OSI Management and/or
telecommunications management networks?

--------------------------

From: villagra@dit.upm.es (Victor A. Villagra)
Organization: dit

There is a mailing list for the discussion of a particular OSI Network
Management System: OSIMIS. It is a management system on top of the ISODE
package. Sometimes, there is also very interesting discussions in the
mailing list about OSI Network Management. 

If you want to subscribe, I think the e-mail address is:

osimis-request@cs.ucl.ac.uk

--------------------------

From: schoenw@ibr.cs.tu-bs.de (Juergen Schoenwaelder)
Organization: TU Braunschweig, Informatik (Bueltenweg), Germany

We are using postgres (M. Stonebraker says it's OO) for a network 
management station that also supports system management (we think 
of network management as a part of system management). From the
network management point of view, the key issue is to use the DBMS 
for statistical data. Here we like the postgres feature, to store 
the whole history of an object in an archive. So it's very easy to 
generate reports while examining the history of MIB objects.

Since we are in the developing stage, I can't tell you anything
about the performance. But we like to generate a DB schema that
is very close to the data model of the MIB.

--------------------------
 
From: chacar@timeplex.com (Ronald Chacar)

I share the same interest as you do. I am starting to work on
an OSI module where the first thing to be done is to qualify
an OODBMS to be used in the project. The issues that I will
have to address include evaluations of OODBMSs and RDBMSs.
I would be able to give more accurate information about my
experience at a later stage.

--------------------------

From: James Malcolm (comqjam@hatfield.ac.uk)

I too have thought about this sort of thing, and implemented some ideas in C++.
But that was years ago, and probably wouldn't help you much.  The (very
elemntary) implementation was never written up, but our ideas were presented 
in "Issues in LAN Management" ed. Dallas and Spratt.  The paper title was:
'Recnik: a virtual database for the coordination of distributed network 
management services' (pp161-172) by Dejan Sirovica and James Malcolm

...
Also can post you a photocopy of the paper if you think it might help.

--------------------------

From: didier@o2tech.fr (Didier Plateau)

My name is Didier Plateau and I work for a company
called O2 Technology which markets an OODBMS called O2
(have you heard of it ?)

I read your mail in the news concerning the implementation
of a network management interface on top of an ODBMS.

One of our main customers, CNET which is France Telecom
R&D lab has been using O2 for more than a year to prototype
a CMIS/CMIP platform on top of our object server.

We have been through an evaluation process and then through
a prototyping stage. CNET has been happy enough with the experimentation
and decided to extend the experimentation and go with more
ambitious projects. We are also discussing with France Telecom,
Telesystemes (A france Telecom subsidiary) but also with Siemens
(In Zurich where they are involved in network administration).

If you want to know more about the O2 system, I'll be glad
to give you more information.

I am looking forward to hear from you,

     Didier Plateau
     O2 technology
     7, Rue du Parc de Clagny
     78035 Versailles Cedex
     France

     Tel: +33 1 30 84 77 91
     Fax: +33 1 30 84 77 90
     Email: didier@o2tech.fr

PS: sometimes, the email reply does not work correctly.

>From didier@o2tech.fr (Didier Plateau)

There was a good issue of CACM (Comunications of the ACM, October 1991
Volume 34, Number 10) on "Next Generation Database Systems".
It contains papers describing 3 ODBMS (ObjectStore from Object Design,
Gemstone from Servio and O2 from O2 Technology) and 2 extended
relational systems (Postgres and Starbust).

--------------------------

From: Jeff.Bone@EBay.Sun.COM (Jeff Bone)

I'm not affiliated with these guys, but...

Tivoli Systems has won bids from OSF and UI/USL to provide same with
their Distributed Object Management technology as a basis for building
system administration and management applications.  My understanding
is that the framework technology will be part of the OSF and UI/USL
distributed environment offerings, and Tivoli and others will write
applications to the open framework API to implement system management
services.

Tivoli's existing product is called WizDOM, and is pretty slick.  They
are located in Austin, and they can be reached at (512) 794-9070. If
you do contact them, tell 'em I put in a good word for them. ;)

--------------------------

From: rory@spock.retix.com (Rory Ward)

As far as I know there aren't any specific mailing lists for
discussion of management. comp.protocols.iso is probably your best
bet. However, the OIW (OSI Implementors Workshop) Network Management
SIG (based in NIST) has a mailing list. It is mainly for passing info
about the SIG, but sometimes they answer technical questions regarding
the standards.  I haven't seen anything about implementations & their
associated problems on this list. To get on the list, talk to
nmsig-request@ics.uci.edu. To mail to everyone on the list, talk to
nmsig@ics.uci.edu

--------------------------

From: alex@netdev.comsys.com
Organization: Communication Systems Research

We are working up an SS7 MIB for an SCP. I'm very interested in
what you have accomplished. We have also considered developing
management services using the facilities of an OODB.

Let me know how you progress. Are you building a management system
or a managed system ? If management system perhaps some interoperability 
testing would be most useful. Are there such arrangements ?

	We are building a managed system.  Anybody want to take
	Alex up on his offer? - djr

--
========================================================================================

FOLLOWING ARE THE RESPONSES I RECEIVED DIRECTLY FOR THE QUERY I HAD POSTED.

From georg@de.heeg Thu Feb 27 12:50:54 1992
Subject: Re: OODBs Report

Why don't you look at GemStone?

Georg Heeg


From Stewart.Clamen@edu.CMU.CS.SP.BYRON Thu Feb 27 23:32:06 1992
To: "Anjula Garg (EDC" <Anjula.Garg@uk.ac.newcastle>

This is a little out of date, not having been updated in six months or
so, but you might find it useful.

------- Forwarded Message

The following is the result of my public survey into the schema
evolution and database conversion support exhibited by known research
and commerical DB and OODBMS.  Further contributed are welcome.

	     --------------------*-*---------------------

Direct quotes are attributed by including the email address of the
poster directly following the information.  Prose written by the
poster, but with primary information provided by email are so
identified.  Information gleaned from publications are so noted.  The
information included here is not intended to completely describe the
systems addressed, but rather, to describe what support, if any, is
provided by the system for the evolution of schemas and the conversion
of database objects (class instances) resulting from the schema
change.

							SMC

		       ----------*-*----------


		 <<< EXTENDED RELATIONAL DB MODEL >>>

			<< Research Systems >>


> POSTGRES (Berkeley)

You ask explicitly about type evolution.  We support schema
modification on all classes, including user classes.  This means that
you can add attributes (instance slots) and methods at any time.
Further, since postgres is a shared database system, such changes are
instantly visible to any other user of the class.

The language syntax supports attribute deletion, but the system won't
do it yet.  Since all data is persistent, removing attributes from a
class requires some work -- you need to either get rid of or ignore
all the values you've already stored.

[mao@postgress.berkeley.edu]



<			<<< OO DATA MODEL >>>

			<< Research Systems >>

> COOL/COCOON (ETH Zurich)

No implementation as yet.  Project goals are:

- to develop a general formal framework for investigations of all
  kinds of schema changes in object-oriented database systems
  (including schema design, schema modification, schema tailoring, and
  schema integration);
- to find implementation techniques for evolving database schemas,
  such that changes on the logical level propagate automatically to
  adaptations of the physical level (without the need to modify all
  instances, if possible).

Contact Markus Tresch <tresch@inf.ethz.ch> for more information.


> Encore (Brown)

Objects are never converted, rather, classes are versioned, and the
user can specify filters to make old-style instances appear as new
instances to new applications (and vice versa).

REFS:
 	Andrea H. Skarra,  and Stanley B. Zdonik. "Type
	Evolution in an Object-Oriented Database."  In the
	book, "Research Directions in Object-Oriented
	Programming", by Shriver and Wegner.  (An earlier
	version of the paper appears in the proceedings to
	OOPSLA86.) 

[clamen]


> ORION (MCC/Itasca System, Inc.)

ORION is a prototype OODBMS developed at MCC, an American consortium.
It is built on top of Common Lisp, and is intended to support
applications such in the CAD/CAM, AI, and OIS domains.  Advanced
functions supported include [object] versions, change notification,
composite objects, dynamic schema evolution, and multimedia data.

For schema evolution, ORION identifies a list of database-consistency
constraints that must be preserved across any class evolution
operation.  They then list the type of evolution operations you can
perform, and how the relevant instances can be converted.  Conversion
is performed as the instances are accessed.

I have found nearly a dozen papers published by the ORION folks.  The
most recent and general one is:

	W. Kim, N. Ballow, H-T. Chou, J.F. Garza, D. Woelk,
	and J.  Banerjee. "Integrating an Object-Oriented
	Programming System with a Database System."
	Proceedings of OOPSLA88.  [Pointers to the previous
	papers documenting each of the advanced features
	listed above are cited therein.]

The paper most relevant to the issue of schema evolution is the
following:

	J. Banerjee, W. Kim, H.J. Kim, H.F. Korth.
	"Semantics and Implementation of Schema Evolution in
	Object-Oriented Databases." Proceedings of SIGMOD87.

[clamen]


> Exodus (UWisc)

No solution for the problem of schema evolution is provided.
Emulation is rejected by the authors, who claim that the addition of a
layer between the EXODUS Storage Manager and the E program would
seriously reduce efficiency.  Automatic conversion, whether lazy or
eager, is also rejected, as it does not mesh well with the C++ data
layout.  To implement immediate references to other classes and
structures, C++ embeds class and structure instances within its
referent.  The resulting change in the size of the object might
invalidate remote pointer references.

	Joel E.  Richardson and Michael J.  Carey.  "Persistence
	in the E langauge: Issues and Implementation."  Appeared
	in "Software -- Practice and Experience",
	19(12):1115-1150, December 1989.

[clamen]


> Machiavelli (UPenn)

Machiavelli is a statically-typed persistent programming language
project at the University of Pennsylvania.  It does not address type
evolution. 

[communication with limsoon@saul.cis.upenn.edu]


> ConceptBase

We have developed a deductive object-oriented database called
ConceptBase where everything (tokens, classes, meta-classes
,meta-meta-classes ,attributes, instantiations, specializations) is
treated as an object. That means that you may update the "schema"
(classes) at any time just as any other ordinary object.

The systems has (user-defined and builtin) integrity constraints that
prevent inconsistency (e.g. violation of ref.integrity).  Integrity
constraints in ConceptBase are (as in most other systems) static,
i.e., they are conditions that each database "state" must satisfy.

The data model we use does not distinguish schema level information
(i.e. classes) from instance level information. If you change for
example some classes and this change violates some integrity
constraints, e.g.  some instances now don't have the right attribute
types anymore, then you have the choice either to reject the update or
to change the existing DB. Currently, ConceptBase simply rejects such
updates.  We are thinking of exploiting abduction (see VLDB'90 article
of Kakas&Mancarella) to make more clever reactions in the sense of
"reformating" instances.

[Manfred Jeusfeld <jeusfeld@forwiss.uni-passau.de>]



> AVANCE (SYSLAB)

An object-oriented, distributed database programming language.  Its
most interesting feature is the presence of system-level version
control, which is used to support schema evolution, system-level
versioning (as a way of improving concurrency), and objects with their
own notion of history.  System consists of programming language (PAL)
and distributed persistent object manager. 

REFS: 
	Anders Bjornerstedt and Stefan Britts. "AVANCE: An
	Object Management System".  Proceedings of OOPSLA88.

[clamen]


> Altair/O_2 (INRIA)
Neither of the two articles I have (bibliographic information below)
address the issue of schema evolution or database conversion.

REFS:
	F. Bancilhon, G. Barbette, V. Benzaken, C. Delobel,
	S. Gamerman, C. Lecluse, P. Pfeffer, P. Richard,
	and F. Velez.  "The Design and Implementation of
	O2, and Object-Oriented Database System".
	Advances in Object-Oriented Database Systems,
	Springer Verlag. (Lecture Notes in Computer Science
	series, Number 334.)

	C. Lecluse, P. Richard, and F. Velez. "O2, an
	Object-Oriented Data Model".  Proceedings of
	SIGMOD88.  Also appears in Zdonik and Maier,
	"Readings in Object-Oriented Database Systems",
	Morgan Kaufmann, 1990.
	
[clamen]


> OTGen (CMU)

OTGen describes a scheme for computer-assisted schema evolution.  A
wide variety of changes (wider than those supported by Orion or
GemStone) can be expressed in the evolution "mini-language", which
describes a procedure for transforming instances from their new to old
representations.  Objects are converted as databases (which in the
invisioned OTGen system are rather small) are opened.

REFS:

	Barbara Staudt Lerner and A. Nico Habermann. "Beyond
	Schema Evolution to Database Reorganization" in
	Proceedings of OOPSLA/ECOOP '90.

[clamen, blerner@cs.umass.edu]




		       << Commercial Systems >>

> CLOS

Not persistent, but implementations must support redefinition of
classes and the conversion (either lazy or eager) of existing
instances. [c.f. CLtL II]  In spite of this freedom, implementations
seem to convert lazily.
[communication with gregor@parc.xerox.com, hornig@symbolics.com,
 dussud@lucid.com] 


> Statice (Symbolics)

I'm familiar with Statice, sold by Symbolics Inc.  The Statice command
"Update Database Schema" brings an existing database into conformance
with a modified schema.  Changes are classified as either compatible
(lossless, i.e., completely information-preserving) or incompatible
(i.e., potentially information-losing in the current implementation).
Basically, any change is compatible except for the following:

    -- If an attribute's type changes, all such attributes extant
    are re-initialized (nulled out).  Note that Statice permits
    an attribute to be of type T, the universal type.  Such an
    attribute can then take on any value without schema
    modification or information loss.

    -- If a type's inheritance (list of parents) changes, the
    type must be deleted and re-created, losing all extant
    instances of that type. This is Statice's most serious
    current limitation.  The simplest workaround is to employ a
    database dumper/loader (either the one supplied by Symbolics
    or a customized one) to save the information elements and
    then reload them into the modified schema.

[lgm@iexist.att.com]


> Versant 

Versant provides schema evolution. But in the current release, only
leaf classes in the schema can be modified. Leaf classes can be
added, dropped, renamed and individual attributes and methods 
changed. The class instances are modified later as they are accessed.
There are no security mechanisms for preventing users from 
changing schema. Schema changes are done using a separate utility 
which compares files (with .sch extension) which contain new schema
definitions with those of a database and changes the database schema
so that there is no difference. In case of conflicting class names
or other situations user has control on resolving the conflict.
[h.subramanian@trl.OZ.AU]

I've been looking at the C++ database vendors. Versant has schema
evolution at the leaf class level only. They're trying to come up with
a good way to do it for the general case. They talk about using
versioning to mark class evolution. Then they want to test timestamps
when an object is retrieved to see whether its class has been changed.
If it has, they reformat the object to conform to the new definition
at that time.
[arc!chet@apple.com]


> Object Design

Object Design, to the best of my knowledge, do[es]n't support schema
evolution at this time.

[arc!chet@apple.com]


> Objectivity 

Objectivity, to the best of my knowledge, do[es]n't support schema
evolution at this time.

[arc!chet@apple.com] 


> ObjectStore

ObjectStore does not provide schema evolution as yet but it has
promised to provide schema evolution in the next release.
[h.subramanian@trl.OZ.AU]

	
> Ontos [formerly VBase] (Ontologic)

Ontos provides schema evolution. It allows any class to be modified.
The major drawback is that data does not migrate ie., instances are
not modified to adopt to the new class definition. So schema changes
can be done only on classes that do not contain instances and do not
have sub classes that contain instances.
[h.subramanian@trl.OZ.AU]

As a system for experiments, we are currently using ONTOS from
Ontologic Inc.  Unfortunately, there is no transparent concept of
schema evolution for populated database. Thus, we still investigate
how it works.
[Markus Tresch <tresch@inf.ethz.ch>]


> GemStone (Servio-Logic)

The authors reject the emulation scheme and the lazy conversion
approach as previously outlined.  Instead, they favor a mixed
strategy, which involves lazy conversion until the next garbage
collection, at which point all remaining old instances are upgraded.
(Their current implementation, however, does not yet support this
feature --- the conversion being done eagerly for the time being.)
They identify a list of constraints which must be preserved across
modification to type descriptions and to the inheritance hierarchy.
The authors then proceed to enumerate a number of categories of object
updates that are permitted, and what changes to the dependent
instances and subclasses must be performed in order to maintain the
integrity of the database (i.e., to preserve the above constraints).

REFS: 
	Robert Bretl, David Maier, Allan Otis, Jason Penney,
	Bruce Schuchardt, Jacob Stein, E. Harold Williams,
	Monty Williams. "The GemStone Data Management
	System."  Chapter 12 of "Object-Oriented Concepts,
	Databases and Applications", by Kim and Lockovsky.

[clamen]


> Base/OPEN (NMP-CAD)

A structurally object-oriented system (ie. methods are not stored),
only schema extension is supported.  Instances of older type-versions
are never converted, but can coexist in the database with newer
objects. 

[communication with tomas@basf.nmpcad.se]



			 <<< OTHER MODELS >>>

		       << Commercial Systems >>

> Pick

With Pick and its variants you only have problems if you want to
redefine an existing field.  Because of the way the data are stored
and the separation of the data and the dictionary you can define
additional fields in the dictionary without having to do anything to
the data - a facility which we have found very useful in a number of
systems.

There is no general facility to redefine an existing field - you just
make whatever changes are required in the dictionary then write an
Info Basic program to change the data.  We have seldom needed to do
this, but it has not been complicated to do.

[Geoff Miller <ghm@ccadfa.cc.adfa.oz.au>]


> IDL (Persistent Data Systems)

IDL is a schema definition language. Schema modifications are defined
in IDL, requiring ad-hoc offline transformations of the database, in
general.  A simple class of transformations can be handled by
IDL->ASCII and ASCII->IDL translators (i.e., integer format changes,
list->array, attribute addition).

[conversation with Ellen Borison of Persistent Data Systems]


			<< Research Systems >>

> IRIS (HP Labs)

Objects in the Iris system may acquire or lose types dynamically.
Thus, if an object no longer matches a changed definition, the user
can choose to remove the type from the object instead of modifying the
object to match the type.  In general, Iris tends to restrict class
modifications so that object modifications are not neccssary.  For
example, a class cannot be removed unless it has no instances and new
supertype-subtype relationships cannot be established.

REFS:
	D.H. Fishman, D. Beech, H.P. Cate, E.C. Chow, T.
	Connors, J.W. Davis, N. Derrett, C.G. Hock, W. Kent,
	P. Lyngbaek, B. Mahbod, M.A. Neimat, T.A. Tyan, M.C.
	Shan. "Iris: An Object-Oriented Database Management
	System".  ACM Transactions on Office Information
	Systems 5(1):48-69, Jan 1987.

[clamen]

------- End of Forwarded Message

--
Stewart M. Clamen			Internet:    clamen@cs.cmu.edu
School of Computer Science		UUCP: 	     uunet!"clamen@cs.cmu.edu"
Carnegie Mellon University		Phone: 	     +1 412 268 3620
Pittsburgh, PA 15213-3890, USA		Fax:	     +1 412 268 1793



From simmel%com.oberon.iago@com.oberon.titania Fri Feb 28 09:13:24 1992
To: Anjula.Garg@newcastle \(\).ac.uk \(\) (\) (Anjula Garg \(EDC\))
Subject: OODBs Report


AG> I am doing a survey on OODBs for Application in Engineering. 
AG> We are an R&D center running
AG> a range of 15 projects which will eventually need to access large 
AG> amounts of information stored
AG> on various engineering products on this database.
AG> 
AG> We are interested in the experience of people in the use of OODBs.
AG>  Experience with the following
AG> is of particular interest:
AG> 
AG> - Ontos
AG> - Versant
AG> - Objectivity
AG> - O2
AG> - GBase
AG> - or any other OODB that is sufficiently mature.
AG> 

Although Kala is *not* and OODBMS, it is quite relevant to the
application domain you're trying to cover. You can think of it as a
toolkit to put together your own OODBMS, supporting your own
functionality and requirements, in such areas as data/object models,
transactions, versions, access control, configurations, etc.

If you'd like more information, please send me your mailing address,
and I will send you an informative package.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

                         ====================
                         Kala Technical Brief
                         ====================


------- 
Summary
------------------------------------------------------------------------------
The Kala(tm) Engine manages distributed, shared, arbitrarily complex
and evolving persistent data. Kala is a highly efficient and secure
transactional store. Kala supports any types of transactions,
versions, access control, security, configurations. Kala is an
untyped, low-level engine, built for high performance, compactness,
and portability. Kala is used for applications such as: kernel of DBMS
products, substrate for extended file systems, implementation of
language persistence, data manager for groupware applications as well
as applications which deal with large, complex, and changing volumes
of data (text databases, financial distributed transaction systems).
Kala is a component of broad reuse.


--------
Features
------------------------------------------------------------------------------
- The execution architecture is that of multiple (communicating)
  servers and multiple clients. Kala can also be configured in a
  standalone (single process) mode. Kala's IPC is built for maximum
  performance, portable to any given datagram protocol.

- The managed data elements are made out of uninterpreted bits and
  references. Data elements (named `monads') are universally uniquely
  identified. Bits are stored with no overhead. References,
  represented in memory as native machine pointers, are stored
  very compactly, introducing an average of 2.5 bytes overhead.

- Kala is a fully recoverable system, short of media damage.

- The Kala primitives support arbitrary transaction models, including
  classic short transactions, long (persistent) transactions, nested
  transactions, shared transactions, pessimistic and optimistic
  policies, etc. Concurrency control is achieved through two locking
  mechanisms (short-term and long-term (persistent, shared) locking),
  with full support for atomicity of operations and two-phase commit.

- The Kala primitives support arbitrary versioning models, allowing
  versions to co-exist in split/rejoined networks, various version
  organization strategies (single-thread, tree, DAG, etc.). Kala
  primitives provide mechanisms for arbitrary access and update
  triggers, such as notifications, security checks upon access/update,
  etc. -- with no limitations on what the trigger code does. Kala
  provides protection measures against virus and other intruding
  executions.

- The Kala primitives support a wide range of access control, security
  and protection models, including revocable access rights, access
  control without the overhead of ACL management, arbitrary access
  validation routines, etc. Kala does not introduce any more security
  holes than the operating environment already has.

- Kala has primitives for physical store allocation and de-allocation
  management, for a wide spectrum of store administrative tasks, as
  well as licensing administration. The latter includes application-
  sensitive time-limited client-connect-based licensing, as well as
  metered (connect/load/store) usage. Kala can be set up to do
  automatic archiving and backup of its physical store.

- Kala provides a wide spectrum of licensing schemes, usable by
  platforms and applications built upon Kala to their customer base.
  Kala provides renewable licenses, perpetual licenses, full
  protection against duplication without hardware (hostid) support,
  metered usage, etc.

- And more ... not fitting on this page-long Technical Brief.


--------
Benefits
------------------------------------------------------------------------------
* For those who need functionality traditionally associated with
  databases, but cannot tolerate the overhead and complications DBMS
  products introduce, Kala offers a flexible, compact, performant,
  elegant, and simple alternative.

* For those whose application domain requires data models where the
  mapping to those offered by today's DBMS products is cumbersome,
  introduces development and execution overhead, and is not portable
  across multiple linguistic and environmental platforms, Kala offers
  a data model independent interface against any data model
  expressible in terms of bits and pointers can be easily built.

* For those who need DBMS functionality or qualities that no single
  DBMS product now has, Kala offers the opportunity to build that
  functionality now, and not wait for one vendor or another to deliver
  it later.

* For those who need performance, size, portability, storage
  compactness, and industrial strength that no single DBMS product can
  now satisfy, Kala offers all of the above now.

* For those who realize that while object-level inter-operability is a
  strong desideratum, the likelihood of a single, universal such model
  is practically zero, it is data store interoperability that brings
  us beyond file systems is the best practical bet -- Kala offers such
  a basis for data store interoperability now.


------------
Availability
------------------------------------------------------------------------------

o Kala is available now on Sun platforms (SunOS / 68K & SPARC). A
  80x86/DOS version is now available to alpha and early beta sites.
  Ports to Windows and MacOS are also likely in the near future. Any
  port is possible as NRE.
o Kala's interface is ANSI C, also callable from C++.
o For pricing and other information, please contact me at the phone or
  fax numbers below, or via e-mail at simmel@oberon.com



      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



AG> We would appreciate comments on:
AG> 
AG> - Specific features

    See short write-up above (and more in the information package I
    can send you).

AG> - Limitations/ shortcomings

    Kala in fact addresses many of the limitations of today's
    commercial OODBMS products by providing a small set of reusable
    primitives on which functionality not supported (and often, not
    supportable) by today's OODBMS products can be built with little
    effort.

AG> - Interface to Object SQL

    Not-being a DBMS, it has none. See however one of our AppNotes
    illustrating how a layer that interfaces to an arbitrary set of
    heterogeneous DBMS and to Kala itself can be easily built, and
    still support atomicity of transactions, concurrency control,
    etc.

AG> - Interface to PDES/STEP standards

    None.

AG> - Any language bindings

    ANSI C, C++.

AG> - Any Browsers/Debuggers and their quality

    Part of the API is specifically dedicated to building admin tools.

AG> - Initial purchase costs involved

    A wide range of licensing options, from perpetual licensing (the
    most traditional form) to renewable licensing to metered usage
    ("pay as you use"). Prices vary with platform and volume quite
    substantially (e.g., volume discounts start at quantity 2).

    Just as an example, on the SPARCstation, the first client-year
    renewable license is US$795.

AG> - Maintenance costs involved

    Again, depends on the licensing option chosen. For the same
    example above, all regular maintenance and upgrades during the
    lifetime of the license are free.

AG> - Suitable hardware platforms (in UNIX workstation range)

    Currently: SPARCstation (SunOS), Sun 3 (SunOS). DOS version in
    alpha.

AG> Please reply to me directly. The findings of this survey will be 
AG> summarized to the group ASAP.

Looking forward to your request for more info.



  ___    ___    ___   ________________________________________________________ 
 |   `  |   `  |   `  Sergiu S. Simmel       Software Author & Developer
  \ __   \ __   \ __   50 Princeton Road      Internet: simmel@oberon.com 
       \      \      \  Arlington, Mass        Voice:  +1-617-646-7935
   ` ___) ` ___) ` ___)  02174-8253 USA         Fax:  +1-617-646-5753 















================================== QUERY 2 ====================================================



Does anyone know where I could get a report or reports on:

Comparison of OODBMSs for Application in Engineering

I am trying to collect sufficient information on whether or not
going for OODB is the right way to go for our Engineering Design  
Centre.

Thanks in advance for the information.

Anjula Garg

RESPONSES:
==========

----------------------------------------------------------------------------------------------

From benson@edu.washington.ee.dblab Wed Apr  1 22:51:09 1992
Subject: Re: Comparison of OODBMS for Application in Engineering

I think I got my copy at the last OOPSLA conference. Here's the  
information I have on it:

Massachusetts Institute of Technology
Intelligent Engineering Systems Laboratory
Department of Civil Engineering

"A Comparison of Object-Oriented Database Management Systems for  
Engineering Applications"

by
Shamim Ahmed
Albert WOng
Duvvuru Sriram
Robert Logcher

May 1990
May 1991

Order No. IESL90-03, 91-03
Research Report R91-12
copyright May 1991 Sriram, et. al.


----------------------------------------------------------------------------------------------

From drew@com.netcom Thu Apr  2 16:21:43 1992

This is our particular expertise and focus, Anjula.
We'll send you some information about our product.
If you'd like to hear more, please feel free to contact me or
Remy Malan.

thanks.

-Drew Wade

----------------------------------------------------------------------------------------------

From cnb%cnbisis%lerami@edu.uta.utacfd Fri Apr  3 05:11:13 1992

Based on available literature and evolving standards and requirements it 
would appear to me that OODBs are not yet ready for prime time.  But then 
one of the founders on Ingress described relational DBs that way as recently 
as 1990.   
 
I also appears that there are such a host of viewpoints and potential uses 
for OODB that it is problably to early in the game to be able to do any 
generally useful comparison.  It depends VERY much on what you are 
attempting to accomplish.  Will the product or vendor be around in 6 years?
Who knows. 
 
Your time line horizon, purpose, and the attributes of your application 
could very well drive you to pick any of the available vendors. 
 
Thanks, 
Nelson Baird


----------------------------------------------------------------------------------------------


From mh5l+@edu.cmu.andrew Sat Apr  4 02:46:58 1992

A paper by Ahmad, S. et al."A comparison of object-oriented database
management systems for engineering applications" in the Proceedings of
the 7th conference on computing in civil engineering. 1991. ASCE.
Washington, D.C.  The conference proceedings also include many papers on
the use of databases in civil engineering.

If you need more information, send me e-mail and I'll be happy to respond.

Maher Hakim

----------------------------------------------------------------------------------------------

From awb@edu.cmu.sei Wed Apr  8 05:48:43 1992

Here are a couple of references you might find of interest.  Also try
the Departmental library in the Computing Lab at Newcastle, since
I did my PhD there in 1988 !!

Alan Brown.


@article{key11,
        author =        "A.W. Brown",
        year =          "December 1988",
        journal =       "Computer-Aided Engineering Journal",
        number =        "6",
        pages =         "226--232",
        title =         "{The Relationship Between CAD and Software
Development
Support: A Database Perspective}",
        volume =        "5"
}

@book{key16,
        author =        "A.W. Brown",
        year =          "1990",
        publisher =     "Chapman and Hall",
        title =         "{Database Support for Software Engineering}"
}

@book{key19,
        author =        "A.W. Brown",
        year =          "1991",
        publisher =     "McGraw-Hill",
        title =         "{Object-Oriented Databases: Application in Software
Eng
ineering}"
}



----------------------------------------------------------------------------------------------


From richieb%bony1@com.psi.uu Thu Apr  9 10:03:50 1992

There is a report from MIT called "A Comparison of OODBMS for
Engineering Applications". Order number for it is: IESL90-03,91-03,
Research Report R91-12.

I picked up my copy at OOPSLA, but you maybe able to get it by calling
MIT's Department of Civil Engineering.

There is also a book published by OVUM (an English company) called
"Databases for Objects", which compares some OODBMS systems. This book
is expensive (about $1200).

...richie


-- 
* Richie Bielak   (212)-815-3072   | "Your brain is a liquid-cooled parallel  *
* Internet:       richieb@bony.com | super-computer". He pointed to his nose, *
* Bang {uupsi,uunet}!bony1!richieb | "This is the fan."                       *
*    - Strictly my opinions -      |                     - David Chudnovsky - *