Should I use EJB3 or Spring for my business layer?

Question

My team is developing a new service-oriented product with a web interface. In discussions about what technologies we will use, we focused on launching the JBoss application server and the Flex interface (with possible deployment to the desktop using Adobe AIR) and web services for interacting with the client and server.

We have reached a dead end when it comes to which server technology to use for our business logic. The big argument is between EJB3 and Spring, and our biggest problems are scalability and performance, as well as maintainability of the codebase.

Here are my questions:

• What are the arguments for or against EJB3 vs Spring?
  • What pitfalls can I expect from everyone?
  • Where can I find good background information?

Answer 1

There won't be much difference between EJB3 and Spring based on performance. We chose Spring for the following reasons (not mentioned in the question):

• Spring drives architecture in a direction that more easily supports unit testing. For example, add the layout DAO object to the unit test business layer or use the Spring MockHttpRequest object for the unit test of the servlet. We support a separate Spring configuration for unit tests, which allows us to isolate tests to specific layers.
• The primary driver was compatibility. If you need to support multiple application servers (or, in the end, want to switch from JBoss to Glassfish, etc.), you will essentially carry your container (Spring) with you, and not rely on compatibility between different implementations of the EJB3 specification .
• Spring allows you to choose technologies for Persistence, remoting objects, etc. For example, we also use the Flex interface and use the Hessian protocol for communication between Flex and Spring.

Answer 2

The gap between EJB3 and Spring is much smaller than it was, obviously. However, one of the drawbacks of EJB3 is that you can only enter a bean so that you can turn components into beans that shouldn't be.

The unit test argument doesn't matter right now - EJB3 is clearly designed to be easier to test.

The compatibility argument above also does not matter: whether you use EJB3 or Spring, you are still dependent on third-party implementations of transaction managers, JMS, etc.

What would change for me, however, is community support. When working on the EJB3 project last year, there were not many people who used it and talked about their problems. Spring, right or wrong, is extremely common, especially in the enterprise, and it makes it easier to find whoever got the same problem you are trying to solve.

Answer 3

What are the arguments for or against EJB3 vs Spring? Spring is always innovative and recognizes real limits. Spring offered simplicity and elegance for Java 1.4 application servers and did not require a version of the J2EE specification that no one had access to in 2004-2006. At the moment, this is almost a religious debate that you can drag into - Spring + open source abstraction + and Java Enterprise Edition (Java EE) 5.0.

I think Spring complements more than competes with the Java EE specifications. Because features that were once unique to Spring continue to slide into the specification, many argue that EJB 3 offers a set of "good enough" for most internal business applications.

What pitfalls can I expect with everyone? If you see this as a persistence issue (Spring + JPA) compared to EJB3, you really don't make that much choice.

Where can I find good background information? I have not followed specj benchmark results for a while, but they have been popular for a while. It seems that every vendor (IBM, JBOSS, Oracle and Sun) is less and less interested in having a compatible server. Lists are received by Shorter and shorter certified suppliers, starting from 1.3, 1.4. 1.5 Java Enterprise Edition. I think the days of the giant server, fully compatible with all specifications, are over.

Answer 4

I would definitely recommend EJB3 over spring. We find that it is more optimized, better coordinated, and better supported. In the past, I used Spring and found it to be very confusing, and not as well documented as EJB3 (or JPA, I think, at the end of the day)

• Starting with EJB3, you no longer have to deal with external configuration files, and there is only one POJO that you comment on in the database table. This POJO can be transferred to your web tier without any problems. IDEs like Netbeans can even automatically generate these POJOs for you. We used EJB3 as the back end for quite a few large-scale applications and did not notice any performance issues. Your Beans session can easily be represented as web services that you could open in your Flex interface. A Beans session is easily blocked, either at the method level or at the class level, to assign roles and the like, if you need to.

I can't talk so much about spring since I only tried this for a few weeks. But my general impression of him was very poor. This does not mean that this is a bad structure, but our team found EJB3 as the best for persistence / business level.

Answer 5

I prefer Spring over EJB3, but my recommendation will depend on your approach, try writing POJOs and using standard annotations where possible, like JSR annotations like @PostConstruct, @PreDestroy and @Resource that work with both EJB3 and with Spring, so you can choose any structure you prefer.

eg. You can decide which project to use Guice instead of IoC.

If you want to use pre-injection, for example, in a web application, you may find that Guice is quite a bit faster for dependency injection than Spring.

The beans session mainly comes down to dependency injection and transactions; therefore, EJB3 and Spring are similar for this. Where Spring has the edge over improved dependency injection and nicer abstractions for things like JMS

Answer 6

In the past, I used very similar architecture. Spring + Java 1.5 + ActionScript 2/3 combined with Flex Data Services made everything very simple (and fun!) For the code. although the front of the Flex means you need powerful enough client machines.

Answer 7

Regarding your question:

What are the arguments for or against EJB3 vs Spring?

I suggest reading an answer from experts: ANSWER TO: EJB 3 AND SPRING COMPARATIVE ANALYSIS Mark Fisher . Read the comments to find the comments by Reza Rahman (EJB 3.0).

Answer 8

Another thing in favor of spring is that most of the other tools / frameworks there better support integration with spring, most of them also use spring (for example, activemq, camel, CXF, etc.).

He is also more mature and has a lot more resources (books, articles, best practices, etc.) and experienced developers than for EJB3.

Answer 9

I think EJB is a good component technology, but not a good structure. Spring is the best structure available today. Therefore, I should consider Spring as the best JEE implementation in terms of structure, and my recommendation is to use Spring in every project, which gives us the opportunity to easily integrate with any component technology.