• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Spring vs JEE

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Today when companies have to create a Java development environment, what is the best way to go?
Let�s say that a senior team would maintain this environment, and that this environment would spread everywhere in the company for creating every web applications (Intranet, Internet, ....). That�s why the choice of this environment is so important as it won�t change for the next 5 or 10 years.

Today I see 2 solutions:
1. The unspecified Java solution: Tomcat web server + Spring Framework (MVC, ...)
2. The specified professional JEE solution: A JEE app server (Glassfish, Jboss or Websphere,...) + an MVC framework (Spring, or Struts2, ...)
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is like saying:

"I want to buy a house. Which one should I buy?"

There is absolutely no possible way to answer this question with the information given.
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So the choice you see is basically between a servlet container and a JEE server? That's an odd choice, since JEE also includes a servlet container, so the second "solution" can do everything the first one can, and then some. Plus, Java web apps are standardized, so you can always migrate them to other servers later without relative ease.
 
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:
This is like saying:

"I want to buy a house. Which one should I buy?"

There is absolutely no possible way to answer this question with the information given.



So which information should be given?

I think Josh wants to understand the differences between a lightweight framework such as Spring or Strut versus a more heavyweight J2EE with EJB... That seems to be a very interesting topic nowadays, specially considering the supposed "lightweight" EJB 3 available in the J2EE 5 specification.
 
Josh Chant
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The question is not specific because the problem I have to solve is not specific. Let�s say I have to create an Java development environment in a huge company. I have to chose between Spring+Tomcat and a JEE 1.5 app server (glassfish or websphere...).
Developers in the company will use this "industrialized framework" for all the web applications.

> So what is the best solution?
> What are the major differences?
> If I go light weight with Spring, will I ever be able to use any JEE component properly in my web container (Web services, JPA, container managed transactions,...) For example, I know I won't be able to use Session EJBs, MDB EJBs.
> If I go with a JEE app server, I'll be able to use the full JEE stack properly. But will I be stuck with a particular vendor?

As this environment will be widely used in my company, these choices are crucial.
Today, I think it's a real problem and I didn't find any valuable arguments on the web. So please, tell me about your experiences.
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The beauty of both Java web apps and full JEE apps is that they use a standard API. So there is no vendor lock-in like you would have if you created a Cold Fusion or ASP application. Of course, using a different server means having to retrain the system administrators, but from a development point of view, any such move would only have a small impact, if any.

Furthermore, JEE includes Servlets/JSP, so whatever you can run as a web app in a pure servlet container today, you can run on a full JEE server tomorrow. That's why I said earlier that this is not an either-or choice - the code can be migrated easily.

As to whether a JEE server is necessary - I see many applications (small and large) get by without JEE. EJB is really the only part that can't be used on a servlet container, everything else (e.g. JMS or JavaMail) can be added if necessary. And since EJB use is falling out of favor (if it ever was in favor), the replacement technologies like JPA and Hibernate work fine in a servlet container as well. (Actually, EJB can be added as well, thanks to OpenEJB.)
 
Wagner Danda Da Silva Filho
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Josh, you may want to read this.
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Today I see 2 solutions:
1. The unspecified Java solution: Tomcat web server + Spring Framework (MVC, ...)
2. The specified professional JEE solution: A JEE app server (Glassfish, Jboss or Websphere,...) + an MVC framework (Spring, or Struts2, ...)



Spring is a Java EE component. Apache Tomcat is a Java EE component.
Glassfish, JBoss, Weblogic are Java EE application servers.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Josh Chant:
The question is not specific because the problem I have to solve is not specific. Let�s say I have to create an Java development environment in a huge company. I have to chose between Spring+Tomcat and a JEE 1.5 app server (glassfish or websphere...).
Developers in the company will use this "industrialized framework" for all the web applications.


If the question is so general, then you can't expect a very specific answer...

Neither one of the choices is clearly better in general than the other, so it's not really possible to give a definitive answer to your question.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jesper Young:

If the question is so general, then you can't expect a very specific answer...

Neither one of the choices is clearly better in general than the other, so it's not really possible to give a definitive answer to your question.



And after all this, didn't I already say that? Yep, first response to OP.
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:


Spring is a Java EE component.



This is misleading. Spring does not implement any part of the Java EE Specification. So you can't say it is a Java EE component.

Now Spring provides the ability to make enterprise applications, so it is Java Enterprise, but not Java EE.

