• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Questions about EJB

 
Ranch Hand
Posts: 33
Eclipse IDE MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am reading Servlets and JSP and found a new technology named EJB. What is EJB? Is it required while developing a J2EE web site, if so,why? Why only servlets and JSP both can not solve all problems without using EJB?
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not only is EJB not required to write J2EE-compliant applications, the Tomcat and jetty servers don't have EJB support at all. Of course, they're also not complete J2EE/JEE spec implementors, but they're extremely popular because they have very low overhead.

Enterprise JavaBeans was an attempt to produce re-usuable components for J2EE. It's currently in its third generation. The component types are in 3 major categories: Logical (session EJBs), Persistence (Entity EJBs), and Messaging (Message EJBs).

The original spec was wildly and inappropriately adopted, which resulted in a backlash. People were writing session EJBs full of SQL Stored Procedures, and the maintainability was bad, but the overhead was worse. Quite a few shops in my town ended up banning them altogether. EJBs come with either remote or local interfaces, depending on whether they are to be employed from code within a webapp or from code in some other webapp. The remote interfaces were high overhead because they required a full-fledged network connection to talk to them, plus you had local and remote constituents which had to be incorporated into the client and server apps, respectively. And you had to use JNDI to locate remote EJBs, which was extra coding and overhead.

EJB version 2 lightened up on the spec, allowing local-only EJBs, avoiding the mess of setting up the remoting infrastructure. Also, they changed their communnications mechanism to IIOP, which is more firewall-friendly as well as putting them in the same general communications space as the (disappearing) CORBA platform/language-independent client-server system.

EJB version 3 further lightened up things. Among other improvements, a subset of the spec was made in such a way that you could use it without an actual EJB-compliant server, and, in fact, in non-server application. That subset is the Java Persistence Architecture (JPA), and is implemented not only by all compliant EJB service providers, but also by the Hibernate ORM system, Apache's open-source OpenJPA product, Oracle's successor to the Kodo ORM system that it purchased (Kodo originally used an alternative, similar architecture called JDO), and others whose names I cannot recall off the top of my head.

JPA (and Object Relational Management/ORM in general) do offer advantages for industrial-grade applications. They provide a re-usable set of classes that can be employed in many types of applications. I have stand-alone apps that re-use my ORM definitions from webapps. They provide mechanisms for ensuring transactional integrity within and between applications - although some of this is platform-dependent. ORM classes and their associated standardized query language JPQL make it easier for people who aren't SQL acrobats to perform complex relational functions (joins are the bane of SQL). ORMs are a good fit for plug-replaceable backend data caches. And, finally, apps that really bang on the database are often more performant when done in JPA than they are when done using raw SQL.

I said earlier that Tomcat and jetty do not support EJB, although there are special spin-offs that do. More commonly, however, you can use something like Hibernate JPA under Tomcat (which I do a lot). There are some differences between non-EJB JPA and EJB JPA, mostly doing with the fact that a true EJB server provides the requisite entity managers directly, whereas Hibernate and its friends have to construct their own, but the essential part of the system is the same.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic