random technical thoughts from the Nominet technical team

A New Application Development Architecture

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 3.5 out of 5)
Loading ... Loading ...
Posted by patrick on Mar 20th, 2009

I attended the 2009 Hotsos Symposium, an excellent Oracle database performance tuning conference, in Dallas. The event was a great opportunity to hear world-renowned Oracle performance experts present.

One of the most interesting talks was “The Helsinki Declaration: A set of Principles for the IT Community regarding Application Development” by Toon Koppelaars.

Toon described the expansion of features in the Oracle database over the years. He went on to explain that since the advent of Java, more and more functionality has been implemented outside the database. However new frameworks, methods and languages are appearing frequently and often disappearing quickly, sometimes within a couple of years. Many developers are constantly chasing the latest technology because it’s cool and will allegedly solve all presently-experienced problems. This leads to code quickly becoming legacy, having to be re-written and/or no developers having the necessary skills to maintain it. For example how happy or able would your Java developers be to maintain a system built using Struts, a relatively young framework, but now commonly seen as legacy. Would they first spend ages rewriting it, these days called refactoring, to use Spring, the effort for which gives no value to the user.

Although these technologies are changing, what users want has not changed; they still largely want “window on data” applications.

While this is happening the database technology is remaining stable and under-utilised.

Toon recommends replacing this traditional architecture. He has successfully deployed systems using a new architecture, named The Helsinki Declaration (that’s where it was first proposed). This architecture has a thin user-interface layer, deployed in whatever technology/framework is flavour of the month, and business logic and data logic layers implemented in the comparatively very stable database. Only the thin user interface is then vulnerable to the latest fad.

This is described well on his blog. I recommend starting with his first observation and then proceeding to the second, third and fourth observations.

Talking with conference attendees afterwards I was surprised (or maybe I shouldn’t have been) by how many had experienced exactly the issues Toon described on systems development and maintenance projects.

4 Responses

  1. Chris Rimmer Says:

    I’m assuming that he was the one who confused refactoring with rewriting. That’s like confusing flossing your teeth with major dental surgery whereas sensible regular application of the first can help avoid the pain of the latter.

    Anyway, I seen this guy before and he I’ve seen some of his code and I wasn’t very impressed. I think he could best be described as a database fundamentalist. It is true that there are Java programmers out there who just think a database is a big black box. They are misguided, but going completely the other way is not the whole answer either.

    If you truly are just building a web front end to a bunch of database tables, then yes, his approach will work just fine. But speaking as someone who has developed whole applications within the database, once you get beyond a moderate level of complexity you need to use object oriented programming to keep it under control. That means using Java or Ruby or whatever.

    Software development is a complicated and tricky business with trade-offs to be made at every stage. I think we need a few less fundamentalists and a little more pragmatism.

  2. OraDude Says:

    Chris said: “…once you get beyond a moderate level of complexity you need to use object oriented programming to keep it under control”

    This is just an unproven claim. The Oracle database itself, for example, is a fairly complex application. Yet it is written in C (not C++), without any object-orientation.


    You say you welcome pragmatism; what is the thick database approach if not pragmatism?

  3. Chris Rimmer Says:

    Hi OraDude. Pragmatism is doing what works for you. If the thick database architecture works for you, go for it! Let the results speak for themselves. As I said, I’ve developed whole applications in PL/SQL. My experience is that as the complexity increases it becomes increasingly difficult to manage, which doesn’t seem to happen with OO. So I’m taking the other path.

  4. charlie Says:

    so, program in java then… and run that code _inside_ the oracle database.

    toon’s major idea is simply an axiom of computer science that software vendors would generally have you forget… that DATA CENTRIC APPLICATIONS EMPHASIZE THE DATA MODEL and additionally that ADDING WHOLE LAYERS OF TECHNOLOGY DOES NOT AN ELEGANT SYSTEM MAKE!

    quite simply, if you are not using an intelligent dbms then you are forced to add layers but if you are using an intelligent one then why would you make ones job more difficult?

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

Recent Posts

Highest Rated