DevX has posted the second part of Rod Coffin's series on comparing and contrasting EJB 3.0 and Spring. This installment looks into messaging, remoting, dependency management, and intermediation, and concludes by offering an overall analysis of the two technologies and several integration strategies for combining the best of both. While Mr. Coffin says that Spring and EJB3.0 address messaging in very similar ways (with similar capabilities as well), the EJB3 example of a message-driven bean is far shorter than the Spring configuration is, even though it leaves specific capabilities (like throttling, as Mr. Coffin notes) up to the container rather than the deployed configuration.

A more telling difference in messaging support between Spring and EJB is the type of objects that can be configured to listen for incoming messages. In EJB message listeners must be EJB components whereas in Spring any POJO can potentially be activated in response to incoming messages. Both require that the message listener implement an interface and both support the javax.jms.MessageListener interface for JMS message listeners. However, since the 2.1 version of the EJB specification EJB MDBs can support other messaging interfaces such as javax.resource.cci.MessageListener which allow MDBs to be activated by a JCA CCI connector.

The remoting comparison also has Spring and EJB3 as being very close in terms of capabilities, with Spring having a slight advantage in being able to remote POJOs while EJB3 remotes only EJBs, and with Spring having an advantage in the number of protocols supported. Dependency injection is compared next. Primarily, Spring has a slight advantage as it is easier to test (based on the kinds of injection available) and supports constructor-based injection. Also, in JavaEE, only certain kinds of objects (specifically, container-managed objects) are subject to injection. Intermediation - as in method lifecycle - is covered as well. Spring, through aspects, has a huge advantage here, because while EJB3 provides lifecycle calls, Spring offers a complex and very capable pointcut capability. The last part of the article covers integration of Spring and EJB3. The last part of the conclusion sums up well:

Dependency management and intermediation are strong aspects of the Spring framework. In fact, Spring's flexibility and extensibility are due largely to Spring's strength in these two areas. EJB 3.0's support for dependency management and intermediation pale in comparison to Spring's. The value of Spring's support for dependency management and intermediation cannot be understated, particularly in the areas of testability and runtime configurability. Additionally, it should be noted that Spring can more easily be configured to run in a wider array of environments. For example, EJB 3.0 requires Java 5 while Spring does not. As many large corporations have not yet made the move to Java 5 this is an important distinction. EJB 3.0 requires an EJB container (although this container may be embedded), while Spring can run in a JSE environment. EJB 3.0 also has additional packaging and deployment requirements that Spring does not. There is no doubt that Spring is more configurable and flexible than EJB 3.0, but it does require experience and expertise to be used effectively. Of course, enterprise development always requires skill as these types of applications are among the more complex, and valuable, ones being produced today.

A more telling difference in messaging support between Spring and EJB is the type of objects that can be configured to listen for incoming messages. In EJB message listeners must be EJB components...

Not true; MDBs in EJB3 are POJOs just like session beans are; they no longer need to implement javax.ejb.MessageDrivenBean. They do need to implement some type of "business interface" depending on the kind of messages being delivered to them.

...with Spring having a slight advantage in being able to remote POJOs while EJB3 remotes only EJBs...

