Wednesday, April 30, 2008

SpringSource App Server Released

Ben Alex of SpringSource announced this last night at the Sydney Java Users Group meeting.

As big as the Spring framework has been, I think this product is going to have a pretty profound impact on the Java world. I have always wondered why we couldn't use OSGi for server-side deployment when it seemed such a natural model for dealing with dynamic modules. Apparently, while the model has been working for client-side apps for years, there have been issues with connections and threads on the server side, and these issues have only just been solved by the SpringSource "platform", which enhances the basic OSGi container.

OSGi bundles have long been a good way to build applications with flexibly-definable dependencies. Multiple versions of the same library can be deployed into a container without conflicts, allowing other modules that depend on them to run without problems. One can also deploy urgent patches to production servers without having to bring them down. All this is huge, because it allows application modules to be developed in a loosely-coupled manner, by specifying dependency ranges and following standards for version numbering. This is a Service-Oriented approach to deployment.

Going one step further is the ability to build the App Server itself in the form of bundles rather than as a monolithic executable. (JBoss does this too, but not with OSGi). The SpringSource App Server (S2AP) is the first of this new breed of beast. By way of analogy, S2AP is as different from earlier generations of app servers as the T-1000 of Terminator 2 was different from the earlier T-800 (think liquid metal). It means app servers need be no larger than necessary for the task at hand.

Well, the S2AP product is still in beta, so a few more months are going to pass while the industry kicks its tyres. But ultimately, I think there will be a shift to this more modular, version-friendly style of application deployment.

Monday, April 07, 2008

Is the Domain an Aspect?

We know about aspects - those cross-cutting concerns that we can layer on top of an application, the functions like logging that need to be done in a number of different places.

A curious thought struck me for the first time since I was introduced to Grails. Here's a complete framework for any generic application. It has persistence, a web interface, a testing framework, etc., etc. All you need to do to build your own custom application is to add your domain classes and a set of constraints governing them, and the system essentially generates whatever is required for the application to run.

It's almost as if the developer applied a "domain aspect" to a completely generic application and turned it into a bespoke one.

It's a fascinating thought, and I need to explore this idea some more. By Jove, this could be as profound an idea as Inversion of Control! Before Martin Fowler can jump in to do his mischief, let me lay claim to a number of possible pattern names:

1. Inversion of Aspect
2. Domain as Aspect
3. Domain Injection

There, that should do it until I gain more insights on this.