Enterprise JavaBeans server-side components come in two fundamentally different types: entity beans and session beans. A good rule of thumb is that entity beans model business concepts that can be expressed as nouns. For example, an entity bean might represent a customer, a piece of equipment, an item in inventory, or even a place. In other words, entity beans model real-world objects; these objects are usually persistent records in some kind of database. Our hypothetical cruise line will need entity beans that represent cab-ins, customers, ships, etc.


Session beans are an extension of the client application and are responsible for managing processes or tasks. A Ship bean provides methods for doing things directly to a ship but doesn’t say anything about the context under which those actions are taken. Booking pas-sengers on the ship requires that we use a Ship bean, but also requires a lot of things that have nothing to do with the Ship itself: we’ll need to know about passengers, ticket rates, schedules, and so on. A session bean is responsible for this kind of coordination. Session beans tend to manage particular kinds of activities, for example, the act of making a res-ervation. They have a lot to do with the relationships between different enterprise beans. A TravelAgent session bean, for example, might make use of a Cruise, a Cabin, and a Customer—all entity beans—to make a reservation. 
I find this paragraph confusing It seems like ...
   Jonathan Lostly, September 3, 2001 (1 reply)

  Typo. Change pas-sengers to passengers
    David Stickler, September 5, 2001 (12 replies)

  Why are you talking about reservations when ...
    Karen Littlehelp, September 12, 2001

The activity that a session bean represents is fundamentally transient: you start making a reservation, you do a bunch of work, and then it’s finished. A session bean doesn’t repre-sent something in a database. Obviously, session beans have lots of side effects on the database: in the process of making a reservation, you might create a new Reservation by assigning a Customer to a particular Cabin on a particular Ship. All of these changes would be reflected in the database by actions on the respective entity beans. Session beans like TravelAgent, which is responsible for making a reservation on a cruise, can even access a database directly and perform reads, updates, and deletes to data. But there’s no TravelAgent record in the database—once the reservation is made, it’s done.
  I must take exception to the comment made: 'In ad...
    Jonathan Rasmusson, Dec 2, 1999
I must take exception to the comment made: 'In addition, because EJB is widely supportedby many vendors, corporations do not have to worry about vendor lock-in; enterprisebeans will run in any EJB compliant server.' This simple is not true (today). I have beenperforming EJB compatiblity tests between SynerJ (Suns application server purchasedrecently in the Forte merger) and WebLogic. Because of differences in deploymentdescriptor implementations, looseness and changes in the EJB spec, you simply can notmove an EJB from one app server to another. Even the implementation of the EJB API itselfmay very from vendor to vendor (as was the case with SynerJ and WebLogic - they bothhave different method signatures for the ejbRemove() method of entity bean. As youprobably know, Sun has taken steps to tighten up the spec, to ensure vendors implementmore compatible EJB containers. Hopefully this time next year, after a few more iterationsof the spec, we will be able to move EJBs from one app server to another. You probablyalready know all this already and I may have taken your FAQ out of context. I am justsaying people should be aware that due to the imaturity of the spec, EJBs simply are notportable between the 40 odd vendors out there. Note: I am a big fan of this site and thinkyou are all doing an excellent job. Keep up the great work. Yours truly, Jonathan


  I agree with Jonathan and I still see EJB in speci...
    Subramaniam Kumar, Jan 22, 2000
I agree with Jonathan and I still see EJB in specification mode. For enterprises like mine it ismandatory that we use mature Products not an evolving (probably divergingspecifications). If EJB is not ready yet what is the alternative the Java camp provides forEnterprise level distributed object computing. Feedback is appreciated. Subramaniam Kumar


  I think the following paragraph illustrates better...
    Ramu Meda, Dec 18, 2000
I think the following paragraph illustrates better the difference: JavaBeans components are small-grained application bits. You can use JavaBeans toassemble larger-grained components or to build entire applications. JavaBeans, however,are development components and are not deployable components. You typically do notdeploy a JavaBean because a JavaBean is not a complete application; rather, JavaBeanshelp you construct larger software that is deployable. And because they cannot bedeployed, JavaBeans do not need a runtime environment in which to live. JavaBeans do notneed a container to instantiate them, to destroy them, and to provide other services tothem because the application itself is made up of JavaBeans. By way of comparison, theEnterprise JavaBeans (EJB) standard defines a component architecture for deployablecomponents called enterprise beans. Enterprise beans are larger, coarser-grainedapplication components that are ready to be deployed. They can be deployed as is, or theycan be assembled with other components into larger application systems. Deployablecomponents must be deployed in a container that provides runtime services to thecomponents, such as services to instantiate components as needed.


What makes this distinction difficult is that it’s extremely flexible. The relevant distinc-tion for Enterprise JavaBeans is that an entity bean has persistent state; a session bean models interactions but doesn’t have persistent state.   This may be true, but it depends on how ...
              ( 19 posts to this pargraph)