Spring
Spring is an open source application framework that is very popular these days, it is considered to be the leading application and integration platform for the Java platform. From that perspective, the choice of using the Spring MVC framework for the WebManager Edit environment might seem obvious. But when you take a deeper look into the Spring architecture you will find out that using the Spring MVC framework for WebManager is not as straight forward as it may seem…
The Spring application contextSpring includes a lightweight container for automatic wiring of application objects. In case of WebManager this auto-wiring is used to wire Spring controllers, command objects, views, resolvers and to map controllers onto URLs. The configuration of this wiring is defined by a single XML file for the entire web application; the Spring application context. And this is exactly where the problems start. The static definition of controllers, views and other Spring beans in the Spring application context does not really fit into a hot deployable component based architecture like WebManager.
WebManager uses an OSGi implementation, Felix, to hot deploy components onto the WebManager platform. But the Spring beans (views, controllers) that come with the component cannot be registered into the Spring application context at runtime. For that reason we needed to enhance the Spring framework to support component composition and controller delegation.
So why Spring?So why did we choose to use the Spring application framework then? There are numerous reasons for that. First of all, Spring is open source and is a low-level framework. This makes it very flexible and easy to adept to our needs, which is exactly what we did. Since Spring is the leading application and integration framework, Spring is continuously enhanced and improved. Lots of documentation and FAQs can be found on the web and developers will generally be more pleased developing in Spring, since Spring knowledge is more valuable in the IT industry compared to less mainstream alternatives.
The MVC architecture of Spring also seems to fit quite well in the frontend architecture of WebManager, which is also based around the MVC pattern. This enables us to replace the current MVC frontend framework by Spring in the future. Finally, what we didn’t know then but do know now is that Spring will offer an OSGi integration in its 3.0 version. This might provide a solution for our most important concern; the lack of component support.
Are there any alternatives to Spring?
Of course there are. Java component based Web frameworks like Tapestry, JSF and Wicket have been evaluated by GX. But although these frameworks did have a solution for the component support needed for WebManager, they all had their own disadvantages. None of these frameworks were as mainstream and flexible as Spring. Remember that Spring is not just a Web application framework, it is an application and integration framework.
ConclusionI believe the choice of Spring was the right choice. Especially with the 3.0 version in mind, Spring provides us a platform with the flexibility and stability we need, while still evolving rapidly. Although we currently only use the Spring MVC framework, I expect us to use more and more of the Spring framework in the future.
Ivo Ladage is product architect and is part of one of the SCRUM-teams. Ivo has special interests in Workflow and Authorization processes and Spring MVC.
Other blog entries: