从上面的代码，我很能体会到Context所代表的意义：公用信息、环境、容器....。所以我觉得Context翻译成上下文并不直观，按照语言使用的环境，翻译成“环境”、“容器”可能更好。                                                                        (转)

1. 概述
   随着web应用的增多，新的模式解决方案中以web为核心的应用也越来越多， 很多公司各种应用的架构都以B/S及web应用为主，但是有关WEB测试方面的内容并没有相应的总结，所以我在这里对web的测试方法和采用的测试技术进行总结，便于内部交流。
   测试方法尽量涵盖web程序的各个方面，测试技术方面在继承传统测试技术的技术上结合web应用的特点。
   相关的测试和实现技术也有着很大的关系，由于本公司使用J2EE体系，也许例子中只有JAVA平台可以使用，.NET平台测试技术暂时不涉及，如果你有请与我联系。
2. 测试方法
说明：测试方法的选择取决你的测试策略。
   一般的web测试和以往的应用程序的测试的侧重点不完全相同，基本包括以下几个方面。
   当然圆满的完成测试还要有好的团体和流程等的方方面面的支持，你同样应该对这些方面进行注意。
   有些测试方法设计到了流程，哪些应该在你的测试团队建设中建立。

2.1 界面测试
   现在一般人都有使用浏览器浏览网页的经历，用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试，那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分，但是恰恰相反界面对不懂技术的客户来说那相当关键，慢慢体会你会明白的。
   方法上可以根据设计文档，如果够专业的话可以专业美工人员，来确定整体风格页面风格，然后根据这个可以页面人员可以生成静态的HTML，CSS等甚至生成几套不用的方案来讨论，或者交给客户评审，最后形成统一的风格的页面/框架。注意不要靠程序员的美术素养形成你的web风格，那样可能会很糟糕。
主要包括以下几个方面的内容：
站点地图和导航条 位置、是否合理、是否可以导航等内容布局 布局是否合理，滚动条等简介说明 说明文字是否合理，位置，是否正确
背景/色调 是否正确、美观，是否符合用户需求；
页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）表单样式 大小，格式，是否对提交数据进行验证（如果在页面部分进行验证的话）等
连接 连接的形式，位置，是否易于理解等
   web测试的主要页面元素
页面元素的容错性列表（如输入框、时间列表或日历）
页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
页面元素的容错性是否存在
页面元素的容错性是否正确
页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
页面元素是否显示正确（主要针对文字、图形、签章）
元素是否显示（元素是否存在）
页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
   测试技术
     通过页面走查，浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果，如果有影响应该交给设计人员提出解决方案。 
    可以结合数据定义文档查看表单项的内容，长度等信息。
    对于动态生成的页面最好也能进行浏览查看。如Servelet部分可以结合编码规范，进行代码走查。是否支持中文，如果数据用XM  封装要做的工作会多一点等等。

   界面测试要素:
符合标准和规范,灵活性,正确性,直观性,舒适性,实用性,一致性
   1.直观性:
   用户界面是否洁净,不唐突,不拥挤.界面不应该为用户制造障碍.所需功能或者期待的响应应该明显,并在预期出现的地方.
   界面组织和布局合理吗  是否允许用户轻松地从一个功能转到另一个功能  下一步做什么明显吗  任何时刻都可以决定放弃或者退回,退出吗  输入得到承认了吗  菜单或者窗口是否深藏不露   
   有多余功能吗  软件整体抑或局部是否做得太多  是否有太多特性把工作复杂化了  是否感到信息太庞杂   
   如果其他所有努力失败,帮助系统真能帮忙吗   

   2.一致性
   快速键和菜单选项.在Windows 中按F1键总是得到帮助信息
   术语和命令.整个软件使用同样的术语吗  特性命名一致吗  例如,Find是否一直叫Find,而不是有时叫Search   
   软件是否一直面向同一级别用户  带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息.
   按钮位置和等价的按键.大家是否注意到对话框有OK按钮和Canc  e按钮时,OK按钮总是在上方或者左方,而Canc  e按钮总是在下方或右方  同样原因,Canc  e按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter.保持一致.

   3.灵活性
   状态跳转.灵活的软件实现同一任务有多种选择方式.
   状态终止和跳过,具有容错处理能力.
   数据输入和输出.用户希望有多种方法输入数据和查看结果.例如,在写字板插入文字可用键盘输入,粘贴,从6种文件格式读入,作为对象插入,或者用鼠标从其他程序拖动.
   4.舒适性
   恰当.软件外观和感觉应该与所做的工作和使用者相符.
   错误处理.程序应该在用户执行严重错误的操作之前提出警告,并允许用户恢复由于错误操作导致丢失的数据.如大家认为undo /redo是当然的.
   性能.快不见得是好事.要让用户看得清程序在做什么,它是有反应的.

2.2 功能测试
   对功能测试是测试中的重点
主要包括一下几个方面的内容
   连接这个连接和界面测试中的连接不同那里注重的是连接方式和位置，如是图像还是文字放置的位置等，还是其他的方式。这里的连接注重功能。如是否有连接，连接的是否是说明的位置等。
   表单提交应当模拟用户提交，验证是否完成功能，如注册信息，要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证，异常处理等，最好结合易用性要求等。B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
   Cookies 验证 如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。关于cookie的使用可以参考浏览器的帮助信息。如果使用B/S结构cookies中存放的信息更多。功能易用性测试 完成了功能测试可以对应用性进行了解，最好听听客户的反映，在可以的情况下对程序进行改进是很有必要的，和客户保持互动对系统满意度也是很有帮助的。
   测试技术功能测试的测试技术可是很多的，我们可以结合实际环境选择使用
   白盒测试技术(White Box Testing) 深入到代码一级的测试，使用这种技术发现问题最早，效果也是最好的。该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，在JAVA平台使用Xunit系列工具进行测试，Xunit测试工具是类一级的测试工具对每一个类和该类的方法进行测试。
   黑盒测试技术（Black Box Testing）黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行，根据软件需求，设计文档，模拟客户场景随系统进行实际的测试，这种测试技术是使用最多的测试技术涵盖了测试的方方面面，可以考虑以下方面
     正确性 (Correctness)：计算结果，命名等方面
     可用性 (Usability)：是否可以满足软件的需求说明。
     边界条件 (Boundary Condition)输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等.
     性能 (Performance) 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了. 如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着
