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.
SCJP, SCWCD
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, ...)
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.
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.
Originally posted by James Clark:
Spring is a Java EE component.
Java Enterprise, but not Java EE
Originally posted by Gregg Bolinger:
You all might find this article of interest.
http://www.theserverside.com/news/thread.tss?thread_id=50477
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 ]
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?
I feel there must be far better ways to do what I do... that makes learning even funnier
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.
I feel there must be far better ways to do what I do... that makes learning even funnier
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?
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.
Originally posted by arulk pillai:
Out of interest, does the Spring JMS listener support rebind service if the destinationwas down for what ever reason?