44

Are they different or they are used interchangeably? If they are Different, then what made them different from each other?

JUST MY correct OPINION
  • 35,674
  • 17
  • 77
  • 99
GuruKulki
  • 25,776
  • 50
  • 140
  • 201

4 Answers4

52

A JavaBean is just a plain old Java object that conforms to certain conventions including the use of accessor functions (getFoo/setFoo) for member access, provision of a default constructor and a few other things like that.

An Enterprise JavaBean is a component in a Java EE application server which comes in several flavours, the details of which vary by which version of Java EE you're talking about (or, more specifically, which specific set of EJB specifications are involved).

JavaBeans were originally mostly intended to be used in builder tools by providing a known interface which could be looked for through introspection in the tools. They quickly turned into what amounts to a religion, however.

Enterprise JavaBeans are intended to provide encapsulated business logic for enterprise applications within a general container that provided things like session management, security, resource pooling, etc. as services thus allowing the business logic to be (relatively) untainted by these cross-cutting concerns. (Whether or not they accomplished this is a matter that is up for debate, given how difficult they were to use at first. More recent versions of the specification have made this easier, however. Legacy apps, though, are still a pain and sadly likely the majority of the EJBs you're likely to encounter.)

Edited to add:

JUST MY correct OPINION
  • 35,674
  • 17
  • 77
  • 99
  • 2
    I was just about to finish an almost identical answer but you beat it to me so I decided to +1 instead. Good work. – Fredrik Mar 17 '10 at 05:30
  • Thanks. I'd have been interested, however, in seeing your take on it. I always like to read others' perspectives on information. – JUST MY correct OPINION Mar 17 '10 at 05:34
  • @ttmrichter: Well, you covered it all and few more things so my takes wasn't really worth publishing. The only thing I think is missing was a confusing attempt to describe MDB, CMP and session beans but I wasn't really happy with the attempt so it is just as good. – Fredrik Mar 17 '10 at 05:50
  • 1
    +1 for JavaBean explanation -1 for EJB explanation. Less buzzwords please! – allyourcode Mar 17 '10 at 06:03
  • It's hard (perhaps impossible) to explain EJBs without buzzwords because as far as I can tell their creation and use centres almost exclusively on buzzwords! :D – JUST MY correct OPINION Mar 17 '10 at 09:43
  • @ttmrichter. Don't agree about the necessary buzzword. You can summarize it like this: java bean is a naming convention, EJB is component *model*. That's the heart of the difference, you didn't emphasized that enough in my sense. See my answer. – ewernli Mar 17 '10 at 09:50
  • 1
    First JavaBeans is a lot more than a naming convention. Check out the link I provided above. It's just that the naming convention is the part that stuck. Second, "component model" is also buzzword-ish. It doesn't explain what the model in question is intended to accomplish (you covered the network code in your question, but not the session management, the persistence, the security, etc. etc. etc.). Really, I don't think there is an easy answer to "what is an Enterprise JavaBean" (aside from "a horrible name"). Trying to do this results in jargon and buzzwords. – JUST MY correct OPINION Mar 17 '10 at 10:20
  • 1
    +1 you convinced me :) (Though I would still argue that what the component model provides exactly is not what matter the most if you want to understand the big picture behind EJB. You just need to understand it's a component model, like CORBA, COM, or others. But yes, you need to know what a component model is in general which most of the time isn't the case.) – ewernli Mar 17 '10 at 10:47
17

A Java Bean is defined as an instance of a class that contains private attributes (data), and getter & setter methods.

If you have:

private String myString; in your class, you should have the methods public String getMyString (); and public void setMyString (String settingString); defined in your code. Although, I have found that it is not absolutely necessary to have everything defined, just don't be surprised if something breaks!

An EJB (Enterprise Java Bean) is much more complex They only reside in application servers that handle EJBs (Tomcat doesn't hold EJBs). There are 3 types of EJBs:

  1. Session: Usually contain some business logic.
  2. Entity: Usually interface with a data store (such as a database).
  3. Message-Driven: Receives messages from JMS.
sah1
  • 380
  • 1
  • 6
  • 23
sbose
  • 1,791
  • 5
  • 24
  • 46
  • Note that there is now TomEE, Tomcat server which supports EJB (and the full Web Profile): http://tomee.apache.org/tomcat-ejb.html. – Hawkeye Parker May 02 '17 at 20:04
7

Java beans refers to classes with only fields and their getter-setter methods. With little or preferably no business logic at all. They are also known as POJO (Plain Old Java Object).

EJB's are part of J2EE specification that can be used to leverage full functionality of J2EE compliant servers, such as transactions, session management, security etc. (That does not mean that you cannot use these without using EJBs)

saugata
  • 2,823
  • 1
  • 27
  • 39
4

"Java Beans" are used to store the data retrieved data from the database and used as a container to carry the data between the Servlets and JSPs in MVC model. A class (container) with setters and getters is used to (put) and (get) the data.

"Enterprise Java Beans" are similar to "Java Beans" with added features such as Session Management, Security, Transaction etc with the aid of different types of EJBs that are

  1. Session Bean
  2. Entity Bean
  3. Message Driven Beans
isopropylcyanide
  • 423
  • 4
  • 16
user2790341
  • 49
  • 2