Spring Framework

[Dave Brown]

Anyone know any resources that outline under what scenario using the Spring Framework becomes advantagous ?

[Roy Ben Ami]

Since this is a much debated topic (there are a lot of zealous spring advocates out there ) , you can hear many answers...

In my opinion, spring is a very nice framework, with a slight advantage over the more comlicated J2EE stuff.
In the new EJB 3.0, it is a much closer call...

I myself prefer to use the EJB, since it is the sun standard and because i like JBoss (i know i can use spring too but still...).

It's your call actually but here are several articles with some comparisons:
ejb 3 vs spring
pro spring presentation

Ofcourse there are more evil frameworks out there that don't use java likie LAMP and Ruby on Rails, but hey why look at them when we have java

[Dave Brown]

Thanks for the reply, i'll have a look at those links.

I think my problem is that I havent found any plain english explanations as to when an example J2EE project would benefit from using these frameworks. All the Spring resources I've looked at so far seem to jump into the technical aspects as opposed to the reason "why" in the first place. All the projects I've done so far I've accomplished just using plain ole servlets & jsp's and i've felt to integrate struts/jsf/spring/EJB would cause a lot of extra overhead.

My interest in the frameworks is coming from looking at well paid job adverts and noticing EJB/Spring etc..

Slowly I'm finding OR Mapping with hibernate more attractive, I like the idea of being able to let something else worry about the database connectivity, especially if I want to change DB vendor.

I guess everything will all make sense eventually..

[Roy Ben Ami]

No problem

Actually, if you can use only jsp and srvlets in your apps then there is no need to move to any of these frameworks.

I will try to make it a bit clearer:

Strut/JSF - These frameworks allow you to use a better way of developing web applications. They provide you with a better MVC model (model view controller) in creating the HTMl and JSP/Servlets pages.
If you are developing web applications then they are defintly worth looking at.

EGB/JBoss - The move to the entire EJB and EJB Container (Application Server versus Web Server) is a big change and make sure you really need it. If you don't need something to manage the transaction/secutity for you then you don't need th overhead of the entire App container or EJB at all.
However, in many cases, having the container take care of stuff for you, or wanting to have a remote application (like a client that connects to your server through RMI) then EJB is your choice.

Spring - This is an alternative to the EJB thing
It allows you to do almost the same things with less complication and with any container. some say it is better, others don't and it is your call. Like i said i don't use it often.

Hibernate - This is a good alternative to the thing called Entity Beans in EJB. Like you said it allows much easier persistence and quite nice to use. In EJB 3.0 they took almost all the ideas from here.

These are mostly my opinions, and i'm sure that there are better explantions out there (from more knowledgable users) but hope i helped you a bit.

[Dave Brown]

In addendum, I found a very usefull PDF here which compares the frameworks, so this will be usefull for anyone who has the same questions as me...

webframeworks comparison pdf

[Michael Duffy]

Originally posted by Roy Ben Ami:
No problem

Actually, if you can use only jsp and srvlets in your apps then there is no need to move to any of these frameworks.

I will try to make it a bit clearer:

Strut/JSF - These frameworks allow you to use a better way of developing web applications. They provide you with a better MVC model (model view controller) in creating the HTMl and JSP/Servlets pages.
If you are developing web applications then they are defintly worth looking at.

EGB/JBoss - The move to the entire EJB and EJB Container (Application Server versus Web Server) is a big change and make sure you really need it. If you don't need something to manage the transaction/secutity for you then you don't need th overhead of the entire App container or EJB at all.
However, in many cases, having the container take care of stuff for you, or wanting to have a remote application (like a client that connects to your server through RMI) then EJB is your choice.

Spring - This is an alternative to the EJB thing
It allows you to do almost the same things with less complication and with any container. some say it is better, others don't and it is your call. Like i said i don't use it often.

Hibernate - This is a good alternative to the thing called Entity Beans in EJB. Like you said it allows much easier persistence and quite nice to use. In EJB 3.0 they took almost all the ideas from here.

