Mickaël’s Weblog

This post is the third of a serie of posts on persistance stack.

In the previous posts, I describe my humble opinion of the layering for a persistance stak for an entreprise application (for smaller application, there is no problem to mix or get ride of layers). Most of the folks talking about a persistance layer are often forgot to talk about the various services that are providing a strong added value to the applications build on top of it. So, this post is dedicated to some of these services. I’m not saying I will be exhaustive (because I simply do not know all of the potential servics that a persistance stack could provide) but I will try to go beyond what I usually see on this topic.

What is a persistance stack service?

I should;maybe say: why are they so often forgotten? I think this is because we start to deals with business requirements that are not so attractive to technical folks that prefer challenge on the core of the persistance stack. IMHO, a persistance service is an engine that can fulfill extra business requirement from a persistance perspective. That means it’s not mandatory at all from a persistance stack to provide such services as they can be provided through the applciations themselves. The huge benefit to integrate them in the persistance stack is to allow consistent and rapide application development without derundancy in code.

In this post i will details services as query language, scripting, database creation and upgrade, workflow engine, archiving, versioning and partitioning. Some of this service are low level services … I mean they require access to the lower layers of the stack (even if their configuration can be localised in the same area than configuration of higher level services).

Query language

Even if lot’s of persistance stack provide a query language, I do not concider it as a core service of the persistence stack as these persistance framework are usually presenting it as a tuning step or a way to workaround the regular usage of the framework for complexe request. Despite this, this is probably the persistance service having the strongest capabilities and is often a requirement for the other services as partitioning for example. The aim is provide a query pseudo SQL to the framework. I don’t think the key feature of this service is to provide an RDBMS independante query language…I’m sure most of you won’t agree. To me the key feature is to provide a way to provide to the application administrator a way to go beyond the application limitations…if it’s RDBMS independant: great, but we all know that even if SQL is a standard, all implementations are differents and I don’t talked about opitimization! This service is so powerful that it should be

Partitioning

This service is a low level service, that means it’s customization requires the user to use the Query Language as it expose more the database schema than business objectes. Partitioning is a way of doing segregation on (read or write) access to entities (I should say main record of entities). This is tipically a where statement.

Workflow Engine

The persistence layer will trigger this engine to handle integrity check and process steps.

Cette question refait encore surface (cf billet sur slashdot). Il est incroyable de voir tant de guerres de chapelles avec des arguments totalement loin de la vraie problématique. La question classique est “En quoi l’assembleur peut apporter quoi que ce soit alors que tout le monde utilise un langage de haut niveau style Java ou C#?”.

Primo, tout le monde n’utilise pas ce genre de langages et l’assembleur est parfois totalement indispensable dans certains domaines (drivers, pixel shader,…etc). Secundo, même en dehors de ces domaines, l’assembleur ou plus précisément des connaissances en assembleur sont très utiles. On peut sans problème coder sans avoir la moindre connaissance de l’assembleur…c’est vrai, mais il assez impressionnant de voir comment des Bac+5 se plantent sur des problèmes simples genre listes chainées. Ensuite, quand arrivent les problèmes de performances, consommation mémoire, un développeur qui ne sait absolument pas comment cela se passe en interne, sera complètement démuni. On pourrait re-phraser la question initiale en :”Quel est l’intéret de connaitre les pointeurs quand on programme en Java ou C#?”. La réponse est la même: on peut faire sans, mais on se casse les dents sur des bugs tout bêtes et on tombent sur des problèmes de consommation mémoire.

En conclusion, le langage assembleur n’est plus vraiment utilisé (saufs domaines spécifiques a ne pas négliger) mais sa connaissance (ou tout du moins la connaissance des méandres internes des langages de haut niveau) permettent d’éviter beaucoup de problèmes. Les développeurs ayant cette connaissance ont aussi en général un très bon niveau algorithmique et savent optimiser et coder correctement. Ce n’est donc pas indispensable mais reste la preuve d’un niveau élevé.

I’ve read a very interesting post on this topic. I must admit I’m 100% in agreement. By googlelizing a little bit on this topic, I found an old article that present a completely different positioning…of course it’s written by a guy from Sun.

The key point is really expressed by Micah saying : “If we have a single implementation for something that works across platforms do we even need to have a ’standard’? Especially if an implementation is open source then isn’t the code itself the best standard? It may be much more fruitful to focus on making the same code base perform the same way across multiple platforms than creating an open standard that defines how something should behave just in case it is implemented by different groups of people, in different programming languages, on different platforms”.

I think Open Standard and Open Source are sharing only one concept: to be open….and that’s all! For sure, Sun says that Open Standard if much more important mainly to allow CIO to decide which implementation they will choose… that’s true, but as most of the implementation are most of the time differing…even largely, this argument comes down pretty quickly.