Click on our Sponsors to help Support SunWorld

Informix leaps to objects

Informix Universal Server promises to
raise the database technology bar

By Bill Rosenblatt

SunWorld
June  1996
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!

Abstract
With its Universal Server, Informix is planning to shake up the object-oriented world. The company's takeover of Illustra Information Technologies has led to the meshing of relational and object databases. We examine the challenges of creating Universal Server. (1,700 words)


Mail this
article to
a friend

In the ongoing competition between the major database vendors, each has attempted to hold "objects" as a Sword of Damocles over the others' heads. How has this tactic worked? Not particularly well, so far. But Informix's recently-announced Universal Server, the intended byproduct of its acquisition of Illustra Information Technologies, could change all that. Universal Server is by far the most ambitious foray into the object-oriented world that any major database vendor has announced publicly and in detail so far.

Informix, at least in terms of name recognition, ranks third among the three major relational database vendors. The company has spent the past few years sitting on the sidelines as its two arch-rivals pummeled each other in the marketplace. Sybase and Oracle have spent inordinate amounts of effort on engineering bullet-list features that relatively few of their customers actually use, while Informix has concentrated on clean architecture, outstanding OLTP performance, and robust 4GL-based development tools. Its ad blitz seems to be limited to a billboard on northbound Highway 101 in Redwood Shores, CA, just past Oracle's ever-expanding corporate campus, that says, "You have just passed Oracle. So have we."


Advertisements

