Friday, 14 September 2007


2-5 years, j2ee will be a thing of the past.

i believe it has failed in achieving it's aims. i'm not sure what those aims were exactly, but i find j2ee hard to use. people have tried to make it easy to use by adding further frameworks on top, e.g. spring/struts. i always believed that servlets and jsps were enough, with a good bit of design to seperate display logic, business logic and database logic. that's the kind of design you should apply in any type of application (e.g. .net, php), not just j2ee.

let's face it, ejbs were always a bit rubbish. ejb3 has tried to become the silver bullet object-relational-mapping solution but i'm just not convinced there's very little modularity about ejbs. your application is tightly coupled to the interfaces they declare and there's no getting away from that. if the implementation of those interfaces are not available your application will not work. ok so an ejb may be used by several applications, but in reality... i've never seen that! further more it isn't as though you can have code dynamically contributing application functionality at runtime with a web app. and don't get me started on the hibernate nightmare!

so step aside j2ee and welcome osgi. i believe it's already starting to happen. some of the big app servers are already moving over to an osgi based architecture; ibm's websphere was already there, of course. my worry is that they'll do it wrong and it's such a simple thing to get right. rather than producing app-servers they should be producing high quality, enterprise capable osgi compliant frameworks. creating a web app as an osgi plugin is already easy since there should be an http-service running in your framework. you can just look it up, register your servlet and away you go. the ibms and weblogics of the world should focus on making it happen fast and reliably. i think you can forget sun on this one though. my impression is they see osgi as a threat and are deliberately trying to avoid it, though before long osgi or something like it will become part of the java specification.

and anyway, back to databases. since this is java we're talking about shouldn't we be doing things with objects and not having to worry about mapping them to a relational schema? which leads me to my next prediction...

5-10 years, rdbms will be a thing of the past.

rdmbs are great for procedural languages, but most modern languages deal with objects. pretty much every modern language deals with objects. what a waste of time mapping objects to a relational schema when you could just be storing your objects directly in to a oodbms. oracle 9i (i think, definately 10) has object support in it, but you still access the database in a relational way. i think the team over at db4o have the right idea and their solution works for all versions of java and .net. great stuff! and it runs in an osgi container. even better.


tom said...

chris, nice blog. i agree with your predictions that a new database technology based on oo ie db4o will be the next generation leader, but rather than predict j2ee and rdbms will be a thing of the past, maybe we should state for the record that the next big breakthrough will be a database superset. a container that will enable rdbms and allow us to have our cake and eat it too? what do you think the real issues are? i suggest: 1) effectiveness 2) efficiency 3) eloquence 4) emoney

(sorry about no. 4, but it had to start with an e!)

tom 2e

Chris Brind said...

hi tom and thanks.

right now, i don't see how the containers can make life any easier. they've tried and it just isn't working. if people are still having to use struts, spring and so on to create we applications and tools like hibernate to do object relational mapping, then we're not really making progress.

mostly, people already don't work in an rdbms kind of way any more, hence the need for tools like hibernate, which help us to work the way we like (object oriented) against legacy (rdbms) databases.

how the database implements an oo interface, well most people wouldn't care. if it was clever enough to map it to an rdbms then fine, but i feel that the physical make up of the average rdbms is not very well suited to the kinds of activities required for an oodb.

i would like to continue to see databases being seperate from application frameworks - when i worked in a financial instution i never saw a database for about 9 months, everything was done through messaging.

so i don't believe we'll have a container that will give us everything, nor do i think we should be aiming for it.

dutyofficer said...

Chris - (this is Derek BTW) It's all going to be a 'thing of the past' at some stage isn't it? It's just a matter of when. Or do you think that at some point software will stabilise and no new tools or languages will be invented?

OTOH I keep waiting for C to disappear but it seems that the majority of projects on Sourceforge as still written in plain old C.

But then you know I never did believe in 'objects' and 'methods' didn't you ;)

It's all just bits and bytes at the end of the day :)

Chris Brind said...

hi derek!

even bits and bytes will be a thing of the past one day! ;)