Dev 2Dev Days 2006
免费技术培训，线上闯关夺宝；最酷的技术，最新的工具，最佳的实践，最缤纷的礼包，尽在ＢＡＥ Ｄｅｖ２Ｄｅｖ Ｄａｙｓ开发者大会！
将开源与商业技术混合使用，开发更强大、更优秀的企业级应用已经
不是梦想，以开发人员为中心的ＢＥＡ Ｄｅｖ２Ｄｅｖ Ｄａｙｓ ２００６，报名截止日期将近，抓住最后的机会，享受专业人士为您精心烹制的技术大餐。
您将学习和实践最酷的技术、最新的工具和最佳的实践。资深专家讲
解，现场演示；赠送的包含演示中所有代码的光盘，让您可以亲自动手操作并评估，使您能够在ＢＥＡ ＷｅｂＬｏｇｉｃ ＳｅｒｖｅｒＴＭ中混合开源与商业技术，打造优秀的企业级解决方案：
数据层的演示：Ｈｉｂｅｒｎａｔｅ ｄａｔａ ｐｅｒｓｉｓｔｅｎｃｅ和Ｋｏｄｏ ｐｅｒｓｉｓｔｅｎｃｅ；Ｗｅｂ层的
演示：Ｓｔｒｕｔｓ、ＮｅｔＵＩ和Ｊａｖａ Ｓｅｒｖｅｒ Ｆａｃｅｓ；Ｗｅｂ层上门户内容和Ａｊａｘ的演示；业务层上Ｓｐｒｉｎｇ ｂｅａｎ和远程处理的演示。
您将能够与一线工程师对话，与其他开发人员交流。使您更准确地了
解行业动态，把握技术前沿。
您将获得精美礼品与ＳＯＡ开发培训优惠。用户于Ｄｅｖ２Ｄｅｖ Ｄａｙｓ大会上
报名，可享受８．５折优惠，现场付费更可享受６．５折优惠。
您参与线上答题，可赢取积分和连环大奖。参与线上闯关夺宝，即刻
赢得积分奖励，通关者更可获得优胜礼品，并有机会参与现场终极ＰＫ，获得ｉＰｏｄ大奖！
注册成为ＢＥＡ Ｄｅｖ２Ｄｅｖ社区会员，即刻能免费报名参加活动。名额有
限，赶快注册吧！
利用短短一天的时间，混合使用开源与商业技术的开发方法将使您开
发企业解决方案的能力迈上一个新台阶。SILVE R SP ONSOR ５月１６ 北京长城饭店５月１８ 上海华亭宾馆５月２３ 深圳圣廷苑酒店５月１６ 成都天府丽都喜来登饭店会议热线
010-*******
DIAMOND SP
ONSOR
ＢＥＡ系统（中国）有限公司 北京市朝阳区朝外大街１６号 中国人寿大厦１１层 邮编：１０００２０Ｃｏｐｙｒｉｇｈｔ ２００６ ＢＥＡ Ｓｙｓｔｅｍｓ， Ｉｎｃ． Ａｌｌ ｒｉｇｈｔｓ ｒｅｓｅｒｖｅｄ．Ｃ
Copy right ? 2006 BEA Sy stem s,Inc. All rights reserv ed. BEA and WebLogic are registered trademarks and BEA WebLogic Enterprise Platf orm, BEA WebLogic Serv er,BEA WebLogic Integrat ion,BEA WebLogic Portal,BEA WebLogic Platf orm,and BEA WebLogic Workshop are trademarks of BEA Sy stems, Inc. All other commpany and product names may be the subject of intellectual property rights reserv ed by third parties.
卷首语
>1Ｂｌｅｎｄｅｄ
专访
>3塑造商业与开源软件完美组合
——访ＢＥＡ公司Ｗｏｒｋｓｈｏｐ Ｂｕｓｉｎｅｓｓ Ｕｎｉｔ副总裁Ｂｉｌｌ Ｒｏｔｈ
前沿
>6ＥＳＢ复合管理能力护航ＳＯＡ实现
专题
>
8导读>
9使用Ｊａｖａ Ｐｅｒｓｉｓｔｅｎｃｅ ＡＰＩ及Ｓｐｒｉｎｇ ２．０>15ＡＪＡＸ在ＢＥＡ ＷｅｂＬｏｇｉｃ Ｐｏｒｔａｌ中的应用原理>20ＪＳＦ与Ｂｅｅｈｉｖｅ Ｐａｇｅ Ｆｌｏｗ的完美应用集成>25使用Ｅｃｌｉｐｓｅ和ＷｅｂＬｏｇｉｃ－Ｐｌｕｇｉｎ调试ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ应用程序>29深入浅出构建高级Ｂｅｅｈｉｖｅ控件
动态>35新闻回顾>36Ｕｓｅｒ Ｇｒｏｕｐ>
38论坛精粹>40专家博客
技术
>41利用ＷｅｂＬｏｇｉｃ Ｐｏｒｔａｌ设计成功的门户部署>45使用ＸＵＩ框架构建ｅＢａｙ富客户端应用>51ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ ９．０中的工作负载管理
百家争鸣>59你知道的Ｊａｖａ，和你不知道的Ｊａｖａ
对症下药
>62Ｊａｖａ应用系统内存不足泄漏问题解决方案
contents
《BEA dev 2dev 专刊》20063专访
塑造商业和
开源软件完美组合
——访ＢＥＡ公司Ｗｏｒｋｓｈｏｐ Ｂｕｓｉｎｅｓｓ Ｕｎｉｔ副总裁Ｂｉｌｌ Ｒｏｔｈ
□ 记者：霍泰稳
BEA 宣布了新的“Blended ”战略。能否说明一下出台
这一战略的背景情况？
答：混合开发的理念建立在Ｊｏｙ＇ｓ Ｌａｗ的坚固基础之
上，该规则大致可以解释为“大部分最聪明的人都不为您
工作”（也可以这么说：“革新都发生在别处”）。由于种种
原因，使得在语言和框架两方面都出现了众多的革新。其
中大多数都是开放源码。语言方面包括：Ｐｅｒｌ、ＰＨＰ、Ｐｙｔｈｏｎ
和Ｒｕｂｙ。框架方面包括Ｓｔｒｕｔｓ、ＪａｖａＳｅｒｖｅｒ Ｆａｃｅｓ、Ｓｐｒｉｎｇ和
Ｈｉｂｅｒｎａｔｅ。我认为，这主要是因为革新是以波动的形式出现
的。想想１９６７年到１９７３年编程语言方面出现的那些具有里
程碑意义的革新吧——我是说Ｃ和Ｓｉｍｕｌａ。此时ＩＢＭ有了ＰＬ／１，
并由此崛起。然后平静了一段时间，直到８０年代和９０年代
初期，出现了Ｃ＋＋、Ｓｍａｌｌｔａｌｋ、Ｏｂｊｅｃｔｉｖｅ－Ｃ之类的面向对象
语言。于是语言方面的竞争尘埃落定，Ｃ＋＋和Ｊａｖａ成为主
导语言。
这些语言使用了数年之后，很明显，需要有一种轻松地
构建ｗｅｂ应用程序的方法。这场变革从用Ｐｅｒｌ编写的ＣＧＩ脚本开始，发展出了ＰＨＰ。这种新范例为Ｐｙｔｈｏｎ（最早的面向对象脚本编写语言之一）赋予了新的生命。还有一种即将引发极大兴趣的新语言正在产生，即Ｒｕｂｙ。可以说，没有人可以预测下一个热门框架会是哪一个，但是我们的新策略可以让我们预先做好准备。BEA 是如何定义“Blended ”的？您能否举例说明一下
Ｂｉｌｌ Ｒｏｔｈ是ＢＥＡ公司Ｗｏｒｋｓｈｏｐ Ｂｕｓｉｎｅｓｓ
Ｕｎｉｔ副总裁。他负责将ＢＥＡ Ｗｏｒｋｓｈｏｐ Ｆｏｒ
Ｊａｖａ产品线推向市场。作为一个拥有１８年行
业经验的老手，Ｒｏｔｈ之前是ＣＲＭ软件提供商
Ｅｐｉｐｈａｎｙ公司的首席技术推广员。在进入
Ｅｐｉｐｈａｎｙ之前，Ｒｏｔｈ在Ｓｕｎ公司担任过数个
重要的营销职务，负责Ｊ２ＥＥ产品营销和产品
管理以及ＳｕｎＯＮＥ开发人员营销。Ｒｏｔｈ还为
ＯｐｅｎＯｆｆｉｃｅ．ｏｒｇ的启动和社区创建做出了很
大的贡献。
4dev https://www.doczj.com/doc/cd16467693.html, 技 术
混合开发？
答：关于“Ｂｌｅｎｄｅｄ”开发以及混合开发模型，我们
已经说得够多了。那么它到底是指什么呢？目前存在多
种框架和执行环境，开发人员正在混合使用它们来完成
工作。我们意识到了这种情况，并且尽一切努力为开发
人员提供支持。有必要意识到，在编程模型的革新方
面，我们正处于一个历史性转折点上。在开发范例的发
展历史中，总是会有一段时间会发生重大革新，出现许
多可用的框架，随后是一段稳定时期，然后又会发生重
大变革，这个周期不断重复发生。回顾一下上个世纪８０
年代末９０年代初，那时有多种开发范例，包括Ｓｍａｌｌｔａｌｋ、
Ｃ、Ｃ＋＋、Ｏｂｊｅｃｔｉｖｅ－Ｃ、Ａｄａ以及ＡＰＬ。然后，几年之
后，只有为数不多的几种幸存下来了，比如Ｃ＋＋／ＭＦＣ
以及Ｊ２ＥＥ和Ｊ２ＳＥ。
目前的形势是，框架和开发语言／模型正处于井喷
爆发中。其中包括Ｓｐｒｉｎｇ、Ｂｅｅｈｉｖｅ和Ｈｉｂｅｒｎａｔｅ等框架以
及ＰＨＰ、Ｐｅｒｌ和Ｒｕｂｙ等语言。我们注意到了这一发展方
向，并宣布在Ｄｅｖ２Ｄｅｖ上为Ｓｐｒｉｎｇ提供客户支持服务、
对Ｓｐｒｉｎｇ进行认证。我们还在收购Ｍ７之后所产生的新
的工具产品中提供了对Ｈｉｂｅｒｎａｔｅ等框架以及ＪＢｏｓｓ和
Ｔｏｍｃａｔ等环境的支持。
这自然就引发了一个问题：“这难道不会危及到
ＢＥＡ在ＷｅｂＬｏｇｉｃ产品家族及其框架上所做的投资吗？”
提出这一问题的人根本就不了解ＢＥＡ的业务以及我们在
激烈的市场竞争中一直发展到今天的原因所在。ＢＥＡ的
目标是要简化企业开发。有人可能会问：“支持Ｈｉｂｅｒｎａｔｅ
不就支持了它的创建者吗？”而事实是，现在许多开发
人员正在使用这些框架，主要是因为它们强大而且简
单。这符合我们的目标，而我们将继续提供强大的工具
以及健壮的执行环境。如果它非常受欢迎，运行于服务
器端Ｊａｖａ，并且可以使开发人员的工作变得轻松，我们
就会支持它。
您认为混合应用程序开发可以为企业与开发人员
带来什么好处？
答：企业可以看到的好处是它们可以更快地开发
质量更高的软件，而且这些软件将运行得更好、更有
效。实际上，企业级混合开发是对开发机构的扩展。它可以利用开放源码的优点来满足机构的需求。对于开发人员来说，混合开发意味着我们（我自己也是一个开发人员）获得了得力工具。我们可以使用最好的库和源代码，并在最好的商业容器（如ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ）上运行它们。比如对我们前一段时间收购的Ｋｏｄｏ，现在这个项目叫做Ｏｐｅｎ ＪＰＡ，我们把它开源之后这意味着开发人员将有一个免费的、经过Ａｐａｃｈｅ认证的ＥＪＢ ３ Ｐｅｒ－ｓｉｓｔｅｎｃｅ规范实现。同样不可忽视的是，客户将可以获得ＢＥＡ长期以来为客户提供的品牌支持服务，如果需要的话，还可以通过ＢＥＡ Ｗｏｒｋｓｈｏｐ Ｓｔｕｄｉｏ产品获得工具支持。我们非常欢迎开发人员在Ｏｐｅｎ ＪＰＡ可用之后立即试用它，因为ＥＪＢ ３规范还没有最终确定。ＥＪＢ ３规范团队需要来自社区的更多反馈，以便确保他们实现了使企业Ｊａｖａ更易于使用的承诺。对应于BEA 的“Blended ”战略，有哪些面向开发人员社区的计划？答：多年来，我们一直在进行混合。我们一直在推广Ｓｐｒｉｎｇ，并为其提供支持。我们的产品一直在使用开放源码，比如来自Ａｐａｃｈｅ的ＣｏｍｍｏｎＪ库。但是，最近我们开始为Ｓｐｒｉｎｇ等提供支持并为Ｈｉｂｅｒｎａｔｅ等提供工具支持。这使得开发人员可以利用最好的框架来完成工作。此外，我们在ＢＥＡ Ｗｏｒｋｓｈｏｐ上所付出的努力以及确保这些框架具有工具支持的工作，这些都是“Ｂｌｅｎｄｅｄ”计划的一部分。具体来说，比如Ｋｏｄｏ（Ｏｐｅｎ
ＪＰＡ），在收购之后，我们将围绕Ｏｐｅｎ ＪＰＡ建立一个社区，而这个社区包含的将不只是Ｗｅｂｌｏｇｉｃ Ｓｅｒｖｅｒ的用户。我们欢迎所有从ＷｅｂＳｐｈｅｒｅ和ＪＢｏｓｓ等商业产品到Ｔｏｍｃａｔ和Ｓｐｒｉｎｇ等开源框架的用户。这很容易做到，因为Ｏｐｅｎ ＪＰＡ的核心是一个开放的行业标准。在标准以及协议的定义方面，商业软件与开源软件有相当大的区别。BEA 如何能够做到使商业和开源软件“无缝”混合？答：我觉得区别并不是很大。开放源码也遵循标准和协议，并常常用来设置标准和协议。ＢＥＡ消除开源与
《BEA dev 2dev 专刊》20065专访商业软件之间边界的一种方法是提供一些工具，以便使
开源产品使用起来就像使用一些商业框架那样容易，就
像我们在ＷｅｂＬｏｇｉｃ应用框架上所做的工作那样（这些
成果现在都被投入Ａｐａｃｈｅ Ｂｅｅｈｉｖｅ下的开源社区中了）。
我们的主要目标是为开发人员提供编写优秀软件所需的
工具。我们希望使开发人员的生活更为轻松，并使他们
可以在适当的时候使用适当的工具。
开源社区中有许多杰出的软件。当BEA 选择其中
的一个用于建立混合开发环境时，选择产品的指导原
则是什么？换句话说，什么样的开源软件适合与BEA
进行协作？
答：总体上，这要看我们客户的意见。现在有两
个框架，几乎每个我所遇到的客户都会提到它们：
Ｓｐｒｉｎｇ和Ｈｉｂｅｒｎａｔｅ。我们的客户说，他们希望拥有企业
级的工具以及对这些框架的支持，而我们打算交付他
们所需要的。
但是，回到您的问题上，我们欢迎所有的开放
源码。我们在Ｄｅｖ２Ｄｅｖ站点上支持一个很棒的开源
站点，ＣｏｄｅＳｈａｒｅ，任何开源项目都可以在上面开拓
一片天地。
虽然开源软件是开放的，但是其核心开发人员发
挥着重要的作用。曾经发生过核心开发人员的离开导致
整个软件项目不再继续发展的事情。那么，在混合开发
环境中，如何保证其中的开源软件应用程序的连续性
呢？BEA 如何保证开源软件开发的持续进行？
答：ＢＥＡ通过其在开源项目（如Ｅｃｌｉｐｓｅ以及各种
Ａｐａｃｈｅ项目）上的投资来保证开放源码的未来。我们的
投资有助于保证这些软件持续发展。
许多国际性软件公司比如Sun 、IBM 都与开源社区
建立了关系。BEA 的“Blended ”战略与他们有何区别？
答：我们的策略之所以不同，是因为我们采用了一
种非常实用的方法，并交付了我们的客户所希望得到的
开放源码。与Ｓｕｎ将一切进行开源的战略不同，我们只
关注那些能为我们每天为之工作的人带来价值的东西。与试图控制所参与项目的ＩＢＭ不同，我们只努力交付我们的客户希望从开放源码中得到的。BEA 是否会为“Blended ”战略下的开源产品提供必要且有效的技术支持？如果答案是肯定的，那么如何做到？答：是的，我们会提供。除了Ｄｅｖ２Ｄｅｖ上提供的ＳｐｒｉｎｇＦｒａｍｅｗｏｒｋ支持之外，我们将在我们的产品中为所有的开放源码提供开源支持。我们还将为诸如Ｔｏｍｃａｔ之类的开源容器提供支持。这些都是很让人期待的。说到具体的支持我可以以Ｗｏｒｋｓｈｏｐ为例来一步阐述我的观点。新发布的Ｗｏｒｋｓｈｏｐ ３．０新增加了对ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ ９．０的支持，这样它就支持了ＪＢｏｓｓ、Ｔｏｍｃａｔ、Ｊｅｔｔｙ、ＷｅｂＳｐｈｅｒｅ、Ｒｅｓｉｎ等包括ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ在内的应用服务器。要注意的关键一点是，ＢＥＡ支持将应用程序部署到其他应用服务器上。在我们看来，这为客户提供了重要的选择权。当客户的应用程序扩大时，许多情况下开源应用容器无法提供ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ所提供的可靠性、可伸缩性和可管理性。ＢＥＡ Ｗｏｒｋｓｈｏｐ提供了一种非常整洁而简单的方法来将ｗｅｂ应用程序从这些容器迁移到ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ９．０所提供的具有行业优势的环境中。其次要注意的是，通过支持其他服务器和开源框架，ＢＥＡ还打算为非Ｊ２ＥＥ开发人员提供工具，甚至有一天可能会不限于对Ｊａｖａ语言的支持。我们还从Ｗｏｒｋｓｈｏｐ产品名称中去掉了“ＷｅｂＬｏｇｉｃ”字样。这是由于两个原因：首先，现在我
们还支持其他容器。其次，Ｅｃｌｉｐｓｅ框架会成为整个产品线的富客户端工具的基础。您能否预测一下，“Blended ”开发模式将为整个软件业带来什么样的影响？答：总体上来说，开放源码的出现将使那些真正理解“Ｂｌｅｎｄｅｄ”涵义的公司以前所未有的速度和质量进行革新并为客户创造价值。这将加快整个行业的革新速度，将会导致新的软件范畴出现，比如“服务基础架构”的概念就通过我们的ＡｑｕａＬｏｇｉｃ产品线又获得了新生。谢谢您抽出时间接受我们的采访。
6dev https://www.doczj.com/doc/cd16467693.html, 技 术ESB 复合管理能力
护航SOA 实现
谈到ＳＯＡ，您的第一反应是什么？是“好热门”，还
是“那又怎样”？不管您的答案是哪一种，目前似乎人
人都在谈论面向服务架构（Ｓｅｒｖｉｃｅ－Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ，
ＳＯＡ）。越来越多的机构将目光投向Ｗｅｂ Ｓｅｒｖｉｃｅｓ和
ＳＯＡ，希望借助它们来优化ＩＴ和业务，并帮助他们解决
许多复杂问题——进一步审查ＩＴ投资使其更注重成本
控制；从后台管理的自动化到前台与客户、合作伙伴和
供应商的协作的转换；扩展基于标准的产品平台等等。
不管是哪一种问题，ＳＯＡ都可以把企业应用程序
中所包含的分散的功能组织为可互操作的、基于标准的
“服务”，这些服务可以快速地进行组合和重用以满足业
务需求。通过围绕服务而不是应用程序来组织ＩＴ，ＳＯＡ
帮助企业提高了生产力，加快了服务时间，并提高了响
应不断变化的业务环境的灵敏度。根据Ｆｏｒｒｅｓｔｅｒ的说法，
７７％的大型企业、５１％的中型企业、４６％的小型企业
都在积极实现ＳＯＡ。
出于成本和复杂性考虑，在采用ＳＯＡ策略时，ＩＴ并
不是要破坏并取代现有的基础架构。相反，它通过将现
有的业务应用程序公开为服务，从而扩展了它们，使它
们可以用于其它业务流程和应用程序中。因此，ＳＯＡ策
略成功的关键是要有一个支持在异构环境中的服务之间
进行动态交互的集成层。该集成层必须适应ＩＴ环境中唯
一不变的因素——变化。随着业务为满足新的客户、合
作伙伴和业务需求而不断发展，而又要将服务消费者与
服务端点的改变隔离开来，它必须支持现有服务的不断发展以及新服务的快速出现。服务层的设计必须可以消除从服务端点本身管理服务之间交互的需求。这样的话，服务的发展就不会导致产生点到点实现中所固有的中断点。现在，这个集成层被称为Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ Ｂｕｓ（企业服务总线）或ＥＳＢ。ＥＳＢ提供了支持服务进行动态交互的关键功能：一个用于发布服务的服务注册库、服务版本控制、消息代理，以及服务之间的动态路由选择和转换。ＥＳＢ还应该支持消息和传输安全性。它们通常用作分布式中介体，支持将与路由选择规则、转换、安全性和访问相关的策略从端点中抽象出来。而且，像ＳＯＡ一样，ＥＳＢ是现实存在的。据Ｆｏｒｒｅｓｔｅｒ估计，美国有三分之一的基础架构决策者计划在未来一年中扩大ＥＳＢ的部署范围。ＥＳＢ及类似产品简介那么，ＥＳＢ与其他基础架构集成层相比又如何呢？首先是Ｗｅｂ ｓｅｒｖｉｃｅｓ，它添加了一个抽象层，使用开放标准来提供以一种易于理解和使用的方式对应用程序进行访问的能力。但是，仅有Ｗｅｂ ｓｅｒｖｉｃｅｓ无法满足一般的集成项目的需要。Ｗｅｂ ｓｅｒｖｉｃｅｓ标准缺乏管理可靠性和安全性的规范，也没有提供跨越Ｗｅｂ服务消费者需求与Ｗｅｂ服务生产者的能力之间的鸿沟的调停和流程管理功能。Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｔｆｏｒｍ Ｓｕｉｔｅｓ （ＡＰＳ）也具有类似的缺点。它们难以在分布式网络中的各种服务器中进行部□ 作者：Ｍａｒｔｉｎ Ｐｅｒｃｉｖａｌ
《BEA dev 2dev 专刊》20067前沿署和重新配置。ＡＰＳ为运行在单个服务器或者包含同类
服务器的集群中的业务流程提供了可见度和管理特性。
但是它不能提供运行在多个异构服务器或分布式环境中
的服务器中的统一视图或管理流程。因此，诸如．ＮＥＴ以
及Ｊ２ＥＥ中的ＥＪＢ容器之类的环境就非常不适合用于在企
业ＳＯＡ中管理大量动态配置的服务。
与ＡＰＳ不同，ＥＳＢ服务容器允许根据需要有选择性
地部署调停服务。而对于ＡＰＳ，只要集成功能中的一部
分，就必须安装整个应用服务器堆栈。这将导致不必要
的高成本：许可证、安装以及随时间产生的拥有成本等。
传统的ＥＡＩ产品是专门为应用程序集成而设计的。
它们在一个中心辐射型（ｈｕｂ－ａｎｄ－ｓｐｏｋｅ）模型中执行
应用程序到应用程序的映射，这将集成多个应用程序的
极度复杂性集中在一个点上。在开发过程中，要找到深
入了解项目中的ＥＡＩ产品以及所有要集成应用程序的语
义细节的ＩＴ人员，将会花费昂贵的代价，而且也不切实
际。在部署过程中，要扩展一个ＥＡＩ产品的中心辐射型
架构来承担附加功能，则需要单个服务器或者运行在单
个局域网中的同类服务器集群中的过多计算资源。
ＳＯＡ的灵活基础架构
虽然目前有很多基础架构解决方案被描述为ＥＳＢ，
但是并不是所有这些解决方案都可以满足异构ＩＴ环境
中的服务集成需求。ＥＳＢ必须支持运行在各种应用平台
上的服务之间的集成，包括传统环境、．Ｎｅｔ、Ｊ２ＥＥ以及
其他被广泛采用的技术。在ＳＯＡ中，服务被设计为消
费者，访问和消费其他服务的值。ＥＳＢ需要对服务的消
费者和提供者屏蔽由于所使用的传输协议和消息格式而
产生的复杂性。ＥＳＢ旨在消除在不同服务所使用的“语
言”之间进行转换的复杂性，使用双方均可使用的标准
（如ＸＱｕｅｒｙ）进行动态转换。
丰富的可管理性
当服务被连接到一个智能中介体，并且支持异构
服务交互的路由选择和转换功能也已具备之后，ＩＴ就
需要具有评估这些服务交互的健康状况和可用性的能
力，以便支持当今业务事务所需的可靠性。不支持管理特性的ＥＳＢ就像没有油耗表和速度表的汽车一样，使用起来非常危险。一个作为单个统一层的一部分而交付的智能可管理基础架构可以管理所有已注册的服务。它可以跟踪消息，监控性能，定义服务水平协议，并用其来确保服务交互质量以及对服务基础架构的前瞻性管理。ＢＥＡ ＡｑｕａＬｏｇｉｃ Ｓｅｒｖｉｃｅ Ｂｕｓ是专门针对ＳＯＡ集成而设计的“企业级”ＥＳＢ产品，它管理服务交互，在多种异构ＩＴ环境中调度消息。Ａｑｕａｌｏｇｉｃ Ｓｅｒｖｉｃｅ Ｂｕｓ交付了一个轻量级、无状态、性能卓越、可以即时满足企业ＳＯＡ需求的架构。ＡｑｕａＬｏｇｉｃ Ｓｅｒｖｉｃｅ Ｂｕｓ是策略驱动的，它支持服务客户端（服务消费者）与业务服务（服务提供者）之间的松散耦合，提供了一个进行安全性控制、监控以及实施服务水平协议的地方。对服务集成关系的更改是通过配置（而不是编码）动态实现的，这使客户可以根据安全性、服务位置、可用性和响应灵敏度、数据格式、监控、传输和通信等方面对服务基础架构进行改进。开发和管理的整合随着时间的推移，最终成功的将是那些提供的功能从开发和管理两个角度进行了集成，但又是开放的，可通过已有的标准协议和接口进行扩展的服务基础架构。这些成功实现的核心将是一个统一的服务元数据储存库，它支撑着所有的基础架构功能。ＥＳＢ指明了获得竞争优势的最直接的方法就是成为一个服务驱动的企业。Ｆｏｒｒｅｓｔｅｒ将ＥＳＢ市场明确地分为两部分。“ＥＳＢ套件”部分是面向要求“尽量简单”的买主的。ＥＳＢ套件被定义为具有可选组件（用于服务编排、服务管理以及合作伙伴协作）的ＥＳＢ（作为套件提供）。而“综合性
ＥＳＢ套件”市场是面向要求“全部都要”的买主的。综合性ＥＳＢ套件是包含了所有套件特性以及对人工工作流、垂直行业解决方案、门户、规则引擎以及其他方面的支持的完全服务集成套件。现在，通过服务基础架构层部署ＳＯＡ已经成为技术现实，但是一定要确保ＥＳＢ支持在一个统一的解决方案中进行多种复合管理。这非常重要！
8dev https://www.doczj.com/doc/cd16467693.html,
专 题
在２００５年１２月７日、８日举行的ＢＥＡＷｏｒｌｄ
２００５大会上，我采访ＢＥＡ全球副总裁Ｆｒａｎｚ Ａｍａｎ
先生时，问他“当类似ＢＥＡ这样的商业公司对开源
软件做技术支持时，会不会影响使用者的热情”时，
Ａｍａｎ非常乐观地表示“一点也不会，因为我们会
向那些寻找技术服务支持的客户保证，他们所花的
每一分钱都是非常值得的。比如，用户使用Ｂｅｅｈｉｖｅ
是自由的，使用Ｅｃｌｉｐｓｅ也是自由的，但当用户将
Ｂｅｅｈｉｖｅ或者Ｅｃｌｉｐｓｅ与我们的商业产品如
ＷｅｂＬｏｇｉｃ系列产品或者ＡｑｕａＬｏｇｉｃ产品相绑定而
遇到问题来求助时，我们都会给予专业的支持，当
然，是付费的。”也许很多人对“付费”这个词比较
敏感，认为商业的项目一定会阻止软件业的前进，
殊不知如果没有ＢＥＡ、ＩＢＭ及Ｏｒａｃｌｅ等这些公司
在背后的大力支持，Ｂｅｅｈｉｖｅ、Ｅｃｌｉｐｓｅ、Ｓｐｒｉｎｇ等
这些开源的软件也不会支撑到现在而且生机盎然。
不论商业公司在背后支持开源软件的动机如何，但
客观来讲，因为有商业的推动，开源软件拥有了持
续前进的动力。
这里有必要简要介绍一下ＢＥＡ公司所主导或
者参与的几个开源项目：
Ａｐａｃｈｅ Ｂｅｅｈｉｖ：基于ＷｅｂＬｏｇｉｃ Ｗｏｒｋｓｈｏｐ
应用框架而开发，为开发Ｊ２ＥＥ和ＳＯＡ应用提供一
个易用的跨容器编程模型和应用框架，主要包括页
面流（ＰａｇｅＦｌｏｗ）和Ｊａｖａ控件两部分。
Ａｐａｃｈｅ ＸＭＬＢｅａｎｓ：一个Ｊａｖａ－ＸＭＬ绑定工
具，通过ＸＭＬＢｅａｎｓ可以方便地访问ＸＭＬ结构、Ｓｃｈｅｍａ，并且可以基于Ｊａｖａ对象查看、使用ＸＭＬ数据。Ｅｃｌｉｐｓｅ ＡｓｐｅｃｔＪ ５：是Ｊａｖａ的一个简单扩展，目前已经具备面向方面编程（ＡＯＰ）的功能，现在的ＡｓｐｅｃｔＪ ５是由ＡｓｐｅｃｔＪ与ＡｓｐｅｃｔＷｅｒｋｚ合并而成。Ｅｃｌｉｐｓｅ ＷＴＰ：ＷＴＰ全称为Ｗｅｂ ＴｏｏｌｓＰｌａｔｆｏｒｍ，主要是为开发Ｊ２ＥＥ Ｗｅｂ应用而开发的一种工具，主要包括各种源代码的编辑器，ＸＳＤ、ＷＳＤＬ图表编辑器等等非常强大的功能。Ｓｐｒｉｎｇ Ｆｒａｍｅｗｏｒｋ：一款非常强悍的应用框架，允许使用ＰＯＪＯ开发Ｊ２ＥＥ应用，目前ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ对Ｓｐｒｉｎｇ提供了完整的支持，已经发布了Ｓｐｒｉｎｇ ｏｎ ＷｅｂＬｏｇｉｃ工具包。《ＢＥＡ ｄｅｖ２ｄｅｖ专刊》无意破解商业与开源之间的深层比较关系，这既非我们的初衷，更远非我们所能。介绍这些开源软件的目的并不在于说明ＢＥＡ公司对开源给予了多么大的支持，因为开源本身是一个非常大的事业，是由全世界的程序员与更多的商业公司在默默地支持着它的发展，ＢＥＡ是其中的一员。在本期的专刊里，我们精选一些基于这些开源软件应用的技术文章以飨读者，目的在于期望通过这些为数不多的文章帮助读者了解这些实用的工具并进而发掘出在这次商业项目与开源软件整合的过程中ＢＥＡ所起的作用。有关这些工具更详尽的介绍，请登陆ｄｅｖ２ｄｅｖ中国网站（ｄｅｖ２ｄｅｖ．ｂｅａ．ｃｏｍ．ｃｎ）。
让开源在
商业产品上腾飞
《BEA dev 2dev 专刊》20069专题
摘要
Ｊａｖａ Ｐｅｒｓｉｓｔｅｎｃｅ ＡＰＩ（ＪＰＡ）和Ｓｐｒｉｎｇ Ｆｒａｍｅｗｏｒｋ版
本２．０为开发人员带来了许多好处。本文将探讨如何将
Ｓｐｒｉｎｇ ２．０和ＪＰＡ用于ＢＥＡ ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ。具体来说，
我们描述了使用Ｓｐｒｉｎｇ和ＪＰＡ的ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ的Ｍｅｄｉ－
ｃａｌ Ｒｅｃｏｒｄｓ示例应用程序的升级版本。本文展示了Ｓｐｒｉｎｇ
和ＪＰＡ是如何形成强大的组合，从而奠定简化的基于
ＰＯＪＯ的应用程序架构的基础的。使用的主要技术包括
ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ ９．１、Ｓｐｒｉｎｇ ２．０和Ｋｏｄｏ ＪＰＡ。简介Ｍｅｄｉｃａｌ Ｒｅｃｏｒｄｓ示例应用程序（ＭｅｄＲｅｃ）是一个综合应用程序，它演示了如何在ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ中使用各种技术。这包括Ｓｐｒｉｎｇ和Ｓｔｒｕｔｓ等开源技术，也包括ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ自带的技术，如Ｗｅｂ ｓｅｒｖｉｃｅｓ、ＪＳＰ、消
息驱动Ｂｅａｎ（ＭＢ）以及ＪＤＢＣ。
本文介绍如何在ＭｅｄＲｅｃ更新版本中结合使用Ｊａｖａ
Ｐｅｒｓｉｓｔｅｎｃｅ ＡＰＩ（ＪＰＡ）和Ｓｐｒｉｎｇ Ｆｒａｍｅｗｏｒｋ。一个重要
的目的就是向开发人员展示如何结合使用Ｓｐｒｉｎｇ ２．０、
ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ ９．１和Ｋｏｄｏ ４．０。通过阅读本文，开
发人员将能够简要了解如何使用ＪＰＡ以及Ｓｐｒｉｎｇ ２．０版
本中对ＪＰＡ的新的支持。本文还将讨论在企业应用程序
的多个层次中重用ＪａｖａＢｅａｎｓ（ＰＯＪＯｓ）时将遇到的挑战。
这种重用也正是基于Ｓｐｒｉｎｇ和ＪＰＡ的应用程序架构的主要优点。对于不熟悉Ｊａｖａ Ｐｅｒｓｉｓｔｅｎｃｅ ＡＰＩ的开发人员，ＪＰＡ是一种新的简化ＡＰＩ，它可指定在数据库中存储Ｊａｖａ对象的方式。ＪＰＡ是作为ＥＪＢ ３．０（ＪＳＲ ２２０）的一部分开发的，因为它替代了ＥＪＢ ２．ｘ实体ｂｅａｎ，不过它可用于Ｊ２ＥＥ和Ｊ２ＳＥ应用程序中。ＪＰＡ的优点之一就是它是基于ＰＯＪＯ的。ＪＰＡ还使用Ｊａｖａ ５．０注释来简化指定从Ｊａｖａ对象到关系数据库的映射的方式。ＢＥＡ公布了ＯｐｅｎＪＰＡ的构成，这是一种即将发布的基于Ｋｏｄｏ的开源项目，不
过您现在就可以使用Ｋｏｄｏ ４．０的早期访问版。
本文将从概述Ｓｐｒｉｎｇ中的ＰＯＪＯ和数据访问开始。下
一节概述ＭｅｄＲｅｃ的架构，并简要地描述ＭｅｄＲｅｃ的数据
访问层。然后详细介绍ＪＰＡ持久类，并讨论它们遵循的
设计模式。最后进行总结，包括Ｓｐｒｉｎｇ和Ｋｏｄｏ ＪＰＡ的
ＸＭＬ配置。Ｓｐｒｉｎｇ中的ＰＯＪＯ和数据访问Ｓｐｒｉｎｇ Ｆｒａｍｅｗｏｒｋ最为众所周知的优点就是简化了业务组件的开发。熟悉Ｓｐｒｉｎｇ的开发人员都知道，通过使用Ｉｎｖｅｒｓｉｏｎ ｏｆ Ｃｏｎｔｒｏｌ（ＩｏＣ）和Ａｓｐｅｃｔ Ｏｒｉｅｎｔｅｄ Ｐｒｏ－ｇｒａｍｍｉｎｇ（ＡＯＰ），Ｓｐｒｉｎｇ允许开发人员编写强大的业务组件，人们也经常称之为常规ＪａｖａＢｅａｎｓ或ＰＯＪＯ（简单的Ｊａｖａ对象）。对于需要访问数据库的企业应用程序，Ｓｐｒｉｎｇ还提
使用
Java Persistence API
及Spring 2.0
□ 作者：Ｓｅｔｈ Ｗｈｉｔｅ
10dev https://www.doczj.com/doc/cd16467693.html,
专 题
供了一个架构，用来简化封装持久数据访问的数据访问
对象（ＤＡＯ）的创建过程。Ｓｐｒｉｎｇ的ＰＯＪＯ主题还延伸到
了数据访问领域，因为它们查询和修改的数据访问对象
和域模型对象都可能是ＰＯＪＯ。
在Ｓｐｒｉｎｇ中使用ＰＯＪＯ模式具有许多重要的实际优
点。首先，对于业务组件，ＰＯＪＯ可减少开发人员要实
现应用程序必须完成的工作。因为它是标准的Ｊａｖａ，所
以涉及的代码不仅更少，而且也更为简单。其次，使用
ＰＯＪＯ意味着其他的应用程序代码（涉及数据访问对象
的代码）不再依赖于特定的持久性技术。例如，如果您
的应用程序使用原始的ＪＤＢＣ或ＪＤＯ，使用ＰＯＪＯ时就可
相对简单地切换为将ＪＰＡ用作持久性解决方案。
第三个优点与域模型对象本身有关，在ＭｅｄＲｅｃ中，
域模型对象表示患者、医生和处方等实体。因为这些类
是ＰＯＪＯ，没有绑定到特定的持久性环境（通常为ＥＪＢ ２．
ｘ实体ｂｅａｎ），所以当应用程序需要访问域模型时这些类
可在多个层次中重用。对于ＭｅｄＲｅｃ来说，这包括域模型
对象由ＪＳＰ用来呈现用户界面的Ｗｅｂ层以及将域模型类
用作参数并将类型返回到Ｗｅｂ服务方法的Ｗｅｂ服务层。ＭｅｄＲｅｃ概述想要综合了解ＭｅｄＲｅｃ应用程序的架构以及它使用Ｓｐｒｉｎｇ的方式，请阅读Ｓｐｒｉｎｇ Ｉｎｔｅｇｒａｔｉｏｎ ｗｉｔｈ ＷｅｂＬｏｇｉｃＳｅｒｖｅｒ（ｄｅｖ２ｄｅｖ，２００５年９月）。这是一篇较早的文章，很出色地介绍了Ｓｐｒｉｎｇ和ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ的常规集成。不过，这里我们也会简单讨论一下ＭｅｄＲｅｃ架构，帮助读者清楚地了解如何在ＭｅｄＲｅｃ环境中使用ＪＰＡ。图１演示了ＭｅｄＲｅｃ的总体架构。ＭｅｄＲｅｃ的最顶端实际上是两个分开的Ｊ２ＥＥ应用程序（ＥＡＲ文件）：ＭｅｄＲｅｃ应用程序和Ｐｈｙｓｉｃｉａｎ应用程序。所有的数据访问都在ＭｅｄＲｅｃ部分完成，因此我们首先关注这个部分。如图１所示，ＭｅｄＲｅｃ应用程序分为多个层次：包含Ｗｅｂ服务的演示层、服务层、包括数据访问的集成层以及数据库层。集成层中的Ｓｐｒｉｎｇ数据访问对象（ＤＡＯ）主要由服务层中的业务对象调用。ＤＡＯ和服务对象都是Ｓｐｒｉｎｇｂｅａｎ，它们由Ｓｐｒｉｎｇ应用程序环境配置。服务对象使用Ｓｐｒｉｎｇ的声明性事务支持控制事务。Ｍｅｄｉｃａｌ Ｒｅｃｏｒｄｓ应用程序为它需要保持的四个域模型类（Ｐａｔｉｅｎｔ、Ｐｒｅｓｃｒｉｐｔｉｏｎ、Ｒｅｃｏｒｄ和Ｕｓｅｒ）各使用一个不同的ＤＡＯ。这四个ＤＡＯ
实
图１：ＭｅｄＲｅｃ应用程序架构
《BEA dev 2dev 专刊》200611
专题现类分别命名为ＪｐａＰａｔｉｅｎｔＤＡＯ、ＪｐａＰｒｅｓｃｒｉｐｔｉｏｎＤＡＯ、
ＪｐａＲｅｃｏｒｄＤＡＯ和ＪｐａＵｓｅｒＤＡＯ，可在ｃｏｍ．ｂｅａ．ｍｅｄｒｅｃ．ｄａｏ．
ｏｒｍ包中找到。
ＪＰＡ持久类
到目前为止，我们介绍了用于查询和更新的示例
数据访问代码，但还没有涉及持久类本身。它们看起来
是什么样子的呢？先考虑ＰＯＪＯ和元数据。实际上，持
久ＰＯＪＯ需要遵循一系列规则或设计模式。这些规则中
的一部分是由ＪＰＡ指定的，其他的则是总体应用程序架
构的结果，如下所示。
首先我们来看看元数据。ＪＰＡ使得开发人员可以选
择是在ＸＭＬ文件中、Ｊａｖａ ５．０注释中还是二者的组合
中指定与持久性和对象关系映射相关的ＪＰＡ元数据。
Ｍｅｄｉｃａｌ Ｒｅｃｏｒｄｓ应用程序使用ＪＰＡ元数据的Ｊａｖａ注释。
其优点在于该元数据是使用作为它的应用对象的Ｊａｖａ
类、字段和方法进行配置的，有助于理解。如果要使元
数据与代码分开，可改用ＸＭＬ。
请看Ｐａｔｉｅｎｔ类及其字段声明，观察注释ＪＰＡ类示例：
注意，Ｐａｔｉｅｎｔ类是使用Ｅｎｔｉｔｙ注释进行注释的。这是对使用注释的所有持久类的要求。Ｅｎｔｉｔｙ注释的存在告诉持久引擎此类为ＪＰＡ实体。通常情况下，实体类不一定是公共类，但ＭｅｄＲｅｃ的持久类应该是公共类，这样Ｗｅｂ层和Ｗｅｂ服务层才能使用这些类。实体类也不需要实现Ｓｅｒｉａｌｉｚａｂｌｅ，但因为Ｐａｔｉｅｎｔ类要由ＭｅｄＲｅｃ状态操作放入ＨＴＴＰ会话，因此应该可序列化。这样应用程序才能在集群环境中工作，在这种环境中，会话状态可在集群中的各个节点之间序列化。对实体类的其他要求还包括它必须是顶级类以及不能是ｆｉｎａｌ。有关要求的详细列表，请参见ＪＰＡ规范（ＪＳＲ２２０）。使用ＤＡＯ实现服务前面我们讨论了如何使用Ｓｐｒｉｎｇ ２．０和ＪＰＡ实现数据访问对象，现在略微介绍一下使用ＤＡＯ完成其工作的ＭｅｄＲｅｃ服务对象。下面的代码示例展示了ＰａｔｉｅｎｔＳｅｒｖｉｃｅＩｍｐｌ类及其业务方法ｐｒｏｃｅｓｓＮｅｗＲｅｇｉｓｔｒａｔｉｏｎ方法：
https://www.doczj.com/doc/cd16467693.html,
专 题
在新的患者使用ＭｅｄＲｅｃ Ｗｅｂ界面自行注册时会调用ｐｒｏｃｅｓｓＮｅｗＲｅｇｉｓｔｒａｔｉｏｎ方法。该方法以Ｒｅｇｉｓｔｒａｔｉｏｎ对象作为参数来保存新患者的注册信息。ＰｒｏｃｅｓｓＮｅｗＲｅｇ－ｉｓｔｒａｔｉｏｎ首先从Ｒｅｇｉｓｔｒａｔｉｏｎ对象获取Ｐａｔｉｅｎｔ和Ｕｓｅｒ，并初始化二者之间的关系。Ｕｓｅｒ对象包含患者的用户名和密码信息，也包含患者状态，由于新患者必须通过管理员的确认，因此其状态设置为ＵＳＥＲ＿ＮＥＷ。接下来，就要对Ｐａｔｉｅｎｔ ＤＡＯ进行调用以便在数据库中插入新的患者。
我们为ＭｅｄＲｅｃ服务对象配置了Ｓｐｒｉｎｇ声明性事务，这样就可在调用ｐｒｏｃｅｓｓＮｅｗＲｅｇｉｓｔｒａｔｉｏｎ这样的业务方法前由Ｓｐｒｉｎｇ启动一个事务，并在该方法完成后提交事务。这可确保ＤＡＯ能作为自动提交的现有事务的一部分完成其任务。另外还要注意ｓｅｔＰａｔｉｅｎｔＤａｏ方法，它由Ｓｐｒｉｎｇ用来把对ＤＡＯ对象的引用注入服务ｂｅａｎ中。
配置
现在我们已经介绍了组成这个版本的ＭｅｄｉｃａｌＲｅｃｏｒｄｓ应用程序的一些Ｊａｖａ代码。本节我们将介绍Ｓｐｒｉｎｇ和Ｋｏｄｏ所需的外部配置。我们从Ｓｐｒｉｎｇ开始介绍。
Ｓｐｒｉｎｇ配置
Ｓｐｒｉｎｇ Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｎｔｅｘｔ是使用一系列模块化ＸＭＬ配置文件配置的。包含数据访问对象的配置的配置文件是ａｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔ－ｏｒｍ．ｘｍｌ，它位于ＭｅｄＲｅｃ安装目录下的ｓｒｃ＼ｍｅｄｒｅｃＥａｒ＼ＡＰＰ－ＩＮＦ＼ｃｌａｓｓｅｓ目录中。下面的代码摘自ａｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔ－ｏｒｍ．ｘｍｌ，声明了Ｐａｔｉｅｎｔ ＤＡＯ：
Ｓｐｒｉｎｇ的ＪＰＡ ＤＡＯ具有一个需要被注入的依赖关系。这就是ＪＰＡ ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ。ＥｎｔｉｔｙＭａｎａｇｅｒ－Ｆａｃｔｏｒｙ由ＤＡＯ用来创建执行实际的持久存储工作的ＪＰＡＥｎｔｉｔｙＭａｎａｇｅｒｓ。这里的接线工作是使用Ｓｐｒｉｎｇ的ａｕｔｏｗｉｒｅ功能完成的，这也是我们无法在ＸＭＬ中显式看到ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ依赖关系的原因。ａｕｔｏｗｉｒｅ功能根据ＤＡＯ的ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ属性的类型将ＤＡＯ自动接线到ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ，这个属性继承自ＳｐｒｉｎｇＪｐａＤａｏＳｕｐｐｏｒｔ类，所有ＭｅｄＲｅｃ ＤＡＯ类均是后者的扩展。
下面的代码展示了如何声明用于创建ＥｎｔｉｔｙＭａｎａ－ｇｅｒＦａｃｔｏｒｙ的Ｓｐｒｉｎｇ工厂ｂｅａｎ。这里讨论了两个工厂，似乎很容易弄混，不过您只要记住，Ｓｐｒｉｎｇ工厂ｂｅａｎ的目的仅仅是提供一个间接寻址级别，以允许我们执行创建ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ的自定义代码。ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ是ＤＡＯ对象知道或者说关心的惟一的工厂。
ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ是使用自定义的工厂ｂｅａｎ创建的，因为直到撰写本文时，ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ尚不支持与ＪＰＡ的标准集成。ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ需要知道在何处查找ＪＮＤＩ中的Ｋｏｄｏ资源。此信息是作为Ｓｐｒｉｎｇ工厂ｂｅａｎ上的一个属性进行配置的，Ｓｐｒｉｎｇ工厂ｂｅａｎ会将此信息传递给ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ。记住，工厂ｂｅａｎ的工作是创建一个ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ实例并将其返回给Ｓｐｒｉｎｇ，这样Ｓｐｒｉｎｇ就可将ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ注入ＤＡＯ ｂｅａｎ中。创建实体管理员工厂实例的工厂ｂｅａｎ的代码如下所示：
《BEA dev 2dev 专刊》200613
专题ＫｏｄｏＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙＢｅａｎ是一个相当直观的
Ｓｐｒｉｎｇ工厂ｂｅａｎ。在运行时，Ｓｐｒｉｎｇ首先调用默认构造函
数创建ｂｅａｎ的实例。然后，Ｓｐｒｉｎｇ调用ｓｅｔＪｎｄｉＮａｍｅ（）方
法设置Ｋｏｄｏ资源适配器的ＪＮＤＩ名称。注入所有属性后，
Ｓｐｒｉｎｇ就会调用ａｆｔｅｒＰｒｏｐｅｒｔｉｅｓＳｅｔ（），后者会创建
ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ实例。最后，Ｓｐｒｉｎｇ调用ｇｅｔＯｂｊｅｃｔ（）
获取将注入到我们的ＤＡＯ中的ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ。
要重新进行封装，我们要查看Ｓｐｒｉｎｇ ＤＡＯ是如何
包含ＤＡＯ要用来完成所有持久存储工作的Ｋｏｄｏ Ｅｎｔｉｔｙ－
ＭａｎａｇｅｒＦａｃｔｏｒｙ的。Ｋｏｄｏ ＥｎｔｉｔｙＭａｎａｇｅｒＦａｃｔｏｒｙ反过来要
通过ＪＮＤＩ连接到Ｋｏｄｏ资源适配器。接下来，我们要介
绍如何配置Ｋｏｄｏ资源适配器，但首先我们要了解一个
有助于将任何内容绑定到一起的附加Ｓｐｒｉｎｇ配置。
Ｓｐｒｉｎｇ被告知使用ＷｅｂＬｏｇｉｃ ＪＴＡ事务管理器开始和提交事务。这可通过下面的ＸＭＬ代码片段完成：这里有一点非常重要，就是Ｓｐｒｉｎｇ会被特别告知将事务工作委托给ＷｅｂＬｏｇｉｃ ＪＴＡ实现。之后，我们会发现Ｋｏｄｏ也被告知在配置中使用ＪＴＡ事务。这样，ＭｅｄＲｅｃ服务对象就会开始一个ＷｅｂＬｏｇｉｃ ＪＴＡ事务，然后在该事务的上下文环境中调用ＤＡＯ。然后ＤＡＯ调用Ｋｏｄｏ，后者执行数据库读写操作，作为现有ＷｅｂＬｏｇｉｃ ＪＴＡ事务的一部分。Ｋｏｄｏ配置我们使用Ｋｏｄｏ ４．０ ＥＡ４，它是Ｋｏｄｏ的ＪＰＡ实现的早期访问版本。直到撰写本文时，定义ＪＰＡ的ＥＪＢ ３．０规范还不是最终版本，因此Ｋｏｄｏ支持ＪＰＡ的非最终版本。Ｋｏｄｏ是作为资源适配器部署到ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ中的。该资源适配器在ＪＮＤＩ中注册。资源适配器的配置工作在标准ｒａ．ｘｍｌ描述文件中完成，该文件位于资源适配器ＲＡＲ文件的ＭＥＴＡ－ＩＮＦ目录中。如果查看一下ｒａ．ｘｍｌ文件，您就会发现Ｋｏｄｏ可支持许多配置选项（成熟产品的标志）。不过，该示例应用程序仅需要我们对此进行少量修改。现在我们看一下这个示例应用程序所需的属性：
14dev https://www.doczj.com/doc/cd16467693.html,
专 题作者介绍Ｓｅｔｈ Ｗｈｉｔｅ目前是ＢＥＡ的工程师。他已经在ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ开发团队工作了六个年头。在加入ＢＥＡ之前，Ｓｅｔｈ曾是ＷｅｂＬｏｇｉｃ Ｓｅｒｖｅｒ开源开发团队的成员。
Ｋｏｄｏ需要被告知的一件事情就是ＪＤＢＣ数据源的
ＪＮＤＩ位置，这样它才能与数据库交互。实际上，Ｋｏｄｏ需
要知道两个数据源：一个用于处理事务工作的数据源，
一个用于处理非事务工作的数据源，因为Ｋｏｄｏ有时会
访问数据库以便完成一些不属于全局事务的工作。正像
您所猜测的那样，ＣｏｎｎｅｃｔｉｏｎＦａｃｔｏｒｙＮａｍｅ和
ＣｏｎｎｅｃｔｉｏｎＦａｃｔｏｒｙ２Ｎａｍｅ属性就用于这个目的。这两个属
性的值都是ＷｅｂＬｏｇｉｃ数据源的ＪＮＤＩ名称。请确保
ＣｏｎｎｅｃｔｉｏｎＦａｃｔｏｒｙ２Ｎａｍｅ引用的是不在全局ＪＴＡ事务中注
册其连接的数据源。
Ｋｏｄｏ还需要知道应用程序使用的是ＪＴＡ托管事务
还是本地事务。由于ＭｅｄＲｅｃ的服务ｂｅａｎｓ（控制事务）
配置为使用ＪＴＡ，我们将ＴｒａｎｓａｃｔｉｏｎＭｏｄｅ属性的值配置为托管。此外，我们还需要在资源适配器文件中配置Ｋｏｄｏ许可，并列出应用程序将使用的持久类。这里使用的属性应该是自释性的。如果您曾经阅读过ＪＰＡ规范，就应该知道ｐｅｒｓｉｓｔｅｎｃｅ．ｘｍｌ文件。这是一个包含与ＪＰＡ持久性相关的元数据的标准配置文件。Ｋｏｄｏ还支持一个ｐｅｒｓｉｓｔｅｎｃｅ．ｘｍｌ文件。但是，在应用服务器环境下使用Ｋｏｄｏ的当前较早访问版本时，ｐｅｒｓｉｓｔｅｎｃｅ．ｘｍｌ实际上仅包含资源适配器配置中指定的信息的一个子集，并且仅能由Ｋｏｄｏｅｎｈａｎｃｅｒ这样的工具使用。结束语本文详细讨论如何使用Ｓｐｒｉｎｇ ２．０中新的ＪＰＡ支持，这用于重新实现ＭｅｄＲｅｃ示例应用程序的数据访问层。我们希望本文能够在您开始使用这些新的ＡＰＩ时提供帮助。如果您想要了解更多，我们建议您参考本文提供的实际的ＭｅｄＲｅｃ代码。该示例代码演示了如何结合使用ＷｅｂＬｏｇｉｃ ９．１、Ｓｐｒｉｎｇ ２．０和Ｋｏｄｏ ＪＰＡ。我们发现新的ＪＰＡ ＡＰＩ集易用性、直观性和灵活性于一身。Ｊａｖａ注释使得指定数据库映射所需的元数据的数量大为减少。虽然ＪＰＡ是新产品，但它的功能已经足够强大，使我们的域模型类可继续用于整个应用程序中的持久层、Ｗｅｂ层和 Ｗｅｂ服务层。这种重用使得应用程序架构大为减化，并大大减少开发人员需要编写的Ｊａｖａ类的数目。简单地说，Ｓｐｒｉｎｇ ２．０提供了一个用于创建可利用ＪＰＡ的数据访问对象的高质量工具。Ｓｐｒｉｎｇ的数据访问架构使其能够容易地在不同持久性技术之间切换而无需改写应用程序代码的其他部分。
《BEA dev 2dev 专刊》200615专题
摘要
门户应用程序非常适用于从多个源提取信息以及
为包含门户Ｗｅｂ应用程序的ｐｏｒｔｌｅｔ提供应用服务。对于
用户，ｐｏｒｔｌｅｔ应用程序是独立的实体，类似于桌面上的
窗口应用程序。如果在一个窗口应用程序中执行一项操
作会导致其他所有应用程序中的内容被刷新，那又会怎
么样呢？这就是当前大多数门户的情况。在一个ｐｏｒｔｌｅｔ
中通过页面流进行转移会导致整个Ｗｅｂ页面被刷新，包
括该页面上的其他所有ｐｏｒｔｌｅｔ。
为了避免出现这种有时不希望有的行为，Ｗｅｂ开
发人员采用了所谓Ａｊａｘ风格的编程方法。Ａｊａｘ即异步
Ｊａｖａ和ＸＭＬ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｊａｖａ ａｎｄ ＸＭＬ），它是一个
技术的集合，包括用于创建交互式Ｗｅｂ应用程序的
ＸＨＴＭＬ、ＣＳＳ、ＪａｖａＳｃｒｉｐｔ、ＤＯＭ和ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ对象。
本文将说明在ＢＥＡ ＷｅｂＬｏｇｉｃ Ｐｏｒｔａｌ环境中使用Ａｊａｘ编
程方法的基本原理，并提供了一些最佳实践和建议，以
避免新手Ａｊａｘ程序员经常会犯的许多错误。Ａｊａｘ所解决的门户问题
考虑那些大量使用Ｊａｖａ ａｐｐｌｅｔ而且希望利用其现
有资产创建门户的潜在客户。把现有ａｐｐｌｅｔ和其他页面
流包装到ｐｏｒｔｌｅｔ容器中是一件很简单的事情，但是也要
考虑到进行门户测试时会出现哪些问题。例如，某个
ｐｏｒｌｅｔ中的一个动作会导致刷新以及随后的重新加载，
并重新初始化页面上其他所有基于ａｐｐｌｅｔ的ｐｏｒｔｌｅｔ。如
果所讨论的ａｐｐｌｅｔ具有后端连接，那么ｐｏｒｔｌｅｔ的重新初AJAX 在
BEA WebLogic Portal
中的应用原理
□ 作者：Ｊｏｈｎ Ｍａｒｇａｇｌｉｏｎｅ
始化将导致服务器丢弃现有连接，然后强制ａｐｐｌｅｔ重新进行连接，这不仅加重了服务器的负担，而且会使门户用户看到几秒钟的“静止时间”，在这段时间内，基于ａｐｐｌｅｔ的ｐｏｒｔｌｅｔ必须保持灰色，一直到它们完成初始化为止。这显然是一个潜在的瑕疵。告诉客户们重写所有的ａｐｐｌｅｔ，因为基于ＪＳＰ的应用程序并非有用的响应，尤其是对于已经在现有资产中投入大量资源的客户来说。此外，门户必须帮助客户包装现有的应用程序，而不是强迫他们重写整个系统。我们需要一种让单个ｐｏｒｔｌｅｔ在不引起页面刷新的情况下进行操作或获得新数据的方法。虽然这显然存在一些不利之处（我将在本文后面讨论这些），但是在这种情况下，把避免页面刷新作为使用门户的进入屏障是完全有必要的。注：对于这个问题，一个可行的解决方案是ｉｆｒａｍｅｓ，也就是ｉｎｌｉｎｅ ｆｒａｍｅｓ，一种基于浏览器的机制，它可以使
屏幕的一块区域变为独立的实体，当页面重新加载时它
不会刷新。使用类似于Ａｊａｘ编程中所使用的技术，我们可以使用ＸＭＬ－ＲＰＣ进行服务器调用，从而获取数据并将其加载到ＤＯＭ文档中。Ａｐｐｌｅ的开发者Ｗｅｂ站点上有一篇文章（Ｒｅｍｏｔｅ Ｓｃｒｉｐｔｉｎｇ ｗｉｔｈ ＩＦＲＡＭＥ）非常好地总结了这种方法的优点和缺点。我确信，关于为什么ｉｆｒａｍｅｓ更好或Ａｊａｘ更好，双方的支持者已经进行过精彩的辩论，但是Ａｊａｘ已经流行开来，而ｉｆｒａｍｅｓ则没有。因此，本文只介绍了Ａｊａｘ，而没有就ｉｆｒａｍｅｓ进行讨论。
16
dev https://www.doczj.com/doc/cd16467693.html, 专 题
用例
在下列情形下，Ａｊａｘ技术很有用处：
● 门户中使用了一个或多个基于ａｐｐｌｅｔ的ｐｏｒｔｌｅｔ。例子：参见前面内容中描述的场景。
● ｐｏｒｔｌｅｔ需要定期刷新其数据或重绘其内容。
例子：一个带有股票价值表的可执行面板，这些值
每分钟都要更新。
● 使用Ｐｏｒｔｌｅｔ间通信（Ｉｎｔｅｒ－ Ｃｏｍｍｕｎｉｃａｔｉｏｎ，ＩＰＣ）
而不能刷新整个Ｗｅｂ页面。
例子：一个列出股票名称的ｐｏｒｔｌｅｔ需要更新另一个
用于简要描述这些股票的当前状态（比如股票的当前价格、最高价格和最低价格）的ｐｏｒｔｌｅｔ。
● 页面包含大量通常为静态的数据，这样页面操
作只需要置换少量数据。
例子：Ｇｏｏｇｌｅ地图。
● 一个ｐｏｒｔｌｅｔ需要基于在此ｐｏｒｔｌｅｔ中的其他地方所
做的选择来检索一个有限的数据集。
例子：一个表单有３个组合框：Ｓｔａｔｅ、Ｃｉｔｙ和ＺＩＰ。当用户选择一个州时，该州所有的城市名称都将出现在Ｃｉｔｙ组合框中。然后，用户从Ｃｉｔｙ组合框中选择一个城市，接着ＺＩＰ组合框中就会显示该城市所有有效的邮政编码。
示例架构
Ａｊａｘ技术的核心是Ｗｅｂ浏览器对一些负责提供信
息的Ｗｅｂ服务的调用。如何为该解决方案设计架构呢？有３种值得考虑的架构。第一种架构使用Ｗｅｂ浏览器作为集成点，出于随之而来的安全考虑和浏览器方面的问题，该架构存在问题。第二种解决方案使用代理来获取分布的资源，这消除了安全问题，但是添加了一个单点故障。第三种架构使用企业服务总线（ｅｎｔｅｒｐｒｉｓｅ ｓｅｒｖｉｃｅｂｕｓ，ＥＳＢ）来消除单点故障，并为Ｗｅｂ服务和Ａｊａｘ技术的蓬勃发展提供了最适宜的环境。
以浏览器为中心
在以浏览器为中心的架构中，Ｗｅｂ浏览器成为联
系远程系统的中心点，如图１所示。数据从各个远程系
统中获得，然后在浏览器处的ＪａｖａＳｃｒｉｐｔ中进行整理和排序。这种架构是最自然的设计，它具有多处设计缺陷：1. ＪａｖａＳｃｒｉｐｔ是一种糟糕的集成语言／环境。Ｊａｖａ在各个方面都要比它好得多。2. 浏览器必须通过每个系统的身份验证，而且可能使用不同的方法。3. 缓存静态信息的能力很差，这会导致整个系统出现很长的延迟，这首先就失去了使用Ａｊａｘ方法的意义！代理服务如图２所示，代理服务消除了第一种架构的所有缺陷，但是它也有自己的不足之处。它导致出现了一个系统单点故障。当然，Ｗｅｂ服务器可以作为带有硬件负载平衡器的集群的一部分。这无疑可以解决这个问题。尽管这种架构比起以浏览器为中心的架构已经有了巨大的改进，还可以做得更好。我们已经为Ｗｅｂ开发人员提供了一个非常好的环境，但是这很可能为后端系统开发人员带来不便。对远程系统进行身份验证以及数据整理仍然是必要的，但是至少后端程序员应该有更多可使用的工具来迎接挑战。企业服务总线图３与前面的两幅图又有所不同，因为企业服务总图
１：以浏览器为中心的架构
《BEA dev 2dev 专刊》200617专题线（ＥＳＢ）架构是一种逻辑架构。服务可以位于网络上的任意位置，数据源可以被抽象到（可插入到ＥＳＢ中的）服务中。ＥＳＢ为后端系统开发人员处理了他们通常必须做的工作，比如服务身份验证、数据转换、协议转换和可靠性特征。ＥＳＢ可以扩展到带有硬件负载平衡器的计算机集群上，这提供了代理服务架构所具有的优点。
为了说明在门户中对Ａｊａｘ应用程序使用ＥＳＢ的优
点，考虑对于每次Ａｊａｘ调用都要引用一个Ｗｅｂ服务的情况。对于小型门户来说，Ｗｅｂ服务的数量可能相对较少，譬如说几十个。但是随着门户的增长，将会引入更多的Ｗｅｂ服务。大量Ｗｅｂ服务的添加与Ａｊａｘ没有关系，但是与ＳＯＡ的实现有着密切的联系。这是一个ＥＳＢ的经典用例。尽管从严格意义上来说，它对于Ａｊａｘ实现的操作不是必要的，但是它还是带来了几个好处：
● ＥＳＢ消除了对ＰｒｏｘｙＳｅｒｖｌｅｔ类（稍后将会介绍）的需求，因为代理服务更好地完成了同样的工作；● ＥＳＢ支持监控和管理单个Ｗｅｂ服务，同时无需在每个Ｗｅｂ服务中增加额外的代码。这包括监控服务水平协议（ＳＬＡ）和报告违反情况；● ＥＳＢ可以保护Ａｊａｘ代码不会被外部提供者修改。如果外部提供者以一种无需修改门户用户界面但需要修改Ａｊａｘ调用代码的方式修改了ＷＳＤＬ，那么就有可能在ＥＳＢ的代理服务中修改配置，而不用修改Ａｊａｘ代码。为什么这样做比修改Ａｊａｘ代码更好呢？我认为，在ＥＳＢ中代理服务的配置中进行小的改动比起在ＪａｖａＳｃｒｉｐｔ中对每个到相关服务的引用进行修改更不容易出错。此外，对于同样的信息（比如股票报价查询）还可以使用多个外部提供者，但是每个提供者具有不同的调用接口并返回ＸＭＬ。如果某个提供者出现故障或者只是为了进行负载平衡，使用多个提供者就很有利了。在ＥＳＢ中可以轻松实现这一点，但是在ＪａｖａＳｃｒｉｐｔ中这几乎是不可能的。在这里的例子中，我之所以使用了以浏览器为中心的架构和代理服务架构，是因为作为例子来说，它们比较简单，但是我希望能够使您相信，Ａｊａｘ是体现ＥＳＢ优点的非常不错的方式。对门户使用的影响当在门户内采用Ａｊａｘ编程方法时，出现了几个问题。这些问题中的大多数与门户的生命周期以及如何／何时挑选用户信息有关。具体来说，门户要使用诸如用户在哪里单击之类的信息来决定向其显示何种类型的相关信息。ＷｅｂＬｏｇｉｃ Ｐｏｒｔａｌ具有一种叫做ｃａｍｐａｉｇｎ的特性，它允许门户设计人员基于用户个人信息指定对用户的有目的广告宣传。用户个人信息中包括用户的页面历史，即，用户过去点击过的页面。门户在页面刷新时收集这类信息，所以如果用户从未刷新页面，门户就无法（容易地）自动收集用户信息。但Ａｊａｘ编程也可能对门户产生的以下副作用：● 不可跟踪性使ｃａｍｐａｉｇｎ得不到有效使用（参见上面的内容）；● 页面刷新重置了ＤＯＭ树，
所以当用户最终刷新
图
２：代理服务架构
图３：企业服务总线
18dev https://www.doczj.com/doc/cd16467693.html, 专 题
页面时，所有对使用Ａｊａｘ修改过的ｐｏｒｔｌｅｔ的更新都会丢失。对ｐｏｒｔｌｅｔ内容的修改将会丢失，还原为初始的页面状态；
● ＪＳＰ中的所有ＪａｖａＳｃｒｉｐｔ都是整个页面共用的。考虑一个包含在每个ｐｏｒｔｌｅｔ中的ＪａｖａＳｃｒｉｐｔ片断。当呈现最终的ＨＴＭＬ页面时，ＪａｖａＳｃｒｉｐｔ片断将在包含它的每个ｐｏｒｔｌｅｔ中重复使用。类似地，如果已经将两个ｐｏｒｔｌｅｔ嵌入了ＪａｖａＳｃｒｉｐｔ，而且每个ｐｏｒｔｌｅｔ的脚本都有一个名为ｇｅｔＤａｔａ（）的方法，那么最终的ＨＴＭＬ页面将会有两个不同的ｇｅｔＤａｔａ（）函数定义。调用该函数时很可能导致调用不正确的方法。如果有两个名为ｉｓＯＫ（）的变量，也会出现同样的情况。
使用适当的编码风格可以防止这些问题的发生，比如给所有变量和函数取独有的名称，或者使用ｃｏｏｋｉｅｓ来保存ｐｏｒｔｌｅｔ中使用的当前数据。
一种最佳实践是在所有脚本中使用独有的变量和函数名称，具体做法是在每个变量和函数的名称前加上包含它们的ｐｏｒｔｌｅｔ的名称。
浏览器战争尚未结束，专有浏览器和基于标准的浏览器之间的战争仍在延续。Ａｊａｘ相当有趣的一点是，其中有一半是标准（ＸＨＴＭＬ、ＸＳＬＴ、ＪａｖａＳｃｒｉｐｔ／ＥＣＭＡＳｃｒｉｐｔ、ＤＯＭ和Ｗｅｂ ｓｅｒｖｉｃｅｓ）驱动的。但是其核心技术——ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ对象——来自微软。
下面列出了在进行跨浏览器的Ａｊａｘ编程时要注意的一些重要的常见错误，以及如何避免这些陷阱。安全性
ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ对象直接把浏览器连接到一台远程主机，要么是加载页面的Ｗｅｂ服务器，要么是另一个完全不同的服务器。正如您所想像的，这里为恶意软件提供了大量的机会。例如，一段恶意的ＪａｖａＳｃｒｉｐｔ可能等着用户输入口令字段，然后把口令传递给一个远程浏览器，而用户却不知道，甚至还没有单击页面上的提交按钮。如果把口令换为信用卡号码，事情就变得更加糟糕了。
为了避免这种风险，Ｍｏｚｉｌｌａ拒绝到为Ｗｅｂ页面提供服务的主机之外的任意主机的连接。用户不会看到错
误消息，因为它根本就不会运行！Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（ＩＥ）采用另一种方法。当要求连接到远程主机时，将使用一个对话框通知用户，而用户可以决定执行什么操作。但是要注意，该对话框不会告诉用户要连接到哪个站点，所以用户缺乏可以用于做出决策的信息。这个问题的解决方案是使用一个Ｊａｖａ ｓｅｒｖｌｅｔ作为到Ｗｅｂ服务的代理。该ｓｅｒｖｌｅｔ获得所有的参数，并把它们传递给远程服务，接着将响应返回给Ｗｅｂ站点。通过让ｓｅｒｖｌｅｔ运行在创建Ｗｅｂ页面的Ｗｅｂ服务器上，Ｍｏｚｉｌｌａ就会认为服务是本地的。注意，这是企业服务总线（比如ＡｑｕａＬｏｇｉｃ Ｓｅｒｖｉｃｅ Ｂｕｓ）的一个绝好用例。使用ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ对象包含ＸｍｌＨｔｔｐＲｅｑｕｅｓｔ对象的ＸｍｌＨｔｔｐ库最初是随Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ ４一起发行的ＡｃｔｉｖｅＸ控件。Ｍｏｚｉｌｌａ包含一个兼容的函数库，所以没有什么好担心的。我仍然推荐使用一个开源库，比如Ｓａｒｉｓｓａ或ＤＷＲ（Ａｎ Ｉｎｔｒｏ－ｄｕｃｔｉｏｎ ｔｏ Ａｊａｘ中使用了它）。然而，它们在将ＸＭＬ数据传递到对象的方式上存在着细微的区别。更新ＤＯＭ节点Ｍｏｚｉｌｌａ和ＩＥ之间最令人恼火的区别就是Ｗｅｂ页面中对ＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ，文档对象模型）的处理。大多数函数的工作方式是一样的（至少在ＤＯＭＬｅｖｅｌ ２上），但是仍然有很多值得注意的地方。下面给出两个例子。ｉｎｎｅｒＨｔｍｌ与ｉｎｎｅｒＴｅｘｔ的使用当使用新的动态内容更新＜ｄｉｖ＞标签时，ＩＥ用户有图
４：没有有用的信息