CODEWITHSUNDEEP
architectureejb-3.0pojo
Shaw
Shaw

Reputation: 1494

To EJB3 or not?

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.

Upvotes: 3

Views: 1363

Answers (8)

Armen Arzumanyan
Armen Arzumanyan

Reputation: 2053

Answer is simple - If jboss/glassfish, use EJB3 if tomcat, use pure JPA, or Hibernate or Spring data

EJB3 vs Hibernate? of course EJB3. You should know what EJB3 under jboss used hibernate, EJB3 under glassfish used eclipse link JPA.

Upvotes: 0

user2770375
user2770375

Reputation:

EJB3+JPA will make you work very simple..It's highy scalable and very easy to configure and use with each other.Creating entities is the toughest part but after that things go java wise(Specially if you use entities relationships)..I used spring and hibernate for 4 years and yes they are excellent if you don't have an application server. But as long as you have WAS 7.0 then i recommend using EJB+JPA.

Working with JPQL is far easier and reasonable to java programmers. However; you can't call stored procedures unless you use JPA 2.1 which is supported only in WAS 8.5.

Upvotes: 0

kalyan
kalyan

Reputation: 46

WAS 7 defaultly has the OpenJPA implemenation provided. Spring+

Upvotes: 0

Deian
Deian

Reputation: 1374

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.

Upvotes: 0

Richard Kettelerij
Richard Kettelerij

Reputation: 2174

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.

Upvotes: 1

skaffman
skaffman

Reputation: 403501

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.

Upvotes: 1

djna
djna

Reputation: 55907

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.

Upvotes: 1

Aaron Digulla
Aaron Digulla

Reputation: 328614

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.

Upvotes: 2

Related Questions