内容


WebSphere Process Server 操作体系结构,第 1 部分

基本体系结构和基础结构组件

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: WebSphere Process Server 操作体系结构,第 1 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:WebSphere Process Server 操作体系结构,第 1 部分

敬请期待该系列的后续内容。

引言

WebSphere Process Server 由许多紧密相连的组件组成,并利用了许多不同的概念,例如服务组件体系结构 (SCA)、Business Process Choreographer (BPC) 和服务集成总线 (SIB)。虽然这些概念已经有了很好的文档说明,但是获得有关这些概念如何在 IBM WebSphere Process Server 中协同工作的概述是非常困难的。由于此知识对于运行在 WebSphere Process Server 上的业务流程应用程序的成功操作至关重要,本文将提供上面提及的概念的技术内聚性的详细和深刻的视图。本文将描述在运行 SCA 模块时涉及到哪些资源(例如 SIB 目标),以及它们如何彼此相关。此外,本文将介绍 BPC 的技术背景(包括 BPEL 流程的执行),从而强调与诸如 SCA 等基础概念的关系。最后,本文列出了可能发生的错误条件,并说明如何从操作的角度识别它们(失败事件管理器、异常队列等等)。

本文为 IT 架构师和 WebSphere 管理员提供了了解 WebSphere Process Server 的操作背景和这些概念及技术之间关系的极好机会,以帮助更好地管理您的 SOA 基础结构。

本系列中的最后一篇文章 使用 WebSphere Process Server V6.1 体系结构设计应用程序,第 2 部分:实现 SCA 运行时、Business Process Choreographer 和支持服务 将进一步探索 IBM WebSphere Process Server 的操作体系结构。您将从技术的角度了解哪些组件构建了 WebSphere Process Server 的运行时层,以及它们如何在操作环境中协同工作。在这方面,您将了解 SCA 模块如何考虑运行时,以及 Business Process Choreographer 如何管理业务流程。您将获得 Process Server 的操作体系结构的整体视图,此外,您将更好地了解如何在组织中建立成功的 WebSphere Process Server 操作。

WebSphere Process Server 参考模型

当今的每个 (IT) 人,无论您是 IT 专家还是更加重视业务的顾问,均对有关 SOA 是什么和不是什么具有个人的定义。这以对术语“服务”的一千零一遍解释开始,并以数百万种可能的实现技术而告终。本文并不试图定义 SOA ,而是尝试对 SOA 意味着什么和 WebSphere Process Server 在面向服务的世界中的作用建立大致的共识。最后,本文介绍将帮助您从操作的角度了解 WebSphere Process Server 体系结构的 WebSphere Process Server 构件和技术详细信息。

WebSphere Process Server 在面向服务的体系结构中的作用

让我们从术语 SOA 开始吧。考虑到您无法购买 SOA,并且 SOA 甚至根本就不是产品,我们可以将其定义为概念。从概念上讲,SOA 以特殊的方式构造 IT 基础结构,其中重点放在面向组件、组合、重用和灵活性上。此外,该概念使 IT 基础结构与业务需求保持一致,而业务本身是所有活动的驱动因素。然而,这实际上意味着 SOA 不多不少恰好定义了一种体系结构样式。

从概念的角度看,SOA 的技术实现必须满足几个关键要求:

  • 用于定义组件和接口的公共方法或公共语言。
  • 不同组件之间通过公共接口定义建立的契约
  • 使组件能够在企业中甚至企业间协同工作的平台
  • 编排组件和促进组合的方法

为了解决这些要求,Open Service Oriented Architecture (OSOA) 活动定义了一个称为服务组件体系结构(以下称为 SCA)的新行业标准;有关更多信息,请参阅“参考资料”部分的“服务组件体系结构 (SCA) 规范”。SCA 背后的核心思想是为业务服务的定义建立公共组件模型。在这方面,“服务”这个术语是指通用服务提供者提供的抽象服务;例如“银行查询”或“贷款审批”。从更加技术性的角度看,SCA(通过公共接口定义)定义了围绕业务组件的框架,并使组件能够越过企业边界彼此通信。由于大量软件厂商对 SCA 的广泛认可,可以将其视为用于将 SOA 作为一种体系结构样式来实现的事实上的规范,请参见大图 图 1. WebSphere Process Server 的分类和划分

图 1. WebSphere Process Server 的操作参考体系结构
操作参考体系结构
操作参考体系结构

正如已经讨论过的,SCA 定义了如何定义组件和接口,以及如何调用它们。然而,OSOA 活动没有提供任何可用作执行平台的具体实现。

此时,WebSphere Process Server 就派上了用场,因为它是 SCA(以及相关)规范的 IBM 实现。通过其作为 SCA 应用程序执行平台的角色,WebSphere Process Server 成为 IBM 的 SOA 组合的主要构件之一。此外,它是使用 WebSphere Integration Developer 开发的业务流程(例如,BPEL 流程、人工任务等等)的运行时平台,因此在企业的 SOA 基础结构中起着非常重要的作用。

WebSphere Process Server 参考体系结构

正如前面提到过的,WebSphere Process Server 是 IBM 用于所谓的 SCA 模块(实现 SCA 规范的应用程序)的执行平台。由于在面向服务的环境中所起的核心作用,了解该服务器的主要构件以及那些构件如何彼此相关是真正至关重要的。在这方面,下面的插图介绍了一个操作参考体系结构,本文将其用作了解该服务器的起点。此外,全文还将使用该参考体系结构来解释组件之间的技术内聚性,请参见图 2。

图 2. WebSphere Process Server 的操作参考体系结构
操作参考体系结构
操作参考体系结构

WebSphere Process Server 体系结构主要由三个层定义,这些层为业务应用程序构建了非常基本的基础:

  • 基础结构层
  • 运行时层
  • 功能层

所有这些层自底向上彼此依赖。

基础结构层

基础结构层中的组件为之上的所有层提供非常基本的功能。一个核心功能是业务数据(例如,来自业务应用程序或 Business Process Choreographer 的数据)和消息功能及其他组件产生的运行时数据的持久性。由于此数据的有效性和完整性对于 WebSphere Process Server 的作用真正至关重要,因此将使用企业级数据库系统(有关更多信息,请参见“参考资料”部分中的“WebSphere Process Server:系统要求的详细列表”以了解详细的选项列表)来实现此目的。

此外,基础结构层提供了各种各样基于 WebSphere 的服务集成总线技术(也称为 WebSphere Platform Messaging)的消息资源。一方面,SCA 运行时大量使用这些资源进行异步通信和缓冲。另一方面,功能层的几乎所有组件也利用了这些资源。

运行时层

此层从 SCA 的角度提供了基本的服务组件功能。此层整合了 IBM 对 SCA 标准的实现,以下将其称为 SCA 运行时。该层的此部分提供了运行 SCA 模块的能力,此外还支持所包含的组件彼此通信。有关通信的一个非常重要的方面在于,技术基础(以及功能的具体实现)完全被 SCA 构件所隐藏(因此开发人员只需定义“组件 A 对组件 B 发出异步调用”)。实际上,SCA 运行时负责选择正确的通信通道,并负责执行实际的工作。在这方面,WebSphere Process Server 大量使用了位于基础结构层的基础消息功能。

除了 SCA 运行时提供的附加功能以外,WebSphere Process Server 还包括核心 WebSphere Application Server 功能。该应用程序服务器支持使用诸如 JMS(包括 MQ JMS 连接)、Web 服务、J2EE 容器服务、JDBC 数据库访问等技术。SCA 运行时最终使用这些技术向开发人员提供不同种类的绑定类型(可以将“绑定”视为向外部世界公开的 SCA 式接口的技术实现;有关更多信息,请参见“参考资料”部分中的“服务组件体系结构 (SCA) 规范”以了解通常可能的类型列表),例如 Web 服务绑定或 EJB 绑定。

