Why I will continue to use Spring *and* Java EE in new Enterprise Java Projects in 2012/2013
After some years any framework will carry some dead freight due to downwards compatibility requirements. For those reasons this blog won’t be a technical essay about the what’s and why’s of Spring and Java EE. I think – in the first place – the whole issue comes down to the question where you want to place framework libraries that you use as development API to write your business applications: in the server library directories or with the WAR/EAR file in WEB-INF/lib.
 |
| Figure 2: Simplified development architecture of Spring and Java EE applications |
The biggest relevant difference in Spring and *pure* Java EE applications is that the development framework API in Spring applications is part of the Java application (WAR or EAR file) deployed to an arbitrary Java runtime. In contrast, pure Java EE applications only consist of business code and the application framework is part of the application server. Hence, the business applications directly work on application server APIs. Beside these pure scenarios a majority of todays Java enterprise applications use a mix of Java EE and Spring APIs. It’s possible to make a Java EE *or* Spring decision in almost any distinct subject matter (Web-Services, IoC-Container, GUI and so forth).
There are also pure runtime environments for Java EE and Spring applications: Java EE compliant servers (Redhat JBoss, IBM WebSphere, Oracle WebLogic) and VMWare’s vFabric tc Server. So on a green field one could choose pure Java EE application architecture vs. pure Spring application architecture. However, as explained, the most applications out there run a mix. I haven’t made an acedenic evaluation but I suspect that many applications run on a Java EE or Tomcat server environment with a Spring IoC container. Rather then using *only* Java EE or full blown Spring stack it’s just very common to use a well-balanced combination of mature Java EE and Spring API’s.
The strength of Java EE is the open standard established in a documented process by various parties. For this reason building applications for this platform is very popular, although many projects use only a little amount of Java EE API. Another important fact to notice is that every (wise) Java packaged software supplier supports the major Java EE platforms. As a result of all this many larger enterprises host Java EE servers in house anyway. Running Spring applications on Java EE servers is near-by then. This setup may provide benefits for enterprises with many dozens or even hundreds of Java applications in production.
1 – Migrating JEE servers is considerably easier because the applications use less server API *directly*.
2 – For the sake of little migration costs, most of the in-house clients will decide to migrate their business applications to current server versions.
3 – Less server generations in IT landscape, less local development environment generations due to little Java versions in production, simpler ALM solutions – all in all: manageable complexity and more homogeneous landscape.
4 – Fast response to new client requirements: if you need new (Spring) features you’ll only compile a new version of WAR/EAR files and deploy the stuff to an arbitrary Java runtime.
5 – The range of potential target runtime environments will be higher compared to Java EE full stack. Which means you may be “more” plattform independent.
6 – With Spring you can add smaller peaces of functionality to your applications or server environments (avoids: Snowball-effect).
7 – Compared to Java EE, the complete innovation cycle is faster (from the feature request to the usage in production).
8 – Spring enhancements are made according to actual real world client project requirements which ensures their practical applicability.
9 – Application development teams remain responsible for the application development stack and can decide flexibly which API fits the clients needs.
It’s difficult to achieve all these benefits in a pure Java EE development stack (some of them address conceptual problems in Java EE). One possible option may be to modularise JEE application server architecture. Modularization as a standard, like in Java SE. It may also be valid to think about the release processes (i.e. JCP).
As I said previously, I do believe it’s never been JEE *against* Spring in general ’cause these two options work in harmony together in so many instances. Today it’s still a valid option to use both, Spring and Java EE, like explained in my other blog entry. I believe the vital discussion in the past is more about the programming model for our business applications: CDI vs. Spring IoC and JSF vs. Spring MVC. The debate is also often an emotional one about “like EJB” or not (for historical reasons). Furthermore, it’s a lot about *real* independence of your business applications from the underlying platform (server, operating system, hardware). For example: we use EJB as integration technology but the business applications don’t know about it. The key to platform independence is not using either Java EE or Spring but: making sound decisions which APIs to use *directly* in your business applications programming model. And sometimes it may be better not to use some application-server-lib-directory derived ones.
Reference: Why I will continue to use Spring *and* Java EE in new Enterprise Java Projects in 2012/2013 from our JCG partner Niklas.
me too :)
In your code, do you extends classes from Spring, or annotated with Sprint Special annotations? I guess that’s the problem, it’s like cancer, later you will find it spread everywhere, and there is no way you can get out from Spring, or even worse, it’s hard to migrate to new version (some classes are gone in new version), and I remember year 2009, Spring tried to change their license, not sure when will they do that again.
There are tons of other projects that required or use annotations(XML/Json binding framworks,etc..), it doesn’t mean it makes an application less maintainable.