小弟翻译的， 希望大家喜欢，多指点，批评！
第一章
概述
企业级JavaBeans（EJB）是一种基于Java技术的组件结构，其目的是简化构建企业级分布式组件型应用程序。通过使用EJB，不用自行编写复杂的分布式组件的框架，便可写出可伸缩的、稳定的、安全的应用程序来。EJB是用来在服务器端快速开发应用程序的；通过利用由产业标准提供的现成的分布式底层结构，开发人员可以方便快捷的构建服务器端组件。EJB是一种可以向任何厂商提供企业级中间件服务，实现应用程序的可移植性和可重用性。
如果你是一个企业级软件开发的新手，接下来将会详细阐述上面提到的一些概念。EJB是一个复杂的话题，理应得到详细地说明。现在通过回答下面几个问题来介绍EJB。
1． 构造一个健壮的分布式对象部署，需要哪些组件？
2． 什么是EJB? 使用EJB的价值是什么?
3． 如果EJB是一个生态系统，那么在这个生态系统中演员是谁？
让我们思考一下上面这些问题。
EJB的目的
Figure1.1展示的是一个典型的商业应用程序。这样的应用程序可以用于任何门类的企业，能解决任何商业问题。这里有一些例子：
1． 股票贸易系统
2． 银行应用程序
3． 客户呼叫系统
4． 采购系统
5． 保障风险分析应用程序
可以看出每个程序都是一个分布式系统。我们通常把一个大型的，整体的应用程序分离成一层层的完全独立的、清晰的应用程序。
请看一眼这幅画，仅仅用你的个人经验和直觉：如果我们开发一个大型应用程序，并且把它分布在网络上的多个客户连接和多个服务器和数据库上，什么是我们目前需要考虑的问题。
请考虑一会，尽你所能列出你所想到的所有条款。然后再翻到下一页和我们为你列出的相比较。不要作弊！
构建大型商业系统时所需考虑的问题
到目前为止，当你构建一个大型商业系统时，你应该有一个恰当的需要考虑问题的清单。这是一个我们针对这个系统所提出问题的短小的清单。如果你目前仍不能明白所有这些也不要在意，你终会明白这些的。
1. 远程方法调用。我们需要能通过网络连接客户机与服务器的逻辑层。他包括发送方法需求，传递参数等。
2. 负荷平衡。客户端要尽量直接与服务器相连，以减轻负担。如果一个服务器过载，应有备用的服务器可供选择。
3. 清晰的自我排故系统。如果一台服务器死机了，或者发生了网络故障，客户端能够在不中断服务的情况下重新路由到其它服务器么？如果能，从故障开始能够多快解决？几秒？还是几分钟？对你的商业程序能接受么？
4. 后端整合。编写的代码要能将商业数据保存到数据库，也要能与现有的逻辑层整合。
5. 处理事务程序。如果两台客户机同时访问数据库的同一行数据会发生什么？或者服务器死机呢？处理事务程序能解决这些问题么？
6. 集群。当服务器死机时服务岂能保存包含的信息么？如果这些信息在所有的服务器上都有备份，客户端能利用另一台服务器么？
7. 动态部署。当站点还在运行时，你如何升级你的软件。你需要把机器关掉么，或者你可以让他一直工作。
8. 安全关机。如果你需要关掉一台服务器，你可以做得平缓，安全，而且不打断当前服务器为客户端的服务。
9. 日志与审计。如果发生了错误，有一个能让我们参考并找出错误原因的错误日志系统么？日志系统能帮助我们调试程序以保证程序不再发生同样的错误么？
10. 系统管理。如果发生不可挽回的错误，谁能监视我们的系统？我们希望发生灾难性错误时有一个监视软件能够帮我们记录所发生的一切。
11. 多线程。既然我们有多台客户机连接到服务器，那么服务器要有同时处理多个客户机需求的能力。这意味着应使用多线程的方法编写服务器端代码。
12. 信息导向中间层。当客户机与服务器可以轻松连接时，客户机需求应采用消息型。
13. 对象生命周期。活动于服务器端的对象应随着客户机需求的增加与减少相应的被创建与销毁。
14. 资源池。如果一个客户机当前没有使用一个服务器，服务器宝贵的资源就要被送进资源池，当其他客户机连接时再被使用。
15. 安全性。服务器与数据库需要保护不被人侵犯。用户只能进行自己权力范围之内的操作。
16. 高速缓冲。让我们这样假设，这里有一个数据库，像一般产品目录册，供所有的客户机共享与利用。为什么要你的服务器一次又一次的调用同一个目录册的数据呢？你可以把数据放在服务器的内存中，避免代价昂贵的网络带宽与数据库浪费。
17. 需要考虑的问题还有很多``` 很多``` 很多``````
上面的每一个问题对于服务器端编程都是要进行严肃的讨论的独立的服务。在任何产业与任何商业项目都需要考虑这些服务。每一个服务都需要考虑很多事情，一些管道进行疏通。所有这些服务统称为中间件。
在以前，多数公司会编写自己的中间件。例如,一个金融服务公司可能会编写一些中间件服务来帮助自己组建一个股票贸易系统。
如今，那些自己编写中间件的公司大多都失败了。因为创建和维护一个中间件的工作是极其复杂的，需要专家级的知识，几乎绝大多数公司都不能胜任。这样看来为什么不买一个而不是创建一个中间件呢？
应用程序服务商应运而生，你可以向他们购买你所需要的中间件服务，而不是你自行创建。应用程序服务商提供给你一些通用的中间件，如资源池、网络及其他中间件。应用程序服务商让你集中精力关注你的应用程序，而不用操心那些应该部署在服务器上的健壮的中间件。你只需编写企业的具体应用的代码，然后在选定的一个应用程序服务器运行环境下运行这个程序。只有把程序分解然后再一一攻克才能完成你的任务。
分解然后再一一攻克才能完成你的任务
我们刚刚讨论过你可以从应用程序服务商那里得到你所需的中间件，以使你更加专注的设计程序的本质逻辑。但这里有一个更好的消息，你可以买一些可以解决当前问题的中间件。
要做到这些，你需要用组件来构建应用程序。一个组件是一段实现一系列确定接口的程序代码。这些组件是可维护的，各自具有自己的逻辑。组件不是一个完整的应用程序，它们不能独自运行。它们主要用于解决大型问题的组成模块。
软件组件的思想非常重要。一个公司可以购买一些特定的模块解决一些问题，或者用它们和其他一些模块结合解决更大规模的问题。例如，有一个软件组件可以计算货物的价格。我们可以调用这个价格组件。你向这个组件输入一系列产品的价格，他就会计算出订单的总价。
关于价格的问题是相当危险的。例如，假设我们定购电脑配件，像内存和硬盘。价格组件按照一系列规则计算出正确的价格，这些规则如下所示：
1. 基本价格：单独内存升级或单独硬盘升级所需的价格。
2. 折扣量：用户定购10个以上存储单元后会有一定的折扣。
3. 套装折扣：用户成套定购内存和硬盘会有一定的折扣。
4. 大客户优惠：你可以给大客户一定的优惠。
5. 本地用户优惠：给本地用户以优惠。
6. 日常开支：像运费和税费。
对于订购电脑配件来说，这些价格规则不是唯一的方法。其他产业，如诊断系统、设备、机票系统，和其他用于报价的系统。显然，一个公司需要一个复杂的，久经考验的价格引擎，都需要从头编写代码，那将是巨大的浪费。因此，软件提供商提供一个能为不同的公司通用的价格组件是明智的。例如：
1. 美国邮政服务商可以用价格组件计算邮包的运费。如图Figure1.2所示。
2. 一个汽车制造商可以用价格组件为每辆车报价。这个汽车制造商可以建立一个网站，客户可通过Internet访问网站得到汽车的报价。Figure1.3为图示说明。
3. 一个在线购物系统可以用价格组件作为这个工作流程的一个个独立的模块。当一个客户在线订购了一件商品，这个价格组件首先计算出商品的价格。接着，提供商的另一个组件向各户提供已计算好价格的账单。最后，第三个组件完成订单，帮助服务商把商品派送给最终用户。在Figure1.4描述了这些情况。
可重用的组件是有相当的诱惑力的，因为它能加速应用程序的开发。一家IT商店能使用预先编写好的组件构建一个应用程序，而不是编写整个程序的代码。
这个IT商店不需要内部专家。对于这个IT商店，价格组件就像一个黑箱，它不需要专家编写复杂的价格算法。
这个应用程序可快速构建。组件供应商已编写好强壮的逻辑，IT商店可以利用此点来减少开发时间。
总成本下降。组件供应商靠卖组件来赚钱，因此如果组件用于商业，供应商会提供顶级的文档、支持、维护。因为组件提供商是这个领域的专家，所提供的组件比IT商店自己编写的解决方案有更少的Bug和更高的性能。这样会减少IT商店的维持费用。
一旦如何编写组件的雇佣规则建立起来，组件市场就诞生了，提供商们就可以向公司出售可重用的组件了。组件被部署在可以提供所需的中间件的应用程序服务器上。
组件市场是一个神话么？
目前只有一个小型的组件市场。我们希望过些年这个市场会膨胀，但它恐怕会预期的来得晚。独立软件提供商（ISVs）不会涉猎组件市场，有以下几个原因：
成熟。因为组件存活于应用程序服务商的服务器，在我们看到组件用于其他服务器前，这个应用程序服务商的程序首先应该成熟。
策略。许多ISVs编写他们自己的应用程序服务器。一些人（错误的）认为这是一个有竞争力的优点。
怀疑。许多ISVs都是客户需求驱动者（这就是说客户需要什么他们就提供什么）。因为组件对许多客户来讲都是新的，他们中许多都没要向ISVs提供组件需求。
我们的观点是组件市场最终会膨胀，这仅仅是个时间问题。如果你投身于一个ISVs，那么这将是一个诱人的机会。
一个好消息是这个市场已经开始启动了。大多数经营电子商务软件包的ISVs（Ariba、
Broadvision、Vignette等等）都涉猎或宣布支持服务器端的Java技术了。
与此同时，如果你必须编写你自己的组件。我们的一些中间件公司的客户也在努力，他们的一个部门可以向另一个部门提供组件。事实上，这些部门表演的是内部ISV的角色。
组件结构
多服务器部署的从出现到现在已经有好多年了。从那时起，市场中出现了50多个应用程序服务商。起初，每个应用程序服务商提供的组件是没有标准的、用的是自己的技术。发生这种情况主要因为没有一个组件应该是什么样子的定义。结果呢？就是一旦你看上了某个应用程序服务商，你的代码就锁定在这个提供商的解决方案内。这大大减少了可移植性，这对一直标榜开放和可移植的Java世界来说就像一个苦药丸卡在了喉咙里一样难受。这也阻碍了组件的商业性，因为一个客户为一个服务器编写一个组件，当他为另一个服务器编写组件时还要编写另一个组件。
我们多么希望有一个协议，或者应用程序和组件间的一套接口呀。这个协议可以使一切组件运行于一切服务器内。这样就可以使组件随意从应用程序服务器上添加或移出了，而不用必须改变代码或效能，甚至都不用从新编译了。这样的协议就被称为组件结构，如图Figure1.5所示。
如果你想以非技术的观点理解组件，可以试着这样类推：
因为有CD的标准，所以每台CD机都能播放所有CD碟片。试想一台应用程序服务器就像一台CD机，组件就像一张CD碟片。
在美国，因为有NTSC标准，每台电视机都能接收所有的广播信号。可以把一台应用程序服务器想成一台电视机，把组件想成电视节目信号。