程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑到软件的性能问题
     压力测试 (Stress) 多用户情况 可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化(软硬件都可以).这里的压力测试针对的是某几项功能,.
     错误恢复 (Error Recovery) 错误处理，页面数据验证,包括突然间断电,输入脏数据等.
安全性测试(Security)这个领域正在研究中,不过防火墙,补丁包.杀毒软件等的就不必说了,不过可以考虑破坏性测试时任意.看了一些资料后得知,这里面设计到的知识\内容可以写本书了,不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的web更是,需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件是的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容.
     兼容性 (Compatibility) 不同浏览器，不同应用程序版本在实现功能时的表现,不同的上网方式,如果你测试的是一个公共网站的话.
   兼容性测试内容详述
   硬件平台
   浏览器软件和版本:浏览器插件,浏览器选项,视频分辨率和色深.文字大小,调制解调器速率.
     软件配置 (Configuration) 如IE浏览器的不用选项-安全设定最高,禁用脚本程序,等等,你们的程序在各种不用的设置下表现如何.

单元测试技术(Unit Test):
2.2.1 下面是对白盒测试和单元测试的区别的论述:
   单元测试和白盒测试是不同的,虽然单元测试和白盒测试都是关注功能虽然他们都需要代码支持,但是级别不同,白盒测试关注的是类中一个方法的功能是更小的单位,但是完成一个单元测试可能需要N多类,所以说作单元测试需要什么写驱动和稳定桩,比如查询单元是一个查询包包N多的测试类,测试数据,运行他需要提供数据的部分,输入参数和发出命令的驱动等等.是比类大的一个整体进行的.
   另一个明显的区别是白盒测试不会关注类接口,但是单元测试主要的内容就是类接口测试.
   不过很多时候是很少区分的,因为这两种技术实现起来有很多相互关联的部分.不过要看你对质量的关注程度来决定.
2.2.2 功能测试边界测试\越界测试技术详述
   边界条件
边界条件是指软件计划的操作界限所在的边缘条件.
如果软件测试问题包含确定的边界,那么数据类型可能是:
数值 速度 字符 地址 位置 尺寸 数量
同时,考虑这些类型的下述特征:
第一个/最后一个 最小值/最大值
开始/完成 超过/在内
空/满 最短/最长
最慢/最快 最早/最迟
最大/最小 最高/最低
相邻/最远
   越界测试
通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:
第一个减1/最后一个加1
开始减1/完成加1
空了再减/满了再加
慢上加慢/快上加快
最大数加1/最小数减1
最小值减1/最大值加1
刚好超过/刚好在内
短了再短/长了再长
早了更早/晚了更晚
最高加1/最低减1
   另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.
2.2.3 状态测试技术

   软件可能进入的每一种独立状态;
   从一种状态转入另一种状态所需的输入和条件;
   进入或退出某种状态时的设置条件及输入结果.

   具体测试方法可以参考如下:
   每种状态至少访问一次;
   测试看起来最常见最普遍的状态转换;
   测试状态之间最不常用的分支
   测试所有错误状态及其返回值
   测试随机状态转换
2.2.4 竞争条件测试技术
   竞争条件典型情形参考如下:
   两个不同的程序同时保存或打开同一个文档
   共享同一台打印机,通信端口或者其他外围设备
   当软件处于读取或者修改状态时按键或者单击鼠标
   同时关闭或者启动软件的多个实例
   同时使用不同的程序访问一个共同数据库

2.3 负载\压力测试(StressTest)
   在这里的负载\压力和功能测试中的不同,他是系统测试的内容,是基本功能已经通过后进行的.可以在集成测试阶段,亦可以在系统测试阶段进行.
   使用负载测试工具进行,虚拟一定数量的用户看一看系统的表现,是否满足定义中的指标.
   负载测试一般使用工具完成，  oadrunner，web  oad，was，ew  ，e-test等，主要的内容都是编写出测试脚本，脚本中一般包括用户一般常用的功能，然后运行，得出报告。所以负载测试包括的主要内容就不介绍了。
   负载测试技术在各种极限情况下对产品进行测试 (如很多人同时使用该软件，或者反复运行该软件)，以检查产品的长期稳定性。例如，使用压力测试工具对web服务器进行压力测试. 本项测试可以帮助找到一些大型的问题，如死机、崩损、内存泄漏等，因为有些存在内存泄漏问题的程序，在运行一两次时可能不会出现问题，但是如果运行了成千上万次，内存泄漏得越来越多，就会导致系统崩滑。用J2EE实现的系统很少但是并不是没有内存问题.
   无论什么工具基本的技术都是利用线程技术模仿和虚拟用户，在这里主要的难点在与测试脚本的编写，每种工具使用的脚本都不一样，但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。
   对负载工具的延伸使用可以进行系统稳定性测试，系统极限测试，如使用100的  oad Size连续使用24小时，微软定义的通过准则是通过72小时测试的程序一般不会出现稳定性的问题。

2.4 回归测试 (Regression Test)
   过一段时间以后，再回过头来对以前修复过的Bug重新进行测试，看该Bug 是否会重新出现。
   回归测试技术可以在测试的各个阶段出现，无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。
   回归测试的目的就是保证以前已经修复的Bug不会再出现。实际上，许多Bug都是在回归测试时发现的，在此阶段，我们首先要检查以前找到的Bug 是否已经更正了。值得注意的是，已经更正的Bug 也可能又回来了，有的Bug 经过修改之后可能又产生了新的Bug。所以，回归测试可保证已更正的Bug不再重现，不产生新的Bug。
2.5 A  pha 和Beta 测试 (A  pha and Beta Test):
   在正式发布产品之前往往要先发布一些测试版，让用户能够反馈出相关信息，或者找到存在的Bug，以便在正式版中得到解决。
   特别是在有客户参加的情况下，对系统进行测试可能会出现一些我们没有考虑的情况，还可以解决一些客户实际关心的问题

