Objects In Use

Real-world applications of commercial ODBMSes show performance and development advantages

Russell Kay

Not too long ago, DBMSes were complex pieces of mainframe software that only people with long experience could begin to comprehend or use. When microcomputers came along in the late 1970s, the first databases oriented toward end users were developed and marketed. Using these products, a whole new class of user-programmers began to create their own database applications. This was such a radical development that it marked a turning point in database computing.

Now, another shift is at hand. A whole new class of ODBMSes (object-oriented database management systems) has since been added to the wide variety of powerful and relatively inexpensive flat-file DBMS and RDBMS (relational DBMS) products on the market. To find out how these new products are being used in the real world, BYTE talked to a number of end users and systems developers about their experiences with object databases. We asked why they had chosen to go the object-oriented route, how they had evaluated and chosen the particular ODBMS product(s) they use, and what's still on their wish list--that is, what they would like to do but cannot at present. We found that most users began using object databases because, quite simply, they had complex data objects that needed to be stored. Here's a look at a few of these situations.

Betting on an ODBMS Is No Gamble

The Austin, Texas-based company Continuum is a vertical marketer of software to the insurance industry. The company's products help insurance companies--which until very recently were strictly large mainframe shops--move much of their processing onto workstation-based systems. Of course, the existing data and legacy systems are still important considerations. Continuum has two major products: Conti nuum Workstation Platform/Enterprise Solution, or CWP/ES, which helps insurers manage distributed transaction systems; and Business Process Management/Enterprise Solution, or BPM/ES, which manages work flow and resource allocation.

According to Kenneth Schoff, a manager/consultant at Continuum, a typical insurance company can have as many as 15 different administrative systems, mostly mainframe-based, that might be up to 30 years old. But such a company wants to be able to present a single view of data to its internal users; for example, a user should be able to update an address change just one time and have it applied to all systems.

This type of system has to be transaction-oriented so that if a transaction fails for some reason, the data is current to the point before the failure. "We use Ontos ODBMS on OS/2 to maintain the persistence of all data that the user enters on-screen," says Schoff. Once the entry is completed on the PC, a local server submits the transaction to the mainframe, whic h handles validation, verifying that there is no conflict with another transaction. The local server resubmits the transaction later on if the system happens to be down.

This particular application didn't have to use an ODBMS, Schoff notes. "But everything else about the systems was object-oriented, so we tried to present an object view to the users. Then we translate that onto legacy systems," he adds.

Continuum's work-flow management system is a true object-oriented system, where the objects are distributed. BPM/ES works by defining available resources--equipment, people, and so on--as one type of object. The system also defines work to be performed in terms of work-flow objects, which Continuum calls "case objects." These can be nested with subcases to any depth, down to the level of individual tasks, which is where the work gets done. The system also uses a bidding/assignment algorithm to assign the work to the resources. It uses a best-skills match and also balances work flow--so it doesn't overload one person while others are idle, for example.

An object-oriented database works so well for Continuum because it provides all the data that the company needs in one call, according to Schoff, who adds that "with a relational DBMS, we might have to do a series of joins to get all the information we need."

For both Continuum products, the processing engine is written in Smalltalk (Parc Place on OS/2, Digitalk on Unix). A database interface-process module acts as a layer between Continuum's object model and the operating system. The company developed the products on a SparcStation and is currently porting both BPM/ES and CWP/ES to Hewlett-Packard's HP-UX. A client interface layer, also written in Smalltalk, allows a customer to mix and match workstations and data-bases; for example, an OS/2 engine can talk to an AIX database or vice versa.

Continuum selected the Ontos ODBMS as the basis for its systems in 1991. "We had a requirement from our customers, who were underwriting the de velopment," says Schoff, "that the systems had to run on OS/2. We knew ourselves that they also had to operate on Unix." Support for those two operating systems was the deciding factor in Continuum's picking Ontos. At that time, Schoff comments, "Ontos was the only vendor whose development schedule matched our needs." He adds that Continuum also evaluated GemStone, ObjectStore, and Versant before deciding on Ontos.

Objective: Exploring Relationships

