To EJB3 or not?

Question

I have an architecture scenario and I would like to discuss to get your opinion.

I can choose between these two (this is a constraint imposed on me)

1. Use EJB3+JPA - no Spring/Hibernate
2. POJO + JDBC - again no Spring/Hibernate

I have series of web applications (only intranet) that all need to be integrated. At database level, there will be 3 to 4 oracle databases (and about 40 to 50 tables per database). Some applications may interact with more than one database for some queries. Number of concurrent user(s) will be less than 100. User/audience per application will range from 10 to 6000 (max).

All applications will be deployed on one server, and it's very likely that database and server could be on the same machine.

Most of the use cases will be CRUD based (some can offer a good domain model for an ORM while others may not), with some business process, automated jobs etc There may be a future need to integrate with SAP for some applications.

Do you think EJB3 in this case will make the application more scalable or just add complexity? If I design with POJO, will an application of this I don't want to add complexity for no good reason. I tried to lobby for Spring and Hibernate but no success.

let me know if you need more details.

EDIT: I forgot to mention the application server. it's WAS 7.

Answer 1

EJB and JPA are just interfaces; you'll still need someone to implement them. So if Spring+Hibernate aren't possible, then this means no JPA unless you can get an OK for another framework (... err ... Toplink, maybe? Is there anything which isn't Hibernate based?)

If you're stuck with POJO and JDBC, I suggest to look at Grails. That will make your life much more simple.

Answer 2

First level of discussion is to compare {POJO + JDBC, write persistence by hand} against {framework for peristence}. (I'd also suspect that you're going to end up with a need for interesting services, so I think EJB3/SLSB or Spring equivalent is relevent, even if you were to roll your own persistence).

So my belief is that persistence technologies (JPA or Hibernate) are now at a level where you need a good reason not to use them. hand-rolling crud JDBC is just routine work one should not have to do by hand.

As for the JPA v Hibernate and Spring v EJB3 debates, I'm much moe equivocal, seems to be an area with much religion.

Answer 3

I can't see how JPA would be permitted, but Hibernate wouldn't. That doesn't make a lot of sense, given that Hibernate is a JPA implementation. Would another JPA implementation be OK, such as OpenJPA?

You haven't mentioned if you have an existing server, or will be installing your apps on a yet-to-chosen server. Has this decision already been made? If so, that may dictate your choice. A full, up-to-date JavaEE server will come with EJB3 and JPA implementations already.

If the server isn't an EJB3-enabled server, then EJB3 is much less compelling.

But if sensible technologies such as Spring and Hibernate have been ruled out, there always simple frameworks like iBatis that allow you to combine POJOs with JDBC.

Answer 4

Although your constrains are somewhat a contradictory (Hibernate is a JPA implementation after all) I would advice you to adopt a standard solution. If your only choices are a standard stack like EJB3/JPA vs. a handcrafted POJO/JDBC implementation I'd say go for EJB3.

When you take the POJO/JDBC road you'll probably end up creating your own Spring like - but less feature rich and less well tested - framework. Writing a custom framework is hardly ever justifiable for application developers.

Answer 5

Just go EJB+JPA!

I guess you're stuck in some "corporate" env and you cannot use open source frameworks .. if this is the case I guess some IBM or Oracle implementation of the above interfaces is available - use it.