总而言之,运行时层构建了 WebSphere Process Server 功能的核心,并将其用作根据 SCA 组装模型实现的应用程序的执行平台。

功能层

正如在前面的几个部分中所述,基础结构和运行时层提供了用于运行 SCA 应用程序的核心服务。除了 SCA 组装模型的具体实现以外,WebSphere Process Server 还重点展示了几种 SCA 组件实现类型(例如 BPEL 或 Java™),以及许多补充服务,使得集成开发人员的工作变得容易多了。

该层中的主要组件之一是 Business Process Choreographer,可将其视为业务流程(使用 SCA BPEL 实现模型;有关更多信息,请参见“参考资料”部分中的“服务组件体系结构 (SCA) 规范”)和人工任务(请参见“参考资料”部分的“WS-BPEL Extension for People”)的执行容器。由于 SOA 更多地是一种以业务为中心的方法,许多 SCA 模块往往在一定程度上利用所谓的业务流程执行语言(Business Process Execution Language,BPEL),因此从操作的角度将与 Business Process Choreographer 联系起来。

除了 BPEL 组件外,WebSphere Process Server 还支持许多附加的组件和服务,这些组件和服务不是 SCA 标准的直接组成部分,但是可由业务开发人员加以利用。其中较常见的是选择器和业务规则(有关更多信息,请参见“参考资料”部分的“Make composite business services adaptable with points of variability, Part 3:Using selectors and business rules for dynamicity”)。这些组件对 WebSphere Process Server 环境的总体操作透视图具有一定的影响,因为它们使用基础消息和持久性功能,并且业务应用程序层中的模块还可能依赖它们。

最后,公共事件基础结构(以下称为 CEI)位于功能层。可以将 CEI 视为用于记录业务事件、审核和/或监视 SCA 组件(甚至业务流程)执行的框架。该框架紧密集成到 IBM 的 SCA 实现中,以便能够使用 CEI 生成各种各样可进一步分发到各个目标的事件。例如,BPEL 开发人员可以使用 CEI 事件向监视控制台(可以考虑 IBM Tivoli Enterprise Portal)报告 SCA 组件的执行统计信息。但是,CEI 并不与 SCA 标准本身直接相关,但它与其他 IBM 产品高度可互操作,例如 IBM WebSphere Business Monitor(有关更多信息,请参见“参考资料”部分的“Business Activity Monitoring with WebSphere Business Monitor V6.1”),以支持业务活动监视(Business Activity Monitoring,BAM)解决方案。

业务应用程序层

实际的 SCA 模块与 WebSphere Process Server 的功能层紧密相连,因为它们从操作的角度大量利用了所有功能,例如 BPEL、人工任务、CEI 事件等等(这种复杂性实际上对开发人员是隐藏的)。所有其他层或多或少对应用程序都是隐藏的。

总而言之,WebSphere Process Server 的操作参考体系结构大致可在三个不同的层中进行构造,而最低的层提供基本的基础结构功能,例如持久性和消息。运行时层包含 SCA 组装模型的实际运行时实现,并支持 WebSphere Process Server 成为 SCA 模块的执行平台。最后,功能层公开了若干可供业务应用程序开发人员利用的 SCA 组件实现(例如 BPEL、Java、人工任务)。

WebSphere Process Server 组件的操作视图

在本部分中,您将了解服务集成总线(Service Integration Bus,SIB)技术背后用于 WebSphere Process Server 中的异步通信的一般概念。本部分首先阐明与 SIB 相关的技术术语,并通过将其加入层模型中来设定它们彼此之间的关系。本部分的第二个部分将概述 WebSphere Process Server 操作环境中使用的不同 SI-Bus,以及与它们的交互是如何进行的。

系统集成总线概述

SI-Bus 是在 WebSphere Application Server V6 中引入的,并取代以前作为内部平台消息实现的 WebSphere MQ Series。该实现完全基于 Java,所有对象都存在于 WebSphere Application Server 运行时中。

