Java and Caché—a wave worth catching

• By Jon Elsom
• September 24, 2001

InterSystems describes its Caché product as a "post-relational database." That's a term we're beginning to see more of in the tech press and some analyst reports, but a solid definition is hard to come by. According to InterSystems, it doesn't refer to a single technology, "... but rather a collection of technologies that provides solutions for the most pressing problems of network-centric computing. These problems are those associated primarily with ensuring superior performance in large-scale environments for complex requirements."

Fair enough, not to mention intriguing. When we heard that Jon Elsom, a freelance consultant working with Hang 10 Systems, an OO consultancy based in the UK, was using the product to provide a series of functionally rich Web-based applications for the buying and selling of real estate, we asked him to share his experience with Java Report readers. Hang 10 was charged with creating apps that would allow for the rapid growth of the business. To accomplish that task, they needed to incorporate technologies that were highly scalable, easily installed, and made low maintenance demands.

Jon says he's still not exactly sure what a post-relational database is, but in his search for a high-performance, highly scalable object database, he and the Hang 10 team decided that Caché was worth a look. "Of particular interest to us," he says, "was their provision of a Java exposure of the database. Given our objective to use Java, JSPs, and OOD, Caché became our leading contender."

—John K. Waters
Product Review Editor [email protected]

	Version Reviewed: Caché 4.0 Current Version: Caché 4.0
	CUP RATING SYSTEM: 5 Outstanding 4 Very Good 3 Acceptable 2 Has Potential 1 Poor

ALTHOUGH THE NAME Caché was new to us (as I suspect it is for many developers), we had some confidence the product would prove robust in use. We knew InterSystems had been selling the underlying database technology into the U.S. healthcare and financial markets for many years. In Caché 4.0, InterSystems has created a foundation of robust technology that includes both OO and relational features, giving developers a powerful product.

Caché is available for Windows 95/98/ME/2000/NT 4 (post-SP4), various types of Unix and Linux, and Alpha OpenVMS. The development environment at Hang 10 Systems is a mix of Windows 2000 and Linux; the deployment environment is Linux.

Installing Caché on Windows was extremely simple, facilitated by a standard wizard-based setup. Linux installation is script-based, so a better understanding of the OS is required for this installation than for the Windows install. That said, it is not unduly taxing. The documentation guides you through the process well.

For the rest of this review, I will concentrate on the Windows tools. These can connect to a Caché database running on another platform via a standard TCP/IP network, and the Java attachment to the database is the same in either case.

Once Caché is up and running, users are presented with a bewildering array of tools: an Object Architect for creating database classes; a Studio for writing Caché-executable code (using ObjectScript); a Terminal for obtaining command-line access to the database; an Explorer for inspecting data, classes, and routines in the database; a SQL Manager for permitting the data objects to be viewed as relational tables; and a Control Panel, System Viewer, and Configuration Manager for administering system management. Most developers will be interested mainly in the first four tools.

The first step in system development is to define a set of classes using the Object Architect (see Figure 1). Properties and their types can be defined, as can methods and queries. These will be executed within Caché, and therefore must be written in ObjectScript and SQL, respectively. However, the method call itself will be available in the exported Java. I would recommend sticking with data-only classes until you become more familiar with ObjectScript.

Classes can be grouped into packages as in Java. Making your Caché package names the same as your Java package names will simplify the business of exporting to Java. Note, however, that when stored as persistent sparse arrays (or globals) there is a limit of 31 characters, thereby making an otherwise excellent naming convention slightly inconsistent in its application in the database.

Once the classes are defined, they must be compiled, either one by one in the Object Architect or as a whole package from the command line. Although there is an Export button on the Object Architect, I do not recommend using it to generate the Java classes. Instead, I recommend using the "Export" button/right-click menu item in the Caché Explorer. The Object Architect is not without its idiosyncrasies, and exporting files to obscure locations in a networked environment (and not telling you where) is one of them.

InterSystems has suggested that the exported classes are JavaBeans. A look at the generated code shows that, both in the use of constructors and method naming, a strict interpretation of the standards has not been followed (see Listing 1 in our Code Section). Nevertheless, when the Caché jar file (containing the base Caché classes) is added to the Classpath, the generated code allows you to access the database directly and treat it as a persistent object store, which is what we want.