不同的测试技术区分
3.1 覆盖测试技术
说明:测试覆盖率可以看出测试的完成度,在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。
   覆盖测试可以是程序代码的执行路径覆盖，亦可以是功能实现的步骤覆盖（可以理解成流程图的路径覆盖）。
   该技术可以用在任何测试阶段，包括单元测坏死、集成测试、系统测试。
   使用该技术时可以使用以上的任何测试方法和测试技术。
3.2 白盒测试和黑盒测试技术
   白盒测试技术 (White Box Testing)该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段，开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主，使用Xunit系列工具进行测试，可以包括很多方面如功能性能等。
   黑盒测试 (Black Box Testing)测试的主体部分黑盒测试的内容主要有以下几个方面，但是主要还是功能部分。主要是覆盖全部的功能，可以结合兼容，性能测试等方面进行,包括的不同测试类型请参考以上内容。
3.3 手工测试和自动化测试
   手工测试（Manual  Testing）：即依靠人力来查找Bug。方法可以参考上边的测试，也可以根据对实现技术及经验等进行不同的测试。
   自动测试（Automation Testing）使用有针对工具实行。可以作出自动化测试的计划,对可以进行自动化测试的部分编写或者录制相应的脚本,可以加入功能,容错,表单提交等,可以参考MI,Rationa  或者其他类测试工具说明.
   根据权威的软件测试经验，手工测试还是主要的测试方法，自动测试不够灵活，在这里不再详述。微软的测试过程80％还是手工完成。
   自动测试永远也代替不了手工测试，但是手工测试的工作量很大是不争的事实。
3.4 根据RUP标准按阶段区分测试
   单元测试在上边有详细的叙述，还有针对单元测试和集成测试的论述，请参考。
   集成测试分为功能集成测试和系统集成测试，相互有调用的功能集成，在系统环境下功能相互调用的影响等，使用方法可以任意选用上面的内容。注重功能方面。
   系统测试在功能实现的基础上，可以加入兼容性，易用性，性能等等
   验收测试可以包括Alpha和Beta测试，在这里就不再详述。

4. 存在风险及解决方法
说明：测试不能找出所有的问题，只是尽量将问题在开发阶段解决大多数的问题而已。
测试风险如下：
   软硬件的测试环境提供上也对测试结果有很大的影响。
   测试团队的水平，经验，合作效果等
   整个开发流程对测试的重视程度，测试的进入时间等
   由于测试环境操作系统，网络环境，带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。
5. 软件缺陷的原则
   软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等
   软件未达到产品说明书标明的功能。
   软件出现了产品说明书指明不会出现的错误。
   软件功能超出产品说明书指明范围。
   软件未达到产品说明书虽未指出但应达到的目标。
   软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

6. 文档测试
   产品说明书属性检查清单
   完整.是否有遗漏和丢失  完全吗  单独使用是否包含全部内容   
   准确.既定解决方案正确吗  目标明确吗  有没有错误   
   精确,不含糊,清晰.描述是否一清二楚  还是自说自话  容易看懂和理解吗   
   一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突   
   贴切.描述功能的陈述是否必要  有没有多余信息  功能是否原来的客户要求   
   合理.在特定的预算和进度下,以现有人力,物力和资源能否实现   
   代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码   
   可测试性.特性能否测试  测试员建立验证操作的测试程序是否提供足够的信息   

   产品说明书用语检查清单
说明 对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.
   总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
   当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
   某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
   等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
   良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
   已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
   如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.

　　简化不是功能的减少

　　简化一个编程模型并没有减少它的功能。简化只是把复杂的逻辑隐藏到了框架代码或可重用的组件中去了。根本上，它是把复杂的东西从需要应用开发者直接管理的地方转移到了大多数开发者看不到的地方。

　　上述的模板和工具让初学者更容易上手，同时也提高了有经验的Java开发者的生产力，现在它们正在被JCP合并到下一代的Java EE标准中(比如:EJB 3.0)。由Java开发人员Raghu Kodali最近所做的研究显示:将Java EE的示例程序RosterApp从EJB 2.1转到EJB 3.0可以减少百分之五十以上的代码。

　　Java注释是EJB3.0背后的关键，它将POJO服务，POJO持久化和依赖注入一起绑定为一个完整的企业级中间件解决方案。这篇文章中，我使用了一个示例应用:JBoss EJB 3.0 TrailBlazer，来演示使用注释开发轻量级的EJB 3.0 POJO应用。TrailBlazer的应用使用EJB 3.0中不同的工具和API重复实现了一个投资计算器。示例程序完全可以在JBoss 应用服务器4.0.3版本中运行，并且与最新的EJB 3.0标准完全兼容(完成时)。

　　让我们来开始体验一下注释驱动编程模型的好处吧。

　　EJB 3.0的注释驱动编程模型

　　从开发者的观点来看，EJB 3.0广泛地使用了Java 注释.注释有两个关键优势:它们取代了过多的XML配置文件并且消除了严格组件模型需求。

　　注释 vs XML

　　基于XML的布署描述和注释一起都可以用来在Java EE应用中配置服务的相关属性。它们的区别在于:XML文档是与代码分开处理的，特别是在运行时刻，而注释是与代码编译在一起的并被编译器检查的。对于开发者来说这就有了一些重要的含义，正如我下面所列出的:

　　冗长:XML配置文件是出了名的冗长的。为了配置代码，XML文件必须复制许多信息:比如代码中类名字和方法名字。Java注释则不同，它是代码的一部分，不需要额外的引用就可以指明配置信息。

　　强壮性:在XML文件中重复的代码信息引入了多处龃淼目赡堋１热?如果你写错了方法的名字，那应用直到运行时刻才会出错垮掉。也就是说，XML配置文件的强壮性就不如注释，注释是被编译器检查的，并和其它代码一起被处理的。