下图提供了属于 WebSphere Platform Messaging 技术的不同组件的概述。更准确地讲,图中显示了四个层,您应该自顶向下对其进行理解(以获得更好的认识)。

图 3. 分层 SIB 体系结构
分层 SIB 体系结构
分层 SIB 体系结构

应用程序层

利用异步消息标准和概念的 Java EE 应用程序驻留在应用程序层。例如,消息驱动 Bean(Message Driven Bean,MDB)利用 Java Messaging Service (JMS) 标准异步地处理消息。

JMS 层

JMS 层通过引入所谓的 JMS 构件的概念,从而封装了 JMS 提供者的具体实现。JMS 构件表示指向物理资源的逻辑对象。其中一种 JMS 构件就是所谓的 JMS 目的地。JMS 能够识别其中两种目的地:即 JMS 队列和 JMS 主题。前者用于点对点消息,后者用于发布-订阅场景。其他 JMS 构件包括 JMS 连接工厂,用于抽象 JMS 目的地的连接处理,例如对 JMS API 用户隐藏池的概念。此外,JMS 激活规范也属于 JMS 构件。此类激活规范基于 Java Connector Architecture (JCA),后者提供了使用 Java 与企业信息系统通信的标准化方法。JMS 激活规范表示一组可能随每个 JMS 提供者而异的消息配置属性。

逻辑 SIB 层

逻辑 SIB 层将 JMS 标准引入的构件与特定于 WebSphere 的资源联系起来。尽管充当 JMS 提供者只是 WebSphere Default Messaging 的许多功能之一,但是最好将某些核心 SIB 概念描述为考虑到了 JMS。

可以将总线视为一个体系结构概念,它由基于消息的应用程序使用,并由一组其特征为“总线成员”的服务器或集群所定义。JMS 层与 SIB 之间的连接使用兼容 Java 2 Connector Architecture (JCA) 的资源适配器。资源适配器实现了将特定系统(在此例中为 SIB)连接到基于 Java 的环境的标准化方法。唯一的要求在于该 Java 环境充当 JCA 提供者。事实上,诸如 WebSphere Application Server 之类的每个兼容 Java EE 的应用程序服务器都是这样做的,因此使用资源适配器非常合适。使用资源适配器所带来的一些现成优点包括事务完整性和细粒度的服务质量概念。下面将更详细地描述 SIB JMS 资源适配器。

在逻辑 SIB 层,另外存在称为队列和主题的组件。务必记住的是,这些术语的含义与 JMS 队列和 JMS 主题不同。然而,JMS 队列和 (SIB) 队列都体现为一对一关系;它们的区别在于其放置和技术实现。同样地,目的地与 JMS 目的地不同,并且只是 SIB 队列和主题的总括术语。在上面的模型中,可以看到一个目的地(例如一个队列)唯一地分配给一个总线成员。

物理 SIB 层

到目前为止,本文仅描述了不同的抽象层。还没有谈到任何有关 SI-Bus 的物理模型的内容。显而易见,每个目的地必须至少有一个持久存储区,以便保存其内容及其内容数据。此外,需要一个用于保存该数据并从持久存储区获取该数据的技术组件。SIB 中实现此需求的组件称为消息引擎(Messaging Engine,ME)。每个 ME 与某个数据库或文件存储区相关以保存其数据。

表示 SIB 目的地的物理对象称为消息点 (Message Point)。对于每种目的地,将使用不同的术语表示对应的消息点:“队列”类型的目的地仅由“队列点”表示,“主题”类型的目的地仅由“发布点”表示。每个消息点确切地仅属于一个目的地,但是一个目的地可以存在多个消息点(在集群总线成员的情况下)。一个消息点始终唯一地分配给一个 ME。

消息引擎操作体系结构视图

