The Elusive Promise of Ubiquitous OOOO programming languages and applications designed using OO
technology are widely accepted. Nevertheless, in most contemporary
software systems, information is still stored and manipulated via
files or relational databases (with "data" and "process"
separated), and the interfaces to common OS services are modeled
as function calls. As a result, our object models are frequently
corrupted by these physical considerations at much higher levels
of abstraction than we would wish, and we spend much of our
careers struggling with (amply documented) "impedance mismatches"
between our OO programming model and the non-OO context in which
our software lives. We have been highly influenced by the work of the RAPIDS group at the
University of Glasgow; we specifically refer the reader to "Orthogonal
Persistent Object Systems", M.P. Atkinson and R. Morrison,
VLDB Journal, vol. 4, no. 3, 1995, which is for us
something of a manifesto. Much more briefly stated, our goals are
to work towards --
> |
An application development environment
(including operating system services) that presents a model of
cooperating persistent objects; and -- |
> |
An end-user model that, through an
OOUI, is highly congruent to the business object model as
implemented in the underlying software system. |
This problem has been understood by software vendors, and
various attempts made to solve it, for much of the past decade;
witness the goals and efforts of --
> |
The Spring
operating system from Sun Microsystems, a secure OS built
from the ground up on the basis of cooperating objects; |
> |
The OpenDoc
initiative from Apple and IBM, a compound document
infrastructure permitting pluggable "part editors" and
flexible embedding; |
> |
The Component Object Model (COM) from Microsoft
which, despite much hype and initial promise, has yet to
yield a truly integrated OO application development
environment; |
> |
The long-forgotten "Pink" application
environment from Taligent; and -- |
> |
The Self project,
once again from Sun Microsystems. |
If one is to take this work seriously -- and we here do --
then, clearly, a paradigm shift is needed and has been for quite a
while. However, and especially given the current burgeoning demand
for new software and the urgency with which it must be delivered,
we do not live in a climate particularly conducive to stepping
back and re-evaluating our approach. FavaBeans is an attempt to
change this state of affairs; it is based on two imperatives
--
> |
Change the world through
pictures. A system which introduces developers to a
visual metaphor for a persistent object system will
help them to think of their applications in these terms and
lead them to ask for more pieces to fill the gaps underneath
the pretty visuals; and -- |
> |
Make it easy, fun and
rewarding. In order to achieve widespread
acceptance, such a system must be compatible with currently
popular technologies, and must provide a tangible
improvement in the quality of the software development
process and the products that result from it. |
We can change the world through pictures by providing an OOUI
framework. This seems like a strange statement to make when almost
all mainstream desktop environments -- Windows, the Macintosh OS,
and several Unix window managers -- have adopted OOUI concepts.
And yet they implement OOUI operations (dragging and dropping,
consistent contextual menus, etc.) primarily at the level
of files and directories and, as a result, do little to help
developers make the mental shift away from filesystems; this is
true even for the latest versions of Windows (Windows XP) and the
Macintosh OS (Mac OS
X). We need to provide a framework that allows people to build
fine-grained OOUIs into their applications. We choose Java as our base system not only because of its
popularity but also since it is better for our purposes than any
other commercially viable alternative. Due to both JVM
improvements and increases in available CPU speeds, Java programs
now run fast enough to do real work. And the Java environment is
safe enough to permit long-running applications that don't "crash"
arbitrarily due to memory overwrites; it provides a good run-time
type introspection facility; and it ships with an extensive
standard class library. That said, Java is far from ideal; most
irksome, in our opinion, are its retention of the traditional
separation of "code" and "data" that makes transferring mobile
objects between loosely coupled systems inconvenient at best; its
failure to provide a coherent system for the wide-area deployment
of disparate versions of a code base; its dearth of management
facilities for shared state in java.lang.System and
elsewhere; and its lack of support for orthogonal long-term
persistence. But -- these problems are being addressed,
and Java will do for now. What we Have to Offer
> |
An attractive OOUI implementation.
FavaBeans presents what is by now a pretty familiar OOUI
visual metaphor (see Screenshots). We have folders,
which can be displayed as lists of icons or tabular "details"
views. Every object has a property sheet; every view has a
contextual menu (there are no menu bars in individual
windows); and objects can be directly manipulated, primarily
by dragging and dropping. And, our plans include matching some
of the eye candy provided by the latest Microsoft and Apple
UIs; our icons, currently definable as SVG documents, will
soon be scalable, and we will support "thumbnails" for
individual objects. |
> |
A non-intrusive object model. We have
gone to great lengths to make it unnecessary to modify your
business object model in order to integrate it with FavaBeans.
Our scheme for doing this, using object types and
facets, is described under Architecture, and more
extensively in the Documentation. |
> |
Built-in goodies. Our plans include
bundling, with the base release of FavaBeans, utilities like a
Web browser; image and SVG viewers; multimedia players based
on JMF; an email and Usenet client; a Gnutella client; a local
filesystem browser; and a theme engine. These should provide
the same sort of functionality that developers and users have
come to expect from frameworks like Gnome and KDE, and should provide a
working example of how to do things "right". |
> |
Interesting scripting tools. An
important goal is to provide a visual programming tool (most
likely based on the Mozilla implementation of JavaScript, Rhino). This will
provide what may be the fundamental paradigm shift
in developers' minds: the mixing of type and instance, as in
dragging an object into a script --
for ( x in
 My favorite Bach pieces
) {
print(x);
}
|
Related WorkAs we've said, there is work already being done in Java that
can further our cause of a ubiquitous OO model; for example --
> |
The Forest project
at Sun Microsystems attempted to build an orthogonally
persistent programming environment in Java, and hoped to
tackle the issues of software development and evolution. |
> |
The OOPSLA
2000 conference featured proposals for handling the
concurrency and security issues so that mutually unrelated
applications can safely share
a JVM. This is an important step towards eliminating from our
programming model the ideas of traditional OS "processes";
program "startup" and "shutdown"; and the
main(String[]) function. |
And -- we believe that this list now includes FavaBeans. |