　　灵活性:既然XML文件是在代码之外被单独处理的，那也就是说基于XML的配置信息不是“硬编码”的，是可以以后修改的。部署的灵活性对系统管理员来说是非常非常重要的特性。

　　注释是简单易用的，已证明对大多数应用来说足够了。XML文件更复杂，但能被用来处理更高级的问题。EJB 3.0允许你通过注释来配置大多数的应用。EJB 3.0也支持用XML文件来覆盖默认的注释，及配置像数据库联接这样的外部资源。

　　除了替换和简化XML描述符，注释也允许我们废除困扰EJB 1.x, EJB 2.x的严格组件模型。

　　POJO　vs 严格组件

　　EJB 组件是容器管理(container-managed)的对象。容器在运行时刻操作Bean的状态和行为。为了让行为发生，EJB 2.1规范定义了一个Bean必须遵守的严格的组件模型。每一个EJB类必须从某一种抽象类中继承，并为容器提供了回调的钩子。既然Java只支持单继承，严格组件模型就限制了开发者使用EJB组件创建一个复杂对象结构的能力。当把复杂的应用数据映射到实体 Bean中的时候，正如我们在第二部分中看到的，这会成为一个很大的问题。

　　在EJB 3.0中，所有的容器服务都可以通过使用注释的POJO应用来配置和交付。大多数情况下，并不需要特殊的组件类。让我们通过JBoss EJB 3.0 TrailBlazer示例看一下如何在EJB 3.0中使用注释。

　　开发藕合松散的服务对象

　　像Java EE这样的企业级中间件的一个最重要的好处是允许开发者使用藕合松散的组件来开发应用。这些组件仅仅通过他们自己发布的商业接口来藕合。因此这些组件的实现类可以在不改变应用其余部分的情况下改变自己的实现。这将会使应用更加强壮，更容易测试，更易移植。EJB 3.0使得在POJO中创建藕合松散的商业组件变得更简单了。

　　Session bean

　　在EJB 3.0应用中，藕合松散的服务组件的典型应用是Session Bean。一个Session Bean至少有一个接口(也就是:商业接口)，其它应用组件通过它获得服务。下面的代码为我们的投资计算器服务提供了商业接口。它只有一个方法，根据给定的起始年龄，终止年龄，增长率，月存金额，计算出总投资额。

public interface Calculator {
  public double calculate (int start, int end,
                double growthrate, double saving);
}

　　Session bean类简单地实现了商业接口。你必须通过使用Stateless或Stateful注释来告诉EJB 3.0容器这个POJO类是一个Session Bean。有状态(Stateful)的session bean在不同的服务请求间维护着客户的状态。相反地，对于无状态(Stateless)的session bean，每次的请求都是被随机挑选的session bean实例处理的。这些行为是与EJB 2.1规范中的有状态和无状态session bean的定义是一致的。EJB 3.0容器算出何时实例化Bean对象，并通过商业接口让其可用。下面是session bean实现类的代码:

@Stateless public class CalculatorBean implements Calculator {   public double calculate (int start, int end,                     double growthrate, double saving) {     double tmp = Math.pow(1. + growthrate / 12.,                           12. * (end - start) + 1);     return saving * 12. * (tmp - 1) / growthrate;   } }

　　你也可以为一个session bean指明多个接口-一个为本地客户服务，一个为远程客户服务。只要使用@Local和@Remote注释来区分。下面的代码片断显示了同时实现了本地和远程接口的CalculatorBean。如果你没有@Local和@Remote注释，session bean接口默认为本地接口。

@Stateless @Local () @Remote () public class CalculatorBean implements Calculator, RemoteCalculator {   public double calculate (int start, int end,                            double growthrate, double saving) {     double tmp = Math.pow(1. + growthrate / 12., 12. * (end - start) + 1);     return saving * 12. * (tmp - 1) / growthrate;   }   public String getServerInfo () {     return "This is the JBoss EJB 3.0 TrailBlazer";   } }

　　Session bean用户通过JNDI得到bean的一个存根(Stub)对象。容器所提供的存根对象实现了session bean的商业接口。所有针对存根的调用都被引向了容器，由容器调用相应的实现类中的接口。对于有状态的的session bean，你必须自己在客户端缓存存根对象，这样在每次的后续调用时，容器才知道要提供相同的的bean实例。下面的片断显示如何调用session bean.在后面，你将会学到获取存根对象的更简单的方法。

InitialContext ctx = new InitialContext(); cal = (Calculator) ctx.lookup(Calculator.class.getName()); double res = cal.calculate(start, end, growthrate, saving); Session bean生命周期的管理

　　为达到藕合松散的目的，应用把session bean实例的创建、缓存、销毁全部交给EJB 3.0容器(也就是，反向控制设计模式)。应用只和bean的商业接口打交道。

　　但如果应用需要对session对象更好的控制呢?比如说，应用可能需要在创建session bean的时候初始化数据库联接，而在销毁bean时关闭外部的联接。上述这些，你都可能通过在bean类中定义生命周期的回调方法来实现。这些方法将会被容器在生命周期的不同阶段调用(如:创建或销毁时)。通过使有下面所列的注释，EJB 3.0允许你将任何方法指定为回调方法。这不同于EJB 2.1，EJB 2.1中，所有的回调方法必须实现，即使这是空的。EJB 3.0中，bean可以有任意数量，任意名字的回调方法。

　　@PostConstruct:当bean对象完成实例化后，使用了这个注释的方法会被立即调用。这个注释同时适用于有状态和无状态的session bean。

　　@PreDestroy:使用这个注释的方法会在容器从它的对象池中销毁一个无用的或者过期的bean实例这前调用。同时适用于有状态和无状态的session bean.

　　@PrePassivate:当一个有状态的session bean实例空闲过长的时间，容器将会钝化它，并把它的状态保存下来。使用这个注释的方法会在容器钝化bean实例之前调用。适用于有状态session bean。

　　@PostActivate:当客户端再次使用已经被钝化的的有状态session bean时，新的实例被创建，状态被恢复。使用此注释的session bean会在bean的激活完成时调用。

