What can SOA learn from RDBMS?

At first blush, there doesn't look to be a lot of synergy between Service Oriented Architecture and relational database management systems (RDBMS). The primary function of a database management system is, after all, to manage the storage, retrieval and integrity of the data it is called upon to manage. It's that last word, integrity, that provides insight into commonality.

In the late 1980s Sybase introduced the notion of triggers into their flagship RDBMS product. A trigger was a piece of code that was executed when "something interesting" happened to the data under management. Triggers provided a very flexible way of reacting to changes like, for example, deleting a row from the database. That deletion could then cause a series of other actions (usually embedded in stored procedures), for example cascading the delete of one row to others - and thus enforcing referential integrity. Quite an elegant solution at the database level.

Of course, being about the only capability available for guaranteeing that the events would be detected, triggers started to get abused, whole rafts of business logic were embedded in stored procedures, and the database became the logic engine and the storage engine. No real separation of concerns there.

Now let's forward to 2008 and look for parallels and opportunities. For transaction processing, we are beginning to see much lighter weight data management engines (look at Google's bigtable implementation or Amazon's simpledb). Business logic is being pushed into services - probably where it should be. That leaves us with a bit of a hole. The value that triggers provided is still needed, but now it should be at the same level of data abstraction as the data managed by the services. That level is typically at the business object level.

So taking the simple concept of a trigger, we can ask ourselves if there is value to the enterprise in knowing when "interesting" things happen to business objects. (Of course this is still too broad, but bear with me here). There are some business events that are quite interesting to know about. For example a big customer win (resulting in the creation of a new customer in business terms) is likely to be very interesting to the organization as a whole. Can be notified as a morale booster/internal PR operation, can add some heft to other sales activities,... The list is endless. It isn't sensible to notify this at the database level, that is too low level, to proprietary. It makes a whole lot more sense to publish the "event" on the corporate internal nervous system.

It is impossible for the customer management service to know who or what might be interested in the information. Just as in the database world, the table with the "add trigger" doesn't actually know which other tables might be affected. All the customer management service knows is "that something just happened and there may be others interested". It then becomes the job of the corporate nervous system to let this event be "broadcast". Anything interested can then pick it up and make its own decisions.

It is therefore the responsibility of the ESB to provide this kind of capability in the containers that surround and manage the business objects, just as it was the DBMS's responsibility a generation earlier. It is the enterprise business architecture's job to determine which of these events should be triggered, and how the interested parties might react.

No there isn't much new here, we have had pub/sub architectures before - usually to aid with application integration. What is new here is that we can use the standards based capabilities that our SOA frameworks give us, together with a firm understanding of the need to drive change, to guide us to delivering a more flexible, sustainable architecture.