EJB3.0,JPA,Hibernate之间的关系

[size=medium]1.EJB3.0和JAP之间的关系
EJB3.0是一份规范，该规范由不同的部分组成：
第一部分为session bean和message-driven bean定义了新的编程模型，以及部署规则等等；
第二部分专门定义了持久化相关的规范：实体,对象/关系映射元数据,持久化管理接口和查询语言。第二部分就是我们所说的JPA(Java Persistence API),之所以取名叫JPA，很有可能是因为持久化的接口位于javax.persistence.
所以，JPA是EJB的一部分，是EJB专门为持久化定义的规范。

2.Hibernate和EJB3.0之间的关系
首先你必须要了解的是，一个规范和一个产品是没有太多可比较性的，EJB3.0是java服务器端组件模型的一份规范，而hibernate是一个具体的产品，所以准确的提问应该是：[color=red]hibernate实现了EJB3.0的规范吗？[/color]

正如EJB3.0的规范划分成了不同的部分一样，EJB的实现者也有区分，有些产品完全实现了EJB3.0的规范，而有些产品只是实现了EJB3.0的一部分，比如仅实现了Java Persistence部分。
Hibernate就是这样的产品，它实现了Java Persistence那部分规范，不仅如此，而且它还提供了一些Java Persistence规范里面没有的一些功能。所以也可以说,JPA规范所对应的功能是hibernate的子集。

3.如何判断你使用的功能是JPA描述的还是hibernate自己特有的呢？
一个简单的方式就是检查你引入的包，如果你只使用了javax.persistence.*，那么你使用的功能是通用的JPA提供的，如果你的代码里还引入了org.hibernate.*，那么你就使用了hibernate专有的功能。

4.实现JPA的不仅仅只有Hibernate EntityManager,还有TopLink,OpenJPA.

5.JPA已经作为一项对象持久化的标准，不但可以获得Java EE应用服务器的支持，还可以直接在Java SE中使用。开发者将无需在现有多种ORM框架中艰难地选择，按照Sun的预想，现有ORM框架头顶的光环将渐渐暗淡，不再具有以往的吸引力。
[/size]


英文内容摘取自《Hibernate in action》(the second edition) 第1.4.4小节
[b]what exactly is the relationship
between Hibernate and EJB3, and what is Java Persistence?[/b]

[b]Understanding the standards[/b]
First, it’s difficult (if not impossible) to compare a specification and a product. The
questions that should be asked are, “Does Hibernate implement the EJB 3.0 specification,
and what is the impact on my project? Do I have to use one or the other?”
The new EJB 3.0 specification comes in several parts: The first part defines
the new EJB programming model for session beans and message-driven beans,
the deployment rules, and so on. The second part of the specification deals with
persistence exclusively: entities, object/relational mapping metadata, persistence manager interfaces, and the query language. This second part is called Java Persistence
API (JPA), probably because its interfaces are in the package
javax.persistence. We’ll use this acronym throughout the book.
This separation also exists in EJB 3.0 products; some implement a full EJB 3.0
container that supports all parts of the specification, and other products may
implement only the Java Persistence part. Two important principles were
designed into the new standard:
■ JPA engines should be pluggable, which means you should be able to take
out one product and replace it with another if you aren’t satisfied—even if
you want to stay with the same EJB 3.0 container or Java EE 5.0 application
server.
■ JPA engines should be able to run outside of an EJB 3.0 (or any other) runtime
environment, without a container in plain standard Java.
The consequences of this design are that there are more options for developers
and architects, which drives competition and therefore improves overall quality of
products. Of course, actual products also offer features that go beyond the specification
as vendor-specific extensions (such as for performance tuning, or because
the vendor has a focus on a particular vertical problem space).
Hibernate implements Java Persistence, and because a JPA engine must be
pluggable, new and interesting combinations of software are possible. You can
select from various Hibernate software modules and combine them depending on
your project’s technical and business requirements.

[b]Hibernate Core[/b]
The Hibernate Core is also known as Hibernate 3.2.x, or Hibernate. It’s the base
service for persistence, with its native API and its mapping metadata stored in XML
files. It has a query language called HQL (almost the same as SQL), as well as programmatic
query interfaces for Criteria and Example queries. There are hundreds
of options and features available for everything, as Hibernate Core is really
the foundation and the platform all other modules are built on.
You can use Hibernate Core on its own, independent from any framework or
any particular runtime environment with all JDKs. It works in every Java EE/J2EE
application server, in Swing applications, in a simple servlet container, and so on.
As long as you can configure a data source for Hibernate, it works. Your application
code (in your persistence layer) will use Hibernate APIs and queries, and
your mapping metadata is written in native Hibernate XML files.
Native Hibernate APIs, queries, and XML mapping files are the primary focus
of this book, and they’re explained first in all code examples. The reason for that
is that Hibernate functionality is a superset of all other available options