　　@Init:这个注释指定了有状态session bean初始化的方法。它区别于@PostConstruct注释在于:多个@Init注释方法可以同时存在于有状态session bean 中，但每个bean实例只会有一个@Init注释的方法会被调用。这取决于bean是如何创建的(细节请看EJB 3.0规范)。@PostConstruct在@Init之后被调用。

　　另一个有用的生命周期方法注释是@Remove，特别是对于有状态session bean。当应用通过存根对象调用使用了@Remove注释的方法时，容器就知道在该方法执行完毕后，要把bean实例从对象池中移走。

@Stateful public class CalculatorBean implements Calculator, Serializable {     // ... ...         @PostConstruct     public void initialize () {         // Initializes the history records and load         // necessary data from database etc. // 初始化历史记录，并从数据库中装入必需的数据。     }          @PreDestroy     public void exit () {         // Save history records into database if necessary. // 如有必要则将历史记录保存至数据库中     }           @Remove     public void stopSession () {         // Call to this method signals the container         // to remove this bean instance and terminates         // the session. The method body can be empty. // 调用这个方法来通知容器将bean实例移除并中止session. // 这个方法可以为空。     }         // ... ... }

　  消息驱动bean

　　Session bean服务提供了同步调用的方法。另一个重要的藕合松散服务类型是一种通过进入的消息来触发的异步服务(比如:email或Java消息服务产生的消息)。EJB 3.0的消息驱动bean(MDB)是设计用来专门处理基于消息请求的组件。

　　一个MDB类必须实现MessageListener接口。当容器检测到bean守候的队列一条消息时，就调用onMessage()方法，将消息作为参数传入。MDB在OnMessage()中决定如何处理该消息。你可以用注释来配置MDB侦听哪一条队列。当MDB部署时，容器将会用到其中的注释信息。在下面的例子中，CalculatorBean MDB会在JMS队列queue/mdb有消息进入时调用。MDB解析消息，并根据消息内容计算投资。

@MessageDriven(activateConfig = {   @ActivationConfigProperty(propertyName="destinationType",     propertyValue="javax.jms.Queue"),   @ActivationConfigProperty(propertyName="destination",     propertyValue="queue/mdb") }) public class CalculatorBean implements MessageListener {   public void onMessage (Message msg) {     try {       TextMessage tmsg = (TextMessage) msg;       Timestamp sent =           new Timestamp(tmsg.getLongProperty("sent"));       StringTokenizer st =           new StringTokenizer(tmsg.getText(), ",");       int start = Integer.parseInt(st.nextToken());       int end = Integer.parseInt(st.nextToken());       double growthrate = Double.parseDouble(st.nextToken());       double saving = Double.parseDouble(st.nextToken());       double result =           calculate (start, end, growthrate, saving);       RecordManager.addRecord (sent, result);     } catch (Exception e) {       e.printStackTrace ();     }   }   // ... ... }

　　依赖注入

　　客户端与服务端必须有一致的基于字符串的名字。它没有在编译时得到认证或在布署时得到检查。

　　从JNDI返回的服务对象的类型没有在编译时进行检查，有可能在运行时出现转换(casting)错误。

　　冗长的查找代码，有着自己的try-catch代码块，在应用之间是重复的和杂乱的

　EJB 3.0，对任何POJO,提供了一个简单的和优雅的方法来解藕服务对象和资源。使用@EJB注释，你可以将EJB存根对象注入到任何EJB 3.0容器管理的POJO中。如果注释用在一个属性变量上，容器将会在它被第一次访问之前赋值给它正确的值。下面的例了演示了怎样把CalculatorBean无状态session bean的存根注入到CalculatorMDB MDB类中。

public class CalculatorMDB implements MessageListener {

  @EJB Calculator cal;
 
  // Use the cal variable
  // ... ...
}

　　注释如果被用在JavaBean风格的setter方法上时，容器会在属性第一次使用之前，自动地用正确的参数调用bean的setter方法。下面的片断演示了这是如何做的:

public class CalculatorMDB implements MessageListener {   Calculator cal;     @EJB   public void setCal (Calculator cal) {     this.cal = cal;   }     // Use the cal variable // 使用cal变量   // ... ... }

　　除@EJB注释之外，EJB 3.0也支持@Resource注释来注入来自JNDI的任何资源。下面的例子中，我演示了如何注入服务器端默入的TimerService和SessionContext对象，也演示了如何注入来自JNDI的命名数据库和JMS资源。

@Resource TimerService tms; @Resource SessionContext ctx; @Resource (name="DefaultDS") DataSource myDb; @Resource (name="ConnectionFactory") QueueConnectionFactory factory; @Resource (name="queue/A") Queue queue;

　　此外，你也可以把一个容器管理的持久化管理器(也就是，EntityManager-类似于Hibernate session对象)注入到EJB 3.0 POJO中。

　　把容器服务交给POJO

　　除了管理生命周期和访问藕合松散的服务对象外，EJB 3.0通过简单的注释也为POJO提供了运行时刻服务。

　　事务

　　最有用的容器服务可能就是事务管理服务，当应用出现失败或异常时，它保证了数据库的完整性。你可以简单地将为一个POJO方法申明它的事务属性。这样容器就可以在合适的上下文中运行这个方法。举例来说，下面的代码申明了容器在运行updateExchangeRate()时必须创建一个新的事务。当这个方法退出时提交事务。实际上，所有在updateExchangeRate()中被调用的方法都在此事务中运行，除非有特别申明。在updateExchangeRate()中的数据库操作要么全部成功，要么全部失败。

@Stateless public class CalculatorBean implements Calculator {   // ... ...   @TransactionAttribute(TransactionAttributeType.REQUIRED)   public void updateExchangeRate (double newrate) throws Exception {     // Update the database in a loop. // 在循环中更新数据库     // ... ...     // The operations in the loop must all be successful or     // the database is not updated at all. // 循环中的操作必须全部成功或者根本不更新。   } }

　　安全

　　容器也提供了安全服务来进行用户认证和根据用户规则来限制对POJO的访问。对每一个POJO来说，你可以通过使用@SecurityDomain注释为它指定一个安全域, 安全域告诉容器到哪里去找密码和用户角色列表。JBoss中的other域表明文件是classpath中的users.propertes和roles.properties。这样，对每一个方法来说，我们可以使用一个安全限制注释来指定谁可以运行这个方法。比如，下面的例子，容器对所有试图调用addFund()的用户进行认证，只允许拥有AdminUser角色的用户实际运行它。如果你没有登录或者没有以管理员的身份登录，一个安全意外将会抛出。

@Stateless @SecurityDomain("other") public class CalculatorBean implements Calculator {   @RolesAllowed()   public void addFund (String name, double growthrate) {     // ... ...   }   @RolesAllowed()   public void addInvestor (String name, int start, int end) {     // ... ...   }   @PermitAll   public Collection <Fund> getFunds () {     // ... ...   }     // ... ...   @RolesAllowed()   public double calculate (int fundId, int investorId,                                        double saving) {     // ... ...   } }

　　通用拦截器

　　事务和安全服务都可以被看作是容器管理的运行时刻拦截器。容器拦截了对EJB存根的调用，并在其上应用事务上下文或进行安全限制。

　　在EJB 3.0中，你可以自己写拦截器来扩展容器服务。使用@AroundInvoke注释，你可以将任意bean方法作为拦截器方法在任意bean方法之前和之后运行。下面的例子中，log()方法是一个拦截器，它计算和记录了其它bean方法的执行时间:

@Stateful public class CalculatorBean implements Calculator {   // Bean methods that are to be intercepted by "log()"   // bean方法将被log()方法拦截 //   // ... ...     @AroundInvoke   public Object log (InvocationContext ctx)                             throws Exception {     String className = ctx.getBean().getClass().getName();     String methodName = ctx.getMethod().getName();     String target = className + "." + methodName + "()";     long start = System.currentTimeMillis();     System.out.println ("Invoking " + target);     try {       return ctx.proceed();     } catch(Exception e) {       throw e;     } finally {       System.out.println("Exiting " + target);       cal.setTrace(cal.getTrace() + " " +                    "Exiting " + target);       long time = System.currentTimeMillis() - start;       System.out.println("This method takes " +                           time + "ms to execute");     }   }

　　那么，作为程序员的你，面对新的规范，该做哪些准备呢？

　　处理好架构问题

　　首先要确保你的架构可以利用持久性方面的标准及认可的设计模式。实际上，这可能需要改动你的应用程序，不过如果你期望应用程序能经得起时间的考验，那么进行这种投入是值得的。使用会话外观、数据访问对象（DAO）层或者服务层总是好主意，不过在这里它们都至关重要。如果你的应用程序已经使用远程实体构建而成——虽然这种做法并不常见，那么就需要重新设计架构。访问持久性对象之前，应当先部署可远程化服务层。如果要使用实体，它就应当完全是本地实体。

　　不过，使用本地实体不是目的，因为实体还为部署人员提供了为实体声明事务和安全需求的功能。EJB 3.0不允许任何这些属性在实体层面进行设定。相反，实体的运行环境将由调用者来确定，所以所需的任何事务或者安全环境将由负责封闭的J2EE组件来安装或者声明。

　　CMP应用程序

　　如果你已经是容器管理持久性（CMP）用户，那么你可能迫不及待地想获得新特性，希望抛弃无关的接口、不必要的bean代码以及繁琐的XML部署描述符，这些是与以前的实体bean开发相关的一些烦人问题。分别要扩展EJBObject和EJBLocalObject的远程和本地接口再也不需要了；现在实体只要实现普通Java接口（POJI）即可，如果它们选择这么做的话。

　　其次，你可能在想如何更容易地在容器中部署EJB，或者甚至根本不用部署，而是在独立环境中的容器外面进行测试。因为实体是具体的普通Java对象（POJO），你就可以像一直以来创建Java对象的方式那样，即使用new()来创建。

　　POJO应用程序

　　可以通过实体管理器（EntityManager）访问大部分新的持久性API。实体管理器可以注入到会话bean里面，或者用Java命名和目录接口（JNDI）进行查询。实体管理器代表事务的持久性上下文。一旦发现操作单元或者实体管理器管理的对象在事务结束后“很脏”，就会被写到外面的数据存储区。

　　应用程序可以通过抽取含有操作单元/会话工件（artifact）的代码，让自己不受全面变化的影响。这样一来，就可以通过可插入方式来获得所用的实际会话。定义会话、然后允许包围层把它与外界隔离开来，这类似EJB 3.0容器所采用的依赖注入范例（dependency injection paradigm）。应用程序中使用的所有资源应当采用这种模式。在EJB 3.0中，标准资源将由应用程序声明，随后在运行时被注入到bean里面。

　　采用标准特性

　　EJB 3.0的许多特性可以在TopLink存在已久的特性当中找到影子。只要使用这些特性，你就能够拥有EJB 3.0的功能，虽然API还没有完成。

　　查询就是这样一个方面，你现在可以开始使用EJB 3.0的特性。EJB 3.0查询可以从实体管理器获得，并且可以在上面执行。可以在你需要直接查询SLQ、并通过查询返回对象的少数情况下，创建本地SQL查询。

　　查询语言往往是造成迁移问题的根源，因为不编写实质性或者穷举性的转换分析工具，就很难实现自动转换。EJB查询语言这种合理、有效的方法可对关系查询语言进行抽象处理，将受益于新增的几项特性。现有的EJB查询语言仍可以适用，不过EJB查询语言方面的更多构件和功能将进一步改进查询语言。使用EJB查询语言编写查询将是明智之举，因为查询语言不会出现重大改变，除了功能上有所添加外。

　　继承

　　EJB 2.1从来没有指定真正的、自然的继承。实际上，只有在厂商不设置障碍的情况下才有可能实现继承，不过仍很难定义及管理。EJB 3.0却不会这样。由于具体的Java对象能够彼此继承，也用不着定义约束继承范围的方法，所以你能够创建任意深度及广度的实体继承层次。

　　目前可以通过TopLink Mapping Workbench或JDeveloper、映射Java对象的GUI工具以及用于映射对象的基于Java的API，获得同样的这种灵活性。现在你可以创建域模型（domain model），以遵守适合你应用程序的继承策略，而不必等规范发布。

　　乐观锁定

　　TopLink支持的乐观锁定（optimistic locking）模型现在将被采用到EJB 3.0模型里面。这种机制对应用程序非常有用，不仅仅是因为在读/写访问比通常为90：10的情况下，它可以大大提高性能；还因为它有助于获得现代系统所需的那种可扩展架构。业界的众多应用程序使用这种主要的锁定范例，来获得Web应用程序所需的可扩展性。只要使用简单方法：为每个乐观锁定的对象采用数据库列和对象版本字段，就很容易获得可移植性。

　　这种锁定带来了另外的好处：能够使用非连接模式的对象。只要把数据重新并入事务、然后通过乐观锁值验证已改动的对象是不是失效副本，就很容易支持在离线状态下改动数据和关系的功能。

　　对象－关系映射

　　想编写面向对象的Java程序，却把数据保存在关系数据库里面，这在以前是困扰应用程序开发的一个重大问题。

　　决定把用于对象关系映射的标准化元数据和语义添加到EJB 3.0内，这向实现下列功能迈出了一大步：让应用程序能够灵活地把应用程序放在不同数据库上面运行，甚至可以使用不同的持久性框架来进行运行。对象－关系映射标准的第一个阶段将包括如今人们用来映射域模型的几种最流行的映射方法，譬如数据转换和一对一及多对多关系等。随后还会添加“高级”映射方法。

　　Enterprise JavaBean (EJB) 是可重用的、可移植的 J2EE 组件。EJB 由封装业务逻辑的方法组成。譬如说，EJB 可能有这样的业务逻辑：包含了更新数据库中客户数据的方法。众多远程和本地客户端可以调用该方法。另外，EJB 在容器里面运行，这样开发人员只要关注bean里面的业务逻辑，不必担心复杂、容易出错的问题，譬如事务支持、安全性和远程对象访问等。EJB 作为普通Java对象（POJO）的形式来开发，开发人员可以使用元数据注释（metadata annotations）来指定容器如何管理这些bean。

　　EJB 包括三种主要类型：会话 bean、实体 bean和消息驱动的bean。会话bean执行独立的、解除耦合的任务，譬如检查客户的信用记录。实体bean是一个复杂的业务实体，它代表数据库中存在的业务对象。消息驱动的bean用于接收异步JMS 消息。下面，让我们进一步研究EJB 3.0规范中的这些类型。

　　一、会话bean

　　会话bean通常代表业务流程里面的操作，譬如“处理订单”。可根据对话状态的保持性，即有状态和无状态对会话bean进行分类。

　　无状态的会话 bean没有内部状态。它们不跟踪记录从一个方法调用传递到另一个方法调用的信息。因此，每次调用无状态的业务方法都独立于前一次调用，譬如计算税款或者运费。用某个应税值调用计算税款的方法时，对税款值进行计算并返回给调用方法，而不必保存调用者的内部状态供以后调用。因为这些bean并不保持状态，所以容器对它们进行管理就很简单。客户端请求无状态的bean实例时，可以从容器保持的无状态的会话bean 实例池当中接收一个实例。另外，因为无状态的会话 bean可以共享，所以容器可保持数量较少的实例为许多客户端提供服务。想指定Java Bean作为无状态的会话bean加以部署及管理，只需要为该bean添加注释@Stateless。

　　有状态的会话 bean在方法调用时可保持对话状态，譬如客户的网上购物车。客户开始网上购物时，可以从数据库中检索客户的详细信息。客户往购物车里面添加商品或者从里面删除商品、下订单等时调用的其他方法也可以使用这些详细信息。不过，有状态的会话bean是暂时性的，因为出现会话终止、系统崩溃或者网络故障后，状态不复存在。客户端请求有状态的会话bean实例时，就为该客户端分配一个有状态的实例，并为该客户端保持该组件的状态。要指定容器在某个方法完成后删除有状态的会话bean实例，只要为该方法添加注释@Remove。

　　会话 bean示例如下：

import javax.ejb.Stateless.*;
/*A simple stateless session bean implementing
the incrementValue() method of the * CalculateEJB interface.*/
@Stateless(name="CalculateEJB")
public class CalculateEJBBean
implements CalculateEJB
{
int value = 0;
public String incrementValue()
{
value++;
return "value incremented by 1";
}
} 

　　二、实体bean

　　实体bean是管理持久性数据的一个对象，有可能使用几个相关的Java对象，并可以通过主键实现惟一性。通过添加@Entity注释，可以把某类指定为实体bean。实体bean代表数据库中的持久性数据，如客户表中的一行或者员工表中的一条员工记录。实体bean还可以在多个客户端之间共享。譬如说，某个员工实体bean可以由多个客户端用于计算某员工的年薪或者更新员工地址。实体bean对象的特定字段可以成为持久性字段。实体bean中没有被@Transient注释标记的所有字段都被视为持久性字段。EJB 3.0的一个主要特性就是，能够使用元数据注释来创建包含对象/关系映射的实体bean。譬如说，想指定把实体bean的empId字段映射到 Employees表中的EMPNO属性，就要使用@Table(name="Employees") 来注释表名，使用 @Column(name="EMPNO") 来注释字段，如下面的例子所示。另外，EJB 3.0 的一个特性是，在开发期间可以方便地测试实体bean，因为现在使用 Oracle 应用服务器实体测试工具，就可以在容器外面运行实体bean。

　　实体 bean示例如下：

import javax.persistence.*;
import java.util.ArrayList;
import java.util.Collection;
@Entity
@Table(name = "EMPLOYEES")
public class Employee implements java.io.Serializable
{
　private int empId;
　private String eName;
　private double sal;
　@Id
　@Column(name="EMPNO", primaryKey=true)
　public int getEmpId()
{ return empId;}
　public void setEmpId(int empId)
{ this.empId = empId; }
　public String getEname()
{ return eName; }
　public void setEname(String eName)
{ this.eName = eName; }
　public double getSal()
{ return sal; }
　public void setSal(double sal)
{ this.sal = sal; }
　public String toString()
{StringBuffer buf = new StringBuffer();
buf.append("Class:")
.append(this.getClass().getName()).append(" ::")
.append(" empId:").append(getEmpId()).append(" ename:")
.append(getEname()).append("sal:").append(getSal());
return buf.toString();}
} 

　　三、消息驱动的bean

　　消息驱动的bean（MDB）为实现异步通信提供了一种比使用直接的Java消息服务（JMS）更简单的方法。MDB用于接收异步JMS消息。容器处理JMS队列和主题所需的大部分设置进程。它把所有消息发送给相关的MDB。MDB允许J2EE应用程序发送异步消息，随后这些消息由应用程序来处理。要把bean指定为MDB，需要实现javax.jms.MessageListener接口，并且用@MessageDriven注释该bean。

　　消息驱动的bean示例如下：

import javax.ejb.MessageDriven;
import javax.ejb.ActivationConfigProperty;
import javax.ejb.Inject;
import javax.jms.*;
import java.util.*;
import javax.ejb.TimedObject;
import javax.ejb.Timer;
import javax.ejb.TimerService;
@MessageDriven(
activationConfig = {
@ActivationConfigProperty(propertyName="connectionFactoryJndiName",
　propertyValue="jms/TopicConnectionFactory"),
@ActivationConfigProperty(propertyName=
"destinationName", propertyValue="jms/myTopic"),
@ActivationConfigProperty(propertyName=
"destinationType", propertyValue="javax.jms.Topic"),
@ActivationConfigProperty(propertyName=
"messageSelector", propertyValue="RECIPIENT = 'MDB'") } )
/** A simple Message-Driven Bean that listens to the configured JMS Queue or
Topic and gets notified via an * invocation of it's onMessage() method
when a message has been posted to the Queue or Topic.The bean
* prints the contents of the message. */
public class MessageLogger implements MessageListener, TimedObject
{
　@Inject javax.ejb.MessageDrivenContext mc;
　public void onMessage(Message message)
　{ System.out.println("onMessage() - " + message);
　try
　{
　String subject = message.getStringProperty("subject");
　String inmessage = message.getStringProperty("message");
　System.out.println("Message received\n\tDate:" + new java.util.Date()
+ "\n\tSubject:" + subject + "\n\tMessage:" + inmessage + "\n");
　System.out.println("Creating Timer a single event timer");
　TimerService ts = mc.getTimerService();
　Timer timer = ts.createTimer(30000, subject);
　System.out.println("Timer created by MDB at:"
+ new Date(System.currentTimeMillis()) +" with info:"+subject); }
　catch (Throwable ex)
　{ ex.printStackTrace(); }
}
　public void ejbTimeout(Timer timer)
　{ System.out.println("EJB 3.0:Timer with MDB");
　System.out.println("ejbTimeout() called at:"
+ new Date(System.currentTimeMillis()));
　return; }
} 

　　四、使用 EJB 3.0

　　EJB客户端是访问bean的应用程序。它不必位于客户端层上，但可以是独立的应用程序、Java服务器页面（JSP）、服务器小程序或者另一个EJB。客户端通过bean的远程或本地接口来使用EJB的方法，远程还是本地取决于客户端是在同一个JVM里面还是不同的JVM里面。这些接口定义了bean的方法，而bean类负责实际实现这些方法。客户端访问bean类的方法时，容器就会为bean生成一个代理，名为远程或者本地对象。远程或者本地对象接收请求后，交给相应的bean实例，并将结果返回给客户端。想调用bean的方法，客户端需要通过使用EJB部署描述符（deployment descriptor）里面定义的bean名称来找到该bean。在以下的示例中，客户端使用Context对象找到名为“Statelessejb”的bean。

　　EJB 客户端示例如下：

import javax.naming.Context;
import javax.naming.InitialContext;
/* A simple bean client which calls methods on a stateless session bean.*/
public class CalculateejbClient
{
public static void main(String [] args)
{
　Context context = new InitialContext();
　CalculateEJB myejb =(CalculateEJB)context.lookup
("java:comp/env/ejb/CalculateEJB");
myejb.incrementValue(); }
} 

    IDE：NetBeans IDE 6.0.1
    SERVER:Sun Application Server(9.0)

二、安装NetBeans

    我使用的是NetBeans IDE 6.0.1，大家可以从sum公司网站下载。安装过程很简单，只需要点“下一部”就 OK了，需要注意的就是在选择要安装的应用服务器的时候，选择GlassFish V2 URL，这是Sun公司在NetBeans里集成的一个应用服务器，其实也就是：Sun Application Server.
                    

        安装完成后启动NetBeans IDE 6.0.1,不知道是什么原因,当一启动IDE和应用服务器后电脑暴卡,进程java.exe占用内存达220M之大,不知道那位朋友可有什么好的解决方案,知道的文章下面留言告诉下,谢谢.
                      

三、建立EJB类库

    新建一类库EJB3.0,将开发EJB所需要的jar包导入便OK。详细步骤如下：菜单中的“工具”选项里选择“库”，在弹出的窗体中建立新库并命名为EJB3.0, 然后将EJB所需要的 jar包(所有的jar包都可以在GlassFish的安装目录下的lib目录里)导入到此类库里便OK。
             

四、启动应用服务器

      启动服务器很简单，在菜单里选择“窗口”里面的“服务”选项，在弹出的窗体里选中“服务器”，点开子节点，里面有个GlassFish V2的选项，右键-->启动。
                                                 

        OK，到这里我们的准备工作算是告一段落了，我们来测试下服务器是否可以正常启动。 打开浏览器，在地址栏里输入：http://localhost:4848,看是不是出来如下登录界面。  
               

     输入用户名和密码登陆试试。
     User Name:admin 
     Passwrod:adminadmin，成功登录后的控制界面如下所示：


       EJB开发的环境搭建基本上就搭建好了，本文就此结束