With direct access to relational databases being marginalised we need to question the next evolution of ORMs. Now our architectures have to be more considerate of other ways accessing data as relational models hide behind services, sit on the cloud or are even replaced with non-relational storage.
I have been involved in, and a spectator to, the ORM wars for over ten years. I remember the birth of Hibernate, the Java predecessor to nHibernate, which was formed as Smalltalk programmers moved over to Java and looked with shock and horror at the hoops you had to jump through to get to the database. ORMs have been the subject of serious debate over the years and the technical implementation of the interstice between developers and DBAs. They have been pivotal in empowering the object movement on mainstream frameworks and crucial in encouraging object principles in software engineering. ORMs of ten years ago share the same DNA as modern ORMs – the ability to develop with purer objects, but over time the sales pitch has changed – or at least the audience is finally listening to the issues. Today ORMs are about enabling better software engineering practices including loose coupling, test driven development and, more recently, domain driven design. Ten years ago ORMs were positioned as technologies that, apart from enabling better object orientation, took the pain out of working with awful database APIs and allowed, at least in theory, the underlying database to be swapped out – a big deal when Microsoft SQL Server and MySQL were gaining traction and still considered a bit risky for the enterprise.
Let’s, for purposes of this post, assume that ORMs have solved the problem and that they are not nearly there as discussed in Ted Neward’s classic ‘The Vietnam of Computer Science’. Let’s ignore for a moment the issues with ORMs – the XML configuration, the funny query language, the problem of stored procedures and the finger pointing between backers of different implementations. If ORMs are unequivocally and unanimously the best and only way to interface our objects with the relational model, is that enough? Is the relational model the only place that we need to store our data?
For years, the relational model was the accepted way of storing data in an enterprise. Object databases stayed in their niche and xml-based databases couldn’t perform. The relational model, as implemented by a handful of vendors, has a stranglehold on data storage and, in virtually every object oriented solution, is the default persistence store. While not yet having much penetration, a new breed of data storage mechanisms are beginning to surface. The new data storage mechanisms are providing solutions to problems by making themselves available as services – abstracting the data storage behind a service with the promise that whatever is behind the service is secure, fast, reliable and scalable. If the relational model, accompanied by SQL, aimed to create an abstraction of the physical database implementation, the service oriented data stores aim to abstract the physical layer completely, most of the logical layer and pretty much all of the lower level protocols.
These new service oriented databases (SODs?) come in two forms. Those that are simply services on top a relational model and those that are services on top of columnar or other non-relational database systems. Services-on-relational technologies, such as ADO.NET Data Services, are riding on the wave of providing data in a RESTful manner. The benefit of providing RESTful data is the removal of database APIs that require client installations and specific ports open on the network. RESTful data is accessible anywhere on the Internet on any device – the providers of the data don’t really care. The proliferation of fat client applications using AIR, WPF, Silverlight or iPhone necessitates a RESTful (or similar) mechanism to get to data.
The increasing interest in cloud computing raises the question on the scalability of the relational model – the short answer being that it doesn’t scale and that a completely new database paradigm is required. The new cloud databases such as SQL Data Services, Google BigTable and Amazon SimpleDB are not relational at all and everything we know about talking to relational databases is pretty much useless. Not only is there a problem with the different paradigm, but there is also the problem of vendor lock-in on the cloud; the market is not yet mature and your cloud database provider of today may be the wrong choice for tomorrow – and you have no option but to rewrite. Another problem with the cloud is that there may still be a need for an on-premise relational database and objects which interface with a cloud database may also need to talk to a good old fashioned relational database too.
So, given the fact that our architectures will need to talk to service oriented databases, how does our currently technology stack measure up? Can I create an object that will run on, say, Silverlight and save itself easily to the service back-end? Can we create an object that can switch between SQL Data Services and BigTable as simply as nHibernate would switch between SQL Server and Oracle? This is not really possible with the current tools but it is coming. Microsoft’s ADO.NET Entity Framework is due to add support for SQL Data Services, which will be a big deal in establishing its credibility as a conceptual application model. Although I don’t know much about the product, IdeaBlade’s DevForce EF seems to be trying to create a mapper between objects and data services.
ORMs provide much that is useful and have had a good influence on software engineering but need to understand that there is more to map to than relational databases. If they are to maintain their market and mindshare they need to evolve into frameworks that can map to services and replace the ‘R’ in ORM with an ‘S’ for service. Maybe Ayende can find time this weekend to knock one up out but failing that, it is something that we need to start talking about.
Does anyone have an OSM (Object Service Mapper) for me to have a look at?
Simon Munro @simonmunro