Promises, promises
All three database vendors have promised object-oriented technology in various forms over the past few years, responding to the rise of object-oriented programming as the paradigm of choice, the increasing amount of complex data types customers want to manage, and competition from object database vendors like Object Design, Inc. (ODI) and Versant. Yet none of the Big Three found it possible to incorporate object technology into their relational engines. Their forays into object-land have taken the form of enhanced 4GLs (like Informix's NewEra) and design tools (like Gain Momentum, a Sybase acquisition). Oracle promised objects in Oracle 8, its next major server release, but has yet to deliver the goods.

It's easy to understand vendors' difficulties. The main difference between a relational database and an object-oriented database is that while the former can only track simple data types, like numbers, Boolean values, and character strings, object databases can handle arbitrarily complex, user-defined data types. In order to turn a relational database into an object database, it's necessary to add "pointer to a row in another table" as an allowable type for relational tuple elements. Think about it: to achieve arbitrary degrees of data type complexity, objects can contain (or refer to) other objects. So if you allow that a relational tuple (row) corresponds to an object, then the tuple must be able to point to other tuples in other tables.

For example, an object type car might have an attribute engine. This is equivalent to saying that a relational table called car has a column called engine. But engine itself is a complex type, consisting of attributes such as intake valve, camshafts, etc. With an object model, engine can itself be a complex data type. To get a car's engine requires only a "pointer chase" (memory dereference) -- an extremely fast operation. In the relational model, however, engine would have to be a key to a row in another table that can only be accessed through a computationally expensive join operation. The upshot is that an operation that's trivial in the object world becomes expensive in the relational world. Modifying an existing relational engine to overcome this limitation has turned out to be virtually impossible.

Relational databases, however, have several advantages over object databases -- related to such vital matters as scalability, manageability, and robustness -- which is why ODI and Versant haven't put Oracle and Sybase out of business. A couple of other vendors have taken a third path by designing databases from scratch to be both object and relational. One of these vendors is UniSQL; the other is Illustra, which Informix just acquired.

Meshing Illustra's object model
Informix wants to integrate with Illustra's so-called Object-Relational technology in a novel way. Usually, when one technology company acquires another, it tries to retrofit the acquired technology into its existing product line by retrofit engineering - which we all now know doesn't work. Instead, Informix is attempting a sort of Hegelian synthesis: they will combine the most desirable features of each product, add some more features, and produce an entirely new product. Specifically, they plan to combine Informix's Distributed Scalable Architecture (DSA) components with an adaptation of Illustra's object model and add significantly to Illustra's already substantial development tool technology. The result, Informix Universal Server, is expected out sometime this year.

The DSA components that Informix will bring to Universal Server include the vendor's pioneering work on query decomposition for parallel computing architectures, database administration tools, and support for distributed infrastructure. These components will work with the core object-relational engine from Illustra instead of Informix's relational engine.

Beyond that, Universal Server's successful introduction hinges on extremely ambitious feats of engineering. One of the most intriguing sets of issues they must grapple with relates to development tools. In last month's column, we covered Illustra's DataBlades, which are object class libraries for handling such specialized data types as image, video, sound, and HTML pages for the World Wide Web. The idea behind DataBlades was to offer developers something beyond a bare language interface by partnering with experts in each specific type of data. But instead of building DataBlades on top of a popular, existing object language (such as C++), they based them on a proprietary object type definition language, one that presumably was designed to work optimally with their underlying database engine.

This is a problem. Regardless of how well Illustra's object model fits their database engine, Informix correctly understands that they must interoperate with the current and emerging standard object-oriented languages -- including C++, Java, and CORBA/IDL -- as well as Informix's latest 4GL-based development tool, NewEra. Working with Java applications is especially important given Illustra's well-positioned bid to become the database back end of choice for content-rich Web sites.

To accomplish this, Informix/Illustra's engineers must perform a particularly difficult conjuring trick. In the Universal Server architecture, the first layer above the database engine that application developers can access is, naturally, the API. Above that sits the Illustra DataBlade object class definitions. Applications can use DataBlades, whether pre-existing or custom built, through the API. The new feature is a layer called Language Adaptors, which purports to translate code written in other object-oriented languages to Illustra's native object model.

This is an easy promise to make, but it's one that will be almost as hard to keep as Apple's promise of handwriting recognition in the Newton. It's very much related to another unkept promise, that of a salubrious, egalitarian marketplace for object class libraries and, in general, of objects taking over the world.

The simple fact is that it's very hard to get nontrivial object models to interoperate. If you are a C++ programmer, for example, you may have spent time developing your own sophisticated class definitions and hierarchies for a complex application. You may have tried to incorporate commercial, off-the-shelf class libraries into yours and found the task to be intractable. It has been impossible to do this because of the lack of standards for C++ class libraries. Everyone has their own way of defining the Ultimate Base Class, whether it's called Object, Entity, Thing, or whatever. No two are alike.

Language barriers
Now consider the same problem across different languages instead of across different class hierarchies in the same language. The problem gets much worse because of differences between one language and another in the mechanics and semantics of basic types, ways of constructing new types from existing ones, and runtime behavior.

This problem of language interoperability is easy to solve for conventional, non-object-oriented languages. Indeed, the remote procedure call (RPC) standard is predicated on a standard way of constructing data types from atomic elements like integers, characters, and Booleans. What makes it infinitely harder for object-oriented languages is that those languages' type definitions include operations (a.k.a. methods or functions), which constitute a type's behavior.

The most successful attempt to get different object-oriented languages to interoperate so far has been within the Object Management Group's CORBA (Common Object Request Broker Architecture) specification. The CORBA architecture includes the type specification language IDL (Interface Definition Language) and prescribes a set of language bindings that allow data types specified in IDL to be implemented in another language. In other words: you use IDL to specify the behavior and attributes of a type, without saying anything about how the behavior will be implemented; you use another language (C++, say) to specify the same type and the implementation; and the C++ Language Binding maps your C++ code to IDL. C++ greatly influenced the design of IDL, so it's not surprising that a C++ binding to IDL was fairly easy to create. OMG's next binding attempt, to Smalltalk, turned out to be much harder.

Informix and Illustra are attempting a similar task with their Language Adaptors. But they have it even harder than the OMG. Whereas IDL was designed with the express purpose of being bound to other languages for type implementation, Illustra's type definition language was not. Luckily, Informix/Illustra realizes this. Instead of using Illustra's type definition language out of the box, they will adapt it for Universal Server so that it can be used with Language Adaptors in the cleanest way possible -- and hopefully current Illustra developers will be able to migrate automatically to the new language.

Still, the Language Adaptors layer will be difficult to deliver. Call me a skeptic, but I would be surprised if Informix delivers on this one by the end of calendar 1996. At the same time, such technology is necessary, given the likely metamorphosis of the object-oriented programming scene from one standard language (C++) and a few niche players (Smalltalk, Objective-C) to three standards (C++, Java, IDL) that cover relatively non-overlapping application domains. These languages will be part of toolkits used to build new applications that handle complex data and are enterprise-scalable (CORBA/IDL) and Internet/intranet-enabled (Java).

The database solution for these types of applications has been a choice between C++-based object databases, which handle complex types well and mesh nicely with C++ as an application language, and relational databases, which offer scalability but don't deal well with data complexity and fit poorly with object-oriented languages. Informix is poised to be the first to offer a way out of this dilemma. Universal Server, when released, will not represent a new paradigm for databases, but it should combine readiness for complex data with the major-league infrastructural wherewithal and Internet/intranet readiness today's organizations need. In other words, it should come closer than anything else available to living up to its lofty name. If Informix can defy history by incorporating major technology through acquisition, it will have a winner.


Click on our Sponsors to help Support SunWorld


Resources


What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free!
[Search]
Feedback
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-06-1996/swol-06-cs.html
Last modified: