GemStone System's VM Heritage
This site has been composed, with the permission of
GemStone, by a group of practitioners who very much appreciate what
GemStone
provides to the marketplace. It's this
practitioner's perspective that sometimes it is possible to be so close
to the
company that it is difficult to know where one's value truly resides. I
believe
that GemStone's achievements in using VM technology on behalf of its'
ACID test
compliant object databases is both what binds its Java and Smalltalk
products
and is where its "magic" is--the thing that really makes GemStone
special. How so, you might ask? To answer this
question, one needs to cover a bit of history.
GemStone history, an outsider's perspective
In the early to mid nineties the "object" world, as far as
business was concerned, was comprised of C++, Smalltalk, object Pascal
(Delphi)
and any other language whose vendor put "object" in front of their
name. As far as market share is concerned, in late
1995 I remember hearing Grady Booch speak at Denver University where he
was
giving a talk from his then upcoming "Object Solutions" book. Grady
declared C++ the winner in the object
language wars. On its face you could not
argue with him. Any developer could,
and often did, purchase a C++ IDE for less than a $100 and solve real
problems
on behalf of their respective businesses. C and C++ were serving
business well. Also, about this same time the very early releases of
Java were
available to build "cross-platform" GUIs with. Well, what about
Smalltalk?
As it turns out, through hindsight, we know that Smalltalk
was at the height of its popularity, as a percentage of the market, in
the
U.S. As a language Smalltalk had
provided a terrific platform for solving real, heavy-duty business and
aerospace problems--it was, and is, a terrific, powerful language to
implement
domain-driven-design. But, it was also
prohibitively expensive.
At the time, there were two primary vendors: Parcplace and
Digitalk, which soon after became Parcplace Digitalk. As I recall, a
development seat was about $5000, irrespective of
whether you purchased Parcplace's VisualWorks or Digitalks full
offering a la
carte (you could "step into" Digitalk a bit cheaper). While my partners
and I paid the price per developer for our consulting
practice, I have only met one individual who shelled out his own money
for a
copy. As a result there was a strange
situation where ordinary developers were paying $99 for a C/C++ IDE and
having
great success with a language that was notoriously difficult to work
with
versus the proud folks of Parcplace Digitalk who believed only the
extraordinary developer could "grock" their fine tool and charged
accordingly. Long story short is that
the market eventually chose the upstart--and free--Java programming
language over
both incumbents.
The bad news for GemStone was that it lived in the shadow of
Parcplace and Digitalk. In order to benefit from its very fine
Smalltalk object
database GemStone's customers needed to have invested in and committed
to Smalltalk,
therefore most customer opportunity came from these two vendors.
While Parcplace was among the first vendors with an
interesting way to deliver UI to a browser through its VisualWave
product and
had a very mature IDE and rich set of classes, the market chose the
lesser
technology. I am not too clear on my
time lines but, much to my surprise, it seems that within a year
Parcplace
Digitalk share price went from about 50 dollars to about 50 cents. The
European company Cincom then came
along and scooped up Parcplace Digitalk for a song where Smalltalk
continues to
thrive "on the Continent" and also here with its open-source version,
Squeak.
(It is worth noting that Smalltalk still thrives much as it always has,
well
off the radar, and yet uniquely solving substantial problem domains; it
will be
interesting to see if Smalltalk makes a comeback with the advent of Web
Services where it does not matter what the implementation language is
behind
the service.) Meanwhile, GemStone took
its expertise and applied it to Java, where it helped to turn Java into
the
server-side technology it is today.
So, what was GemStone's expertise?
(I use "was" here because GemStone has since developed an
extraordinary caching product called GemFire that is not VM-based and
that you
can read about at GemStone.com.)
In 1988, GemStone-Smalltalk was the very first commercially
available object database (known as simply GemStone at the time). For
much the same reason that the Smalltalk
market was smaller than the C/C++ market, GemStone's object database
market
share was eventually surpassed by the C++ object database vendors such
as
ObjectStore, Poet, Versant et al. But,
as with the underlying technology, IMO there was nothing remotely
similar
between the products.
A friend and colleague of mine, whom I met through our
common connection to GemStone-Smalltalk, use to call his consulting
company Relevant
Magic. His practice was based on
the GemStone technology and was well named, as GemStone provided
nothing short
of magic to the then client-server world of Smalltalk. Let me explain
through a brief example.
Imagine you were working in the MVC (Model, View,
Controller) world of Smalltalk by way of a VisualWorks IDE, simply
programming
in the debugger and making great progress until, voila, you had a
completed
application. Up until this point
persistence did not matter for your model because you were working
alone, at
least for this scenario, and so you simply used the data built up in
the
Smalltalk image each time you started up. Now that you are ready to
make the application available for concurrent
use all you had to do was connect to GemStone.
With this connection your Smalltalk objects were
transparently persisted to GemStone at store or faulted into the client
VM as you
needed them. Further, you could choose
whether your method(s) would be executed in the client VM or in the
GemStone VM
on the server (Smalltalk is to GemStone as PL/SQL is to Oracle). What a
beautiful world. Simple. Elegant. Powerful.
As a result, in my opinion, GemStone's demonstrated
expertise has been to transparently persist your object model,
originally with Smalltalk and then with Java. The "transparent" part is
enabled by virtue of the machinery in the
GemStone VM that allows it to participate in
transactional-shared-memory and
that automatically tracks and manages dirty state in your "model" or
"domain"
objects, such that when you choose to commit then only the dirty
objects get
written. Transparent also because it persists all objects that are
reachable
from the root object that is bound into GemStone's root context (a JNDI
tree)
which is called "persistence by reachability". As a result, one could
say that the real GemStone expertise is in
creating enterprise-class VMs, first for Smalltalk and then for Java.
GemStone's Java story, a partner's perspective
GemStone has from very early on been a licensee of Sun's
Java VM--and Sun benefited from GemStone's expertise right away as
GemStone
engineers helped to debug Sun's nascent VM offering. As a licensee,
GemStone starts with the Java VM provided by Sun
and then enhances it to participate in transactional-shared-memory,
much the
same as GemStone's well-established and proprietary Smalltalk VM.
Similar to the extent that the Java language
was able to support what Smalltalk did (Java is a strongly typed
language where
base types are not first class objects which differs substantially from
Smalltalk's loosely typed language where everything is a first class
object,
and there are substantial differences in what a class is and the role
it plays
in Smalltalk versus Java). Nevertheless, Java as a VM-based object
oriented language has more
similarities than differences and porting the VM magic to Java was
quick and
straightforward. GemStone's version of
the Java VM then passes the same test suite the Sun stock VM does plus
the
added test suite incumbent of an object database.
GemStone's first Java offering came in their Beta release of
GemStone-Java (GS-J) in October of 1996, followed by a GA release in
early
1997. For those of us who were use to
writing perl and oraperl to run out of CGI in the Web Server, moving on
to
Smalltalk and Java for Web-based applications was a terrific leap
forward. To
get our persistence for free, it was terrific beyond words. The only
problem, recognized in hindsight,
was the denial of GS-J's true nature as an object database.
For reasons beyond my understanding the analysts whom
pontificate on such subjects declared object databases as dead (not a
substantial market opportunity, relational has won, etc.). As a result,
GemStone focused on its
powerful server-side VM and declared itself an Application Server and,
later, a
J2EE container. With the emergence of
J2EE, the likes of Netscape Application Server (later iPlanet), Web
Logic
(later Bea), and WebSphere were all competing with GemStone and a
handful of
other players for the space now owned by Bea, WebSphere and JBoss.
GemStone incorporated New Atlanta's Servlet
Container, partnered with numerous JMS vendors and built their own EJB
Container on top of the core Java object database. This part of the
story culminates in Bea, WebSphere and
eventually JBoss winning the Application Server war, but not before
GemStone
was purchased for $237MM by a Stuttgart-based platform vendor for
GemStone's
EJB Container, which, in truth, was very sweet.
Only of late have other Application Servers approached the
kinds of deployment, caching and execution capabilities that GS-J had
early
on. With the evaporation of platform
sales so did the German platform vendor retreat to Europe and allow
GemStone to
be purchased back by its original investor. And, significantly, Facets
was born: GS-J without the Servlet or EJB
containers--back to its object database roots.
Until the arrival of this portal, in spite of the underlying
core technology, GS-J and Facets had never been marketed as an object
database. The practitioners
participating in this endeavor intend to rectify this, believing that
the time
is right for the IT community to take another look at Facets as an
object
database. When trying to understand
what Facets has to offer, the place to begin is with the VM.
