Building Applications with eXcelon
August 25, 1999
Nothing we've discussed so far requires programming beyond the level of XQL and update expressions. But eXcelon is, appropriately, full of hooks that can support applications layered on top of it. These applications fall into two categories: server extensions, and client applications that talk to the server and its extensions.
You can build customized clients two ways: as Web applications, and as COM-based Win32 applications. Of the two methods, the first is by far the most accessible. The reason is that eXcelon comes with a CGI adapter in the form of an ISAPI DLL, a Netscape NSAPI plug-in, or an Apache module—all for NT which is the only supported eXcelon platform. These adapters create URL-accessible Web APIs grouped into four request types:
- get, to retrieve a document from the repository
- query, to run an XQL query
- update, to run an XML update
- run, to run a server extension
The same query shown in Figure 3 can, alternatively, run straight from a browser as shown in Figure 5. Because that's so, eXcelon is also easily accessible to HTTP-aware scripting languages such as Perl or Python.
Figure 5: Browser view of a query.
Given the Web API, why would you want to write a COM-based client? These applications can wield a richer API. They can create and rearrange files and directories in the repository, and work with same management features—security, user roles, indexing, cache management—available in the eXcelon Explorer and its companion management tool, eXcelon Manager, an MMC (Microsoft Management Console) snap-in. An integrator can use the client API from Visual Basic to integrate an organization's content-management workflow with the eXcelon repository.
On the server side, eXcelon supports extensions written in COM or Java. These extensions can issue XQL queries, and use the W3C DOM API to navigate and modify resulting XML content. Server extensions are the eXcelon equivalent of SQL stored procedures. Operations that can't be expressed atomically as standard queries or updates can be made into extensions, which are then callable from clients (or from other server extensions). An example of an extension is the addbid item shown in Figure 1. It receives a bid, queries the auction data, and inserts the new bid if it's higher than the existing ones in its category.
Designing XML structures with eXcelon
eXcelon Studio, shown in the Figure 6, is a kind of entity-relationship modeller, which in this example presents a schematic view of the auction demo's XML content. The meaning of the diagram is that an item has a one-to-one relationship to a set of bids. The terminology won't make immediate sense to DTD-oriented XML designers, and in fact this diagram does not generate a DTD. Rather, it generates a Document Content Description (DCD) file. DCD was proposed to the W3C as a way to integrate the Resource Description Framework (RDF) with XML-Data.
Figure 6: eXcelon Studio's schematic view.
In addition to the DCD file, Studio can also generate code skeletons for Java and COM server extensions, and Web-based applications, that operate on instances of the schema. But all this is really just a trial balloon. eXcelon's DCD-based schema offer little of the expressiveness of a DTD, focusing almost exclusively on defining one-to-one and one-to-many relationships among elements. This makes sense, in ObjectStore terms, when you consider that a relationship among objects is a native, highly-optimized feature of the underlying engine. But Studio in its current form, untethered to current practices of XML document design and very limited in its expressiveness, seems unlikely to see much use.
XML and OODBMS: A marriage made in heaven?
I don't think anybody really knows whether, or to what extent, or exactly how a full-fledged data-management discipline should ultimately surround XML. But it's clear that there's going to be a ton of XML content, and that relational databases are not naturally attuned to the storage and management of that content.
Like a lot else about XML—querying, formatting, namespaces, schemas—the issue of native XML storage is very much in flux. That said, eXcelon appears to be a solid product that can be used today to help applications talk to XML data stores more quickly, more easily, and more safely.
Will XML data management emerge as a discipline in its own right? Will XML's high profile help bring OODBMS technology out of the niches it has so far inhabited, and into the mainstream? I'd like to see these things happen, and I applaud Object Design's first step in that direction.