What is Enterprise Java Beans.

[SimonBurton]

I'm sure i've read about them at the java.sun site.
For some reason I still don't know what EJB is about.
I do know about JavaBeans, is this the place for JavaBeans discussion?
[This message has been edited by SimonBurton (edited January 07, 1999).]

[paul wheaton]

I have never used EJB, and don't feel I have a thorough grasp of the subject. But! Here is what I know:
It's Java Beans with RMI thrown in.
Thus, it's a step in the direction of distributed computing. Especially when RMI over IIOP becomes the standard.

[paul wheaton]

If there is an interest in "regular" beans, I could make another forum.

[Matt Midcap]

I would be interested!

[Doug Gschwind]

Enterprise JavaBeans is first a specification from JavaSoft (~200 pages) which defines interfaces and such for a server component model. Its primary benefit to the software development community is that a naive (in terms of transactional behavior, persistence, security) java class can be written as a bean, plugged into an EJB implementation ... and the naive java bean then appears to the RMI or CORBA consumers that it has enterprise capability and is no longer simply naive. The EJB implementation provides this on behalf of its naive constituents and thus giving those that consume from the public interface the impression that the beans are providing the "enterprise" capabilities when in fact it is the EJB vendor who is providing that.
Also, there are two types of beans that an EJB implementation supports: session and entity beans. At a high level a session bean is one whose state is not persisted. An entity bean's state is persisted. An EJB implementation is supposed to support both container managed entity beans (the EJB implementation is responsible for persisting the state of your java bean) and bean managed (the bean takes responsibility for its persistence to/from a DBMS) entity beans.

[Anonymous]

Hi,
I just joined your discussion group and thought I'd reply to the question "What are EJBs?" Basically, dgschwind is correct. However, I would like to add that the main point of using EJB is to place the development of a distributed enterprise in the hands of the appropriate experts.
In other words, the developer of the EJB is the business logic developer. He's the expert in business logic but not necessarily the expert in all the extra low-level stuff that goes on. The Server vendor is the expert in that realm so let him handle this part.
The consumer doesn't really care if the EJB handles the transactions, threads, state management, etc. as long as somebody handles it.
What about JavaBeans? Well, one could use the JavaBeans specification to develop beans for the Enterprise but a developer would have to create all this server infrastructure from scratch. JavaBeans spec. is really a component model that defines an interface for a builder tool to graphically assemble components whereas the EJB spec. is really a component model that defines the interfaces necessary to split up the various tasks that make Enterprise computing development easier. The spec. calls the interfaces "contracts".
There is a contract between the server and container, and a contract between the container and the objects (EJBs).
One more thing - the transactional behavior can be specified at deployment time rather than design time. Makes for more friendlier development and code resuse in such a complicated system.
[This message has been edited by Darlene Khosrowpour (edited January 25, 1999).]

[paul wheaton]

I've heard the EJB isn't quite ready for prime time. True?

[Palani]

Basically all the previous messages do a good job by interpreting what an EJB is, let me try to interpret EJB with my variation.
Apart from JavaBean and EJB are written in Java, there is no connection between the two.
Javabean is a set of specification to be followed which will facilitate the bean to be used in an integrated development environment (IDE). Javabean is used in the client side
EJB is a server side distributed component model which is used to develop distributed, scalable, interoperable business object.
EJB is used on the server side. It can not be used on the client side.
EJB specificies the contract between the various players in the enterprise development.
The players in the enterprise development are
Enterprise Bean Provider
Application Assembler
Deployer
EJB Server Provider
EJB Container Provider
System Administrator
EJB Server Provider and EJB Container Provider provide the infrastructure needed to run the EJB such as naming, security, transaction management.
Enterprise Bean Provider concentrates on the business logic without any concern of the transaction management or the platform where it be deployed.
EJB can be deployed in any vendor provided EJB Server and container.

[Joe Guzzardo]

I found this "white paper" at the Sun site describing in some detail what EJB is all about:
http://java.sun.com/products/ejb/white_paper.html
The Sun tutorial on EJB can be found at:
http://developer.java.sun.com/developer/onlineTraining/Beans/EJBTutorial/index.html

[Javix Protocol]

An EJB System is logically a three-tier system.The three tiers are as follows:
1)The Client
2)The EJB Server
3)The database(or other persistent store)
* This structure is a logical architecture because the three tiers dont neccessarily have to reside on three different machines.For Example
The EJB Server and the database might reside on the same machine.This case could arise if the EJB Server includes built in functionability for persistent storage.
* The client and the EJB Server might reside on the same machine.This case occurs when an EJB bean makes a call to another EJB bean in the same container.The caller EJB bean is acting as a client in this instance.
* If you comine the two cases above ,all the three tiers might reside on a single machine.Most commonly,the client,the EJB Server and the database will reside on seperate machines though not neccessary.For example,if you are using an application servert that supports servlets,you may put your servlet clients on the same physical box as your EJB objects.If you are using an application server that directly supports persistent data storage,you may not involve an external database..

------------------
The Javix