Chapet1 什么是EJB 3.0

    有一天，当上帝在看他的创造物（人类）的时候，他注意到一个叫Sadhu的人，Sadhu、的幽默和聪明让上帝很开心，所以上帝就慷慨的给了Sadhu三个实现三个愿望的机会。

正在装载数据……

因此Sadhu向上帝说出了自己的愿望，他的三个愿望是想让上帝让自己变成三种替身，第一个是瓢虫，第二个是大象，第三个是牛。上帝被对他的三种愿望很惊奇，让Sadhu来解释一下为什么要这样的愿望。Sadhu回答到：想变成瓢虫的原因是我想让世界上的每个人都赞美我的美丽并且原谅我不工作的事实，想变成大象的原因是我可以大口的吃东西而不会被别人讥笑，想变成牛是因为牛被所有人喜爱并且牛对人有用。上帝被他聪明的回答给折服了，并且立即允许Sadhu在这三种化身之间生活。然后他把Sadhu变成了自己的启明星来像牛一样为人类服务。

    同样的是EJB也在三种化身之间存在，当EJB一开始发布的时候，业界被它的创新部分所倾倒，但是就像瓢虫一样，EJB1功能有限，第二版的EJB就如同我们喜欢的厚皮动物，功能前大，但是如果没有相当的勇气和大象般的力气是很难征服EJB2.0的复杂，最后，EJB的第三种化身比之前的版本更加有用，就像一位为了印度教献身的绅士的牛，或者说像一位哺育我们长大的母亲。

    为了能使EJB3能足够的简单和轻便而不用耗费大量的Enterprise-ready能量，很多人付出了艰辛的努力。EJB 要比POJO要更加的小，就像我们在Hello world里看到的程序那样，我们希望你能同意我们将要介绍的这个明日之星。

    我们努力保持本书能足够的朴实并且不跳过任何的内容，这本书帮助我们学习很容易的学习EJB3.0。同时，我们不会忽略一些基础的东西，在必要的时候我们也会深入的水平面以下来展示一些让我们可以惊奇的东西或者给出一些可能发生问题的警告。

    这本书的内容对java世界来说相当的重要并且有独一无二的影响力，特别是基础理论的演化，我们假定你没有通过任何书学习过EJB2的相关内容，但是也有可能你已经完全的认识了EJB2.x或者对这个领域完全是个新手。不管是那种情况，在之前的版本上花费过多的时间在我们认为都是浪费，你不用对EJB2和EJB3之间没有很多的相同点而感觉过分的惊奇。如果你还是对我们这里的观点保有任何的怀疑的话，不要犹豫，拿起来一本关于EJB2的书来，你可以自己来找答案。

    本章的目的是要告诉我们在EJB3.0里边到底有什么东西，为什么我们要考虑用它，并且，相对于EJB2.x来说的我们概括说明了这些新东西，然后在下一章我们将会跳到一些代码上去。有了这些目标在大脑里，让我们开始EJB的愉快旅行吧。

    1．1 EJB概览

    直接的说EJB（Enterprise Java Beans）是一个能够构建可移植的，可复用的，可升级的商用开发平台，就如同java语言本身一样。从第一版开始，EJB就被吹捧为一个组件模型，用来构建企业级的java程序而不用去重新构建很多服务比如事务，安全，自动化和数据持久等服务。EJB允许开发人员集中他们的经历在逻辑部分，而不用去花费时间来构建一些基础的代码。从开发人员的角度来看EJB的话，EJB就是一段在一种被称作EJB container的环境里执行的java代码，这个环境提供了很多的组件服务。持久化的服务被一种称为Persistance Provider的框架提供，在本章的第三小结我们会继续讨论很多的关于EJB container和persistance provider的内容。

    在这个小节，我们将会看到EJB函数如何扮演组件和框架两种角色的，并且我们也会详细的分析EJB如何使自己适用于构建分层架构的应用。本章我们将会通过为什么EJB适合的我们的原因来不断的向前。

    1.1.1作为组件的EJB

    在这本书里，当我们讨论EJB的时候，我们讨论的核心是服务器端的组件，就如同你可以用来作为你的应用程序一部分来使用的组件，比如我们构建业务逻辑和持久化的代码。我们当中的很多人很自然的会把组件和开发复杂和繁重的CORBA，Microsoft的Com+代码联系起来。在EJB3.0的新世界中，组件其实就像它自己那样—一种更加强大的POJO。更为重要的是，它有些在平时我们看不到的强大之出，在我们确实需要的时候，我们才会发觉。通过第二章你可以看到这些强大之处。

    组件的真实含义是：它必须有效的封装应用程序的行为，让使用组件的客户不用去考虑组件的具体的实现的细节。所有使用者唯一需要关心的是调用组件的方法时传入的参数和将会返回的结果。

    有三种类型的EJB组件：Session beans，Message Driven beans，和Entities。Session beans，Message Driven beans用来构建商业逻辑，而Entities用来构建持久曾层。

    组件能被复用，举例来说的话，比如你要负责构筑一个在线图书销售网站。你需要开发一个模块来对客户的信用卡进行check，并且这只是一个普通的Java对象。你的网站运作良好，然后你过着舒服的生活。然后公司决定转型并且开发一个销售CD和DVD的网站，但是新的网站的发布环境和之前的不一样，他们不在相同的服务器上。构建这个系统的人必须被迫拷贝你的代码到他要构建的服务器上去，因为没有简单的方法可以访问你的模块（这里我必须说得是，其实通过web service还是可以办到的）。但是如果我们能像图示那样开发EJB版本的信用卡check模块，那么对其他人来说要访问信用卡check模块就变得非常的简单了。她只需要简单的对需要的方法进行调用，并且她不需要去理解如何实现就可以很容易的复用一个功能模块。

    1.1.2EJB作为框架

    就像我们提到的那样，EJB组件存在于容器中，并且，组件或者EJB，和容器可以被看作是框架，这个框架提供了我们在构建应用程序中的一些很有价值的服务。

    尽管很多人认为EJB用来构建简单的web应用程序太过庞大，但是我们认为这就是事实。当我们盖房子的时候，我们不会自己做所有的事情。相反，我们买来材料或者一些合同商提供的我们需要的服务。让我们自己做所有的事情来盖房子那是很不现实的，很多服务器段的应用程序都有一些共同点，包括提取商业逻辑，管理应用程序状态，从关系数据存取或者查询数据，事务管理，安全，并发处理，系统集成等等。

    作为一个框架，EJB容器通过一个盒子来提供这些服务，因此你的EJB组件就可以方便的使用而不用去重复的发明轮子。作为例子，让我们假设我们需要构建一个信用卡check的模块在我们的web应用程序上，我们写了非常多的复杂的并且有出错可能的代码来管理事务和处理安全访问控制。当然你可以拒绝EJB容器提供的事务和安全服务，这些服务，就如同我们将要在第三小节学到的那些，在我们的EJB组件中是完全可用的，只要我们的EJB组件部署在EJB容器里。在这一天结束的时候，这也意味着我们有比我们想象中快的速度写出了高质量，功能强大的应用程序。

    容器通过一种很优雅的方式因为EJB组件提供服务：在容器中部署EJB的时候，声明metadata来预定义EJB来添加服务的类型。Java5引入了metada定义，metadata是属性设置，通过它我们标示一段代码或者类或者方法具有特殊的属性。Metadata是一种称作是声明式的编程方式，通过这种方式，开发者指定了当系统添加这些代码的时候EJB组件该做什么。

    在EJB中，metadata极大的简化了应用程序的开发和测试，而不用依靠外部的xml配置文件。它允许开发者在需要的时候通过声明式添加服务到EJB组件。通过metadata我们可以很容易的把简单的POJO转换成EJB。

    以后我们就会看到，metadata在EJB中有很广泛的使用，而不仅仅使用在指定服务上，比如，我们可以使用metadata来指定EJB组件的类型。

    尽管有时候我们很容易忘记，但是企业级的应用程序和盖房子还有相同的一点，他们都会延期。为了让软件有高性能，错误处理，可扩展，我们就必须在开发前就考虑而不是在开发结束后才来考虑，这也就意味着我们不仅仅要很快写出服务端的应用，我们要能预见到你的平台能不断向前兼容。当我们在需要增加支持的用户的时候，我们必须不用重写我们的代码。令我们高兴得是这些问题是EJB容器的提供商关注的，通过把我们的组件移动到一个分布式，clustered服务器上，我们只需要作一点点地配置就可以达到我们的要求。

    最后但不是最终，整个世界的业界都在为SOA疯狂，互操作的EJB允许我们的应用程序很容易的转变成功能更加强大的web服务，在我们需要的时候。

    EJB框架是一个有公开说明书的标准java技术，如果你有兴趣，你可以去JPC 网站了解详细的信息。这对我们意味着什么呢？也就是说有很多在努力工作来支持EJB和让它保持兼容，从一方面说很多人都在不断的努力工作来让他们的EJB更加强大，从另外一方面说你必须选择合对你的应用程序详细的设计来让它能够和不同的开发上的EJB容易兼容。

    我们已经从高层讨论了EJB，接下来让我们把目光转向如何使用EJB来构筑层次系统。

    1.1.3层次架构和EJB

    很多企业级的应用程序包含很多的组件，企业级的应用程序被设计用来解决客户端独特的问题，但是他们通常都共享一些功能模块。例如，很多的企业应用程序有相当的用户接口，用来处理业务，模块化问题域，后者保存数据，因为这些相同点，你可以遵循一些普遍的架构或者设计模式来构建企业级应用，这就是我们所说的模式。

    对服务器端的开发来说，这个部分的模式就是layered architecture。在一个层次结构中，组件被分组成层次，每个层都有定义好的功能，就如同工厂里的集成生产线一样。集成生产线的每一个生产线都负责自己定义的处理，然后将剩下的任务传递到下一个生产线去。在层级架构中，每一层都会委托工作给靠近它的下一层。

    EJB的松散结构允许我们使用两种方式的层次架构—传统的四层架构和Domain Drive Design。接下来我们详细的看看着两种结构。

    Traditional Four Tier Layered Architecture：如同图示那样，四层架构很符合人们认识问题的知觉并且很受欢迎。在这个架构中，表现层负责显示图形用户界面和处理用户输入。表现层把用户的请求传递到业务逻辑层。 

    业务逻辑层是应用程序的核心部分包含了工作流和逻辑处理。或者说，业务逻辑层组件区分了应用程序可能的动作和处理，比如订单处理，查询，预定处理，用户帐户管理等等。

    业务逻辑层从persistence层获取数据或者通过使用persistence层来向数据库保存数据。

    Persistence 层提供了对数据库层的oo抽象。

    数据库层由关系型数据库构成，比如oracle或者db2或者sqlserver。

    很明显EJB不是表现层的技术，EJB对构建业务逻辑层和持久层提供了强劲的支持，如下图所示。

    在第三小节，我们会详细的讨论EJB服务，在第二小节，我们会展示EJB bean的类型。而现在，我们只需要知道在我们的业务逻辑层我们使用被称作Session Beans和Message Driven Beans的bean类型，bean类型调用在持久层的Entities来为其提供服务。

    四层结构具有很大的历史意义，但是它也有不足的地方，也就是说不完美。有一点经常被人们拿来指责的就是传统的四层结构破坏了OO观念中的模块化业务逻辑层为对象，这些对象既包含数据，也包含行为。因为传统的四层架构集中于处理模块化业务处理而不是特定的域，所以业务逻辑层看起来如同被数据库驱动的过程应用程序而不是面向对象的概念那样。持久层都是简单的数据持有者，他们看起来如同数据库里的数据集合一样，而不像是OO世界的class居民。Domain Driven Design的目的就是给我们提供了可选择的一种架构来解决上边的问题。

    Domain Driven Design：这个术语可能听起来比较新但是这样的概念并不新。Domain Driven Design强调domain对象应该包含业务逻辑而不因该是简单的数据库记录的替代物。Domain object就是我们说的Entities，我们会在第二小节讨论它。有了DDD，交易应用中的Catalog和Customer对象就是可能包含业务逻辑的entities的实例。

     在他的书POJO IN Action中，作者Chris Richardson指出domain object作为数据集的问题。

    一些开发者仍然认为持久化的对象就是简单的从数据库读取和存储数据的业务逻辑，这样的开发者被Fowler称作为“anemic domain model”即贫血的业务对象。这样的对象只有一个高级的业务对象模型但是继承这些抽象模型的类很少或者根本都没有任何行为。

    DDD的价值变得很明显，但是直到EJB的发布，DDD这种模型却很难被业界很好的执行，Chris接着解释了EJB2如何鼓励开发者开发基于过程的代码。

    诚然，使用EJB2.x来解决一些现实领域的模型问题时不现实的，因为beans不是POJO并且EJB2根本不支持很多OO的特性，比如继承和多态。Chris指出了entity beans的这个问题：EJB2的entity beans，它的设计目的是表示业务对象，但是因为有一些限制使得它很难去扩展来当作持久对象模型使用。

    好的消息是EJB3.0使得我们很容易遵守面向对象的设计和DDD。JPA entity现在是POJO并且支持良好的OO特性比如继承和多态。通过EJB3的JPA我们就很容易派生出持久对象模型。更为重要的是，你可以很容易的在你的实体里添加业务逻辑，因此，使用EJB3来派生rich domain model不是很有意义。

    很多人都不喜欢在domain object中添加复杂的业务逻辑，而是喜欢创建一个称作service layer或者application layer的层来处理业务逻辑。Application layer是比传统的四层结构中的业务逻辑层更加薄的一个层次。不用惊讶，你可以使用Session Beans来构建服务层，无论你使用传统的四层架构或者DDD，你都可以使用Entity来对业务域对象建模，包括对状态建模和行为建模。我们将会在第七章详细的讨论。

    尽管EJB3的服务和vision令人印象深刻，但是EJB的目标不只这些。你可以把很多技术和EJB3组合使用，这些技术或多或少有和EJB服务和基础结构吻合的地方。比如你可以使用Spring或者其的开源技术比如Hibernate和AspectJ来构建应用程序，所以为什么是EJB3呢？很高兴你会这么问，接下来我们将要揭示原因。

    1.1.5为什么选择EJB3？

    在本章的开始，我们暗示EJB现在的状态是做为技术先导者，EJB是一项开天辟地的技术，带动了服务端标准的发展。就像java本身一样，EJB使很多事情发生变化，并且还促进了自己的革新。实际上，直到最近几年，唯一对EJB构成竞争威胁的也只有Microsoft的.Net.。

    在这一章，我们将会指出EJB3的一些引人注目的特性，这些特性我们觉得很确定因为在EJB的后续版本中这些特性很有可能在你的候选名单中。

    感谢他们坚定的将中心集中于易用性上，EJB3可能是服务器端开发平台最容易使用的。最耀眼的特性应该就是POJO编程，是对冗长的XML的革新，更多的使用sensible default，和JPA，这些在这本书里都能学到。尽管有很多的特性我们需要了解，但是你会发现EJB的服务是很容易学习的，就如同我们平时经常使用的模式一样复杂。更为重要的是，EJB3基于实践来构建，并不要求你是个计算机科学家需要了解所有的EJB的详细细节才能使用。实际上，EJB服务的设计的目标就是要打破上边提到的那样，我们可以将注意力集中在我们需要做的工作上，在每天结束的时候我们就会明白今天我们完成了一些事情。

    EJB3的目的是提供给我们完整的解决方案，包括持久化，轻量级的项目管理，远程调用，web服务，DI（dependency injection）和截获。这就意味着你不必花费很多的时候去寻找第三方的工具来集成到你的饮用程序中。另外，EJB3无缝集成其他的j2ee技术比如JDBC，JavaMail，JTA（Java Transaction API），JMS（Java Meessage Service），JAAS（Java Authentication and Authorization Service），JNDI（Java Naming and Directory Interface），Java RMI（Remote Method Invocation）等。并且EJB还和表现层的技术比如JSP，Servlets，JSF和Swing无缝集成。

    EJB是JAVA EE 标准中最重要的一部分，如果你使用JAVA EE，那么这就是最需要我们抓住的概念。EJB3是一个公共，公开的API定义，任何企业和公司都被鼓励创建一个容器或者提供具体的实现。EJB3标准由JCP发展，这个组织由一些相互协作的个人共同推动发展，公开的标准吸引更为广阔的供应商的支持，这也就意味着EJB3比起来一些特殊的解决方案更加适合我们。

    EJB被一大批不同的相互独立的组织支持。这里边包括一些大的，负责任的并且及其富有的公司比如Oracle和IBM以及一些热心的且富有活力的开源组织比如JBoss和Geronimo的支持。广阔的厂商支持有三点重要的事实。第一你不会被一个公司或者一些人牵着鼻子走。第二很多人在集中力量来保持这项技术富有竞争力。你可以一直获得这项技术最新的发展。第三提供商从历史的观点来看都有竞争的意识，所以他们会不断的添加新的非标注的特征到这项技术。所有这些都促成了EJB这项技术在沿着健康的方向发展。