Analyzing and integrating a wide variety of distributed data is the function of InfoPower, a product from Delfin Systems of Arlington, Virginia.

To get an idea of how InfoPower works, and why an object-oriented database is critical to its success, it's necessary to understand how the intelligence community works--how it gathers data and pulls information out of it. Traditionally, says Delfin marketing manager Kent Potter, "in the intelligence arena, you're confronted with [not only] huge quantities of complex data, full-text databases, and traditi onal structured databases, but also image databases and lots of other things--and you've got to bring all this together in a way that makes sense."

Most systems designed for intelligence analysts and for the command-and-control community began with existing databases; applications were built to access them. But pulling together very different kinds of data poses real problems. For instance, you may have one database of locations and another of relationships (e.g., subordinations, who reports to whom, who talks to whom, who controls what, and what facilities control what products). Yet another database may store other attribute information, such as what quantities of a product are produced, how many of what model tank the Italian government possesses (not just where they are located), and trends.

Particularly in the intelligence field, Potter comments, "you're never going to find all the information you need about an entity of interest in one database; [such a situation] doesn't exist, because so me data collectors must collect information in specialized ways, and their needs can only be met by building a database that supports them directly."

The information analyst must break down the walls between different databases. He or she may begin with little glowing dots on a map and then want to see the facilities that, say, produce nuclear weapons or drugs and then uncover any relationships between these facilities. This information could be buried in a database, or it may be located in a set of different data sources.

But what if you think of a new question or acquire some new data? Say you want to click on one of those on-screen map nodes and look at a picture of it. How about recovering the full text? What about a time line? What if you want to include a group of facilities on a chart and add the amount of a particular chemical or the quantity of a piece of equipment each one produced in a given time frame?

One of InfoPower's modules is designed specifically to allow you to look at relationships. It has an auto-investigate function that starts at one node and goes out and looks at all the available relationships, explains Dan Stickel, Delfin's director of decision systems in Santa Clara, California. "Say it started with me; it could find out where I work, my religious preferences, and where I've traveled in the last few weeks."

In its original government-sponsored work, Delfin used a relational database. Stickel comments that "we were trying to look at the relationships between real-world things; we're really strong on relationships. So, what we thought was that doing relationships in a relational database -- the name sounds like it should work."

Experience proved otherwise, however, because exploring relationships with an RDBMS involves doing a lot of joins, and performance drops off steeply. Stickel found that using an object database really sped things up: "We were able to keep reference pointers instead of doing joins over and over again. Using the object database was definitely two orders of magnitude faster," he notes.

Expanding on the differences between the two approaches, Stickel notes that the RDBMS the company first used--Sybase--is a fine product. "If all you want to do is pull back lists of things, with filters, it's fast; there's no question about it. And going to an object database wouldn't make things faster. A lot of the time, the whole object-design methodology is more elegant and more extensible, but a little slower," he says.

Picking the right ODBMS product from the few that were available two years ago was no simple task. Stickel says that the company went through an extensive evaluation of several products, including Versant and Itasca, "to the point where we were actually using them." ObjectStore gave good performance, and at that time its technical support and documentation were deemed to be far superior to those of similar products that offered the features the company needed. "When we started [evaluating ODBMS products]," Stickel contin ues, "they were all really flaky--although reading about them in the press wouldn't have told you that. But trying to use them for real, we ran into one bug after another. Thankfully, that's no longer the case."

Delfin's Potter thinks that the advent of object databases has made a significant change in what's feasible. With more and more power becoming available on the desktop, and with vast amounts of data--of all types, not just rows and columns--proliferating, users need to access it in a fused, integrated way. You don't want to force people to learn multiple interfaces. "Now it is possible to put an object-oriented database in there as the hub; map those other, different databases to it; and then link out to whatever tools you need for visualization/analysis," says Potter. "In our view, that is a new category of product made possible by object databases. It's a brand new kind of product."

Power Play

Florida Power and Light provides electricity to millions of people in the Sunshine State. Part of this job includes the maintenance of existing facilities and the design of new power-distribution channels. A spokesperson for the utility, who asked not to be identified, told BYTE that in the late 1980s it had developed a pilot version of a generic AMFM (automated mapping/facility management) application using a FORTRAN toolkit and mainframe-based technology.

