Ethical Software by Alex Bunardzic

For a number of years now, databases and objects have been coexisting in an uneasy balance of power, ocassionally bursting into religious wars (as some of the discussion threads on this site amply illustrate). At this point, it may be useful to take a step back and review the differences and similarities between the two technologies.

Which Came First?

I’ve been teaching a number of courses in object oriented (OO) development throughout the years, and what I always find interesting is how many of my students take those courses thinking that object technology is the latest invention in computing. I also always find it amusing to see the look on their faces when I tell them that OO is actually older than relational technology.

In a way, relational database technology was a reaction to the ‘bundling of concerns’ that the object oriented paradigm created. Database-oriented application development advocates the concept of separation of concerns. From a purely database vantage point, object oriented systems violate that concept by bundling and coupling data (state) and behavior.

Perceived Weaknesses

Both database-centric and object oriented systems have one major flaw — they lack the time dimension. In other words, any system designed and implemented using either database-centric, or object oriented approach, represents the system frozen at a particular point in time.

The problem is that there is no easy, natural way to express time dependencies of the modeled system using either of the competing technologies.

Now, this problem hasn’t been such a big deal until recently, and that’s why both technologies got entangled in the unpleasant tug of war between the religious factions. The reason we didn’t have this huge awareness of the lack of the time dimension lies in the fact that most commercial software applications so far have been rather simplistic. All the commercial applications available on the market today (at least the ones I’m aware of) are based on a stateless model, where events come and go while the application logic fights the impeding entropy by enforcing some simplistic binary logic on the events.

Some applications fend off the entropy by utilizing the capabilities of the database (i.e. normalization, database constraints, cascading updates and deletes, triggers and stored procedures, etc.) Other applications attempt to do the same by utilizing the capabilities of the object technology — encapsulation, inheritance, polymorphism, etc. Both those approaches rely on the underlying assumption that the applications are stateless, and that the only thing that is not ephemeral is the set of business rules. Those rules get either declared at the SQL level, or they get programmed at the algorhitmic level.

In my opinion, both approaches fall short when it comes to modeling real life systems, such as business operations.

Make or Making?

This problem gets to be acutely clear as soon as we try to model and program overtly time-dependent systems. Such as, say, a build process.

Traditionally, build processes have been modelled by using make or Ant languages. But, as anyone who had tried managing build processes using these languages knows, it’s basically an exercise in frustration and futility.

The reason we all experience so much grief when using make or Ant to define any build process lies in the fact that these languages lack time awareness. Every build process, regardless of what is being built within the confines of that process, is severely constrained by the time factor, and if the time constraints get violated, the process itself falls apart. But time constraints are incredibly difficult to express using the database, or an imperative language.

Instead of make (imperative), we should have a tool that’s focused on making (the time-driven process).

Why Should We Be Concerned?

By now the traditionalists may feel compelled to object that, since we’ve been chugging along nicely for a number of decades without the time awareness capability built into our programming languages, why should we all of a sudden get worried now? Who cares about the obscure time constraints anyway?

The problem is that today we’re slowly starting to reach a critical point, where businesses are beginning to talk to each other via their applications. And that collaboration is extremely time dependent.

And, we don’t have a proper set of tools to see us through this phase.

Long Transactions

While all the transactions traditionally conducted within the confines of the databases are instantaneous (i.e. atomic), the new world of collaborative software processing stretches by necessity this concept into a completely new category, known as long transactions.

For example, there are now very prominent business case scenarios in operation whereby one business may kick-start a business transaction, which then initiates a process that spills over to another business (say, a supplier), which furthermore spills over to another player (maybe a government regulatory office), and so on, eventually making a full round and ending up back where it began. Such a long transaction is anything but instantaneous. As a matter of fact, in may possibly take days, weeks, months (even years!) to complete.

So what we have here is the necessity to keep track of the time dimension, as we need to be able, at any point in time, to roll back as if nothing happened.

Imagine trying to roll back after a several months (even years!) of business processing.

This is where the concept of context must, out of necessity, come into play. Things are definitely not as simple in this scenario as they used to be in a cozy, monolithic environment nestled within the protected walls of a corporation.

Beyond Databases and Objects

Obviously, databases and objects (which are concepts based on the snapshot of the system under study), cannot really help us here. We need a better approach, the one that’s more robust and intuitive.

Of course, the best way to coach a correct answer out of community is to provide the wrong answer and thus irritate the brain power that’s sleeping out there. I’ll attempt to do just that in the subsequent posts; I’ll tackle these issues with my limited brain powers and in the process come up with the most outrageous, outlandish ’solutions’. This will rile to no end the ’software collective’, and that will (hopefully) force someone to come up with a correct (and brilliant) solution.

So stay tuned.