It depends on what is meant by a "Bean" Beans come in two flavors (and many sub-flavors):
1).
Java Beans
2). Enterprise Java Beans
A Java Bean is defined simply as any class that makes its member variable available through get
XXX and set
XXX methods. (Although good OO coding says to do this anyway; if you do, any instance can be thought of as a "bean" [you shouldn't, but you could].)
Theoretically, instances of these classes can have their values modified through a BeanBox (typically part of an
IDE) that provides you graphical access to these attributes.
Example:
You want to place a JLabel in a GUI component. You drag-and-drop the label from the toolbar. The BeanBox creates a new instance of the lable and adds it to the container where you specified. Then a properties pane comes up, and you can edit the "Text" attribute of the label. The BeanBox knows that this attribtue is modified through the "getText" and "setText" methods of JLabel.
There are a few naming conventions that must be followed to get a BeanBox to work like this (e.g., if your attribute is "text," your get and set methods must be "getText" and "setText", not "getTheText" or some such).
Enterprise Java Beans (EJBs) are another matter entirely. The part of the name "JavaBean" is (I find) misleading: They have nothing to do with the definition of a "Java Bean". Instead, EJBs are used to create highly-scaleable, distributed applications. If your application is a large application that will be used by many people, EJBs are they way to go. (I find that the actual value of "many" seems to be diminishing). however, EJBs are meant as a back-end to Servlet/JSP-based web applciations; they can be a pain to implement in a desktop applications (typically the desktop has to communicate with a
Servlet which communicates with the
EJB.