To try and help people understand the business and technical ROI behind using an XML database, I present to you a “top ten” list of customers currently using Berkeley DB XML in their products, solutions, or as part of their day-to-day operations:
- AutoDesk MapServer Enterprise (article) as an open source geospatial data server
- IONA, a software vendor focusing on ESB products, uses it in its Orbix, Artix, and Orbacus product lines (press release)
- Juniper Networks uses it in their hardware products
- The USAF (my old alma mater) uses it in their Joint Battlespace Infosphere (presentation)
- The Online Computer Library Center uses it for their Global Digital Format Registry (design doc)
- Inspirational Technology used it to build the Syncato micro content management system
- Novosibirsk State University (in Russia) used it to create the Arabidopsis GeneNet Supplementary Database (AGNS) to provide an integrated view of genetic data for modeling morphogenesis (research paper)
- LeadScope won an award from Sleepycat for their use of it in their chemoinformatics platform for drug discovery (schema and summary file)
- Starwood Hotels uses it in their SOA (article)
- Now-defunct Comerxia (link now takes you to Borderlinx?) used it as a multi-language CMS solution for their International Shopping Mall (according to someone’s publicly-posted resume I’ll not link to)
Why did I choose Berkeley DB XML? Because it’s the engine we use in Figaro, the embedded XML database for the .NET Framework, and we maintain full compatibility with databases created with Oracle Berkeley DB XML on other platforms and programming languages.
So why should you care?
In the last ten years, we’ve taken our newly-minted XML standard and turned into a vast wealth of industry and communications standards, developer tools and products, and software architectures. One could reasonably argue that it’s been such a disruptive force over the past few years that the disruption itself could be a consideration for some of the JBOWS (just a bunch of web services) and other SOA anti-patterns employed by businesses.
Anne Thomas Maines’ “SOA Is Dead, Long Live Services” article hits it on the head – there are so many technology details to consider that it can cloud any organization’s SOA vision. The road from the “traditional” IT departments to more service and SOA-driven departments is a long, complex road that many get wrong or fall out of. I have seen this pattern repeat itself with BizTalk clients over and over again: here is a world-class integration platform that you can use as a stepping stone or gateway into services and service architecture, but because so few people understand what kind of asset they actually own, they really only end up using a couple of adapters to create a simple, end-to-end integration, and that’s it. BizTalk is a great SOA platform (we use it in our private cloud and “integration as a service” offerings at Endpoint Systems), and I at least take comfort in knowing Richard Seroter’s got my back on this one, but I do digress – let’s summarize by saying that, over the last ten years, we’ve seen more change than most organizations can keep up with, many have overbought software only to find an underwhelming ROI, and now IT budgets are tighter and people are taking a more conservative approach.
The conservative approach to an SOA end-game is to start with services; the simpler the better. The interest and demand for simplicity has helped propel RESTful services, REST being an acronym for Representational State Transfer. REST is particularly interesting because it’s more of a resource-oriented architecture, or ROA. You could make the case that current trends are going from SOAP and SOA to REST and ROA, and presto! We’ve given birth to the hot new slogan!
Going back to the original question, you should care because:
- XML is to data what HTML is to the user interface. In other words, just as HTML is the de-facto markup for the web’s UI layer, XML is the de-facto markup for data.
- The amount of XML published and consumed is only going to increase. This is especially true among RESTful services and their clients; even binary data can, is and will be published with a certain amount of XML metadata describing it.
- As the amount of XML increases, using XML databases for storing and managing content is going to make a lot more sense. Think of the “top ten” customers above as guiding examples to where XML databases may make sense in your own applications and/or data portfolio. What’s great about the list is that it shows Berkeley DB XML being used in a pretty diverse number of scenarios, from web content to embedded hardware product. As we all collectively trend toward service development, the ease in which these data sources can be utilized will be a huge plus for these businesses, guaranteed.
- A REST service driven by an XML Database is easy to use, cheaper to create, and provide consistently higher performance than its RDBMS-driven (or JSON) counterparts. A database running in the same process space as your web service will consistently perform much, much higher than having that same service as a front end to any RDBMS or JSON ‘document store’.
Developing products, solutions and services with XML databases are consistently easier, cheaper, and faster than RDBMS services. And that’s why you should care.