Business
Program the database, not the code
There's no question that I'm a fan of the data-driven approach. The basic idea is to embed programmatic concepts into a database rather than into the source code.
COMMENTARY--More often than most IT managers care to admit, upgrading one part of a software and application infrastructure forces more changes down the line. To the extent that these changes require reparations by programmers, the costs can quickly escalate. Many IT shops will delay upgrades in dread of the domino effect and its resulting expense.
The basic idea is to embed programmatic concepts into a database rather than into the source code. Consequently, changing the software's behavior requires a change to the data rather than a change to the code. In describing their solution to me, CommerceOne officials did not realize that they were preaching to the choir. During my previous career as a software developer, I had started to architect my own data-driven approach to programming [see sidebar at left].
Echoing the sentiment of his customers, CommerceOne corporate marketing vice president Jeff Watts said, "We kept hearing that a key barrier to getting some functionaility was not the functionality itself, but the need to attach that functionality to what a customer already has. The way this gets solved is not with another application. Coding between internal and external business processes, for example, shouldn't be through a series of adapters."
Instead of taking an adapter-like approach to the integration problem (much the way IBM's CrossWorlds technology does), CommerceOne's data-driven model defines every interface, user, and system as a service. The identities and properties of each service are defined and listed in a registry that the applications reference in order to figure out what to do, how to do it, and whether the user or process has the necessary privileges to execute the requested transaction(s). Sound familiar? Think Windows registry, and you'll begin to understand CommerceOne's approach. Like the registry that comes with CommerceOne Conductor, much of Windows behavior is driven by data found in the Windows registry instead of by Windows code.
What exactly goes into Conductor's registry? According to CommerceOne director of Web services product management David Burdett, the registry contains definitions of users, their rights, their permissions, definitions of other entities such as companies, enterprises, rules, choreography (the order in which steps take place), data schemas, and transformation maps. Transformation maps are like data-driven adapters that map one protocol to another or one data model to another.
"The registry forms the standard blueprint from which a services-oriented architecture can work," explained Burdett. " Once you put all this into a common registry, everyone is on the same page. There's no opportunity for error because something is out of synch. If a user definition changes, or a protocol changes, you just change the entries in the registry. Software sitting on top of a registry with this information becomes much more powerful."
Is CommerceOne onto something? In my life as developer, the closest I came to integrating two systems is when I had to design a PC-based database application to send and receive batch feeds from an IBM mainframe. (That development project preceded the data-driven approaches I took with subsequent applications.) I pity the person who had to maintain that code, since the mapping of the mainframe database to the PC database was hardcoded into the source code. There's no question that I'm a fan of the data-driven approach.
There are cases where data-driven models may not be appropriate. To the extent that your entire application infrastructure relies on a database to work, there could be risks associated with the reliability of those databases and costs associated with overcoming those risks. Additionally, nothing runs as fast as natively compiled and linked code. Once you take the data-driven approach, the performance of your applications could be tied to the performance of the data repository.
As a side note, CommerceOne's Conductor is not a replacement for existing application servers like IBM's WebSphere, BEA's WebLogic, or Oracle's 9iAS. Conductor is meant to run in conjunction with them in hopes of making those Web services environements even more change-friendly.
In response, many vendors are attempting to simplify change management by working with a layer of widely accepted XML-based application programming interfaces (APIs) called Web services. The idea is to use this layer to abstract Web services nodes from each other to the point that making changes on one node should not affect the others and, therefore, the typical costs associated with making changes can be avoided.
While officials from CommerceOne agree that Web services is a huge step in the right direction, the e-commerce solutions provider insists it's not enough. Changes will still require the unnecessary expenditure of development resources.
To ease the pain of change, CommerceOne suggests an approach to long-term software infrastructure design that is more data-driven and less programmer-driven.
One routine for all forms Midway through my development career, I was getting tired of developing and maintaining hundreds of different form-specific routines. Many of these forms would have 25 or 30 fields with all sorts of validation-laden interdependencies. Whenever I changed one of the routines that got a lot of re-use, I would have to go back to every application using that routine, and recompile and relink the new code. What a pain. So, instead of developing separate routines for every form, I started from scratch and developed one routine for all forms. The routine's source code was a mere 20 or 30 lines. It was a simple loop that opened a database with records that described everything about every field on every form for one of the applications I had developed. When it came time to paint a form, I would pass the form name and activity (new entry, update, or query) as parameters to my short routine. The routine, in turn, would loop through each record bearing that form name and--based on the other data in those records--would paint the fields onto the display in a specific order using the labels, sizes, attributes, picture statements, and name of validation routine to call. Following this move to a data-driven model, adding, deleting, or changing the specifications for any field in any of the applications I developed entailed nothing more than a change to the database. No coding, no recompiling, and no linking were required. Changes could be made on site at the customer's premises with little or no testing. | ||||
Echoing the sentiment of his customers, CommerceOne corporate marketing vice president Jeff Watts said, "We kept hearing that a key barrier to getting some functionaility was not the functionality itself, but the need to attach that functionality to what a customer already has. The way this gets solved is not with another application. Coding between internal and external business processes, for example, shouldn't be through a series of adapters."
Instead of taking an adapter-like approach to the integration problem (much the way IBM's CrossWorlds technology does), CommerceOne's data-driven model defines every interface, user, and system as a service. The identities and properties of each service are defined and listed in a registry that the applications reference in order to figure out what to do, how to do it, and whether the user or process has the necessary privileges to execute the requested transaction(s). Sound familiar? Think Windows registry, and you'll begin to understand CommerceOne's approach. Like the registry that comes with CommerceOne Conductor, much of Windows behavior is driven by data found in the Windows registry instead of by Windows code.
What exactly goes into Conductor's registry? According to CommerceOne director of Web services product management David Burdett, the registry contains definitions of users, their rights, their permissions, definitions of other entities such as companies, enterprises, rules, choreography (the order in which steps take place), data schemas, and transformation maps. Transformation maps are like data-driven adapters that map one protocol to another or one data model to another.
"The registry forms the standard blueprint from which a services-oriented architecture can work," explained Burdett. " Once you put all this into a common registry, everyone is on the same page. There's no opportunity for error because something is out of synch. If a user definition changes, or a protocol changes, you just change the entries in the registry. Software sitting on top of a registry with this information becomes much more powerful."
Is CommerceOne onto something? In my life as developer, the closest I came to integrating two systems is when I had to design a PC-based database application to send and receive batch feeds from an IBM mainframe. (That development project preceded the data-driven approaches I took with subsequent applications.) I pity the person who had to maintain that code, since the mapping of the mainframe database to the PC database was hardcoded into the source code. There's no question that I'm a fan of the data-driven approach.
There are cases where data-driven models may not be appropriate. To the extent that your entire application infrastructure relies on a database to work, there could be risks associated with the reliability of those databases and costs associated with overcoming those risks. Additionally, nothing runs as fast as natively compiled and linked code. Once you take the data-driven approach, the performance of your applications could be tied to the performance of the data repository.
As a side note, CommerceOne's Conductor is not a replacement for existing application servers like IBM's WebSphere, BEA's WebLogic, or Oracle's 9iAS. Conductor is meant to run in conjunction with them in hopes of making those Web services environements even more change-friendly.