谈到 WebSphere Process Server 参考拓扑(如“参考资料”部分的“Production Topologies for WebSphere Process Server and WebSphere ESB V6”所述),每个总线成员和总线很可能只有一个 ME 在运行,这实际上可以看作是缺省行为。在较简单的 WebSphere Process Server 拓扑的情况下,例如非集群拓扑,这是唯一可能的场景。考虑到较复杂的拓扑,例如所谓的“远程消息和远程支持”拓扑(值得一提的是,在 WebSphere Process Server V6.0,这称为“完全支持”或“金牌”拓扑),将使用集群来支持 WebSphere Process Server 消息基础结构的高可用性。

在这方面,您可以使用不同的配置,这些配置最适合使用由两个分配给某个 SIB 的集群成员组成的集群来加以描述。缺省行为在于,仅有一个 ME 在一个集群成员上是活动的,并且仅当第一个集群成员失败时才会在另一个集群成员上变为活动的(请参见上面的图 3)。如前所述,这种场景支持消息高可用性,并且通常可以在企业级 WebSphere Process Server 环境中看到。

图 4. 不同的消息引擎配置
不同的消息引擎配置
不同的消息引擎配置

考虑到性能和可伸缩性,可以采用另一种设置,其中每个集群成员承载自己的活动 ME,并且每个 ME 拥有分配给该总线成员的目的地的消息点。因此目的地上的消息可同时由两个集群成员处理。然而,这样的设置具有某些缺点:

  1. 消息顺序无法得到保证,因为每个消息可能由其中任何一个集群成员处理。
  2. 仅使用两个集群成员,故障转移将无法实现,因为每个 ME 分配了自己的数据存储区,并且对于一个 SIB,每个集群成员仅有一个 ME 能够是活动的。因此,消息点的数据无法从一个 ME 传输到另一个 ME。

每个总线成员使用多个活动 ME 的概念称为分区目的地 (Partitioned Destination)(请参见上图)。但是,就 WebSphere Process Server 参考拓扑而言,当前不提倡使用分区目的地。

对消息基础结构的访问

正如上面提到的,JCA 资源适配器用于将 JMS 资源和 SIB 联系起来。此“SIB JMS 资源适配器”管理 JMS 构件,尤其是存储诸如总线、目的地名称和处理的并发性信息等属性的 JMS 激活规范。务必要认识到的是,激活规范设置是调整性能的焦点,因为它们影响到能够并发地处理多少个消息(在功能作用的上下文中,它们与线程池相当)。

SCA 运行时不使用 SIB JMS 资源适配器,而是使用“Platform Messaging 组件 SPI 资源适配器”,其中 SPI 表示服务提供者接口 (Service Provider Interface)。此资源适配器承载 SCA 模块的激活规范,就异步通信路径中的总体性能和处理而言,这些激活规范也非常重要。在 SCA 模块部署过程中,没有在 SIB SPI 资源适配器上显式创建任何连接工厂,取而代之的是,SCA 运行时将使用低级 SIB Core API 以编程方式创建连接工厂。因此,这些连接工厂的属性(例如连接池设置)是不可见的,管理员无法更改它们以实现优化目的。对于 SIB JMS 资源适配器,情况则有所不同,因为连接工厂是显式创建的,因此所有设置均在 WebSphere 管理控制台中可见。下图可视化地显示了两种资源适配器之间的区别。

图 5. 通过 SIB 资源适配器进行的 WebSphere Process Server 通信
通过 SIB 资源适配器进行的通信
通过 SIB 资源适配器进行的通信

操作总线基础结构

下图显示了 WebSphere Process Server 中使用的四条 SI-Bus。本部分仅提供有关总线的简短概述。有关目的地的详细信息将在后续部分中讨论。