[b]Hibernate Annotations[/b]
A new way to define application metadata became available with JDK 5.0: type-safe
annotations embedded directly in the Java source code. Many Hibernate users are
already familiar with this concept, as the XDoclet software supports Javadoc metadata
attributes and a preprocessor at compile time (which, for Hibernate, generates
XML mapping files).
With the Hibernate Annotations package on top of Hibernate Core, you can now
use type-safe JDK 5.0 metadata as a replacement or in addition to native Hibernate
XML mapping files. You’ll find the syntax and semantics of the mapping annotations
familiar once you’ve seen them side-by-side with Hibernate XML mapping
files. However, the basic annotations aren’t proprietary.
The JPA specification defines object/relational mapping metadata syntax and
semantics, with the primary mechanism being JDK 5.0 annotations. (Yes, JDK 5.0
is required for Java EE 5.0 and EJB 3.0.) Naturally, the Hibernate Annotations are
a set of basic annotations that implement the JPA standard, and they’re also a set
of extension annotations you need for more advanced and exotic Hibernate
mappings and tuning.
You can use Hibernate Core and Hibernate Annotations to reduce your lines
of code for mapping metadata, compared to the native XML files, and you may
like the better refactoring capabilities of annotations. You can use only JPA annotations,
or you can add a Hibernate extension annotation if complete portability
isn’t your primary concern. (In practice, you should embrace the product you’ve
chosen instead of denying its existence at all times.)
We’ll discuss the impact of annotations on your development process, and how
to use them in mappings, throughout this book, along with native Hibernate XML
mapping examples.


[b]Hibernate EntityManager[/b]
The JPA specification also defines programming interfaces, lifecycle rules for persistent
objects, and query features. The Hibernate implementation for this part of
JPA is available as Hibernate EntityManager, another optional module you can
stack on top of Hibernate Core. You can fall back when a plain Hibernate
interface, or even a JDBC Connection is needed. Hibernate’s native features are a
superset of the JPA persistence features in every respect. (The simple fact is that

Hibernate EntityManager is a small wrapper around Hibernate Core that provides
JPA compatibility.)
Working with standardized interfaces and using a standardized query language
has the benefit that you can execute your JPA-compatible persistence layer with
any EJB 3.0 compliant application server. Or, you can use JPA outside of any particular
standardized runtime environment in plain Java (which really means everywhere
Hibernate Core can be used).
Hibernate Annotations should be considered in combination with Hibernate
EntityManager. It’s unusual that you’d write your application code against JPA
interfaces and with JPA queries, and not create most of your mappings with JPA
annotations.


[b]Java EE 5.0 application servers[/b]
We don’t cover all of EJB 3.0 in this book; our focus is naturally on persistence,
and therefore on the JPA part of the specification. (We will, of course, show you
many techniques with managed EJB components when we talk about application
architecture and design.)
Hibernate is also part of the JBoss Application Server (JBoss AS), an implementation
of J2EE 1.4 and (soon) Java EE 5.0. A combination of Hibernate Core, Hibernate
Annotations, and Hibernate EntityManager forms the persistence engine of
this application server. Hence, everything you can use stand-alone, you can also
use inside the application server with all the EJB 3.0 benefits, such as session
beans, message-driven beans, and other Java EE services.
To complete the picture, you also have to understand that Java EE 5.0 application
servers are no longer the monolithic beasts of the J2EE 1.4 era. In fact, the
JBoss EJB 3.0 container also comes in an embeddable version, which runs inside
other application servers, and even in Tomcat, or in a unit test, or a Swing application.
In the next chapter, you’ll prepare a project that utilizes EJB 3.0 components,
and you’ll install the JBoss server for easy integration testing.
As you can see, native Hibernate features implement significant parts of the
specification or are natural vendor extensions, offering additional functionality if
required.
Here is a simple trick to see immediately what code you’re looking at, whether
JPA or native Hibernate. If only the javax.persistence.* import is visible, you’re
working inside the specification; if you also import org.hibernate.*, you’re
using native Hibernate functionality. We’ll later show you a few more tricks that
will help you cleanly separate portable from vendor-specific code.