| 本文为使用 BEA WebLogic Platform™ 8.1 构建的软件应用程序提供了架构和应用程序最佳实践。讨论的技术包括 BEA WebLogic Server 、 WebLogic Portal 、 WebLogic Integration 、 WebLogic Workshop 和 Liquid Data for WebLogic 。本文使用 4+1 视图模型描述了利用 WebLogic Platform 8.1 构建的应用程序架构，本文的读者对象是企业架构师和应用程序架构师。
简介
4+1 视图模型是描述软件应用程序架构的常见方法。此模型的五个视图是：
- 开发视图（也称为"实现视图"）
- 物理视图（也称为"部署视图"）
- 过程视图（也称为"并发视图"）
- 逻辑视图（也称为"设计视图"）
- 用例视图 （ 也称为"需求视图" ， 该视图即为" 4+1 " 中的" +1 " ）
4+1 视图模型主要用于描述特定的软件应用程序。在本文档中， 4+1 视图模型用于描述构建在 BEA WebLogic Platform 上的任何应用程序的软件架构。具体来说，此模型介绍了典型的 WebLogic Platform 组件，以及与每个视图相关的最佳实践。由于侧重于广泛介绍产品和功能，本文没有过多地深入介绍单个产品细节。更确切地说，本文重在说明如何使用整个平台构造可维护的、架构上稳固的软件应用程序。
本文没有描述特定的软件应用程序，因此， 也 没有指定任何用例。为此，用例视图已被略去。同样，由于不存在需要在逻辑视图中详细介绍的用例实现，因此，逻辑视图已被略去。视图按照有利于读者了解如何使用 BEA WebLogic Platform 构建系统的顺序进行排列。因此，此顺序不同于为特定应用程序指定架构时通常使用的顺序。但是，每个视图都是以自成体系的方式进行介绍，这样便于读者按照自己需要的顺序查看视图。
本文不是一篇产品介绍、产品教程 ， 也不是一篇产品特性、功能或内部运作的描述。本文结尾处向读者推荐一些其他的文章。本文的读者需要熟悉 4+1 视图模型、面向对象的分析和设计，以及 J2EE ，并且具有统一建模语言（ Unified Modeling Language ， UML ）的使用知识。
开发视图
下图给出了构建在 WebLogic Platform 上的应用程序的开发视图 （ 也称为“实现视图” ）：
图 1. 普通 WebLogic Platform 应用程序的开发视图
在开发视图中 ， 应用程序架构分为四层 :
其中每一层都为总体应用程序架构提供特定的功能集合。根据这些层对应用程序的组件进行分割和模块化，可以使系统更具有可维护性。对于大型应用程序而言，它还允许划分开发团队，并指派他们负责特定的层，同时在这些层之间具有定义良好的交互。
应用程序中不一定需要存在所有的层。在应用程序范围的一端 ， 简单的 CRUD （ 创建、阅读、更新、删除 ） 应用程序可能仅拥有“表示和接口”和“数据访问和集成”层。这种简单的应用程序可以不包含任何业务逻辑或提供连接到其他系统的接口。实际上，它是一个两层的 Web 应用程序。应用程序范围的另一端是过程门户，过程门户包括个性化界面、业务流程增强、复杂的业务逻辑和访问多种后端系统（如 CRM 、 SCM 和 ERP ）。
层间通信
在构造应用程序时，任何组件应该只能访问本层或所有较低层的组件。充分的证据表明，这一规则很少出现特例。组件可以对不相邻的较低层进行访问。例如，表示和接口层中的组件可以直接访问业务逻辑层中的组件，无需使用业务流程层中的任何组件。然而，重要的是还要记住，这些层的存在都是有一定道理的，不应该任意绕过一个层。
WebLogic Platform 包括一种回调机制 ，乍看 上去好像违反了较低层访问较高层的限制。例如， Web service 是一个 表示层的组件，可以接收自定义 Java 控件（较低的业务逻辑层的一个组件）的回调。但是，回调是针对较高层组件调用较低层组件所设置的响应通道。较高层组件“发起”回调，并为它所接收的回调显式地提供处理程序。因此，回调是符合层间通信规则的，并且实际上为组件间的异步通信提供了一种简单的机制。
分层和 SOA
通过编程接口 ， 可以在表示和集成层中公开业务流程层和业务逻辑层的组件。公开编程接口允许应用程序作为提供者参与面向服务的架构（ Service-Oriented Architecture 。 SOA) 。数据访问和集成层允许该应用程序消费 SOA 中其他系统提供的服务。换句话说，这一应用程序架构有利于实现真正的 SOA （即，在应用程序之间可以共享业务逻辑和业务流程），从而通过面向服务的应用程序开发（ Service-Oriented Development of Applications ， SODA ）促进复合应用程序构造。
以下章节将要讨论开发视图中的各个层 ， 并简述了每个层中的组件。
表示和接口层
表示和接口层负责提供到应用程序的接口。它的形式可能是 Web 或门户应用程序的浏览器界面，也可能是富客户端或其他系统的编程接口。浏览器界面在远程位置运行，并通过 HTTP 或安全 HTTP 访问应用程序；而编程接口可以使用 HTTP 、 SOAP 、 RMI 、 RMI/IIOP 、 ebXML 或 RosettaNet 。
Web 界面 提供了进入应用程序的最简单的用户界面。 Web 浏览器客户端应用程序是承载所有 Web 应用程序用户界面的平台。除了由 JavaScript 处理的客户端内容之外，浏览器中显示的内容大多数是静态内容。客户端处理通常用于执行轻量级初始数据验证或者可视化增强用户界面。
门户接口为用户提供了统一接口中应用程序和信息的单点访问。门户接口通过可重用门户资源将定制内容和应用程序提供给大众。使用门户接口还可以轻松组织和访问大型数据。这使得门户接口成为企业到客户 (B2C) 和企业到员工 (B2E) 应用程序的理想选择。
编程接口允许其他应用程序对这一应用程序的数据、业务流程和业务逻辑进行访问。设计编程接口时应该三思而后行，因为该接口是这一应用程序和客户端应用程序之间的公共契约。该接口的任何改变都很可能对客户端应用程序产生重大影响。因此，该接口设计时应该抽象出底层实现，从而使该应用程序的改变不会带动客户端应用程序的改变。
WebLogic Platform 支持 HTTP （ S ） 、 SOAP （ 或 Web services ） 、 RMI 、 RMI/IIOP 、 ebXML 和 RosettaNet 。对于企业到企业 (B2B) 应用程序来说， ebXML 和 RosettaNet 是首选，未来的应用程序一般都会这样选择。 SOAP 与 RMI/IIOP 之间的选择 则没有这么明确。一般情况下， SOAP 接口常用于 RMI 或 RMI/IIOP 。 SOAP 接口的好处是：
- 平台和语言无关
- 与其他 Web service 架构可以实现互操作
- 支持回调
- 易于使用的异步和会话语义
- 支持 SOA
- 较少的源于 XML （ 非二进制 ） 接口的固定接口
- 更轻松地支持以文档为中心的接口
RMI 或 RMI/IIOP 的好处在于其原始性能。 SOAP 消息的解析将产生二进制协议所没有的额外计算开销。因此，如果性能是主要考虑因素，那么选择 RMI 或 RMI/IIOP 较好。
下面描述了表示和接口层中的每个组件、组件与其余应用程序的交互，以及与组件相关的设计注意事项：
业务流程层
图 1 中描述的业务流程层负责提供业务流程管理 （ Business Process Management ， BPM ） 。 业务流程作为过程定义或过程定义组合创建。业务流程可以是一个完全自动化的过程，也可以是一个包括人与系统交互的过程。如果业务流程中涉及人为活动，就会使用工作列表控件提供到过程定义的连接点。
业务流程层与到系统或人的表示或接口无关。 相反，表示和接口层负责表示所有业务流程的用户界面，不管是自动的（该接口是编程接口）还是人工交互的。在业务流程层开发的代码应该不具有任何表示或接口逻辑。
以下部分描述了业务流程层中显示的每个组件、组件与其余应用程序的交互以及与组件相关的所有设计注意事项。
过程定义
过程定义组件用于捕获业务流程 ， 因此是业务流程层的核心。 过程定义应该封装特定过程，而不是用作 Java 中编写业务逻辑的替代项。最初目的就是将过程定义绑定在一起，并编排单个业务逻辑组件之间的交互。
在很多应用程序中 ，有一些 低级过程与高级过程是通用的。 同样，过程定义组件可以建模高级过程，然后调用对低级过程进行建模的其他过程定义。当执行应用程序的用例分析时，其他用例中包括的用例是这些可重用过程定义的主要候选项。
过程定义的启动可以通过客户端请求 （ 即同步 ）， 也可以通过消息代理程序发送的消息 （ 即异步 ） 。 由客户端请求启动的过程定义应该在最短的时间内对客户端做出响应，因为该客户端已受阻，正在等待响应。如果处理请求需要很长时间，或者需要的时间不能确定，则过程定义应该首先使用“正在处理中”的消息响应客户端，然后异步处理请求。这就是回调为什么特别有用的缘故。
过程定义的描述位于 Java Process Definition （ JPD ） 文件中。 WebLogic Workshop 提供了 JPD 文件的图形视图。开发人员可以有选择地在过程定义中使用的 .jpd 文件中添加 Java 代码。因为这种代码不可重用，所以越少越好；除了该过程定义外，它就没有别的用途了。对于某些代码来说，如果针对大众要 比针对某个过程定义更有价值的话，则应该置于单独的 Java 类、 EJB 或自定义 Java 控件中。
过程控件
过程控件用于访问过程定义。 此控件可以在各种其他组件中使用 ， 这些组件包括页面流、 Web service 、其他过程定义或自定义控件。过程控件是一个 JCX 文件，可以根据 WebLogic Workshop 中的过程定义（ JPD) 文件自动生成。
工作列表控件
工作列表控件允许在包含人工操作的业务流程中使用过程定义。 工作列表控件允许过程定义将任务分配给用户，并让用户在完成任务时通知过程定义。工作列表控件的两种类型是：任务控件和任务工作者控件。
发布控件
发布控件允许过程定义将消息发布给消息代理上的通道。 此功能允许过程定义将消息发送到另一过程定义，该消息要么可以启动后续过程定义，要么可以在该过程定义中断以等待消息的某一点上继续进行处理。这是应用程序针对业务流程启动异步处理所使用的主要机制。
预订控件
预订控件允许过程定义从特定通道上的消息代理获取消息。 这是启动和继续异步处理所使用的主要机制。
业务逻辑层
所有业务逻辑都在图 1 所示的业务逻辑层中实现。处理请求时，这一层中的组件根据独特的业务规则验证请求中的信息，执行请求的业务逻辑，并可能对数据访问和集成层发出调用，以便创建、阅读、更新或删除相应的外部实体。最常见的外部实体是关系数据库。
从业务流程层或表示和接口层可以调用业务逻辑层中的组件。 如果从业务流程层调用，则组件作为过程定义的一部分使用。这就是跨越多个业务流程使用公共业务逻辑的方式。
如果从表示和接口层调用业务逻辑层组件 ， 则该组件是在为用户请求提供服务。 这就是 J2EE 应用程序中最常用的设计模式。通常情况下，在 J2EE 应用程序中，业务流程都是在 servlet 或 bean 中手工编码。将业务流程抽象到过程定义或页面流中，可以增强应用程序的灵活性和可维护性。
以下部分描述了业务逻辑层中显示的每个组件、组件与其余应用程序的交互以及与组件相关的所有设计注意事项。
自定义控件
自定义控件是一种封装了可重用功能的 Java 控件。 自定义控件是由 Java 控件源（ Java control source ， JCS ）文件和相关的 Java 文件创建的。可以在应用程序中使用自定义控件，也可以将其打包，以便在多个应用程序中使用。因此，自定义控件类似于 EJB 。但是，自定义控件与 EJB 相比，具有如下多种优势：
- 自定义控件可以使用其他 Java 控件
- 自定义控件可以是可扩展的
- 自定义控件通过回调支持异步性
BEA 向 Apache Software Foundation 公开了 自定义控件框架 ， 这些 框架 不仅可用于基于 WebLogic 的开发 ， 还可用于所有 Java 开发。
EJB 控件
EJB 控件用于向会话 bean 或实体 bean 发出调用。 它负责所有初始上下文查找、访问主接口等，允许开发人员仅在执行所需功能的 EJB 上调用方法。
消息驱动 Bean
消息驱动 Bean （ Message Driven Bean ， MDB ） 用于处理来自 JMS 主题或队列的消息。 使用 WebLogic Workshop 可以轻松地开发和部署 MDB 。 MDB 不应该包含业务逻辑，而应该从 JMS 接受消息，根据需要执行数据验证和传输，然后调用无状态会话 Bean 或包含可重用业务逻辑的其他组件。
有状态会话 Bean
有状态会话 bean （ stateful session bean ， SFSB ） 用于提供与客户端的有状态交互。 使用 WebLogic Workshop 可以轻松地开发和部署 SFSB 。在大多数情况下，无状态会话 bean 比 SFSB 更受欢迎，后者在少数特殊情况下才能使用。
无状态会话 Bean
无状态会话 bean （ stateless session bean ， SLSB ） 用于封装业务逻辑。 与有状态会话 bean 不同的是 ， SLFS 可以提供极佳的可伸缩性和性能。使用 WebLogic Workshop 可以轻松地开发和部署 SLSB 。
计时器控件
当指定的一段时间已经过去或已经到达指定的绝对时间时 ， 计时器控件通知应用程序。 计时器控件可用于启动业务流程或为某个事件（例如，接收响应消息）的发生等待一个特定的时间段。
数据访问和集成层
数据访问和集成层的组件可以与应用程序之外的企业信息系统 （ Enterprise Information Systems ， EIS ） 之间互相收发数据。 最常见的 EIS 是数据库管理系统。 该层用于封装与各种 EIS 通信的复杂性。
在当今的企业中 ， 应用程序与更多的不同 EIS 相结合 ，而 不只是限于数据库。 很多外部系统（从大型机到专有遗留系统）都可以作为从应用程序收发数据的目标。 Web services （它 利用了简单对象访问协议 ） 、各种消息传递服务（支持 Java Messaging Service ， JMS ）和 J2EE 连接器架构（ J2EE Connector Architecture ， J2EE CA ）规范的各种实现，这些都是集成传输组件的例子，数据访问和集成层就是由这些组件组成的。这些组件中的每一个都将调用 EIS 中的 API 来发送或接收信息。
以下列表描述了数据访问和集成层中显示的每个组件、组件与其余应用程序的交互以及与组件相关的所有设计注意事项 ：
BEA 向 Apache Software Foundation 公开了 数据库控件框架 ， 这些 框架 不仅可用于基于 WebLogic 的开发 ， 还可用于所有 Java 开发。
- 电子邮件控件 —— 电子邮件控件用于发送电子邮件。 电子邮件控件允许普通电子邮件字段（例如， to 、 cc 、 bcc 、 subject ）包括附件。
- 实体 Bean — 实体 bean 提供了桥接 J2EE 面向对象环境与数据库关系环境所需的对象关系 映射 。 实体 bean 还提供了功能强大的缓存机制，用于处理以读为主的数据或者只读数据。 使用 WebLogic Workshop 可以轻松地开发和部署实体 bean 。
一般来说 ， 在可能的情况下 ， 容器管理持久性 （ Container Managed Persistence ， CMP ） 实体 bean 比 Bean 管理持久性 （ Bean Managed Persistence ， BMP ） 实体 bean 更受欢迎 ， 因为使用 CMP 实体 bean 可以让开发人员省去开发 JDBC 代码的麻烦。
- 文件控件 — 文件控件用于读、写或者添加驻留在文件系统中的文件。 这些文件可以是以下类型之一： XmlObject 、 Binary （原始数据）或 String 。此外，文件控件还支持文件操作，如复制、重命名和删除。使用文件控件，还可以列出存储在特定目录中的文件。
- 控件 — JMS 控件可以将消息发送到 JMS 目的地 ， 或者从其接收消息。 消息系统（例如， MQSeries 、 Tibco ）常用于访问遗留系统。此控件提供连接到这些消息系统（进而连接到遗留系统）的简便机制。
- Liquid Data 控件 — Liquid Data 控件用于访问 Liquid Data for WebLogic 提供的数据。 该控件提供了一种合并数据的简便机制 ， 数据来源是 Liquid Data for WebLogic 可以 获取和聚合的各种 EIS 。
Liquid Data 是一个易于使用而且功能强大的工具 ， 用于跨数据查询和数据聚合创建 EIS 。 自定义代码不应当编写为从多个后端数据源聚合数据。 Liquid Data 可以轻松地完成此操作，并且还可以提供由此而产生的聚合数据的可配置缓存。
- TPM 控件 — 贸易合作伙伴管理 （ Trading Partner Management ， TPM ） 控件提供到贸易合作伙伴的查询 （ 只读 ） 访问 ， 并提供 TPM 存储库中存储的信息。 例如 ， 可以将其用作 ebXML B2B 过程定义的一部分。
- 转换控件 — 转换控件用于执行数据转换。 转换的方式可以是二进制到 XML 、 XML 到二进制或 XML 到 XML 。因此，实际上任何格式之间的相互转换，在 Workshop 中都已经定义，可以方便地使用。 XML 到 XML 的转换使用 Xquery 的功能，与 XSLT 相比，既灵活速度也快得多。
- Web service 控件 — Web service 控件用于访问 Web services 。 任何 Web 服务描述语言（ Web service Description Language ， WSDL ） 文件可用的 Web service ， 都可以通过这一控件进行访问。
BEA 向 Apache Software Foundation 公开了 自定义控件框架 ， 这些 框架 不仅可用于基于 WebLogic 的开发 ， 还可用于所有 Java 开发。
- LBeans — XMLBeans 为 XML 提供开发人员友好的界面。 XMLBeans 是通过将 XML 模式导入 Workshop 应用程序的模式目录中创建的。 Workshop 自动生成相应的 Java 类，稍后可以在 Workshop 开发环境中使用它们。
XMLBeans 比 JAXB 、 DOM 或 SAX 用起来更方便。 XMLBeans 基于高效的 XML 标志流 ， 使用光标提供 XML 数据的轻松导航。 XMLBeans 保持了 初始本地 XML 的结构和丰富程度。 BEA 向 Apache Software Foundation 公开了 XMLBeans ， 让它不仅可用于基于 WebLogic 的开发 ， 还可用于所有 Java 开发。
数据库访问选项
J2EE 提供了几种访问关联数据库的机制，包括 JDBC 、实体 bean 和 Java 数据对象（ Java Data Objects ， JDO) 。 除这些机制外 ， BEA WebLogic Platform 还增加了数据库控件和 Liquid Data 。
很多 J2EE 应用程序使用数据访问对象 （ Data Access Object ， DAO ） 设计模式来编写。 在该模式中，需要开发人员使用 JDBC 编写所有的数据库访问代码。使用数据库控件可以更加方便而快捷地构造数据访问对象设计模式。数据库控件允许开发人员指定 SQL ，这一点免去了编写所有冗长乏味的 JDBC 代码的负担。
在很多情况下 ， 使用数据访问对象设计模式优于实体 bean ， 因为 EJB 1.1 规范存在缺陷。 在 EJB 2.0 规范中，通过提供本地接口和健壮的 CMP ，去掉了与 EJB 1.1 实体 bean 相关的主要问题。因此，如果需要（或希望）提供隐藏了基础关系模式的面向对象的持久性层，则应该使用带有 CMP 的实体 bean 。它将对象到关系的映射从 Java 代码中移出，并移入部署描述符中。
在很多应用程序中 ， 构造一个隐藏了底层关系模式的对象模型并不是迫切需求。 这些类型的应用程序很多情况下直接从 servlet 中 使用 JDBC 。对于 WebLogic Platform 而言，数据库控件是针对这类应用程序推荐使用的方法。数据库控件可以作为结果集、 Java 对象或 XML 从 SQL 选择中返回结果。数据库控件与页面流和数据绑定 JSP 标记一起使用，可以实现快速应用程序开发（ Rapid Application Development ， RAD ）。
Liquid Data 与其他数据库访问选项迥然不同。 Liquid Data 不提供到数据源的写访问。它专门设计用于从多种数据源 （ 数据库、文件、 J2EE CA 、 Web service 等 ） 聚合数据 ， 作为 XML 文档返回聚合数据。如果希望从单个数据库聚合数据，则可以使用数据库控件（带有 SQL join ）并作为 XML 返回结果。但是，如果要聚合的数据存在于两个或多个数据源中，则 Liquid Data 是最适于使用的技术。
上面综合讨论了开发视图中的各个层。 下一节将讨论 4+1 视图模型中的物理视图。
物理视图
物理视图 （ 又称 “ 部署视图 ”） 给出了上面所部署应用程序的硬件。 它还描述了将应用程序哪些部分部署到硬件的哪些物理位置。
本节所描述的硬件和软件部署是一个 很好的例子，说明了 如何部署构建在 WebLogic Platform 上的应用程序，以及如何表示表示“最常见 ” 或 “最 佳实践 ” 架构。 然而，机器的配置多种多样，实际使用的硬件架构取决于实际应用程序以及在众多常见冲突约束中取得平衡，这些约束条件包括调试、可靠性、可用性、可伸缩性、安全性、预先存在的网络和计算资源。
硬件部署
图 2 说明了可以部署构建在 WebLogic Platform 上的应用程序的典型硬件环境 :
图 2. 典型的硬件环境
上图给出了 Web 层和应用层中的三台服务器。 在这两层的任一层中，都可以有任意数量的服务器。此外，每台服务器可以有一个或多个 CPU 。以下内容是对部分硬件环境的描述。
客户端
硬件架构显示三个不同的客户端 ： Internet 客户端、内部网 （ intranet ） 客户端和内部 （ internal ） 客户端。它是客户端最典型的例子，它们都将连接到网络上。这说明了大量的客户端需要更多的安全层来防止对系统的未授权访问。
这里描述的每个客户端都可以通过以下方式访问系统 ： 通过浏览器 （ 使用 HTTP(S) ） 、通过 Web service （ 使用 SOAP ） 、通过 RMI 或 RMI/IIOP （ 可能通过 HTTP ）， 或者甚至通过 B2B 协议 （ 如 ebXML 或 RosettaNet ） 。 无论使用哪种访问协议，请求都由软件架构的表示和接口层来处理。
防火墙
硬件架构中给出了三个防火墙。 第一个防火墙防止恶意 Internet 人员 对 Web 层的攻击。第二个防火墙保护应用层，可选的第三个防火墙用于保护存放公司数据的 EIS 层。
Web 层
Web 层位于第一和第二个防火墙之间。 该层有时又称为 DMZ 。它的主要功能是在 Internet 和公司的其余计算环境之间提供一个安全层。 Web 层还提供几个其他功能，如负载平衡和静态内容提供等。如果需要单点登录（ Single-Sign-On ， SSO ），则通常在这一层中执行初始验证。
Web 层中的计算资源用于运行 Web 服务器环境 （ 比如 Apache 、 Netscape 、 IIS 、 BEA WebLogic Express ） 。 不可将应用程序代码部署到这一层。这一层只能提供静态内容（即图像和 HTML ）。通过在 Web 服务器中安装 WebLogic 代理，可以将应用程序的客户端请求转发到应用层。
应用层
应用层是部署应用程序的位置。 应用程序架构 （ 参见图 1 ） 的全部四个层都在这一层中部署。如果需要高可用性，则应将 WebLogic 集群配置为部署过程的一部分。该图显示 WebLogic 域。硬件可以承载一个或多个 WebLogic 域，每个域可以具有一个或多个应用程序。
因为 J2EE 定义了一个 Web 容器和一个 EJB 容器 ， 所以有些公司选择分别将这些容器部署在不同的硬件层中。 使用 WebLogic Platform 时，建议不要使用这种方法。将 Web 容器与 EJB 容器分开将增加部署应用程序的难度，并导致性能严重下降。性能下降的原因是存在额外的网络往返和通过网络所需的封送和解除封送处理。相反，如果作为单个 EAR 文件部署应用程序，则在应用程序中组件之间的调用可以使用本地接口和按引用传值。
EIS 层
企业信息系统 （ EIS ） 层是存储业务域中所有信息的主要位置。 在当今企业中，在企业数据库管理系统中、在遗留系统或大型机系统中、在商用现货（ Commercial-Off-The-Shelf ， COTS ）产品（例如， Siebel 、 SAP 、 PeopleSoft ）中，或者在某些未知的消息传输或 Web service 后面的位置，都可以存储这些数据。
软件部署
下图显示了应用程序在图 2 给出 的应用层中的部署。
图 3. 将应用程序部署到应用层
上图显示部署到应用层中所有三台服务器中的单一集群化应用程序。 这是部署构建在 WebLogic Platform 上的应用程序的最简单方式，但是还有很多其他可能性。图 4 给出了另一种类型的部署。
图 4. 门户应用程序和 BPM
上图显示一个部署在集群中两台服务器上的门户应用程序和部署在单台服务器上用于业务流程管理 （ BPM ） 的单个应用程序。 在该部署中，门户应用程序可以提供高可用性，而 BPM 应用程序不能。如果门户应用程序很重要，同时使用了不重要的 BPM 应用程序，则使用这种部署可能较为合适。
这些示例给出了三台服务器 ， 在每台服务器上运行一个 WebLogic 实例。 但是，使用任何数量的服务器都可以，而且在每台服务器上可以运行一个或多个 WebLogic 实例。实际上，在 BEA WebLogic Platform 上部署应用程序在数量上具有极大的灵活性。下面是一些部署的 “ 经验法则 ” ：
- 每两个或三个 CPU 运行 一个 WebLogic 实例。
- 要一起管理的应用程序应该位于公共 WebLogic 域中。
- 相互没有关系的应用程序可以位于单独的 WebLogic 域中 ， 即使它们共享硬件资源。
- 如果需要高可用性或故障容错 ， 则应该使用集群管理 WebLogic 实例。
- 如果应用程序需要 N 台服务器才能提供所需的性能和吞吐量 ， 则应该将应用程序部署在 N+1 台服务器中 ， 以允许出现服务器停机现象 （ 计划的或非计划的 ） 。
本节综合讨论了物理视图中的硬件和软件部署。 下一节考察 4+1 视图模型中的过程视图。
过程视图
过程视图（也称为“并发视图”）显示了各种过程以及 过程之间的通信。 图 5 说明了向 Web 浏览器请求关系数据库中的数据所涉及的过程。
图 5. 过程视图
上述过程图的简单例子给出了向单个浏览器请求提供服务的多个过程和多个线程。 实际的过程图比这个例子可能复杂得多，尤其是当单个请求中涉及到异步和多后端系统时。
图 6 给出了 WebLogic Platform 的过程和线程。
图 6.WebLogic Platform 的 过程和线程
如上图所示 ， WebLogic Server 的单个实例对应于具有多个线程的单个过程。 默认情况下，使用单个请求队列来配置 WebLogic Server 。但可以配置其他请求队列来区分不同类型的请求。例如，将较高优先级的请求从低优先级的请求中分离出来可能合乎多数人的要求。
使用纯 Java 的 Socket Reader 实现时 ， Socket Reader 线程和 Worker 线程源自同一个线程池。 配置本地 IO 时 ， 本地 Socket Reader 多路线程具有它们自己的执行队列 ， 不用从请求队列线程池借用线程。
通信
大体上说 ， 构建在 WebLogic Platform 上的应用程序之间的通信是由平台透明处理的。 但是，平台所支持的某些通信可能会对架构造成重大影响。
对话
WebLogic Platform 中的 Web 服务提供了一种机制 ，可以 方便地在客户机和应用程序之间创建对话。 对话的状态是持久存储的，所以对话可以被长久保存下来，即使完全关闭系统也不会造成影响。（此外，可以设置对话超时，以便自动清除废弃的对话。 ）
异步支持
WebLogic Platform 可以提供用于异步通信的多种机制。
- 控件架构提供一种创建和注册回调的的简单机制。
- 使用 Java Web service (JWS) 文件可以方便地构造 Web service 。
- 该平台包括一个可靠的 SOAP 消息处理框架 ， 在该框架中 ，一个 WebLogic 实例中运行的应用程序能够可靠地异步调用另一个 WebLogic 实例上运行的 Web service 。
- 该平台包括消息代理 ， 允许与过程定义以异步方式相互通信。
- 该平台包括 JMS 和 MDB 支持 ， 这是一种用于异步通信的 J2EE 标准机制。
安全性
安全性一般不被视为应用程序内部组件之间通信的一部分。 但是， WebLogic Platform 包括一种行业领先的安全基础架构，可以透明地截获应用程序内部的通信并执行操作。这种安全性基础架构是 WebLogic Server 的一部分，在该平台的其他地方可以利用这种安全架构为各种应用程序创建一致的、声明性的、基于策略的安全性。几乎没有必要在应用程序中编写自定义代码来加强安全性。
WebLogic Platform 还支持 WS-Security 。 这一点不仅可以加密 Web services 消息 ， 还可以将 Web services 协议栈绑定到底层安全性基础构架上。
BEA WebLogic Enterprise Security 是另一种 BEA 产品 ， 它可以合并到构建在 WebLogic Platform 上的解决方案中。 WebLogic Enterprise Security 提供了增强的应用程序安全性，具体包括：基于策略的委派管理、单点登录身份验证、合并审计，以及动态角色和基于策略的委派授权。
结束语
本文旨在使用架构师和设计人员易于理解的高级视图来展示 BEA WebLogic Platform 提供的大量功能。 为了达到此目的，使用了 4+1 视图模型来描述在 WebLogic Platform 上构建的应用程序架构。 开发人员视图提供了 WebLogic Server 、 WebLogic Portal 、 WebLogic Integration 、 WebLogic Workshop 和 Liquid Data for WebLogic 所包含组件的统一视图 。该视图还显示了设计良好的应用程序中的架构层，并标识了在每一层中使用的组件。 物理视图提供了构建在 WebLogic Platform 上的应用程序的简单部署例子。对软件部署和物理硬件部署都进行了描述。过程视图描述了响应用户请求所涉及的线程和过程。另外还提及了应用程序通信问题，如对话、异步和安全性。
我们希望本文能够让您更好地了解 WebLogic Platform 以 及它为应用程序部署所提供的强大基础，也希望这些内容能够帮助您构建和设计利用 WebLogic Platform 功能的应用程序。 |