These are mostly my opinions, and i'm sure that there are better explantions out there (from more knowledgable users) but hope i helped you a bit.

Roy's comments are good, but not quite the whole story.

When he breaks Struts, Hibernate, and Spring out separately, it implies that they are just alternative ways of accomplishing the same thing. I think Spring is more inclusive than Struts, Hibernate, and EJB. It includes all these technologies. Spring is glue code that helps to tie them all together. Spring has a Web tier framework - you can use Spring MVC or Struts. Spring can help with transactions, security, and lifecycle management with POJOs, so you can use it or EJBs. Spring has persistence templates for JDBC, Hibernate, iBatis, JDO, etc., so you can do persistence in whatever way you like.

Spring helps you inject dependencies between objects, putting the relationships in extenal configuration rather than wiring them into code. You can configure, run, and (most importantly) test your components without having a container in the way.

Aspect oriented programming is another key Spring feature that you won't find in EJB. (That's how they manage transactions and security.)

So it's not necessarily either/or. You can use Spring along with all or none of those technologies, depending on your needs.

[Roger Chung-Wee]

This comparison is for the presentation layer. This still leaves unanswered questions like, "My app requires distribution, messaging and transactions, is Spring suitable?"

[Michael Duffy]

Originally posted by Roger Chung-Wee:
This comparison is for the presentation layer. This still leaves unanswered questions like, "My app requires distribution, messaging and transactions, is Spring suitable?"

Not sure what you mean by distribution, but when it comes time to deploy your app you can do it with any JEE container. If your Spring app does not contain any EJBs of your own making you can deploy it on a servlet/JSP engine.

Spring has remoting capability, if that's what you mean by "distribution".

JMS is the JEE messaging technology. You can use Spring to communicate with a queue. You must have a JMS server running, of course, like OpenJMS. I've deployed Spring under WebLogic and used it as a queue provider.

Spring uses JTA to handle transactions and two-phase commit.

[Roger Chung-Wee]

By distribution I mean that EJB instances get distributed across multiple JVMs by the EJB server. (This is why there is an EJB programming restriction that static variables must be final in order to avoid inconsistencies across the JVMs.) I am not knowledgable about Spring, but I don't think that Spring provides this sort of distributed processing.

If JMS is used, then an EJB server is valuable in that it is compelled to support the JMS 1.1 spec (for a server which is compliant with the EJB 2.1 spec) and is always a JMS provider. But with Spring, as you say, a separate JMS server is needed.

[Michael Duffy]

Originally posted by Roger Chung-Wee:
By distribution I mean that EJB instances get distributed across multiple JVMs by the EJB server. (This is why there is an EJB programming restriction that static variables must be final in order to avoid inconsistencies across the JVMs.) I am not knowledgable about Spring, but I don't think that Spring provides this sort of distributed processing.

If JMS is used, then an EJB server is valuable in that it is compelled to support the JMS 1.1 spec (for a server which is compliant with the EJB 2.1 spec) and is always a JMS provider. But with Spring, as you say, a separate JMS server is needed.

Thanks for the clarification, Roger. I hadn't thought of clustering.

I agree with your point about JMS. I've used WebLogic as my JMS queue host when implementing Spring. We deploy on WebLogic 8.1 - we just don't use EJBs in our app.

[Dave Brown]

Does this mean it would be difficult/impossible to scale an application utilising Spring across several servers if the need arose ?

[Michael Duffy]

Originally posted by Dave Brown:
Does this mean it would be difficult/impossible to scale an application utilising Spring across several servers if the need arose ?

No, I don't think so.

If you deploy to a JEE container, the app can still be clustered.

I think Spring's emphasis on interfaces is key here. POJOs are singletons within their own JVM by default. No static or private data members, so they can be shared by all clients. There's no worry about synchronizing state across a cluster.

[Dave Brown]

I see,

Thanks for the comments chaps. I found some good resources now on spring mvc along with struts & hibernate so I'll have a good look through em. After doing some 'paid' work of course....