Java EE：迎合Web 2.0 - 编程入门网

固定的资源连接。应用程序被假设只使用很少一些外部资源。与各个资源的连接工厂通过 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(2)

Web 2.0 带来的巨变

Java EE 迎合 SOA

SOA 的引入首先对 Java EE 提出了挑战。在 SOA 中，交互通常产生很高的吞吐量，并且由于要跨多个域到达服务端点，因此很可能会产生较高的延迟。一些交互可能还需要得到操作人员的允许，而这种批准流程可能会产生几小时到几周的延迟。各种中间流程通常会使延迟情况进一步恶化，SOA 的出现就是为了支持这些中间流程。

通过利用事务消息传递 API 并引入业务流程概念，Java EE 平台已经解决了延迟带来的难题。SOAP-over-HTTP Web 服务调用模型和诸如 JMS 之类的消息传递服务之间一直不太匹配。HTTP 使用同步请求/响应模型并且没有提供任何内置的可靠特性。诸如 WS-Notification、WS-Reliability、WS-ReliableMessaging 和 WS-ASAP 这些规范试图针对部署在 B2B 环境中的 Web 服务解决这种错误匹配。但是对于 B2C 场景，通常部署的是富应用程序客户机，因为这种客户机可以使用特定于场景的交互模式（相对于 Web 应用程序）处理高延迟。

Web 2.0 应用程序具有很多独特需求，因此，不适合将 Java EE 用于 Web 2.0 实现。其中一个需求就是，Web 2.0 应用程序更多地通过服务 API 使用另一个 Web 2.0 应用程序，而不是使用 Web 1.0 应用程序。Web 2.0 应用程序的一个更为重要的因素是，极度倾向于用户到用户（C2C）交互：应用程序所有者只生成一小部分内容；用户负责生成大部分内容。

SOA + B2C + Web 2.0 = 高延迟

在 Web 2.0 环境中，聚合应用程序经常使用通过 SOA 服务 API 公开的服务和提要。这些应用程序需要在 B2C 环境中使用服务。例如，一个聚合应用程序可能从三个不同的数据源提取数据，如天气信息、交通信息和地图。检索这三种独特数据所需的时间延长了总的请求处理时间。不管数据源和服务 API 的数量是否增加，用户仍然期望得到具有高反应度的应用程序。

诸如缓存这类技术可以缓解延迟问题，但是不适用于所有场景。比如，可以缓存地图数据来减少响应时间，但通常并不适合将搜索查询结果或者实时交通信息进行缓存。

服务调用本来就是一种高延迟过程，在客户机和服务器上通常只分配很小一部分 CPU 资源。Web 服务调用的持续时间很大一部分用于建立连接和传输数据。因此，通常来讲，提升客户端或服务器端的性能对于减少调用持续时间效果甚微。

更好的交互性

Web 2.0 对用户参与的支持引发了另外一大挑战，因为应用程序要处理来自每个活动用户的更多数量的请求。下面这些理由证明了这一点：

因为大多数事件是由其他用户的操作引起的，因此会引发更多相关事件，并且用户具备更强大的能力来生成事件。这些事件通常使用户能够更加积极地使用 Web 应用程序。

应用程序为用户提供了更多的用例。Web 1.0 用户仅仅可以浏览类别、购买商品并跟踪他们的订单处理状态。现在，用户可以通过论坛、聊天、聚合等等方法与其他用户进行积极地交流，这将产生更高的通信负载。

如今的应用程序越来越多地使用 Ajax 改善用户体验。与普通 Web 应用程序的页面相比，使用 Ajax 的 Web 页面加载要慢一些，因为页面是由一些静态内容、脚本（可能会非常大）和

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!