Allow me to have one last rant about XML before I finally admit that I’ve discovered a marvelous use for it. A few years ago, you could sell almost anything by slapping a “fat-free” label on it. There was fat-free ice cream, fat-free brownies, even fat-free socks. The “fat-free” designation doesn’t sell goods like it used to, but you can still sell just about anything by calling it a “technology.”
Better still, combine technology with the word breakthrough, and your retirement is but an infomercial away. For example, nobody in his right mind would buy a chopstick and a rubber band for $19.95. But if you call it “Wonder-bun, a breakthrough in hair style technology,” I guarantee you’ll sell thousands.
I don’t know about you, but it annoys me when someone wraps hair around a stick, calls it a breakthrough technology and gets away with it. That’s why I cringe every time I see the phrase “XML technology.” XML isn’t a technology. XML is a text-based syntax to describe hierarchical data. In plain English, XML wraps text labels around data the way you’d wrap hair around a chopstick.
The only reason XML gets as much attention as it does is because software hucksters (most of whom hail from Redmond, Wash.) hyped it as a technology. But don’t take my word for it. Here’s a way to put it in perspective for yourself. XML started as a 26-page subset of the more complex, 500-plus-page specification called the Standard Generalized Markup Language (SGML).
By sheer weight alone, SGML should command at least 20 times the respect of XML. But when I tried a Google search for the exact phrase SGML technology, I found only 433 hits, and most of the articles were about XML, not SGML. When I searched for the exact phrase, XML technology, however, I got around 33,000 hits! (For a real kick, search for HTML technology, the results of which prove you can attach the word technology to virtually anything, including fat-free socks.)
Now that I’ve gotten that out of my system, let me share an idea I had based on some materials I was reading about a cool-sounding product called ILOG JRules 4.0 (www.ilog.com). JRules works around the tricky problem of having to propagate changes to your business rules when your applications and data are scattered across different servers and platforms. JRules seems like an excellent product, and it supports a variety of technologies and chopsticks such as Java, XML and XSLT. The literature implies that you can build and manage all of your business rules in one place and then deploy them to all of your servers and client programs, usually as Java-based objects.
Here’s what I’d prefer instead (my apologies to ILOG if JRules already works this way). I’d like to see a rules server that revolves entirely around XML or a variant of XML, such as the Business Process Modeling Language (BPML, see www.bpml.org) or Business Rules Markup Language (also known as BRML or CommonRules, see www.alphaworks.ibm.com/tech/commonrules). These proposed standards rely heavily on the extensible part of XML to make it more useful for rules-processing. For example, BPML adds programming elements such as “if, then” and case statements, which you’ll need for anything but the most trivial business rules.
I’d want to be able to define and manage business rules and processes through a friendly graphical interface like you can with JRules. But this hypothetical rules server wouldn’t deploy anything. All future server or client applications would simply query the rules server to see what business logic to apply to any given transaction. The rules server might send the appropriate BPML file as a response, perform the calculations and return results, provide the rules as Web services, or all of the above. Regardless, you get to truly manage your business processes in one place.
You can find the best description of what I have in mind in a presentation at http://oopsla.acm.org/oopsla2k/postconf/tavorath.pdf. Apparently KPMG International, a global consulting firm, implemented a system using precisely the kind of design I’ve described. I wish I’d thought of it in time to get a patent on the idea. I guess my only option now is to make an infomercial and sell this breakthrough in rules technology for $19.95.
Petreley, who writes for ComputerWorld (U.S.), is a computer consultant and author in Hayward, Calif. He can be reached at nicholas@petreley.com.