例如，门户通常就属于此类别，这是因为它们通常需要在所有三个层实现多重性 — 对于表示层，体现在门户通常组合了公司各个部分（或部门，或不同的公司，甚至可能是不同的移动家庭）的不同 web 应用程序，对于业务逻辑层，体现在特定“portlet”有时将需要调用由不同的 portlet 的后端提供的功能，对于数据访问层，体现在大多数 portlet 拥有自身的用于交互的数据库（或数据库集，目的是使事物更有意义），但更有趣的是，给定用户的会话通常需要跟踪进程中的信息，即使用户在各种 portlet 之间来回移动。在许多方面，门户及其关联 portlet 是企业应用程序的典范。

“在许多方面，门户及其关联 portlet 是企业应用程序的典范。”

精通J2EE应用程序开发之交叉分析J2EE(3)

它将我们至于何处？

此类分类本身就足够出色了，因此会让技术哲人们陶醉好一段时间，但这究竟与构建如今的企业 Java 应用程序有多大关系呢？

首先也是最重要的是，企业 Java 开发人员必须尽快确定他们被要求构建的应用程序属于以上五种应用程序的哪一种。如果是传统的烟囱系统，则选择哪种技术并不像其他四个应用程序那样重要。当出现 Web 服务问题时，将其看作是其他表示层（意味着您现在在查看珠宝应用程序）而不仅仅看作是 Struts 代码与业务逻辑之间使用的模型对象扩展。实际上，在很多方面，模型视图控制器模式是表示层本身的一部分，而并不是延伸到业务逻辑层的什么东西，这是因为执行有效的“不同”表示层通常将要求我们针对如何与后端交互进行不同的选择，如（对于 Web 服务）将系统的“面向对象”的本质抛在后面。

当出现多个数据库或其他后端问题时，请考虑故障可分性和使用分布式事务实现可分性的需要，以及拥有一个良好的间接可热交换层来访问资源的故障切换建议。当现有系统之间的集成成为问题时，请记住除 Web 服务以外还有很多选择（尽管 Web 服务方法比较实用并且通常被看作是标准），并记住消息驱动的系统以及是否可以将业务逻辑置于数据库本身中以便其他需要与该系统交互的平台更容易地访问此数据库。

请记住，J2EE 只是用于实现某个目标的方法，对于任何技术的武断看法通常将失去技术作为总体的意义。例如，不要试图在烟囱系统上使用 EJB，这是因为 EJB 主要适用于事务处理（尤其是两个阶段的提交事务处理，此种事务处理比较占用资源并且必须在作为同一事务一部分的两个或更多资源中获取可分性），但当聚合器应用程序依靠您执行操作时不要忽略它的使用。当 JMS（和消息驱动 bean，当需要事务处理时）的异步本质更适合于此目的时，不要尝试将所有内容编写为会话 bean。等等。

其次，一定要始终确切地牢记应用程序的性能和可伸缩性目标（参见我的《高效企业 Java》一书）。尽管这对于以任何语言编写的任何应用程序通常都很重要，但在企业 Java 领域中更重要，这是因为企业 Java 开发人员有那么多的技术可以选择。您的系统需要为每个用户操作提供亚秒级响应？基于浏览器的应用程序（尤其是跨广域网应用程序）很难实现此目标，这是因为 HTML 浏览器通常需要大约一秒的时间来处理甚至是中等复杂的 HTML 页；或许一个更好的方法是考虑通过 JavaWebStart 提交的“富客户端”前端，以便使跨网络传送的数据数量尽可能得小，以及接收数据的时间尽可能得短（以避免分析

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