Java EE:迎合Web 2.0[Java编程]

很多成功的企业利用程序都是利用 Java EE 平台构建的.但是,Java EE 的计划原理并不可以有效地支持 Web 2.0 利用程序.深化理解 Java EE 和 Web 2.0 原理之间的脱节可帮忙您拟定明智的抉择,从而利用各种办法和工具在一定程度上办理这种脱节.本文将解答 Web 2.0 和尺度 Java EE 平台缘何成为失利的组合,并演示为什么由事件驱动的异步架构更合适 Web 2.0 利用程序.本文还介绍了一些框架和 API,它们通过支持异步计划使得 Java 平台越发合适 Web 2.0.

Java EE 原理和假想

Java EE 平台的成立目的就是为企业到客户（B2C）和企业到企业（B2B）利用程序供应支持.企业发现了 Internet 的代价之后就开始利用它加强与合作搭档和客户之间的现有业务流程.这些利用程序普通要与一个现有企业集成系统（EIS）举行交互.大大都常见基准测试（测试 Java EE 服务器的性能和可伸缩性）— ECperf 1.1、SPECjbb2005 和 SPECjAppServer2004— 的用例都将这一点反映到了 B2C、B2B 和 EIS 中.近似地,尺度的 Java PetStore 演示也是一个典型的电子商务利用程序.

很多有关 Java EE 架构可伸缩性的明显和暗含的假想都反映在基准测试中:

从客户机角度来看,恳求吞吐量是影响性能的最重要特点.

事件持续时间是最重要的性能因素,并且,缩减全部个体事件的持续时间将改进利用程序的总体性能.

事件之间普通都是彼此独立的.

除长期履行的事件以外,只有少数业务对象会受事件影响.

利用服务器的性能和布置在同一管理域的 EIS 会限制事件的持续时间.

通过利用衔接池可以抵消一定的网络通信本钱（在处理本地资源时产生）

通过对网络配置、硬件和软件举行优化,可以缩短事件持续时间.

利用程序全部者可以掌握内容和数据.在不依靠外部服务的前提下,向用户供应内容的最重要限制因素是带宽.

性能和可伸缩性问题

Java EE 平台最初的计划目的是利用布置在单个管理域中的资源操作服务.其假想的前提是 EIS 事件生存期较短并且恳求处理较快,从而使平台可以支持较高的事件负载.

很多新兴架构办法和情势 — 比方对等（P2P）、面向服务架构和统称（非正式地）为 Web 2.0 的新型 Web 利用程序 — 不满意这些假定.在这些利用程序的利用场景中,恳求处理将占用更长的时间.因此,当利用 Java EE 办法开辟 Web 2.0 利用程序时,将呈现严重的性能和可伸缩性问题.

这些假想产生了以下 Java EE API 构建原理:

同步 API.Java EE 在很多利用中都需求利用同步 API（重量级并且烦琐的 Java Message Service (JMS) API 基本上是惟一的例外）.这种需求更多地源于可用性的需求,而非性能需求.同步 API 易于利用并且开销较低.但需求处理大型多线程时,则会呈现严重问题,因此 Java EE 严峻限制未受掌握的多线程处理.

有限的线程池.人们很快发现线程是种重要的资源,并且当线程数目超越某一边界后,利用服务器的性能将明显下降.但是,按照每个操作都很短暂的假想,这些操作可以分配到一组有限的线程中,从而保持较高的恳求吞吐量.

有限的衔接池.假如只利用一个数据库衔接,则很可贵到最优的数据库性能.固然一些数据库操作可以并行履行,但是增添额外的数据库衔接只能将利用程序提速到某一点.当衔接数到达某一值后,数据库性能将开始下滑.普通,数据库衔接的数目要小于 servlet 线程池中可用线程的数目.因此,衔接池在成立时答应向服务器组件 — 比方 servlet 和 Enterprise JavaBeans (EJB) — 分配一个衔接并在今后返回给衔接池.假如衔接不可用,组件将等候阻塞当前线程的衔接.因为其他组件只对衔接占用很短的时间,因此这种耽误普通较短.

固定的资源衔接.利用程序被假定只利用很少一些外部资源.与各个资源的衔接工厂通过 Java Naming and Directory Interface (JNDI)（或 EJB 3.0 的依靠性注入）得到.实际上,支持与差别 EIS 资源举行衔接的主要 Java EE API 只有企业 Web 服务 API.其他 API 大都都假定资源是固定的并且只有诸如用户凭证这样的额外数据应当供应应开放衔接操作.

在 Web 1.0 中,这些原理玩转得非常好.可以将一些独特的利用程序计划为服从这些法则.但是,这些原理不能有效支持 Web 2.0.

　　以上是“Java EE:迎合Web 2.0[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：