Session & Entity Beans

[Harry Singh]

Hi Gurus,
I've just started EJB development and have gone through the basics of EJB. I have got the idea about sesion and entity beans. But there is doubt in my mind about Entity beans.well as the Ed roman book says Entity beans and persistent data storage and its like ur data store. but i fail to understand why we need such a persistent data storage when we have got databases at backend. We can make connections to databases and use that instaed of Entity beans. Can sume tell me the use of entity beans and how it is related to databases at backend and where entity beans are the best to use.
Thanks in advance

[Ajith Kallambella]

Originally posted by Harjinder Singh:

Ed roman book says Entity beans and persistent data storage and its like ur data store.

Harinder,
I don't quite remember this phrase in Ed Roman's book. Perhaps you are paraphrasing what is there.
Entity beans represent object forms of persistent data. They are not a replacement for data storage itself. They simply map to one or more tables managed by your datastorage. Think of them as "tables in memory". Each entity bean instance would represent a row in the table.
If you have an Employee and a Department table, you might map the two tables to a single entity bean called "employee". The entity bean would encapsulate the logic to read the underlying data from the table and present an "object form" of the data to your application program. When you create a new "employee" entity bean in the application layer, a new record will be created in the underlying tables( EJB architecture would allow you to control how this will be done ). Similarly you can change values on the entity bean and the values of columns in the underyling tablerow changes. When you delete an employee entity bean instance, you will be indirectly deleting the record from the table.
Entity beans require some sort of database connection to actually talk to the underlying table and translate your actions in to SQL statements and execute them. The beauty is, it all happens behind the screens and you as an application programmer consuming the bean will not have to worry about how it gets done. If you are an EJB developer, you will have to learn the tricks though.
As you can see, entity beans do not replace your datastore. They encapsulate underlying data and allow you to manipulate them as domain objects. In fact, they even provide value added services like transactions, concurrency, lifecycle management and keeping the objects synchronized with changes to the underlying tablerow. However, you will still need a database, a database connection and all the related paraphernalia.
Hope that helps.
[ July 23, 2002: Message edited by: Ajith Kallambella ]

[Darryl Failla]

To me, it's just like so many other things in Java. The EntityBean interface provides a standard method of data retrieval and provides for some database housekeeping under the covers. The user never needs to be concerned with the dirty details.

[Rishi Tyagi]

IMO Entity beans are used at middle level in 3-tier development process.
One simple example of using the entity beans is online transaction.
When user starts the transaction at that time we pick the data from database in an entity bean and now during this transaction this entity bean will respond for every user requests ,
At the end of the transaction the data will be updated into the database and transaction will be closed.
Now it can be done by directly interacting with the database but use of beans at the middle level make the process faster as interacting with the database in our programs is always a time consuming task in comparison to entity beans.
Rishi

[John Arnold]

I don't really want to expand on anything any of the previous posters have had to say about what entity beans are, because they've covered that very well. I would like to pose a further question though - It seems to me that if encapsulation is the mechanism we use to hide the implementation of an object, this means that we combine the data and behavior of an object in a single concise interface. From where I'm sitting, entity beans are a violation of encapsulation (I'll probably catch hell for this). They're used to implement a representation of persistent objects, providing a data-centric aspect to the notion of an object. They provide getters and setters, finders, constructors, inserts and updates, but it ends there. While we can easily see the data aspects of these objects, take for instance, a Customer object, the entity beans really offer very little in the way of implementing the behavioral requirements (business logic)of the objects they represent. I also think that to implement business logic in an entity bean would be a total travesty of the notions of inheritance and well-designed class hierarchies.
Entity beans also require a lot of overhead, especially if using CMP.
My 0.02
Please enlighten me, I'm here to learn.
Thanks,
John

[Rishi Tyagi]

------------------------------------
It seems to me that if encapsulation is the mechanism we use to hide the implementation of an object, this means that we combine the data and behavior of an object in a single concise interface. From where I'm sitting, entity beans are a violation of encapsulation
-----------------------------------------
John,
Somewhere you are right here but see if i being a interface programmer have to read/update data from the database directly then i will directly interact with the database, may be i am good enough in front end programming but not in database programming then what will be the result may be i will write some error prone code which may affact to database directly. Now if there is some well tested middleware entity bean which interacts with database then i will have to call its methods only for interacting with the database and don't have to dive into the complex sql queries.
Ajith has written in his posting
--------------------
Entity beans represent object forms of persistent data. They are not a replacement for data storage itself. They simply map to one or more tables managed by your datastorage. Think of them as "tables in memory". Each entity bean instance would represent a row in the table.
--------------------------------------
He is absolutely right here as entity beans are the logical image of a table into memory, which hides the complexities of database programming and being a front end or interface developer we only have to interact with an object which is an image of the actual table. Also prevents us to write the database interaction codes again and again.
Rishi

[Murilo Beriam]

Hi guys!
There are many ways to implement the data persistence in Java. Sun's model JDO is a interesting one. Perhaps you want something closer to what you were used to. Try the open-source JDO-Like Castor. Enter http://www.castor.org

[Ruilin Yang]

Entity bean also enables your program to be more portable and maintainable.

[rajesh karmani]

Hello,
Well the biggest question Entity solves is the
O-R mapping. Coupled with this facility it provides transaction, instance pooling , synchronization etc. Entity beans are based on GoF's Template Pattern. They are slightly deviating from objected-oriented coz of their nature of being data store. But so is sql and relation database too. So the bridge comes in the form of O-R mapping component model.
Rajesh Kumar
SCJP2 (90%)
SCWCD (93%)
UML (79%)
J2EE (89%)

[Rishi Tyagi]

Murilo,
Could you please explain the term JDO, as a matter of fact i am not familier with this term, or could you please give some links where we can find some details about that.
Reagrds,
Rishi

[Rishi Tyagi]

This link may be usefull for the requirements of enterprise beans
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts2.html#62902
Rishi

[Harry Singh]

HI Gurus,
Thanks for the replies. and i call all u guys "GURUS" and rightly so.

[Fabrizio Gianneschi]

Originally posted by Rishi Tyagi:
------------------------------------
It seems to me that if encapsulation is the mechanism we use to hide the implementation of an object, this means that we combine the data and behavior of an object in a single concise interface. From where I'm sitting, entity beans are a violation of encapsulation
-----------------------------------------
John,
Somewhere you are right here but see if i being a interface programmer have to read/update data from the database directly then i will directly interact with the database, may be i am good enough in front end programming but not in database programming then what will be the result may be i will write some error prone code which may affact to database directly. Now if there is some well tested middleware entity bean which interacts with database then i will have to call its methods only for interacting with the database and don't have to dive into the complex sql queries.
...

I completely agree to both. In fact, there are several Design Patterns that helps EJB developers and designers to decouple data-business-container logic. For example, in our corporate we develop EJBs using these three patterns:
-Business Interface +
-Business Object: to separate business logic from container (ejb) logic
-Data Access Object (DAO): to separate business logic from database access logic.
Regards,

[Harry Singh]

The idea that i have got till now is that entity beans and object form of persistent data and hence entity beans should be in middleware, whereas all the business logic should be in session beans. correct me if i am wrong.
and can sum1 explain me about O-R mapping and how entity beans solve this. What is Castor?
Thanks in advance
Regards,
Harry