From: edwardj@microsoft.com (Edward Jung)
Subject: Re: Object Oriented File System: Huh??
Date: 13 Sep 92 23:13:25 GMT
Organization: Strategy Division, Microsoft Corp.

Ernest Prabhakar writes:
>In article <1992Sep4.182618.28508@adobe.com> caro@adobe.com (Perry A. Caro)  
>writes:

>> First generation OOFS are bound to underperform mature traditional
>> filesystems. 
>
>Well, yes.  However, ObjectStore (from ODI) whom NeXT has contracted with to  
>build this sucker bills itself as a 'second-generation OODBMS'.  What does that  
>mean?  I dunno.  All I know is that their promotional literatures has  
>'performance' written all over it, so they apparently think their performance  
>is pretty good.
>
>I was curious if the Honorable Elder Statesman Mr. Caro (;-) could evaluate  
>their claims and let us know whether
>a) ODI has in fact solved that bottleneck
>b) ODI's marketing is a bunch of hooery
>or
>c) OODB and OOFS are sufficiently different that the two don't tell us anything  
>about each other.

I was browsing this newsgroup after a long hiatus from csn (and, no,
the Microsoft bashing has not subsided, I see), and this topic caught
my eye. Starting two years ago up until last year, I led an evaluation
of all the major OODBMS technologies. Microsoft has been working on
a so-called object-oriented file system for a number of years -- it
was mentioned at the NT PDC -- and I have a little perspective on
this problem. I was also the MS rep. to the OMG.

First of all, ODI is unlike most other OODBs. They are based on a
very fast page-fault handling mechanism that pages in-memory objects
into and out of disk on demand. For page-type access to objects,
and for seamless programming model between app and storage objects,
this is a very nice mechanism.

However, many applications need or want non-seamless access, because
they treat persistent objects quite differently from in-memory ones.
Access control, concurrency control, sharing, and a number of other
semantics get in the way of true seamlessness. It is possible to
make all these uniform between memory and storage (so-called single-
level store), but it is quite a different way of programming. It also
has yet to yield high-performance results. That isn't to say it is
not possible, but only that it has not been done before.

Some other systems default toward stream-like access, more like a
traditional file system.

What is orthogonal to both of these mechanisms, however, is how
the system deals with features like transaction control, robustness,
interoperability with stream-based protocols, sharing and concurrency,
and database features like queries and consistency. ODI is strong
on the programming model and seamlessness, strong on object fauling
performance, and weak on feature performance (some other DBs are
better at other things). Designing an OOFS or OODB depends on what
you think are the features you need and performance goals to
optimize. For example, Microsoft spent some time profiling our
current applications and thinking about what future OO applications
will be looking like in terms of access to persistent storage
in order to influence our designs. There is also the matter of what
the primary application of the new filesystem will be -- new forms
of information access and organization, consistency, workgroup and
workflow policy support, programming support, etc., etc.

Of course there are many more complex issues in this area, 
including UI and implementation, but I hope this helps.

Edward Jung, Software Architect, Sr. Program Manager
Advanced Systems, Microsoft Corporation
edwardj@microsoft.com