Standardization should not be understood as a repressive force that prevents creativity. Good standards do the exact opposite – they create a space for innovation. Only bad standards tie your hands. The same can be said of frameworks.
In DSI we use Spring not just as a framework, but as a standard. It forms the backbone of application development in the same way that Ant forms the backbone of our build infrastructure. To see what I mean, here’s an overview of how we use Spring in DSI:
- Applications are broken down into standard project types (service, web, ejb etc), each with their own predictable set of Spring files.
- Pre-Spring 2.0, all projects offer pre-filled Spring configuration files as part of their API. Post 2.0 projects will export their own schema files and leave it to the user to fill in the blanks.
- All project configuration is done through Spring files, which are transparently read using mechanisms specific to the project type.
Let’s look more closely at how Spring reinforces and supports each of these points:
- Applications are broken down into standard project types:
Experience has shown us that all the projects we build can be categorized into a surprisingly small number of standard project types. Whether we’re developing eBusiness platforms, enterprise back-office systems, or high-speed batch processes, our codebase can be predictably sliced into standard independant modules.Our standard project types only have meaning to developers if they are specifically pre-shaped for the job in hand. Web projects, for example, have by convention a directory called ‘web’ into which developers put html, jsp, css files etc. The build system, using common Ant scripts, knows where to find them (and what to do with them – see Larkin’s blog entry on convention over configuration for a discussion on this approach). By adding standard Spring files that are specific to the project type, we fill that shape out even more. The files are templates that effectively templatize the entire project, letting the developer know what lines to follow. In this way Spring supports the project type standards.
- All projects offer pre-filled Spring configuration files as part of their API.
The standard Spring files mentioned above have a drawback: they actually present an obstacle to code reuse! Before Spring came along, designing a good API that could be reused by multiple clients was a well-understood art (though perhaps not always well practiced). Now that you have extracted most of your glue code into xml files, just getting the jar file into their classpath and reading the javadocs isn’t going to be enough to allow others to reuse your project. Again, convention comes to the rescue. There are only a certain number of ways that we can combine our standard project types into an overall standard architecture (see the sidebar below). If every standard project type knows what Spring files it needs from projects in the layer below it, then the obstacle to reuse is overcome.
- All project configuration is done through Spring files:
Configuration files are not sexy. Of all the advantages that Spring brings, it’s hard to get excited about the fact that Spring gives you the opportunity to dispense with ad hoc configuration techniques. But it matters. It matters that project code won’t be littered with IO catch blocks, and mixtures of absolute and relative file names. It matters that everyone in your team will know how and where to add configuration.Moreover, if we always read our Spring files in a way that is transparent to the code, this facilitates the recombination of standard project types – i.e. our overall standard architecture.
Sidebar: Is there One True Architecture?
Why do we break our applications into standard project types? Most system architectures have a shared fundamental idea: the layering or stacking of behaviour – for example from presentation, through service to data. Each layer is built on the one below it (in a loosely coupled fashion), but independent of the layer above. Each layer does a very different job, relying on different libraries, and in fact constructed using different sub-architectures. In a sense it is only when you enter into a layer that there is a real choice about architecture – is the service layer going to be implemented using rules-based programming? Is there any call for an in-memory database? Will we use MVC, AJAX or both on the presentation layer. The overarching layered architecture that joins these together is practically a given. Loose coupling between those layers allows for future reuse and plugability. For these reasons it makes sense to design and develop some of these layers as separate projects, but do so in such a way as to make it easy to recombine them.
It appears to me that the stacked or layered architecture is part of the DNA of computing. The pattern crops up over and over at many different levels. The advent of n-Tier architectures marked the explicit application of this pattern to software architecture. Maybe this will change – maybe the DNA will mutate beyond recognition over the coming years under the evolutionary pressure of innovations like AOP. But for now, I think we can say that no project is truely green field and each new one assumes this defacto standard architecture.
Our ultimate goal in DSI is a kind of Java on Rails, where developers have the freedom to choose between proven layer-specific architectures, while working within one standard overall architecture. Spring helps on both of these levels. Its non-intrusive, whole-stack IoC container behaviour supports the overall standard architecture. And its layer-specific, time-saving wrappers around the technologies we like to use (Hibernate, remoting, AspectJ etc) underpins our standard project types by permiting us to prefill their configuration into standard files.
It is exactly this combination of unintrusive breadth, and technology-specific depth, that has made Spring the ideal basis for standardized software development in DSI.
– brendan lawlor –