Serverside dilemma still exists - JBoss/EJB vs. Spring
Each server-side architect face this delima, which application framework to choose, EJB3.x or Spring ?
although both frameworks rock at development and production time, it's very hard to choose the right one.
I had several talks with tikal's architects about it,and although I get the impressive pro/cons bullets the final selection relate to taste!
while reading "JBoss and SpringSource" article, a new factor add to the table, a war between commercial entities? time will tell...
- lior.kanfi's blog
- Login or register to post comments
Comments
a) Sounds like the people you spoke with don't test their applications.
b) Please explain where's the added value of JEE standards.
1-3 points:
a) JEE6 bring Dynamic context using conversation, while Spring Context is static after runtime initialization.
b) JEE6 is a standard, meaning multi-vendor (although we only have one implementation right now)
c) JEE6 is pool based objects vs. Spring is a singleton model (most of the time).
But for sure non of the above are killer.
1. Only a matter of time.
2. Not sure how good this feature is (like when you use clusters).
b) Multi vendors of what?
1. I get the same freedom (and even greater one) with Spring.
2. The poor Java EE spec will always try to catch up with evolving technologies.
(waiting for the standard is not something that history proved as worthy).
c) Objet pooling is done with Spring as well...
What about standard indexing? scheduling? reporting? AOP? (and many more...)
Sooner or later you find yourself shifting aside from the standard... So, what's the point?
And testing.. what about testing???
You are right about shifting aside from the standard, and we all know the path from non-standard to defacto-standard (eg. hibernate, struts), but I would like to see JEE existence for long term.
And about testing, +1 for Spring.
About testing...
Agree with you.
I would strongly recommend to read Gavin's post at http://relation.to/Bloggers/YouShouldUpgradeToJavaEE6.
The post address most of your points – and actually contradicts some of them. Please drill down to the correspondence between Gavin and Grzegorz Grzybek at the comments section. Its a (very) long discussion, but worth to read it.
Just to to mention some (but not all) points - "The poor Java EE spec will always try to catch up with evolving technologies." is NOT always right. For example the JPA 2.0 new "criteria" api is much cleaner and type safe than Hibernate criteria. Another example is the “portability point” - you are right ...as long as you stay with Spring. The “configuration” xml promoted by Spring (yes, I know that Spring 3.0 enables annotations - but then maybe its better to use a standard ones) are seen by some folks as code.
Please don't get me wrong - I have used Spring in more cases than full JEE stack. But the JEE6 looks to have both innovations (like the CDI) and closing many wholes in previous versions. In addition it standardizes good frameworks like Hibernate, and correct their problems (even Gavin admits this point on Hibernate itself). In addition, I must say that I feel more comfortable to put my configuration in XML, but maybe its just because I'm used to it...
I started writing Java more then 13 years ago and J2EE 12 years ago (they only had Servlets at the time). So basically, this is experience that speaks... Standard Spec. always loose.
JPA 2.0 - the credit for the improved API should be given to the members of Hibernate community. Hibernate forums are full with complaints, work-arounds, requests, and suggestions concerning stuff like Criteria and Queries. The only reason Hibernate doesn't have it implemented already is Gavin's fear of having to adjust Hibernate to the spec. again. He fears of walking the same Via Dolorosa he went through when JPA 1.0 was released.
CDI - It took Gavin 8 years to convince the world that the three standard web scopes aren't enough and that a stateful web application is a good concept. 8 years (!). At the same time other (strong and very successful) web application frameworks promote statelessness. What do you think?
Sorry...I disagree with some of your points (don't be mad on me - its just my humble opinion...).
First - on the technical level. I think that standard specs are good and in fact, and in many cases they win. For example - the JAX-RS (JSR-311) is a good spec. I would rather take RestEASY or Jeresy or Apache CXF than going with Spring MVC (See Spring 3.0 support for REST) to provide REST api for my application. Another example is JPA 2.0 (JSE 317) - its a good spec, which covers almost all Hibernate features and even adds more and correct bad ones. The same goes with Bean Validation (JSR 303) it looks better than Hibernate-Validator...etc.
You see, in the past, many of the specs were used to be created by some guys at Sun which their jobs was...writing specs. For this reason some of the specs like EJB 2.x were hard to use , learn and maintain. But that was 8 years ago. I think that the JEE6 and JEE5 specs were created by great developers, and are based on good open-source innovations. For example “EJB3.0” (and now EJB3.1) and “CDI” by Gavin King, “Bean Validation” by Emanuel Bernard, and “Dependency Injection for Java” by (Crazy) Bob Lee and...right - Rod Johnson from SpringSource.
Spring is neither against standards nor against JEE specs. Spring (Rod Johnson) was traditionally against EJB 2.x and some other bad historical specs. Again, this is history for years now. Spring provides an application framework while embracing both low level specs like JTA and JNDI and higher level like specs like JPA and Bean Validation (in addition to open source).
Regarding statelessness – I think it can scale better, But in many places scalability has price. For example – both NoSQL databaseses and horizontal sharding of your RDBMS will scale much better than put all the data in the same table. Nevertheless, you will probably do it as a constraint of heavy load on you database. The same goes with state management – most of application I work are far from being Google/Digg/Facebook scale grade. Sure, when you develop a public service you may aim there, and in fact I'm consulting a company which has “linear scalability” as a mantra (and I agree with it). However, if you develop a product which has only a few dozens of users you should have scalability for your application, it doesn't have to be linear. A few nodes in the cluster may do well, and you may gain better architecture constructs, scopes and context-life cycle for your components like “conversation” scope (now standard in CDI).
Regarding Hibernate and Gavin– Hibernate is on its way to be JPA 2.0 compliance (Hibernate 3.5 beta is out). As you know I like Hibernate, but that does' t mean throwing JPA. Even if the spec doesn't cover 100% of the open source that doesn't mean we should throw the whole thing. The standards today are more like pick and choose the best of breeds from open sources and developers ideas. I think that Gavin King and Hibernate is one of them.
2. Bean Validation isn't a spec innovation. We had this done years ago... Welcome to the club(!) I can't see why making it standard also makes it better.
3. CDI, Dependency Injection, etc. -- We already had all of this... Again - why should I bother about standards? Why should it matter to me? Can't you see?! The standard is always a step behind.
4. Regarding statelessness -- a) Your sys-admin has to configure routers not to block datagrams (hardly ever happens) in order to replicate data effectively. b) Have your conversation clustered, combined with 2nd level cache and see how quickly you get to the point where replicating data between containers becomes a pain. You'll prefer going to the database.
5. About Gavin and Hibernate. Tell me about one real project you've managed in which you could fulfill all need by using standard JPA only. Let me guess... there is no... You always used Hibernate specific features... Using standard APIs only just so you can one day switch the implementation is a fiction!
Still not convinced...
What do you mean by "internal spec"?
There is no formal REST specification. The protocol is implemented following Roy Fielding's work.
There's a REST wiki, but no formal spec.
BTW - The success of REST is another prove that CDI isn't necessarily right (REST is, of course, a stateless protocol).
No matter how precisely is REST defined, JSR-311 is an excellent spec. Regarding REST being stateless protocol - how do you make authentication without sessions and HTTPS (both are stateful)?
all answers are here http://rest.blueoxen.net/cgi-bin/wiki.pl
Come on, it's like saying: you are wrong, all answers are here: http://google.com :-)
There is a standard final spec JAX-RS. The fact there is NO REST spec is one thing (only Fielding architecture), but Java defined a spec for it. Spring promotes working REST api with their own proprietary annotations “Server-side support for building RESTful applications has been provided as an extension of the existing annotation driven MVC web framework. “ (Spring manual). The fact you can integrate RestEasy and Spring simply enables your Spring beans to be scanned and exposed with RestEasy through context listener. But that is NOT Spring implementation. Just like I don't need Spring to for my Hibernate/JPA application (I never use the notorious HibernateTemplate). The engine is RestEasy/Jersey/CXF not Spring and I don't see a reason to use Spring MVC api to provide REST (just like you don't need HibernateTEmplate to do Hibernate code).
Beanvalidation CDI and all others, like any spec , should be viewed in the glasses of portability. Since you don't read Gavin' blog (now you have to...) :
In which scenario are you really better off, from a portability perspective:
99% of your code, and 85% of your external metadata is compatible between server platforms - and the remaining 1% and 15% can be ported reasonably easily
40% of your code and 80% of your external metadata is tied to a non-standard, single-vendor container architecture
When I make this point, it usually results in an immediate subject change from application server portability is a myth to I don't care about container portability. Well, OK, that's a value judgement that you're entitled to. But your subject-change concedes the point that application server portability is real. And it's useful to many organizations.
That been said, standards sometimes innovates sometimes fixes open-source flaws... and sometimes (not always – see JPA2 and JAXRS and CDI) they are behind. But that's the point – I don't see anything wrong taking with extending the spec with proprietary code.
Don't get me wrong – I'm far from being “No Spring here” guy. On the contrary, they do a great job. Just want to have a variety of solutions ,and have standardization for interfaces (annotation, programming model etc) of the best open sources.
I'm just saying that standard specs are crap!
You didn't answer... How many times were you in the position of switching implementation and thanking god for having a standard to cover all the abstraction for you? Answer this and I'll tell you what I think about Gavin's bullshit (hint).
On the current customer I switched implementation of JAX-RS twice (RESTEasy and Jeresy). In previous customer we changed JMS (yes... its a spec too -JSR 914- part of JEE) provider. I know people and projects that moved to a another application server (not myself though) - It happens many times. I see your point, but I disagree with it. Both Tikal customers (some, not all of them), open-sources and even application framework do care a lot about specs. So, in my opinion its wrong , if we ignore it ourself. I know, I think different than you, but IMO specs are great! Java is a spec (both JDK and JRE), servlets are spec, jdbc is spec , JEE is a spec that saying what specs should be included with it etc.
In fact I think, one of the reason Java and JEE became popular is the specs. Please keep in mind you don't have to take them all. In fact JEE6 has the new notion of profiles - The "Web profile" doesn't provide the whole "elephant".
2. Tikal customers care about specs... so?! That makes the spec right? People go for standard because it makes failures easier to excuse.
3. JEE - Can you deploy the same application on JBoss, Weblogic, and WebSphere?
4. Say - Which came first: Hibernate/Toplink-JPA ; Spring/Guice-Standard Injections ; Spring/Apache validators/BeanValidation ; Seam/WebBeans ; and many more...
5. What about Servlets/JSP/JSF? Are these good specs as well?
Stop lying to yourself and admit it - without the non-standard frameworks: a) we wouldn't have today's beautiful specs, b) your enterprise java development would have been a complete nightmare...
You know what ambulance chasing is? When an ambulance rushes through the traffic, it leaves an open trail behind it... The slimes of humanity take advantage of the situation and follow the ambulance to get past traffic jams. But why am I telling you this? Because this is exactly the situation with today's JEE specs. The hard work is done by non-standard frameworks that adjust to community needs (with hard work and sweat). After these frameworks become mature, the best of them become spec (after a long time of being the de-facto).
1.No. Its not. I can detail why we did it, but it doesn't really matter for our discussion. What matters is that changing the implementation was without any work. I didn't have to touch my code (not my annotations) at all. The only 2 lines I changed was on the web.xml , since I used a different ContextListener. Now imagine the same scenario, using Spring MVC at the first place – changing it to another REST (either JAXRS or yet another propriety) would take a few hours or maybe a few days and its NOT a big project.
2.No. People go with standards for the reasons I mentioned before. Portability – Sure its NOT 100% like mentioned above, but even 80% is very good; Vast adoption of service providers and frameworks, and fixing open-sources which came before the spec.
3.Yes. Sure – many people do it in many projects. It takes time and effort. Its not very interesting job. But it saves a lot of time and money than writing the whole application from scratch.
4.No. IMO its the wrong question. It doesn't matter who came first. What matters, is which one would you take.
5.My knowledge on these UI specs is much less than yours. From what I read on the new versions of these specs (didn't try it yet) Servlet 3.0 and JSF 2.0 are better than precious ones – no more need for web.xml , better integration with open-source through web fragments, annotations support instead of xml, better integration with Ajax and more. Anyway, the question is what would you pick and choose. Yes, you can take a non-Java UI ( as I guess you would take), but that is different discussion. But, assume you are going with Java for your UI, would you go with NON Servlet based MVC framework ? What are the chances you the customer will accept this decision ?
And here is a fresh report on the traffic jam. There are a few ambulance chasing at the moment:
1.A slim driver called “Gavin King” with a “JPA” car is chasing after an ambulance with “Hibernate” sign on its front (the ambulance used to be driven by the same slim driver...)
2.Two slim drivers: “Rod Jhonson” in a “Spring” car, and “Bob Lee” in “Guice” car, are chasing after an ambulance with “Dependency-Injection” sign on its front (the ambulance used to be driven by the same slim drivers..z)
3.A slim driver call “Emanuel Bernard” is chasing with “Bean-Validator” car after an ambulance with “Hibernate-Validator” on its front (the ambulance used to be driven by the same slim driver...)
As said, great specs are made by great developers who developed great open-sources. These guys above spent years of their life to develop great popular open sources. And now they've spent time and sweat to standardize their innovations.
This width is embracing...I guess that within one or more posts we will have
One
word
liner
or
even
one
letter
l
i
n
e
r
Let's stop it here. It's better if I don't reply to this comment. Especially to JBoss-Weblogic-WebShpere part.
I don't know if you're joking or just saying things for the argument's sake... I hope this is the situation, otherwise... well, let's just leave it here...
A very valuable link on the topic, please read the comments: http://www.theserverside.com/news/thread.tss?thread_id=58985