Called the Facilities Graphics Management System, the application allows Florida Power and Light distribution engineers, designers, and service planners to bring up on a computer screen a picture of the geography of a given area, including streets, canals, other waterways, and buildings. It even locates poles, transformers, and switches. And it's not just pretty graphics; the system presents an intelligent map where supporting information is tied to parts of the picture. Place the cursor on a utility pole, for instance, and you can bring up information about the pole's size, class, and ownership.

Although this pilot application st arted out on mainframes, by the early 1990s the developers knew it was a natural for implementation via an object-oriented system. There was also a desire to move it to desktop platforms. The developers looked at Unix workstations and also considered several object-oriented databases, looking for one that was flexible and still had the "usual" DBMS functions one would expect in a mature relational database (e.g., backup and recovery). And since the application was object-oriented, there were naturally many advantages to using an object database. Also, they were concerned that using a relational database might tie their hands and have an impact on the design of the object model itself. Finally, performance and cost were important factors to consider.

The developers decided to create the new system using a Smalltalk-based, object-oriented toolkit called Objective Facilities Management, which was developed at the University of Florida. Unfortunately, the toolkit provided no means of making objects persist ent, so Florida Power and Light opted to use Servio's GemStone. The redone system, which was first implemented in Dade County, uses a master GemStone database on a central server, with local servers (which also run GemStone) at the various usage sites. Actual design work is done on IBM-compatible 486/33 PCs.

One interesting aspect of the system is that it typically encounters the "long transaction" problem. In other words, a single user can tie up a large area or block of data for a long period of time before it gets completed and returned to the server. However, there's not too much of a problem with different users trying to work on the same area at once.

Documenting the Advantages

PassagePro is a recently released document management and production system from Passage Systems. The object-oriented system runs on Silicon Graphics workstations and provides document check in/check out, configuration management, work-flow management, and workgroup notification, with automatic production of both on-line and hard-copy information.

According to Vance Nakamoto, president of the Mountain View, California-based firm, "the object-oriented paradigm fits our problem space very well." He adds that the company expects to ultimately be able to use relational databases as well, "but we figured the best way to start was with an object-oriented DBMS," he says. "We wanted to create an API from an object-oriented perspective rather than having relational technology affect our implementation." To do this, Passage Systems built its API with a database transaction layer beneath it. "Now we're doing a Sybase port," Nakamoto says, "and it will have a new binding layer to the relational database."

Passage Systems decided about two years ago to use Versant as its ODBMS. Reasons for the choice included the fact that Versant was more focused on client/server and multiserver solutions and that there was already a lot of configuration management built into the ODBMS product itself. Finally, Passage Systems was a ttracted to the proactive, customer-oriented attitude of the product's company and its nearby location. "Of the few object databases then available," says Nakamoto, "they seemed to have the best performance for the data management scenario we were facing."

He adds that using relatively new technology carries its own price and that the early versions of the ODBMS software were quite buggy. Things are much better now, he continues, adding that PassagePro stresses the Versant system more than most and that Versant has been quite responsive. At the time BYTE talked with Nakamoto, he was about to begin the process of porting the product to Versant 3.0 on a Sun workstation.

Nakamoto is not clear whether the capabilities and performance of object databases will scale up effectively for large installed databases that have gigabytes of data and thousands of objects. However, he might be encouraged by the positive experience at Florida Power and Light, whose database for Dade County alone is several gigab ytes in size.

No Objections Here

Although this article takes a look at only a small sampling of how object database systems are being used in the real world, it seems clear that for a number of applications the promise of improved performance and added functionality has indeed been realized.

Clearly, ODBMS technology is not appropriate for many situations. However, where data is generated by object-oriented applications that are written with object-oriented programming languages, using an ODBMS to store persistent data is a win-win situation for systems developers and end users alike.

---

Russell Kay is a technical editor at BYTE. He can be reached on the Internet or BIX at russellk@bix.com .