Mark
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Java Enterprise, but not Java EE



EE is an acronym for Enterprise Edition. Spring implements many, if not all of the Java EE APIs.


A few examples of Spring's Java EE implementation

org.springframework.ejb.support.AbstractSessionBean

implements

javax.ejb.EnterpriseBean



org.springframework.jms.core.JmsOperations

implements

javax.jms.MessageProducer, javax.jms.MessageConsumer


The list continues ...
[ August 29, 2008: Message edited by: James Clark ]
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You all might find this article of interest.

http://www.theserverside.com/news/thread.tss?thread_id=50477
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gregg Bolinger:
You all might find this article of interest.

http://www.theserverside.com/news/thread.tss?thread_id=50477



And read the responses, you will see again that Spring might have helper classes if you are using EJB, but Spring is not an EE implementation of any kind. So if it isn't an implementation and isn't supposed to be one, how can it break it. It is like saying it breaks the rules of baseball. It isn't played with 4 bases, there isn't 9 innings, and no one is out.

Any information that might state otherwise could and should be considered either FUD, which in this case it isn't, or just not having all the information or knowledge of the product to make such a statement.

Don't think that I am too concerned or upset here, I'm not. Even if I only have worked for SpringSource for a little over a month. But it is more that there is so much misinformation out there, from people stating it like it is fact and just not knowing. It is like another misinformation that some people see with Seam. Some people think that JBoss Seam requires EJB3, which it does not. I have implemented a JBoss Seam application with just POJOs, not a single EJB3 in sight.

Mark
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:


EE is an acronym for Enterprise Edition. Spring implements many, if not all of the Java EE APIs.


A few examples of Spring's Java EE implementation

org.springframework.ejb.support.AbstractSessionBean

implements

javax.ejb.EnterpriseBean



org.springframework.jms.core.JmsOperations

implements

javax.jms.MessageProducer, javax.jms.MessageConsumer


The list continues ...

[ August 29, 2008: Message edited by: James Clark ]




So on this argument, then Spring also has a HibernateTransactionManager and a LocalSessionFactory class, does that mean that Spring now is a Hibernate and JPA implementation?

Mark
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some Hibernate classes implement Java EE API, so Hibernate can be considered a Java EE implementation.

If any Java-based framework implements Java EE API, why do you think it cannot be considered part of Java EE?
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:
Some Hibernate classes implement Java EE API, so Hibernate can be considered a Java EE implementation.

If any Java-based framework implements Java EE API, why do you think it cannot be considered part of Java EE?



And so I have classes that implement Serializable. Is my code now considered part of the JSE spec? No. Just because you implement an interface you do not automatically become a specification implementation. There is a whole lot more to it than that.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sounds like a case of micro analysis.

If you equate Serializable with the Java EE API, then my comment that Spring is a Java EE implementation might not make sense to you.

However, the Java EE API is not a singe Java interface.

If you want to beleive that Spring is not an implementation of Java EE , then that is fine.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you equate Serializable with the Java EE API

I don't, it is part of the JSE API.

However, the Java EE API is not a singe Java interface.

Nope, and neither is Spring. Nor does Spring inherit from the entirety of the JEE API.

If you want to beleive that Spring is not an implementation of Java EE , then that is fine.

And if you believe it is, then that is fine as well. We're just friends having a conversation.
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree.

There are different interpretations to what the word "implementation" means, and many other terms for that matter, e.g. component, API, etc.

Communication is a very important element of team-based software design. Establishing a "common" understanding of terms and language then become a critical task that must be effectively addressed. Differences in culture and spoken languages add more fuel to the fire.
 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi.

