I have worked with JAVA and enterprise JAVA since 1998 and it have really surprised me how difficult it is to construct and maintain an enterprise application. At first I build the frameworks myself but then the official JAVA enterprise frameworks came out (to “help” the programmers and architects). I struggled for many years to get, one version after another, to work. Just to get the pluming to work was a painful affair – but to get the application to perform was really a bitch. Just to many layers with too much so called “magic”.
But where is JAVA enterprise today – the year 2014? Are we closer to an easy and fast solution? Can we start up a new project and just begin working directly at the business logic and be creative and fulfill the business demands? Is the age over where we have to make a million small tech demoes just to be sure that we are going in the right direction?
The answer is as usual – it depends!!! If you want to be vendor dependent there are some tools out there that can get you get started very quickly. But what if I just want to build an application that is vendor independent, that is easy to build and deploy, that is easy to maintain, where I can concentrate on the business logic?
I am sorry to say but this is still NOT possible in JAVA today.
Many frameworks have been added over the years to the JAVA enterprise stack. Some of them actual help us but a lot of them just make life much more complicated. But are there any frameworks out there that can help us in the right direction? The answer is of cause yes – but they are NOT easy to start using and the learning curve is steep. To setup these frameworks correctly is hard! And is doesn’t make is easier that the Internet is a rough jungle with a lot of very bad advises, terrible examples and there are a long way between the good stuff.
The Internet age is the age of the sniplets! A wise Norwegian once said that a good example must be complicated – otherwise it is not useful. This was the father of object-oriented programming – Ole-Johan Dahl. There are a lot of snippets examples out there that give you the impression that building and maintain an enterprise application is easy.
It you start out with a wrong approach – you will start out with bad foundation and your platform will be rotten at its core. The first edition of your system may be “easy” implemented and you will get it into production – but the maintenance and releasing of future versions will be a hell and it will – for each iteration – be more and more impossible to introduce new features.
Knowing that the world of enterprise JAVA haven’t changes much in the last decade and that it properly not will be revolutionized in the next decade we have to adapt to the current frameworks and make the best of them.
Some of the core frameworks out there are actually quite good. The hard part is to use them in a good cooperative way – a way where you can use them from project to project without reinventing your enterprise foundation for each project.
The big task is to select the frameworks that you want to use as the foundation in your projects. There is not one framework that covers all the important areas today. Some of the frameworks try to do this but it is hard to cover all areas and be in front with the latest technologies.
To ease the selection of frameworks you must create a list of what is needed to handle an enterprise application. There is a wide list of areas that needs to be handles at an early state.
My list of core areas is:
- Terminology (service, repository, web service, etc.)
- Source repository / Libraries / Reusability
- IDE / SQL editor
- Build tool / Deployment / Versioning
- Database / Data model (versioning)
- Domain model / ORM / Validation
- Scheduling / Batch (Tasks / Thread execution)
- User management
- Web services
- Services / Repositories / Global transactions / Logging / Validation
- Maintenance (Initial cost vs. maintenance cost)
- Integration testing / Unit testing / CI
This is all for now. In my future blocks I will go into list of areas above and what my choices has been.