Software development engineers at Elf Aquitaine SA, France’s largest corporation and one of the top ten oil companies in the world, who have been working with Hewlett-Packard Co’s object-oriented OpenODB database management system say the product is not yet robust enough for prime time play. The engineers are trying to build a database application for Elf’s geologists that contains information on 300 oil wells. The information is currently contained in flat files, so it’s impossible for a geologist to find a particular piece of data without knowing first where it resides, says Elf design engineer Renaud Daian. The data access problem is by no means unique to Elf: it is intrinsic to the oil industry. Exploration data, the lifeblood of an oil company, reside on tapes; some oil companies have up to 3m of them.
Seismic work
Elf has a mere half million, but the problem is growing very rapidly because we have a new technique for data acquisition for three-dimensional seismic work that generates more and more data, says Alain Robert, chief of management information systems for Elf’s exploration and production division in Pau. Eliminating the time and effort required to locate valuable well data was the motivation for putting it into a database, says Elf, and, being one of Hewlett-Packard’s largest clients in Europe, Elf chose to use OpenODB for the application. The bottom line, say Robert and Daian, is that OpenODB is not a mature product. OpenODB is a young product which needs to evolve in order to reach a satisfying level of operation. It was commercialised too soon, says Daian. Robert continues We’ve had more than a little trouble with OpenODB. We’re counting on OpenODB and Hewlett-Packard to build a Software Integration Platform that is commercially viable and works well, but the experience we’ve had up to this point is quite negative. We’ve had lots of problems with performance and functionality that is missing. If Hewlett-Packard puts out a huge effort, things could change, but… In something resembling a position paper, Daian details the technical problems he has encountered, including a rudimentary development environment, concurrency and slow performance, and various difficulties with OSQL, OpenODB’s programming language. We have had very good communication with Hewlett-Packard and good support from them on all of these technical difficulties, says Jacky Bernier, manager of Elf’s OpenODB project. What remains are problems with bugs that haven’t yet been fixed. These are more like system problems, which are more difficult to explain and more difficult for Hewlett-Packard to diagnose. For example, he said, Elf developers have been getting an internal error message, at which point they cannot modify functions in the database itself. We couldn’t do anything. It’s there that things become really difficult to resolve with electronic messaging [to Hewlett-Packard], Bernier said. Doug Dedo, Hewlett-Packard’s OpenODB product manager, insists that several of Daian’s points are related to philosophical standpoints that are debated in the industry. When you make those choices, some people won’t be happy, but you have to come up with a package that works.
By Marsha Johnston
In particular, says Daian, the OpenODB environment lacks development tools to ease browsing and editing of objects in the database and export tools to dump OpenODB schema and data into a flat file format. Other problems are system-related, such as performance and concurrency, he says. Although he could provide no specific benchmark figures, Daian says OpenODB’s data selection on the application’s universe of information is surprisingly slow, noting that each of the 300 wells in the database has between 200 to 500 analysis samples. Still, he adds, For OpenODB, when it looks at the data for just one well, it’s already slow. Dedo says OpenODB, which sits atop Hewlett-Packard’s Allbase relational database, runs at between 400 and 500 transactions per second. Daian notes that his definition of performance includes the time it takes to pro
cess the data. Bernier adds that Elf cannot be sure right now if the performance problem comes exactly from OpenODB or from the amount of system memory available. Still some distance from completion, the Elf application, Dedo says, is still in the phase where you have to provide the framework, pilot and prototype it to check on the process, and then you improve the performance. He adds, We have seen performance improvements from the pilot to the final version of between 5,000 and 7,000 times. In its locking strategy, says Daian, OpenODB lacks the functionality present in Hewlett’s own Allbase. Noting that Allbase supports three locking strategies, he says OpenODB supports only one. As a result, you get permanent deadlock when more than one person develops functions in the database, so we can’t work in groups on the database, which we had counted on doing. Tu-ting Cheng, Hewlett-Packard’s lab manager for OpenODB, says the deadlock problem is related to tuning the application. If you remember, relational databases had a similar problem at first. You will never get rid of deadlock in a database environment. The goal is to reduce the number that happen and recognise when they happen. Dedo adds that Hewlett-Packard will be looking at whether Elf needs more than one locking mechanism. Daian laments having to call external C functions to develop, for example, arithmetic processing, and the lack of a tight integration between OpenODB and C’s object sibling C++, or Smalltalk. Dedo points out that being able to re-use C routines is a practical advantage: OSQL enables you to link into parts of applications written in other languages, such as C, rather than rewriting completely. The Elf engineer agrees in part. Theoretically, it’s easier [to use C routines]. But OSQL is an interpreted language, which facilitates prototyping, and at the moment you call a C routine, you can no longer work in the interpretive mode and must work in a compile mode. Thus you lose the transparency and ease of development, Daian says. Dedo says OpenODB has transparent mapping between Smalltalk and OpenODB objects and that programmers can link in C++ calls, although it’s not as tightly integrated as some people would like.
Integration with C++
He adds that Hewlett-Packard is working on a tighter integration with C++, since 95% of its customers are using C++ and only 5% Smalltalk. The change should be made sometime this year, he said. The argument on C++ is, again, a philosophical one, Dedo says. Some people say that C++ and Smalltalk should be more tightly integrated. But those from a database background who want to share data with multiple programming languages want them less tightly integrated with the database. The trend [toward tight integration with programming languages] is contrary to what’s been the rule in the database world. In fact, there’s a joke going around that says if the same philosophy had reigned in the relational database world, today you would’ve had an Oracle database that talked only to Fortran, he quips. Philosophical differences or not, Elf is still hoping for concrete improvements in OpenODB, as it attempts to bring the application to completion.