All I can add (and I admit I'm not sure of) is that I know many people who hate EJB. They've found in Spring an interesting alternative to EJB. But they sometimes use EJB just because they need it when clustering an application. Is it posible to work with Spring and clustering? I don't think so, but I know little about it.

Some people say an EJB container gives you some transaction related advantages. They must be talking about issues I ignore: as far as I know Spring lets you create transactional processes too. And it's even easier.

I think a good question is: "Is there anything you can obtain ONLY from EJB and not without it?"
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does Spring have an equivalent to a Message-driven EJB?

It is very easy to develop a Message-driven EJB. This is a great feature of the EJB system, in my opinion.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:
Does Spring have an equivalent to a Message-driven EJB?

It is very easy to develop a Message-driven EJB. This is a great feature of the EJB system, in my opinion.



Spring has Web Services which handles messages without having to use MDBs, and it just as simple if not simpler, in my opinion. As a matter of fact you can use your Pojo as an Endpoint for your incoming messages, and not have to extend any classes.

Mark
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Spring has Web Services which handles messages without having to use MDBs, and it just as simple if not simpler, in my opinion. As a matter of fact you can use your Pojo as an Endpoint for your incoming messages, and not have to extend any classes.



Sounds pretty fancy.

The key benefit of MDB is the asynchronous remote nature of the message queue. We can simply put messages on the queue and the container will make a call on a pool of MDBs. If we have 20,000 records to process, we can handle them concurrently via messaging and MDB pool

If we were to try handle this load with Spring's web services, how might we do it? Make each web service call via HTTP/SOAP/WSDL URL?
 
Author
Posts: 3473
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is hard to generalize. Design decisions must be made based on the number of factors. Every technolgy/framework has pro/con that needs to specifically addressed:

1. Based on specific requirements e.g. SLAs, volume, availability, mission criticality, future growth (scalability) etc.

2. Based on corporate standards, for example some companies do have Websphere as their standard Server platform, etc


3. Internal & External skill level.

4. Budget.

5. Maturity of the technology/framework.

& more .....


The challenge is to design the application in layers with good design principles (Spring does this very well) without over enginneering it to today's requirements, which can be scaled easiliy if need arise.

[ August 31, 2008: Message edited by: arulk pillai ]
[ August 31, 2008: Message edited by: arulk pillai ]
 
Antonio Fornie
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Spring not only gives an easy way toi implement Web Services, but also Asynchronous Messaging

http://www.onjava.com/pub/a/onjava/2006/02/22/asynchronous-messaging-with-spring-jms.html

But I don't know if it's easier than EJB JMS. I guess it is.
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:


Sounds pretty fancy.

The key benefit of MDB is the asynchronous remote nature of the message queue. We can simply put messages on the queue and the container will make a call on a pool of MDBs. If we have 20,000 records to process, we can handle them concurrently via messaging and MDB pool

If we were to try handle this load with Spring's web services, how might we do it? Make each web service call via HTTP/SOAP/WSDL URL?



Actually, I should have included the complete integration of Spring with JMS for messaging. Sorry about that.

Mark
 
arulk pillai
Author
Posts: 3473
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am currently using Spring Webservices extensively and quite impressed with it.
 
Ranch Hand
Posts: 218
VI Editor Ruby Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James Clark:


Sounds pretty fancy.

The key benefit of MDB is the asynchronous remote nature of the message queue. We can simply put messages on the queue and the container will make a call on a pool of MDBs. If we have 20,000 records to process, we can handle them concurrently via messaging and MDB pool

If we were to try handle this load with Spring's web services, how might we do it? Make each web service call via HTTP/SOAP/WSDL URL?



As Mark had mentioned, Spring has JMS integration which make it very easy to use and you get pretty much all the MDB benefit like remote async process, pool of handlers, etc... but in much easier way for developer to develop, because you just use POJO and POJI.

In fact, because of the simplicity of using Interface and POJO, we can expose the functionality to any remoting strategy available in Spring (such as RMI, Hession, Burlap, etc) just by manipulating the Spring configuration. No extra coding necessary. With exception for JAX-WS, due to the spec that mandates it otherwise.
[ September 01, 2008: Message edited by: Wirianto Djunaidi ]
 
arulk pillai
Author
Posts: 3473
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

As Mark had mentioned, Spring has JMS integration which make it very easy to use and you get pretty much all the MDB benefit like remote async process, pool of handlers, etc... but in much easier way for developer to develop, because you just use POJO and POJI.




Out of interest, does the Spring JMS listener support rebind service if the destinationwas down for what ever reason?
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by arulk pillai:



Out of interest, does the Spring JMS listener support rebind service if the destinationwas down for what ever reason?



Well it is about JMS at that point and not specific to Spring. Spring integrates with any JMS implementation. JMS I believe in the spec says that Destinations can be durable if you want. So you make JMS destinations durable, because Spring isn't implementing JMS here, just integrating with it to give you the same abilities in Spring.

I think there is a misconception that a lot of people have, thinking that Spring's integration with all these great technologies means that Spring is actually implementing a particular technologies specification, instead of their goal of integrating with and making it easier to use those technologies.

Mark
 
reply
    Bookmark Topic Watch Topic
  • New Topic