Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Persistence : third-party ORM's vs EJB 3.0 CMP

 
Stas Ostapenko
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Usage of EJB Message-driven and session beans IMHO is absolutely clear. But how about the Entity beans ? I know that many people avoided of usage Entity Beans. There are many other third-party ORM tools which are rather powerful and easier to study and use. What are pros and cons of Entity EJB's with comparison of third-party ORM tools ? How EJB 3.0 will change the situation ?
 
Mike Keith
author
Ranch Hand
Posts: 304
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The EJB 3.0 spec introduces the Java Persistence API. It is a new model for persistence that describes how to persist simple POJO entities using a standard Java API that is essentially a normalization of the existing persistence vendor APIs. Take a look for yourself and I think it will all be quite clear.

-Mike
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are far more reasons to avoid entity beans than just their kludgy implementation.
The theoretical implications of mapping a single database row to a memory entity like that is a major drawback. It's rare that you can (and should) create such a mapping, it's far more common to have a service that creates and maintains a whole network of database entities as a single logical entity. An entity bean is poorly designed to fit into such a scenario, requiring either mess workarounds (with entity beans maintaining other entity beans) or a system where you avoid them altogether.
 
Stas Ostapenko
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mike Keith:
It is a new model for persistence that describes how to persist simple POJO entities using a standard Java API that is essentially a normalization of the existing persistence vendor APIs.
-Mike


What are criterias of such normalization ? Standard is fine. The question is how the community will accept it. JDO was the standard too, but not much people had used it (sorry if i'm wrong). What are the persistence frameworks were considered by expert group ? I guess, Hibernate is the first(main) of them.

P.S. Thanks for your time to write a reply
 
Mike Keith
author
Ranch Hand
Posts: 304
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are criterias of such normalization ? Standard is fine. The question is how the community will accept it. JDO was the standard too, but not much people had used it (sorry if i'm wrong). What are the persistence frameworks were considered by expert group ? I guess, Hibernate is the first(main) of them.


The criteria was to evaluate the APIs and try to decide on 80-90% of the most commonly used features that people used. The community already has accepted it. JDO had many of the right ideas but was not an enterprise standard and not part of the J2EE platform. It did not have support from any of the major Java vendors so it did not get accepted by the mainstream developer community. JPA is THE enterprise persistence standard and is being endorsed and implemented by all the major vendors. JBoss (Hibernate), Oracle (TopLink), BEA, IBM, SAP, JDO vendors, virtually everyone that sells Java is supporting this and played a role in its development.
 
Richard Collins
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mike,

I just want a small clarification about all the Java Persistence API, if the persistence in EJB3 is done using POJO's are these POJO's considered as beans, and how are they getting mapped to the real columns in the Database.

Thanks,
Adam
 
Mike Keith
author
Ranch Hand
Posts: 304
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Adam,

The persistent POJO entities are not really considered Enterprise JavaBean components, although they may be simple Java beans. They are mapped to the database using the spec-defined O/R mapping model using annotations or XML.

-Mike
 
Richard Collins
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. I understand that the mapping could be done using Annotations, if we dont know the actual name of the Table or columns we use the @Table and @Column annotations with the name attribute.

Is it that the mapping for these table and columns need to be specified in a vendor specific file, if so can you please tell me which file is it for the Oracle Application Server.

Thanks,
Adam.
 
Merrick Schincariol
author
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Adam,

In many cases no vendor-specific file is required at all. I suggest taking a browse through the introductory chapter hosted on OTN or looking at the sample code. The mapping between objects and tables can be done using annotations, a standardized XML file or a mixture of the two.

Cheers,

Merrick
 
Richard Collins
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Merrick,

May be i should be a little patient to understand EJB 3.0, i am confusing it with EJB 2.1, I just not got a copy of your book, i'll go through it and see if I could get my doubts clarified.

Adam
 
Stas Ostapenko
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Additional metadata is handled by the annotations or XML configuration file, rigth ? I just want to compare one feature of my favorite ORM framework - Apache ObJectRelationalBridge (OJB). Is it possible in EJB 3.0 to change metadata at runtime ? For example we have a class that is mapped to table at rdbms_1. We need to migrate some data from rdbms_1 to rdbms_2. The class is the same, so the mapping is almost the same except the table name (it is requirement). In OJB i can enable "per-thread metadata changes" and do a little (or maybe not) change of metadata. How flexible EJB's metadata mechanism is ? Can I do the similar with EJB's ?
 
Merrick Schincariol
author
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can't change metadata on the fly, but when mapped using XML, you can map the same class multiple times to accomodate the case where you want to move data from one database to another, for example.

We provide examples of this in the book. Each set of mappings is associated with a name (the persistence unit), so you can reuse the same class across entity managers associated with different persistence units if the class is shared between them.

Cheers,

Merrick
 
Alexandros Stivaktatis
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting... in database lingo can this be seen as having different VIEWS on the data? Or am I misinterpreting.

Bye,

Alex
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic