Project History

Back in 2005

...the idea came up to start a WMS project, based on Java technology instead of wiring old-fashioned process environments written in native C or plain 4GL or PL/SQL Oracle language. A good candidate to build enterprise applications was the Java Enterprise Edition (well known as J2EE).

So we started implementing some WMS functionality in J2EE version 1.4. As some of you remember, writing business logic with that technology was not such simple as promised to be. But worth while to give it a try. So the first prototype ended up in a small EJB2.1 application that was closely tied to run on JBoss v4. EJBs were used for the business logic, Hibernate3 for the persistency layer and JavaServer Faces in the presentation layer. Furthermore there were several MBeans, responsible for the TCP/IP communication part. To get rid of the cumbersome EJB2.1 stuff XDoclet was a friendly tool to generate additional artifacts and deployment descriptors.

Next step, go back!

The EJB application was hard to maintain as well to improve, hence we decided to go back again and build a prototype using Borlands Delphi for the frontend part and a backend part written in pg/SQL (PostgreSQL procedural language). This was a panic escape to flew out the hell of EJB development which didn't really satisfy us. Also some of the essential requirements were violated by this approach. Basically we wanted to use Java did't we?

Welcome to the Enterprise

In 2007 EJB3.0 technology seem to be mature enough to spend some time again and build a third prototype with. From lessons learned we decided to have a look at the Spring Framework as well. However at that time we had already implemented two backend applications that were competitive each other. The next question was about which frontend technology to use. Did something change in the meantime or is JSF the one and only hero in modern web frameworks that behave well with Java backends? After a short investigation we figured out that there is a pretty cool opensource framework that seems to be a perfect candidate to build rich and fast web applications in an efficient manner. So we decided to do some prototyping with the Adobe Flex Framework and the new JavaServer Faces component library called JBoss RichFaces.

Which one to take?

After closing both implementation branches we had two competitors in each layer and had to decide which one to take. At the presentation layer the choice was between Flex and JSF, in the business layer EJB3 and Spring fought each other. It was possible to let the JSF prototype work with the Spring backend and the Flex client with the EJB backend, or the other way around :-)

And the winner is...

Adobe's Flex Framework for the frontend and the Spring Framework for the backend. But what is the foundation for this decision? To take such a fundamental decision you must have deeper knowledge of all these frameworks and have to try them out instead of watching to some cool webinars or workshops about topics like "How to build the winestore in 15 minutes...". The decision of framework we took cannot be rolled out to other enterprise applications, it depends more or less on the requirements each software project/product has.

Lets's explain some of the major aspects...


Flex because we need to have an user interface that reacts in short time and can be developed very quickly. A project engineer who has to built new user interface views must be able to do this in an efficient way without the knowledge of too many technologies. Using JavaServer Faces requires a well understanding of the JSF lifecycle, all component libraries, JavaScript, CSS styling and probably AJAX frameworks. With Adobe Flex you have one technology ActionScript and one IDE (Adobe Flash Builder) to complete your work efficiently. Compare building a complex view with JSF and with Flex on the other side and you know what I mean. Not only the development time, also the response-time of the whole application is a mayor point that must be addressed before taking a decision. A rich client implemented in Flex technology does not need to send each user interaction back to the server, a (rich) thin client with JSF technology has to.


The Spring Framework is a programming framework that supports a developer who need to implement business functionality in a simple and elegant way. On the other side J(2)EE is a platform specification and targets the runtime environment to ensure that an application implemented in this technology can run on certified application servers. It is more or less the specification that gives you a frame were you implement your business logic that shall run on all JEE servers (with some modifications :). In that frame you are restricted and cannot use all parts of Java technology that you are familiar with. When you ever tried out both technologies you know about the differences. If not, try out to read/write a plain text file with JEE.

What's next ?

It's not planned in future to switch to another technology. There are several other hypes and frameworks around that are more or less popular, but not really comparable to that what we use today. Of course things like Grails promise to be efficient and JavaFX or HTML5 seem to be the new stars on the skyline but why to change when we already have something that is mature enough, still popular and quite easy to use? To be honest, the new JEE6 specification with EJB3.1 brings mayor improvements again, but nothing new for Spring developers. Many things that are well known from the Spring Framework have been adopted to be in the standard JEE6 specification, see CDI or Singletons.