The future of databases
Yesterday I flew to Chihuahua (Northern Mexico) to participate in a roundtable about databases with Oracle and Microsoft representatives. The plane was slightly late and despite the best efforts of the organizers who got us (the Oracle Architect and myself) in a police car that raced us to the Convention Center we arrived a couple of minutes late. Unfortunately, the organizers, in order to stick to the schedule, had decided to start without us and replace us with with salespersons from our respective companies that were at hand on the exhibit floor.
Too bad because I was really looking forward to dicuss the subject of the future of databases. With three sales representatives on stage (MS had sent a Marketing Manager to talk about the matter) the conversation rapidly moved to mundane subjects such as price, support plans and training.
The truth is that such a discussion is really needed. Databases have gone from being the stars of the client/server era to become a commodity (at least in the eyes of many of my customers) in the Internet age. This doesn’t make any sense.
When we talk about SOA, the databases are almost a second thought. That is because in most cases the database never connects directly to the ESB. Instead, the data is exposed through services, normally hosted on an application server. This may change as people start talking about Event Driven Architecture. EDA is complementary to SOA as both rely on the use of an ESB and therefore are not mutually exclusive.
In a SOA environment, the ultimate goal is to allow enterprises to implement BPM (Busines Process Management). In this scenario, the business processes run outside the applications in a process engine that coordinates the enterprise services. The users interact with the processes, and processes, in general do start only in response to a user request.
With EDA, the IT community recognizes the limitations of some of these premises. We must acknowledge that in some cases, processes will have to start automatically in response to external signals coming from different types of systems ranging from SCADA devices to databases. Databases should be able to communicate events to the ESB. These event are the normal evolution of triggers. Today advanced databases can easily send events from a Java based trigger using JMS. However, I think that we need to move to a higher level of integration, such as the MQ datablade for Informix databases which allows to post MQ messages through a standard SQL call.
When we talk about modern architectures, such as SOA or EDA, XML and security are very important topics. Should we privilege XML storage and retrieval speed (as favoured by Oracle in its current database release) or XML processing speed (which IBM has achieved in its DB2 v.9 release). In most cases the later is far more important, but most of the general public does not understand the implications this has on application performance. Database security is changing very quickly too. We used to think of this topic as a totally separated from application security. Today we are moving to a single point of authentication using LDAP and databases have to be part of this new infrastructure.
The conclusion is databases are evolving fast to adapt to a quickly changing environment. Most programmers and DBAs seem however to have failed to keep up wih the changes. That is too bad because databases are at the cornerstone of any advanced IT infrastructure.