分布式企业应用程序的交互软件组件可以看作是分别驻留在多个逻辑层中。根据所提供服务的性质,这些层分别表示软件组件的逻辑和物理独立性。
多数情况下,逻辑层体系结构表示图 1–1 中所示的分布式企业应用程序层。基础结构服务级别介绍的 Java ES 系统服务组件为图 2–4 所示的所有逻辑层中的应用程序组件提供支持。不过,逻辑层概念也适用于提供应用程序级服务的系统服务组件,如 Messaging Server 和 Calendar Server。
本节简要描述图 2–4 所示的四个逻辑层。在描述中引用了采用 Java 2 Platform, Enterprise Edition(J2EETM 平台)组件模型实现的应用程序组件。但是,其他分布式组件模型(如 CORBA)也可支持此体系结构。
客户层。客户层由最终用户通过用户界面直接访问的应用程序逻辑组成。客户层中的逻辑可以包括基于浏览器的客户机、在台式计算机上运行的 Java 组件,或是在手持设备上运行的 Java 2 Platform, Micro Edition(J2METM 平台)移动客户机。
表示层。表示层由应用程序逻辑组成,应用程序逻辑负责准备要传送给客户层的数据并处理来自客户层的请求,以便传送给后端业务逻辑。表示层中的逻辑通常由 J2EE 组件组成,如 Java Servlet 组件或 JSP 组件,它们为 HTML 或 XML 格式的传送准备数据或接收请求以便进行处理。此层还可能包括门户服务,该服务可对业务服务层中的 business service(业务服务)提供个性化、安全和定制的访问。
业务服务层。业务服务层由执行应用程序主要功能的逻辑组成,这些功能有:处理数据、实现业务规则、协调多个用户以及管理诸如数据库或传统系统之类的外部资源。通常,此层由符合 J2EE 分布式组件模型的紧耦合组件组成,如 Java 对象、EJB 组件或消息驱动 Bean。可将单个 J2EE 组件组合起来提供复杂的业务服务,如库存服务或计税服务。单个组件及服务组合体可在面向服务的体系结构模型内封装起来作为符合简单对象访问协议 (Simple Object Access Protocol, SOAP) 接口标准的松耦合 web service(Web 服务)。业务服务还可以组建为独立的 server(服务器),如企业日历服务器或消息传送服务器。
数据层。数据层由提供业务逻辑所用永久性数据的服务组成。这些数据可以是数据库管理系统中存储的应用程序数据,也可以是轻型目录访问协议 (Lightweight Directory Access Protocol, LDAP) 数据存储器中存储的资源和目录信息。这些数据服务还可以包括自外部源馈送而来的数据或可从传统计算系统中访问的数据。
图 2–4 中所示的体系结构维强调了组件的逻辑和物理独立性,由四个独立的层表示。这些层表示联网环境中各台计算机上划分的应用程序逻辑:
逻辑独立性。该体系结构模型中的四层表现逻辑独立性:对某一层中(例如在业务服务层中)的应用程序逻辑的修改可以独立于其他层。无需更改或升级表示层或客户层中的逻辑即可更改您的业务逻辑实现。举例而言,这种独立性意味着:无需修改业务服务组件即可引入新型客户组件。
物理独立性。这四层还表现物理独立性:您可以在不同的硬件平台(即,不同的处理器配置、芯片组和操作系统)上部署不同层中的逻辑。利用此独立性,您可以在最适合各自计算要求和最适合最大化网络带宽的计算机上运行分布式应用程序组件。
您将应用程序组件或基础结构组件映射到硬件环境(即您的部署体系结构)的方式取决于多种因素,具体要根据软件解决方案的规模和复杂性来决定。对于规模很小的部署,部署体系结构可能只涉及几台计算机。而对于较大规模的部署,组件到硬件环境的映射可能需要考虑多个因素,如不同计算机的速度和功效、网络链路的速度和带宽、安全和防火墙考虑事项,以及获得高可用性和可伸缩性的组件复制策略。
如图 2–3 中所示,Java ES 基础结构服务组件为分布式软件解决方案提供底层基础结构支持。但其中有些解决方案包括 Java ES 组件直接提供的应用程序级服务。这些解决方案使用逻辑层设计方法。
例如,Messaging Server 提供的电子邮件通信服务使用多个逻辑上完全不同的 Messaging Server 配置来实现。这些独特的配置各自提供一组独特的服务。在设计消息传送解决方案时,这些独特的配置被表示为位于不同逻辑层的独立组件,如下图所示。
图 2–5 并不是一个完整的逻辑体系结构,为了简化,示意图省略了许多 Java ES 组件。连接组件的线条表示各组件间的交互。
在逻辑上将 Messaging Server 各功能分成独立的层,可使这些逻辑上不同的 Messaging Server 配置部署在物理环境中的不同计算机上。物理分离可以更加灵活地满足不同的服务质量要求(参见第 3 维:服务质量)。例如,它为不同实例提供不同的可用性解决方案,为不同 Messaging Server 功能提供不同的安全性实现。