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.