图 6. Process Server 的操作消息体系结构
操作消息体系结构
操作消息体系结构
  • BPC 总线由 Business Process Choreographer 用于执行长时间运行的流程。BPC 总线上的消息是所谓的导航消息,其中包含有关对应流程的状态和处理信息。例如,如果每个活动参与自己的事务,则从一个活动到另一个活动的转换可能导致产生导航消息。事务行为只能在开发时更改,在运行时既无法查看也无法更改。
    由于种种原因,可以将设置最优事务边界视为流程实现的关键性能方面之一。首先,就计算时间而言,事务上下文切换是开销相当大的操作。其次,在长时间运行的流程的情况下,跨越事务边界会产生导航消息,这与保持在相同事务中相比,开销也是更高的。
  • SCA 系统总线由 SCA 运行时用于与 SCA 组件和 SCA 模块之间的异步通信。流经该总线的消息包含业务数据(源自不同 SCA 构件之间的请求),并且不会像 BPC 总线上的消息那样用于导航目的。
  • SCA 应用程序总线主要用于 SCA 模块的自定义目的地。例如,JMS 导出引用的 JMS 目的地应该引用驻留在此总线上的目的地。
  • CEI 总线用于异步事件传输。此总线上的消息是由一个特殊 MDB 选取的事件,这些事件将传输到所谓的“事件服务器”应用程序以作进一步的处理。

数据库

本部分提供对 WebSphere Process Server 的数据库体系结构的概述。下图显示了 WebSphere Process Server 使用的不同数据库的较为逻辑化的视图。

图 7. 操作持久性体系结构
操作持久性体系结构
操作持久性体系结构

缺省情况下,WebSphere Process Server V6.1 将所有数据库对象安装到单个数据库中。但是,将不同数据竖井的所有数据库对象放到不同的数据库中并不是必需的,因此出于性能和可伸缩性的考虑,普遍的做法是将这些竖井单独地放在可管理的数据竖井中。

  • WPRCSDB 竖井包含 WebSphere Process Server 的配置和单元范围的数据。例如,有关某些 SCA 组件(业务规则、选择器、关系)的数据就存储在这里。此外,该数据竖井还包含失败事件数据。由于在某些请情况下需要失败事件信息来重新启动失败的 SCA 流,该数据的可用性相当重要。此数据库在每个 WebSphere Process Server 单元中仅存在一次。
  • MEDB 数据由 WebSphere Process Server 消息基础结构中运行的消息引擎用于持久化消息数据(有关更多详细信息,请参阅前一部分):事务上下文、消息有效负载和管理信息。每个(活动)消息引擎需要在此数据库中有自己的模式。
  • EVENT 数据竖井包含公共基础事件基础结构的数据。如果选择了持久化所有事件数据的选项,则会将该竖井放在此处。
  • BPEDB 竖井包含 Business Process Choreographer 数据,以及诸如流程和人工任务的模板数据、长时间运行的流程的状态信息等其他内容。如果配置了多个服务器或集群来运行业务流程和/或人工任务,则此数据可以在一个单元中存在多次。

上面提到的每个数据竖井对应于 WebSphere Process Server 单元中的一个或多个所谓的数据源。数据源提供到基础数据库的连接属性,以及连接池机制。了解这些设置如何影响 WebSphere Process Server 的执行是相当重要的。说明这点的一个很好示例是到 BPEDB 的最大连接数量。此值将长时间运行的业务流程的并发性限制到该数量,因为每个流程需要将数据写到 BPEDB 数据竖井。

结束语

本文介绍了 WebSphere Process Server 的操作参考体系结构,您可以将该参考体系结构用作围绕由 WebSphere Process Server 支持的 SOA 基础结构的所有操作工作的基础。此外,您还了解到 WebSphere Process Server 大量利用了消息和持久性功能,并且这些功能的正确操作在通往成功的面向服务的环境之路上发挥着重要的作用。

在本系列中的最后一篇文章 使用 WebSphere Process Server V6.1 体系结构设计应用程序,第 2 部分:实现 SCA 运行时、Business Process Choreographer 和支持服务 中,您将从操作的角度了解位于运行时层和功能层中的组件。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=378394
ArticleTitle=WebSphere Process Server 操作体系结构,第 1 部分: 基本体系结构和基础结构组件
publish-date=03302009