Some of the Caché data types are presented in Java as standard types (e.g., Caché's %Library.String becomes a java.lang.String), but some data types are less easily translated. For example, %Library.ArrayOfObjects becomes COM.intersys.objects.ArrayOfObjects. In fact, it isn't a million miles off from being a Hashtable, but if that's what you want, you will have to do the conversion yourself.

It is interesting to note that Caché can handle multidimensional arrays, and is extraordinarily flexible about what you use as array indices (any mix of integers, strings, or other objects can be used). This is something that would be quite tricky to mirror in Java. In a sense, working with Java limits how much of Caché's intrinsic richness can be used.

For our real-estate Web site project, we chose to wrap more bean-like code around the generated Java. This approach hides the Caché-specific stuff from the application-level classes, servlets, and JSPs. While it probably made my life a bit harder, it made the servlet/JSP developers' lives much easier.

We had hoped that we would be able to develop our applications without having to think too much about the underlying database technology. At first, this approach worked. In particular, there seemed to be no need to worry about up-front database design. Caché easily handles inheritance and one-to-many relationships via the Object Architect, and a rich class structure can be built up. (But be warned that it allows multiple inheritance, which causes problems for the Java generator.)

However, as we progressed, we found that we increasingly needed to understand what Caché was doing. This was particularly true with regard to Caché's own memory management. Also, if you are concerned about precisely how and where Caché stores its data, you will need to understand the limitations of the Object Architect in setting up storage structures; you'll need to get your hands dirty with the CDL files that define such things. Other tools, such as Caché Explorer, tend to give a better view of what's going on behind the scenes.

There are many instances where it is more efficient to put a method that manipulates data into the Caché class, so that the processing is done in the database rather than in a (possibly remote) JVM. This necessitates the learning of ObjectScript, which has a thoroughly procedural pedigree and a slightly arcane syntax. More extreme examples of ObjectScript can be virtually unintelligible, especially some of the auto-generated procedures (see Figure 2).

The situation has improved in Version 4.0 with the adoption of a more OO-friendly syntax. It is now possible to write legible ObjectScript (see Figure 3) in an object-oriented manner, but expect to make heavy use of the documentation. Although extensive, the documentation is occasionally a bit terse and is not very well indexed (particularly the online version), making it a struggle to find the pertinent information. There also appears to be very little third-party documentation on Caché, which would be a problem were it not for some excellent product support.

InterSystems offers both an online facility for problem/bug reporting, and telephone support. We have found both of these to be responsive. In addition, there are small teams of sales engineers dotted around the world—I can only speak for the UK, but we have found them very adept at understanding and resolving our problems, and (just as importantly) explaining to us the underlying issues. We have perhaps had to call on their services more than we would have liked, but I have never experienced a company so keen to understand and accommodate a developer's needs. It should be noted that Caché is relatively new to the world of Java, and clearly wants to improve both its Java abstraction and its standing in this market.

As for using the generated Java code, you can either use it as-is and build an application around it, or you can wrap the exported code that will allow you to use a set of classes as building blocks in a "pure" Java environment. The former is probably okay if you are working alone, while the latter would seem more sensible if you are supplying code for other developers to incorporate. Inter-Systems has made Javadoc available for all of the Caché Java classes, although again it is not always clear what the usage of some methods should be.

I said earlier that there is no need to use JDBC or SQL to access the database. By using Caché, you can expose the same database as an object store or as a set of relational tables.

It's probably clear to readers by now that I feel the Java side of things is a bit immature in Caché. In fairness to InterSystems, they have indicated their road map for this product at a recent developers' symposium. If they deliver what they are offering for Version 4.2 (due out late this year), then I think we are looking at a product that will mature rapidly.

In particular, InterSystems is doing away with the Object Architect and amalgamating its functionality into the Studio, which becomes a proper IDE. A first look at their next generation of exported Java shows a tidier structure. It is still not JavaBeans, but it is certainly something that most Java developers could work with. EJB support is also on offer.

Although I have only considered the Java abstraction in this article, many other technologies are being embraced within Caché, including C++, ActiveX, COM, and CORBA. We will have to see what actually turns up, but I like the direction Inter-Systems is heading.

InterSystems offers Caché as an object database that is an obvious partner for an OO-language like Java. For all the current clunkiness of the tools, InterSystems achieves this end. Essentially, everything Hang 10 has tried to do, it has been able to do, albeit sometimes using workarounds and often relying on InterSystems' support.

In addition, we've been able to use the same OO design on the database as we have in our Java code. Therefore, it is clear that Inter-Systems can justify its claim that Caché is "the data server of choice for many Java developers."