When we went from procedural programming to object-oriented programming, by realizing that we could remove the “object pointer” as the first argument to a procedure, and instead went to a model where methods are invoked on objects with identity, it fundamentally transformed our ability to structure and reason about software. Now, with the introduction of the DCI paradigm, I think that a similar change is possible, by realizing that DCI contexts are to stateless services what objects were to procedures.
For our new StreamFlow project I wanted to try and get management functions in properly right from the start, which basically means exposing configuration, service management and administrator functions through JMX. I figured that if I did that on my part the customer would simply be able to get a decent JMX console and get their work done efficiently through that.
But then yesterday I did some research into the current state of JMX consoles, and in particular downloaded and tested all the OpenSource consoles in Java. The end result of that is a realization that they all basically suck. There’s no point in naming names, and no point in going into detail, because they all seem to have the same basic problem: the developers haven’t talked to a domain expert.
The second presentation from JavaZone 2009 that I want to comment on is “På tide å kaste ut relasjonsdataben?” (Is it time to throw out the relational database?) by Trond Arve Wasskog, which continues the current trend of looking at alternatives to relational databases for persistence.
For myself, I have for some time argued that most people seem to be using relational databases for four separate things: storing objects, querying them, reports, and backups. In my view it is only really good at the reporting part and literally suck at the rest. The object-relational impedance mismatch is a well-known issue, that DDD values are hard to implement using OR mappers also seems to be common knowledge, and that backups are not exactly efficient or easy to make is also an issue.
The JavaZone 2009 conference is over, and although I couldn’t make it this year due to our project, StreamFlow, going into production soon, the Qi was definitely flowing there. I’ve been watching the videos from the conference (available here, and many kudos for making them available so soon), and there’s a number of presentations which either explicitly or implicitly relates to Qi4j. It seems that so many of the issues that Qi4j has been designed to deal with are things that are becoming known and annoying to a majority of developers. So, I’ll try to outline below just how the topics covered at JavaZone relate to Qi4j, and how Qi4j can help you deal with those problems.