Also not true; EJBs are POJOs in EJB3, so clearly EJB3 remotes POJOs as well. (Definition of POJO here is: A Java object that does not need to implement any interfaces specific to the framework you're running in.)

EJB 3.0 requires an EJB container (although this container may be embedded), while Spring can run in a JSE environment.

EJB3 requires an EJB container, Spring requires a Spring container. Spring components do not run standalone in a JSE environment -- they require the Spring container. You can test your Spring components outside the Spring container, and you can test your EJB3 components outside the EJB container. Based on these and other inaccuracies, I think the authors of the comparison need to dig more deeply into EJB3.

A more telling difference in messaging support between Spring and EJB is the type of objects that can be configured to listen for incoming messages. In EJB message listeners must be EJB components...

Not true; MDBs in EJB3 are POJOs just like session beans are; they no longer need to implement javax.ejb.MessageDrivenBean. They do need to implement some type of "business interface" depending on the kind of messages being delivered to them.

...with Spring having a slight advantage in being able to remote POJOs while EJB3 remotes only EJBs...

Also not true; EJBs are POJOs in EJB3, so clearly EJB3 remotes POJOs as well. (Definition of POJO here is: A Java object that does not need to implement any interfaces specific to the framework you're running in.)

EJB 3.0 requires an EJB container (although this container may be embedded), while Spring can run in a JSE environment.

EJB3 requires an EJB container, Spring requires a Spring container. Spring components do not run standalone in a JSE environment -- they require the Spring container. You can test your Spring components outside the Spring container, and you can test your EJB3 components outside the EJB container.

Based on these and other inaccuracies, I think the authors of the comparison need to dig more deeply into EJB3.

I think the author was referring to something along those lines: http://www.jroller.com/page/kdonald/20050328#the_spring_framework_sustainability

EJB3 requires an EJB container, Spring requires a Spring container. Spring components do not run standalone in a JSE environment -- they require the Spring container.

I wanted to add the problem I see is that the spec doesn't make it mandatory for an EJB container to be embeddable. At the moment, I think only JBOSS supports it.

I think the author was referring to something along those lines:
http://www.jroller.com/page/kdonald/20050328#the_spring_framework_sustainability

Hm, I see inaccuracies in that article as well. One of the first things he says is that EJB3 injection is just a way to make JNDI lookups easier, which is not true at all. EJB3/JavaEE5 injection completely removes the need to have to mess with JNDI namespaces. The injection paradigm in EJB3 (and the rest of JavaEE 5) is based on component name and interface type, not on JNDI name. For purposes of backward compatibility, the results of an injection directive can also be accessed through a JNDI lookup if the developer chooses to, but that use case is relatively rare.

EJB3 requires an EJB container, Spring requires a Spring container. Spring components do not run standalone in a JSE environment -- they require the Spring container. You can test your Spring components outside the Spring container, and you can test your EJB3 components outside the EJB container.

Based on these and other inaccuracies, I think the authors of the comparison need to dig more deeply into EJB3.

And I think it would not hurt you to learn a little more about Spring too, even if you are not gonna use it(in production but in debates) because trying to comment on something you don't know well doesn't make you look good.

EJB3 requires an EJB container, Spring requires a Spring container. Spring components do not run standalone in a JSE environment -- they require the Spring container. You can test your Spring components outside the Spring container, and you can test your EJB3 components outside the EJB container.

Based on these and other inaccuracies, I think the authors of the comparison need to dig more deeply into EJB3.

And I think it would not hurt you to learn a little more about Spring too, even if you are not gonna use it(in production but in debates) because trying to comment on something you don't know well doesn't make you look good.

This seems to imply that his statements are wrong. How are they wrong? How can a Spring component be used outside of the Spring Container, yet get the benefits of Spring? How can EJBs not be tested outside of the container? His point is simply that both EJBs and Spring components are simply POJOs, annotated POJOs in EJBs case, whereas with Spring the POJOs are configured externally (perhaps it can use annotations today, I don't know). But without their supporting containers, the actual Java code is simply POJO code.

All in all a nice article. To me EJB3 is a standard without a lot of implementations whereas Spring is an implementation that fills a gap as a defacto standard. The article does a nice job pointing out the relative ease of use of both strategies. Pojo-nisity seems relatively trivial compared to benfits each strategy provides over EJB 2.x. I don't get the impression many developers are using JDK1.5 w/ annotaton let alone EJB3 at this point. Spring can help bridge the gap. Use .hbm files first then annotate later. Spring seems to be taking a leap towards being a daemonized container now that it sports a thread model for asynch listeners. Event the old event model is sync.

How can a Spring component be used outside of the Spring Container, yet get the benefits of Spring? How can EJBs not be tested outside of the container?

JBoss supports testing EJBs outside of the container.

annotated POJOs in EJBs case

EJB 3 does not require annotations. Each annotation has an XML equivalent. So, if you went the pure XML route, your EJB would look like a POJO. Bill

EJB3 requires an EJB container, Spring requires a Spring container. Spring components do not run standalone in a JSE environment -- they require the Spring container. You can test your Spring components outside the Spring container, and you can test your EJB3 components outside the EJB container.

Based on these and other inaccuracies, I think the authors of the comparison need to dig more deeply into EJB3.

And I think it would not hurt you to learn a little more about Spring too, even if you are not gonna use it(in production but in debates) because trying to comment on something you don't know well doesn't make you look good.

...as your own statement does not make you look particularly good, because he's actually right, unless you found a way to run your Spring components outside of the Spring container?

He was only pointing to inaccuracies about EJB3. He does not have to learn Spring to do that.

As I said in another thread, EJB3 EJBs are the same EJBs as they were in EJB2, even though they have that innocent look of POJOs. For people who havn't used EJB2 (or EJB1) before, the effect (of looking like POJO) can be more confusing. Though outside container unit test is a progress. Spring is somehow regarded more white box while EJB is more black box.

EJB3 requires an EJB container, Spring requires a Spring container. Spring components do not run standalone in a JSE environment -- they require the Spring container. You can test your Spring components outside the Spring container, and you can test your EJB3 components outside the EJB container.

Based on these and other inaccuracies, I think the authors of the comparison need to dig more deeply into EJB3.

Spring applications need a spring container? That's right! If you are using Log4j, you need the Log4j environment: you know, you have to make import org.apache.log4j.... The Spring container can be embedded in any environment, as: - tomcat container (j2ee) - standalone container (j2se) - junit/testng contanier (j2se) that's the difference! Can you run your ejb without starting your favourite Application Server? I mean, if you are using GlassFish, can you run your EJB services without Glassfish? I'm afraid, the answer is not, and this means that the unique environment where EJBs live is j2ee; so, you will have many problems to run your junit/testng tests, that's very important! test is very important... Another important thing: Inversion of Control. The IoC is a clear and elegant concept not completely/correctly addressed in a EJB3 container. I mean, if you want to use the IoC mechaninsm in a class of your own, you have to mark that class as @Stateless or @Stateful, i.e., your Foo class must import the EJB3 framework interfaces. That's very ugly! On the other side, if you want to use the IoC in a Spring container , your class Foo must not import any spring interfaces/classes, the IoC is used outside the box. Definitely, I think Spring philosophy is superior than EJB3 philosophy, it is more advanced, powerful and useful. Best Regards. Michele

The Spring container can be embedded in any environment, as:
- tomcat container (j2ee)
- standalone container (j2se)
- junit/testng contanier (j2se)

that's the difference! Can you run your ejb without starting your favourite Application Server?...so, you will have many problems to run your junit/testng tests... ...
Definitely, I think Spring philosophy is superior than EJB3 philosophy, it is more advanced, powerful and useful.

The JBOSS embeddable container can be run outside of the application server in standalone applications, junit tests, and Tomcat. So the distinction you're making is not as clear-cut. However, I tend to agree with you on your last statement, although advanced features etc... are only a plus when they are actually needed.

I mean, if you want to use the IoC mechaninsm in a class of your own, you have to mark that class as @Stateless or @Stateful, i.e., your Foo class must import the EJB3 framework interfaces.

No, it doesn't have to. You can put it in an XML file.

The reason for using POJOs is that you can use them without any container. They are independent of the container. For instance you can test your POJO in JUnit by injecting stubbed or mocked components as part of your unit test. If your unit tests are importing Spring then you have not testing at the unit level. Rather you are testing at some sort of integration level.

Can you run your ejb without starting your favourite Application Server?

Yes, JBoss embedded for instance is such a thing, an embeddable container!

The comparison of the remoting capabilities is a bit off. To say Spring remoting capabilities are limited compared to EJB is misleading - Spring does not really implement any remoting protocol. From a client perspective, all it does is provide a clean, boilerplate code free way of accessing remote components exposed over a variety of protocols, with even the added flexibility of swapping one remoting protocol with another without changing the client code. And it doesn't make any sense to say Spring remoting does not allow propagation of tx or security contexts - Spring is only as good as the underlying remoting protocol and if the underlying protocol allows tx/security context propagation such as RMI/IIOP or the WS-* headers for SOAP you've got that too.

I want breif explanation what is the difference between Spring Framework and Ejb3.0 Please explain to me using simple english. Thanks&Regards Kotaiah.Katragadda

I want breif explanation
what is the difference between Spring Framework and Ejb3.0
Please explain to me using simple english.

Spring: today's hype EJB: yesterday's hype

I want breif explanation

what is the difference between Spring Framework and Ejb3.0

Please explain to me using simple english.


Thanks&Regards
Kotaiah.Katragadda

How amusing it is, that your brilliant question has not been answered properly by anyone yet... :D Fact is, your question hits dead on at how ridiculous the debate over which is "better" really is: No brief explanation can be given! The difference between Spring and EJB3 is in the miniscule details which are completely irrelevant to whether or not a project fails or succeds. In real life what matters is not whether configuring dependency injection is a tiny little bit better this way or that way. What matters is questions regarding "what does it cost?" and "what do we gain?". This in turn depends on: - What existing infrastructure do we have? - What existing maintainance routines do we have? - What existing knowledge base do we have? - What existing partner contracts do we have? ... and so on. Sometimes Spring is the better choice, other times you'll go with EJB3. But only a fool would argue that whether or not messaging clients have to implement an certain interface is even remotely relevant to the decision making process. All too often, the never-ending debate for and against EJB deteriorate into a squabble over the insignificant, like whether square or hex headed lag bolts are better when building a house...

what is the difference..

..which is "better"..

Go to DevX and RTFA on differences between Spring and EJB3. Go to http://labs.jboss.org/portal/jbossejb3 and RTFM. JBoss is just one implementation. Go to http://www.springframework.org and RTFM. As for which is better. Why would you not use both of them together. It's not an either/or question. Why paint yourself into a corner with one or the other. I get the impression that JBoss is not endorsing Spring but who cares. Microsoft doesn't endorse Java on Windows but no one cares.

what is the difference..

..which is "better"..

Go to DevX and RTFA on differences between Spring and EJB3. Go to http://labs.jboss.org/portal/jbossejb3 and RTFM. JBoss is just one implementation. Go to http://www.springframework.org and RTFM.

As for which is better. Why would you not use both of them together. It's not an either/or question. Why paint yourself into a corner with one or the other. I get the impression that JBoss is not endorsing Spring but who cares. Microsoft doesn't endorse Java on Windows but no one cares.

Well said.

As for which is better. Why would you not use both of them together. It's not an either/or question. Why paint yourself into a corner with one or the other.

Check out Ales Justin's JBoss/Spring Integration project. Allows you to package and hot deploy Spring archives and has a few portable and non-portable ways of integrating Spring with EJB3.

I get the impression that JBoss is not endorsing Spring but who cares.

We actually don't care about spring as it only overlaps a very minute subset of our offerings: EJB (not J2EE) and Seam (to a degree). We've had integration with Spring for over a year now and actually that contributor is coming to work for Red Hat in a few weeks.

Microsoft doesn't endorse Java on Windows but no one cares.

Not exactly true...They partnered with us because they saw how many of our users run JBoss on Windows. Bill

I want breif explanation what is the difference between Spring Framework and Ejb3.0 Please explain to me using simple english.

EJB is a standard, Spring is an independent open source project. Being a standard, EJB may give you some advantages on tooling, compatibility, vendor independence. It's more 'standard'. But, if you need something beyond the spec, you may have to use some vendor extension, or wait for the next version of the spec to support what you want. Spring, being an independent project, can respond faster to new technologies, and provides nice integration to many other well stabilished open source frameworks and standard APIs. It's more flexible and solution-focused. But, there is no 'vendor independence', because the only vendor is the Spring project (which is Apache-licensed and provides paid support, so it's not a big deal). EJB folks (aka JBoss's employees :)) say that Spring's stateless view of things has no excuse, because nowadays SFSBs are much better implemented, and state is not that costly anymore. Spring folks say that Spring's DI and AOP features are far more powerful than EJB's. And, with Spring 2.0's new 'bean scopes' you do can make use of stateful components. The 'remoting' aspect pends to the EJB side. Well, since it was projected exclusively for remoting from day one, it's not unexpected. Spring's 'default' remoting strrategies are quite usable, but when you have VERY advanced requirements, such as distributed transactions (not 2PC, which Spring supports, but transactions initiated from a remote client, propagated to the server), you end up having to use EJB. But, Spring also provides nice integration to EJB, if you for some reason must use it. cheers

I am one of those who got burned building an EJB 2.0 application. It worked but it was painful to build and hard to test. Lots of 'Pluming code' for not many lines of Business Logic. When I read Rod Johnson’s Books it simply confirmed for me that a big part of the EJB spec was simply too complex and not suited to most applications. Now EJB 3.0 is out. What about the older versions? A lots of money was spent building systems around older EJB. Did any of the architects behind the first EJB generation get fired for convincing an entire industry to adopt an inefficient component model?