What is difference between JavaClass and Beans and EJB?What are pros and cons ofthem?

[asif aziz]

hi all,
Can anyone help what are differenes between java class beans and ejb?What are pros and cons of them?

[Stan James]

I think we're looking at three things: Java classes, Java Beans and Enterprise Java Beans. Right?

All of these are Java classes. That's the only unit of compilation we have so all java code is in a class of some kind.

Java Beans specify a few special things that the class must have: A no-args constructor and getters and setters that follow a naming convention. This makes it easy for tools like IDEs and screen designers to work with unfamiliar objects through reflection. It's also quite common in Transfer Objects. Some people get the idea they should automatically make getters and setters for every class and in fact that's pretty bad OO design.

Enterprise Java Beans are really something quite different and it's confusing that they used such a similar name. EJBs have to have even more special methods and structure so a "container" can manage them. The container calls various bean methods at appropriate times to manage bean life cycle and to get real work done.

Does that help?
[ July 27, 2006: Message edited by: Stan James ]

[Sol Mayer-Orn]

The notation is indeed a little confusing...

1) "Bean" is a kind of java class, with some simple limitation & coding conventions. To the best of my recallection, a bean has to be Serializable, have a no-arg constructor, have setters/getters for all properties, and should be indifferent to the order in which setters are invoked.
Example:

 
public class Product implements java.io.Serializable{
    private String manufacturer;
    private int price;
    public Product(String manuf, int price){
        this.manufacturer=manuf;  this.price=price;
    }
    public Product(){
    }
    public String getManufacturer(){return manufacturer;}
    public void setManufacturer(String manuf){this.manufacturer=manuf;}
    public int getPrice(){return price;}
    public void setPrice(int price){this.price=price;}
}

As you can see, it's easy to write a Bean. You don't need any speical tools, just follow some conventions.
The motivation for Bean requirement is: making them easy to process by automatic tools, especially by using reflection/introspection.
Some examples:
a) Some xml tools (e.g. Jibx or Axis), can take any Bean and serialize/deserialize it into xml. In simple cases, they use reflection to invoke all 'getXXX' methods, and print the results into xml.
Bean conventions are crucial here...if your Product method was 'obtainPrice' instead of 'getPrice', then the tool would miss it and the price won't be printed to xml.
b) Graphical designers allows you to desing a GUI window by dragging/dropping Swing components (JButtons, JComboBoxes, etc). Since swing components are written by Bean standards, the tool can automatically find all their 'setXXX' methods (setFont, setBackground, setSize....) and allow you to edit those properties through a nice colorful interface.

2) EJB are java classes designed to run inside J2EE containers, and rely in various J2EE services (remoting, automatic transaction management, automatic security checkes, etc).
General outline of writing EJB's:
a) Obtain a J2EE container, including j2ee jars. Most containers cost money, but JBoss is a good free container.
b) Write your class, implementing your business logic (say: stock price calculations). There are some limitatitions: If you use ejb 2.x, you class must inherit from special j2ee classes. If you use the new ejb 3 spec, you don't have to inherit, but there are still some restrictions (e.g. limitation of thread usage).
c) Run your j2ee container, and deploy your class into it. Basically, you use simple xml files to tell the container "here's my service, now use RMI to expose it to remote clients, and while you're at it, make sure that only ADMIN users can edit stock prices...". You can even rely on J2EE persistence services ("here's my Stock object, now map it into database rows).
The advantage is, the container does a lot of work for you, saving you coding.... the disadvantage is being tied to J2EE (having to obtain a j2ee container, and following some restrictions, such as restrictions on thread usage).

[asif aziz]

hi all,
Thanks a lot for very much valuable information.