WebSphere Process Server 和 WebSphere ESB 中的解决方案设计,第 2 部分: 在 WebSphere Process Server 和 WebSphere ESB 中设计一个 ESB 网关

本系列的第 2 部分将讨论 ESB Gateway 架构组件。它与更宽泛的 ESB 概念有何不同?它为什么如此重要?我们随后将讨论如何在 WebSphere® Process Server 和 WebSphere Enterprise Service Bus 中设计和实现 ESB Gateway。

Kim J. Clark, IT 专家, IBM

Kim Clark 是一名来自英国的 IT 专家,目前在 IBM Software Services for WebSphere (ISSW) 工作。他在 1993 年开始从事 IT 行业,自 WebSphere Process Server 第一次实现后,就一直担任各种项目的技术主管,并经常撰写和发表有关 SOA 设计的文章。他拥有伦敦大学的物理学学位。


developerWorks 投稿作者

2009 年 9 月 28 日

简介

关于 WebSphere Process Server 和 WebSphere ESB 的更多技术资源,请参考:

本系列第 1 部分 介绍了面向服务架构(SOA)在历经几个发展阶段后如何日渐成熟,并展示了每个阶段使用的解决方案风格。本文将关注从 Enterprise Application Integration (EAI) 到 Service Exposition 这一演变,换句话说,就是指从 Service Integration Maturity Model (SIMM) 级别 3 推进到级别 4。

我们将讨论在 Enterprise Service Bus (ESB) 上公开成熟服务的意义,并查看 WebSphere Process Server(此后称为 Process Server)或 WebSphere Enterprise Service Bus (WESB) 中您将使用的特性。具体来讲,我们将查看 WebSphere Integration Developer(此后称为 Integration Developer)从 v6.2 开始提供的新的 Service Gateway 模式,以及一些新的中介流(mediation flow)组件功能,比如 Policy Lookup 原语。

随着企业架构推进到 SIMM 成熟度等级 4,一些关键的业务和技术功能逐渐进入了可重用服务的考虑范围。这种可重用可能分为许多不同的级别,从有限的 IT 环境内部,到范围更广的企业级别,再到将服务公开到 Internet 上。随着 SOA 朝向 SIMM 级别 4 的演进,出现了两个关键的改善:

  • 访问备选服务:需要选择合适的 服务以公开给更广泛的受众。其中一些服务可能来自自下而上的项目,比如来自 SIMM 级别 3 的功能。相反地,自上而下的方式可能从早期的实践中获取原料,比如 Component Business ModelingSOMA 等方法结合使用了这种技巧来获取备选服务。尽管这一步骤非常关键,但是它超出了本文的讨论范围。
  • 公开服务:引入架构和设计模式时需要适当地公开这些服务。这些服务需要在架构启用它们的方式上进行特殊处理这是本文的主要关注点

那么,为什么真正的企业服务需要在公开方式方面进行特殊处理?公开给多个并且可能是未知用户的服务需要在安全性、可靠性、可维护性、可伸缩性和治理性方面得到增强。大部分(尽管不是所有)都可以实施到服务公开中。选择一个具有互操作性的标准协议,比如 SOAP/HTTP 或 REST/HTTP,仅仅是我们所谓的 “公开” 服务的一部分。


公开企业服务与传统集成有何区别?

第 1 部分 简单讨论了传统集成(SIMM 级别 3)和服务公开之间的区别。事实上,这是区别技术级别 SOA 与此前的 EAI 的关键概念。让我们回忆一下 SIMM 级别 3 的传统拓扑集成架构(图 1)。

图 1. 传统集成(SIMM 级别 3)
传统集成(SIMM 级别 3)

现在,让我们回想一下这个架构是如何转变为在 SIMM 级别 4 上公开成熟的企业服务(图 2)。

图 2. Service Exposition(SIMM 级别 4)
Service Exposition(SIMM 级别 4)

两者之间的明显不同主要在于引入了 ESB Gateway

  • 标准化公开:位于集线器(hub)的请求一方的连接器在 SIMM 级别 4 图中消失不见(见图 2)。这是因为我们只允许 ESB Gateway 对传输协议、安全性、事务性和交互方式使用标准的机制,以确保服务可以被尽可能多的客户使用。
  • 通用请求处理:ESB Gateway 在实施通用的(并且理想状况下)基于策略的请求处理方面扮演着特定的角色。这允许您以一种通用的方式,对将使用共享通用 策略的服务 执行诸如监视、审计、管理和诊断等操作。
  • 特定于标准化操作的请求处理:某些功能在方式上相似,但是针对每个操作的细节是不同的。对于可以以一种标准化 方式实现的部分,在 ESB Gateway 中也是合适的。在理想情况下,也可以在一个注册表中通过特定于操作的 策略配置它们。例子包括路由、流/并发控制、审计、访问控制和语义映射。
  • 服务注册表:引入了一个注册表。这个注册表至少包含了消费者使用服务所需的信息。如前所述,它还可能包含 ESB Gateway 用于支持集中式配置策略(与服务公开有关)的策略细节。

ESB Gateway 的作用是什么?

由于 ESB Gateway 的概念对于公开服务非常重要,因此我们将在本文后面单独讨论这个主题。

图 3. 将 ESB Gateway 的职责形式化
将 ESB Gateway 的职责形式化

从图 3 中可以看到,ESB Gateway 具有与集线器不同的意图:虚拟化、可见性、安全性和流量管理。它完全侧重于服务的公开方式,以及如何能够 将所有功能标准化,也许还包括策略驱动。之所以这样说,是因为目前只存在部分这类标准。这些内容有时被称为面向方向的功能,因为它们应用到一组服务接口套件中。随着时间的推移,其中的许多配置都将迁移到服务注册表中。

让我们更详细地了解 ESB Gateway 的意图:

虚拟化
  • 路由
  • 映射(只映射数据模型,不包含数据格式)
  • 协议转换(只针对标准化协议)
  • 版本化
可见性
  • 业务应用程序监视
  • 服务水平阈值
  • 问题诊断记录
  • 审计
安全性
  • 身份验证
  • 授权
  • 记录(与可见性中的审计功能有重复)
  • 身份传播
  • 加密
  • 访问控制
  • 威胁保护
  • 数据验证
流量管理
  • 截断
  • 优先化
  • 负载分发
  • 存储/转发
  • 重试

虚拟化

一个经过公开的服务应该从客户的角度进行虚拟化。它们应当完全地从未知(不知道位置和实现方式)的实现中解耦。

  • 路由:这使请求者能够请求一个中央来源(ESB Gateway)并使网关将请求路由到最终的提供者处,这样提供者的位置就可以在不影响请求者的情况下进行修改。取决于地理位置、一天当中的不同时间、服务质量等因素,您可能需要在多个提供者之间选择。
  • 映射:如果提供者使用正确的数据字段执行正确的功能,但是数据模型的结构是不同的,那么 ESB Gateway 将执行映射。然而,这仅适用于映射标准协议中提到的数据模型,比如从 XML 到 XML,从 XML 到 JSON。不要期望 ESB Gateway 对非标准的数据格式执行低级格式化或解析。
  • 协议转换:要将使用不同协议的服务公开到当前提供者提供的协议,必须进行协议转换。然而,注意 ESB Gateway 在这里有一个重要的限制。它只采用 ESB 认可的标准协议进行通信,这些标准协议用于公开服务,还用于与提供者的通信。如果需要对非标准协议进行转换,那么转换工作不应该由 ESB Gateway 完成。这项工作应当由集线器或连接器完成。
  • 版本化:这是前面提到的功能的一个特例。随着时间的推移,服务需要进行维护或提供新特性,但是您必须避免影响到现有客户。版本化策略将创新地应用前面提到的路由、映射和协议转换。例如,通过新旧数据模型之间的接口映射,以及基于头部信息的新旧版本之间的智能路由,将允许保留服务的多个版本。

所有公开的服务是否需要上述的所有 ESB Gateway 功能?

每项服务操作的需求都是不同的。并不是所有服务,或者所有 SOA,都需要全部这些功能。实际上,使用这项服务的用户越多,您与这些用户的解耦程度越高,这些功能就愈加相关和必要。要适当地公开服务,需要付出很高的成本,因此在正式地公开服务之前,您需要确保该服务具有很高的可重用性。

可见性

ESB Gateway 的主要目标就是为服务用户提供功能。然而,许多存在利益关系的其他方可以间接地从服务公开中获得利益,因此,他们需要对网关中正在发生的行为具有可见性。

  • 业务应用程序监视(BAM):为企业提供与其业务直接相关的管理信息。如果服务具有适当的粒度级别,那么它们将执行具有业务意义的操作,因此有关其行为的统计数据对于企业来说是有意义的。这些统计数据可以是任何内容,从产品销售信息,到呼叫中心接收的工作负载的范围。
  • 服务级别:没有人会使用不可信的服务。因此您的声誉,至少在企业内部来讲(并且可能不仅仅限于这个范围),取决于有关服务水平做出的承诺。要想自信地作出承诺,您需要衡量自己对服务承诺的符合度。您通常会关注响应时间、吞吐率和宕机时间。
  • 问题诊断记录:这提供了有关服务问题诊断的信息。与这里描述的其他机制不同,问题诊断记录在运行时通常是可配置的,这样就可以提供有关从网关发出的请求的不同信息,比如说多包含一些有关数据内容的信息,少包含一些有关发出的请求、调用路径的信息,或者根本不包含信息。问题诊断记录的使用者将是 IT 操作人员,因此,数据的表示可能没有其他类型的数据那么复杂。可能仅仅是一个日志文件。
  • 记录:不管出于什么原因,可能都需要捕捉这类信息。例如,如果您要对服务的使用收费,需要了解谁正在使用服务以及一个合理的收费频度。注意,在后面的安全性小节中,将讨论记录的一个特殊形式,称为审计

安全性

服务的可重用度越高,服务公开所面向的受众的范围越广。因此,服务的滥用、错用机会也就越大,不管是有意的还是无意的。总而言之,SOA 越成熟,您就愈加需要关注安全性。下面的安全特性尤其重要:

  • 身份验证 尝试验证请求者确实是他所声称的身份,方式就是接收某种形式的身份标识(比如,用户名/密码或证书),并使用某种形式的目录(例如 LDAP)进行检查。
  • 授权 判断是否允许请求者使用服务。根据安全性级别,可能需要对请求者进行身份验证,或者他们需要属于某个特定的组或角色。对于更复杂的身份验证场景,您可以将这种能力具体化到 Tivoli® Access Manager 之类的产品中。
  • 审计 是必要的,如果存在敏感信息的话,比如客户的个人数据和财务交易经过了您的服务。您需要了解是谁发出请求,他们试图做什么以及何时执行操作。您甚至需要证实 数据的完整性。通常,考虑到法规遵从性原则,这是一个非常困难的要求。
  • 身份传播 意味着并不是所有域都共享相同的用户目录。可能的一种情况是所有经过身份验证的用户仅仅被转换成一个单个的系统用户。从一个域到另一个域的更复杂的用户身份转换通常由一种外部功能执行,比如 Tivoli Federated Identity Manager。
  • 数据加密 非常关键,如果敏感数据被通过公共中介传输的话。加密可能发生在通道级别(HTTPS)或消息级别(信用卡号码加密)。
  • 针对各种各样的攻击实施威胁保护 是必须的,比如 拒绝服务攻击(DoS)和 XML 威胁。尽管这些威胁可能会被 ESB Gateway 的上游组件阻塞,但是需要确定由新出现的协议(比如 Web 服务)引起的新威胁是否得到了充分的考虑。
  • 数据验证 与威胁保护同时发挥作用。在确定 XML 是有效的并且是格式良好的之后,确保内容遵守 XML 模式。除了安全问题之外,数据验证可以极大地简化测试和运行时期间的问题诊断。

流量管理

可见性 小节中,提到了您需要收集有关服务级别以及是否达到了预先设置的阈值的信息。当然,您还需要通过控制流经 ESB Gateway 的流量来对信息进行限制:

  • 截断 允许您控制请求流。可以根据吞吐率或并发性执行截断。这可以保护 Process Server 和 WESB 基础设施本身,同样,还可以防止下游系统出现超载。
  • 优先级别 意味着并不是所有请求都是同等的。您可能需要使用一种方式来确保较重要的请求被首先处理。
  • 当您需要处理多个位置的请求时,那么负载分发 是非常重要的。负载分发可能会跨越一个同构服务器集群,但是这通常是由集群基础设施本身处理的。另一个例子是根据时间表在位于不同地理位置或网络位置的提供者之间切换。
  • 存储/转发 允许在服务提供者不可用时将请求累积起来。另一种用途是协助截断存储尝试,确保没有超出后端系统的并发能力。
  • 如果已知来自后端系统的某类错误或响应是临时性的,重试 将特别有用,比如,将稍后继续尝试同一个请求。在应用重试时需要十分小心,并且要了解提供者的事务性和幂等性。

ESB Gateway 是如何实现的?

我们已经讨论了 ESB Gateway 的理论性知识,现在让我们更实际一些,看看在 Process Server 和 WebSphere ESB 中是如何实现 ESB Gateway 的功能的,以及在哪些位置实现。

回忆一下本文开头的内容,我们在 SIMM 级别 4 中引入的 4 个关键功能 包括:

  1. 标准化公开
  2. 通用请求处理
  3. 特定于标准化操作的请求处理
  4. 服务注册表

图 4 表明,ESB Gateway 非常适合处理前三个功能。每个功能可以大致映射到结构图中的特定组件。

图 4. ESB Gateway 内部
ESB Gateway 内部

我们将查看每一种功能并讨论围绕其实现的各个选项。

标准化公开

标准化服务公开意味着以一种十分常见的方式公开服务,从而确保大多数请求者不再需要使用连接器与集线器展开对话。如图 5 所示,在请求到达网关的位置处完成标准化。

图 5. 标准化公开
标准化公开

下面是有关服务公开需要考虑的主要方面:

  • 传输/协议:首先,需要选择标准的可互操作的协议和传输,比如 SOAP/HTTP 或 REST/HTTP。然而,选择协议和传输仅仅是事情的一个方面。
  • 安全性:安全性本身就足够成为一个主题,但是比如说,您可以指定用户调用的通道的安全性(SSL 等等),或使用头部传播身份和信任关系。服务的重用范围越广,安全性就愈加重要。
  • 事务性:您需要提出的问题包括:用户能否以事务的方式调用服务,从而使他们永远不需怀疑事务是否已被提交?此服务能够与其他服务合并成事务吗?事务性同时为服务的请求者和提供者极大地简化了错误处理,但代价是付出额外的性能开销。您还必须考虑是否希望允许潜在的未知用户对您的内部资源具有低级别的控制。
  • 交互方式:用户应当以同步的方式与服务交互,还是应当以异步的方式进行交互?同步交互为服务的用户提供了更简单的编程模型,并且是提供事务性的一种最简单的方式。异步通信提供的优点包括可靠的交付和可靠的响应。可以这样说,异步通信在具有非常高的并发性的场景下可以实现更有效的资源使用,因为线程没有被打开并且可以实现更复杂的流控制。异步方式也更适合那些需要花费大量时间才能完成的交互,特别是如果所需时间要长于事务或传输的典型超时时间(WebSphere Application Server 中默认为 120 秒)。然而,异步交互将更复杂的错误处理推给了用户。

记住,我们是从如何以标准化 方式提供服务的角度讨论这些功能的,从而确保您的用户能够轻松地使用。目前实现这些特性的主要方式就是使用大量的 Web 服务标准。

图 6. 为 Web 服务导出定义默认策略集
为 Web 服务导出定义默认策略集

您可以使用如图 6 所示的策略集,在 WebSphere Integration Developer 6.2 的 Web 服务导出中实现它们。策略集将标准分组为常见的组合。一个给定的策略集将包含与安全性(LTPA、安全对话、WS Security、SSL 和 HTTPS 等等)、事务性(WS Transaction 等)和交互方式(RAMP 和 WS Reliable Messaging 等等)有关的标准组合。

图 7. Process Server 管理控制台中的策略集定义
Process Server 管理控制台中的策略集定义

在服务器中,许多预定义的策略集都是可用的,并且可以创建更多自定义策略集(图 7)。

Web 服务的替代选择以及用于服务公开的 SOAP

Web 服务并不是有关服务公开的唯一标准。例如,使用 HTTP 绑定也可以通过 HTTP/REST 公开服务。然而,在撰写本文时,HTTP/REST 还不能提供可用于 Web 服务的更深层的标准。因此,它的关键优势在于其简单性、嵌入到 URL 和 HTTP 操作组合中的功能性,以及更灵巧的数据格式(JSON)。给定服务究竟如何被公开,这取决于您能否清晰地理解以上提到的公开功能的需求。

绑定与适配器之间的区别是什么?

如果您曾经考虑过为什么 Process Server 的连接性是使用导出/导入绑定提供,而其他则是由 WebSphere Adapter 提供,那么您现在也许就可以回答这个问题。导出和导入绑定通常用于 “标准化” 公开。例如,它们通常被提供给常用于在 SOA 中公开服务的协议。WebSphere Adapters 用于更加少见的连接方法,这些方法通常使用更低级的 API 和更复杂的交互模式。一般而言,可以认为 ESB Gateway 只使用导出/导入绑定,而不使用适配器,因为它仅仅使用标准化协议。

在您开始深入研究使用 Web 服务提供这些功能的所有方法之前,让我们进一步查看一下本质问题。某些替代服务可能只能在本地域中重用。在这些情况下,可以更加轻松地使用协议/传输提供现成的事务性、安全性和同步/异步交互模式,而不会涉及复杂的 WS-* 标准。默认情况下,这些属于 SCA 的自带的导入/导出绑定。

SCA 在性能方面也提供了许多优势。因此,如果重用范围限制在本地的话,我们强烈建议您考虑通过 SCA 进行公开。如果服务的使用者不一定是 Process Server 或 WESB 的话,那么还可以考虑 JMS,而不是服务集成总线(SIB)或 EJB。

值得一提的是,对于在企业内部公开的服务,考虑任何具有足够的普及性的传输。例如,通过 WebSphere MQ 公开服务是很常见的。

如果需要公开多个协议应该怎么办?

要求使用多个公开机制的需求并不少见。最常见的是通过 SCA 为本地请求者提供服务,以及通过 Web 服务为更广泛的请求者提供服务。然而,此时需要特别小心。您一定不能陷入这样的误区:为每一个用户提供专用的公开机制,否则您将退回到 SIMM 级别 3 并将失去真正成熟服务的可重用性和解耦优点。

为了获得 SOA 的简单性和可维护性,您需要将公开方式的种类减至最少,这些公开方式可以服务于相当广泛的用户群。

让标准生效

让我们强调一下为什么没有讨论与入站请求相关的各种功能,比如数据处理器和适配器。主要原因是因为在 SIMM 级别 4,您只关心通过标准化协议和传输公开请求。可以这样认为,作为所选标准以及产品支持的隐含部分,数据处理和协议管理的功能在一定程度上是免费的。要确保 SOA 不仅是可消费的,并且在今后是可维护的,对所用标准的严格治理至关重要。

通用请求处理

从选择方式的定义来说,已公开的服务是非常重要的业务事务。将有许多不同的群体会对公开的服务感兴趣,所有群体都希望获得不同的信息,甚至是对服务的控制。您需要确保针对这一类型的处理,所有服务都具有相同的待遇,或者至少服务处理遵守已知的方式或策略。

图 8. 常用请求处理
常用请求处理

ESB Gateway 的主要职责就是提供通用请求处理。如图 8 所示,WebSphere Process Server 和 WebSphere ESB 版本 6.2 中的服务网关模式是最合理的方式。我们稍后将更详细地描述服务网关,但是首先来了解一下您需要提供的信息和控制类型:

  • 系统监视:服务是否已经启动并运行?它的事务率和响应时间是多少?它是否满足服务水平协议(SLA)?
  • 记录:如果您向人们收取在 SOA 上使用服务的费用,或者您仅仅是想收集有关服务一般使用情况的统计数据,您将需要记录发生的所有请求,甚至还需要记录请求的发起者。
  • 业务活动监视(BAM):这些是关于服务的聚合的业务相关统计数据。我的客户来自哪里?在一些重要日期完成的销售额是多少?
  • 管理:如何控制对服务的访问?我如何关闭或开启服务?如何在重新定位实现时重定向服务?
  • 问题诊断:我的消息去哪了?数据结构在网络中是什么样子?这些是针对各种诊断目的而经常执行的记录和跟踪活动。

您需要尽可能地令 SOA 具有同构性,因此需要以相同的方式为所有请求实现这些功能。因此,这就是为什么要归类为通用 请求处理而不是特定于操作的 请求处理。许多服务类别很可能需要相同类型的请求处理,因此理想情况下,您需要根据策略执行服务处理,而不是将其编码到每个请求中。

因此,如果您获得了一个由 Process Server 模块公开的简单服务,如何实现这个标准的请求处理呢?有两个主要选择:

  • 中介流组件和服务网关模式
  • SOAP 处理程序和逻辑处理程序

这些内容将在后面的小节中介绍。

中介流组件和服务网关模式

在 Process Server 中,用于执行以上功能的最明显的组件选择就是中介流组件。在中介的请求和响应流中,您具有中介原语,它们将提供上述功能,例如:

  • 消息记录器,用于通过文件和数据库执行记录、跟踪和审计。
  • 事件发射器(Emitter),用于通过 Common Event Infrastructure (CEI) 进行审计,用于实现业务应用程序监视,如果使用了 WebSphere Business Monitor 的话。
  • 服务调用,用于发出请求,比如,将请求发送给 JDBC 适配器,以实现自定义审计解决方案等。

目前为止一切良好,但是等一下,我们不是已经提到了通用 请求处理了吗?在一个普通中介流中,您针对每个单个操作将这些原语单独添加到中介中,那么在哪些方面体现了通用性 呢?对于所有重复的代码,一定会出现不一致性,因此将很难进行维护。要保证使用一种通用的方法,对开发标准进行归档,以确切地定义哪些原语被始终放到流中,以及它们如何配置。但是,仍然需要针对每个操作单独执行原语,这样就会为人为错误留下很大的空间,并且难于维护。如果以一种更加通用和集中的方式执行所有操作,那么将非常理想。

我们稍后讨论的一种选择就是使用中介子流。然而,由于这些必须单独放到每一个操作中,因此实际上更好的做法是在稍后讨论的特定于标准化操作的请求处理中实现通用性。对于通用请求处理,有一个更好的选择。

WebSphere Process Server 6.2 提供了一个新的功能,称为服务网关 模式。它是中介流组件的一项特殊应用。区别在于,普通的中介流组件在接口中为每个单独的操作定义了流,而服务网关通过相同的中介传输所有操作。这允许您以通用的方式定义如何处理传输给给定接口的所有操作,这正是您用于实现通用请求处理 所需的功能。

您可以自己创建一个服务网关。服务网关实际上是由标准组件和一些重要的配置设置组成。如果您是第一次尝试创建的话,最好使用如图 9 所示的服务网关模式。

图 9. 根据提供的模式创建一个新的服务网关
根据提供的模式创建一个新的服务网关

服务网关模式给出了一个向导,提供了以下选择:

  • 网关将如何执行日志记录
  • 哪些路由是必须的
  • 将使用哪些协议来公开网关
  • 将连接到哪些服务提供者

如下所示的两篇文章将提供有关服务网关细节的优秀介绍,因此我们在这里就不做重复介绍。

考虑到本文的意图,我们将只介绍一个非常简单的服务网关示例,它具有一个问题诊断记录功能,您可以在一个注册表中进行远程配置。

图 10. 服务网关包含由策略驱动的问题诊断记录功能
服务网关包含由策略驱动的问题诊断记录功能

图 10 中的 LogForDiagnostics 是一个 Message Logger 原语,它被添加到中介之中,以便在需要执行诊断时提供最好的日志记录。它的大部分属性都是预先配置的。可以从图 11 中看到,某些属性被设置为可提升的属性(promotable properties),这意味着您可以通过管理控制台设置它们。

图 11. LogForDiagnostics 原语中的提升属性
LogForDiagnostics 原语中的提升属性

通过使用提升属性,您现在可以通过管理的方式打开或关闭日志功能(Enabled 属性),修改记录发生时的日志级别(Level 属性),并决定日志记录是否发生在和请求相同的事务中(Transaction mode 属性)。

更加有趣的是,通过使用一个策略查找原语,这些属性可以从注册表中获得它们的值,这正是图 10 所示的 RetrievePolicy 原语的目的。有关如何使用策略查找实现此目的的更多信息,请参考 WebSphere Enterprise Service Bus V6.2 中的新特性,第 3 部分:中介策略

您可以准备一个单一的服务网关,它将公开所有(或者至少是几组)服务并执行所有常见处理,比如监视、问题诊断、记录和安全性。

SOAP 处理程序/逻辑处理程序

我们还将简单讨论另外一个替代选择。您需要的通用请求处理可能停留在 SOAP 或 JAX-WS 协议的级别。如果是这样的话,Integration Developer v6.2 可以直接向一个 Web 服务导出添加自定义编写的处理程序。您可以编写两种类型的处理程序:SOAP 处理程序逻辑处理程序

图 12. 创建一个新的 JAX-WS SOAP 处理程序
创建一个新的 JAX-WS SOAP 处理程序

SOAP 处理程序和逻辑处理程序实际上不过是 Java™ 类罢了。图 12 展示了如何让 Integration Developer 为您创建一个模板处理程序,这样您就仅需编写可以处理请求消息和错误的方法。

SOAP 处理程序允许通过一个 API 访问消息,这个 API 可以感知 SOAP 协议,并且打个比方说,还可以提供对 SOAP 头部的简单访问。在大部分情况下,这将简化处理程序的编写。

当您需要一种对协议不可知的处理程序时,可以使用逻辑处理程序。比如说,该处理程序并不知道您正在处理一条 SOAP 消息,并且将消息完全当作 XML 内容对待。这样做增加了灵活性,但是增加了编码和维护的难度。

特定于标准化操作的请求处理

从根本上说,ESB Gateway 必须知道正在处理的操作有哪些,以便将它们路由到合适的下游中介(以供进一步集成),或者直接发送给服务提供者。在路由过程中,还有一些其他的特定于操作的处理适合 ESB Gateway 执行。

图 13. 特定于标准化操作的请求处理
特定于标准化操作的请求处理

实际上,任何以标准化方式执行、但涉及特定于操作的知识的功能,都适合 ESB Gateway。如果实现了充分的标准化,那么可以将它添加到服务网关 组件中,如图 13 所示。

对于这里指出的特定于标准化操作的工作,以及在普通中介流下游组件中执行的特定于普通操作的功能,两者之间存在一个微妙的职责划分。由于该领域还没有出现可以遵从的行业标准,因此在设计这方面时仍然需要特定于每一个用户。然而,我们开始将以下内容看作是通用的功能:

  • 路由:您现在已经知道自己正在处理的是什么操作,这一事实已经提供了足够的信息来将请求连接到合适的端点。路由可能还需要基于 URL,后者对于服务网关来说,可以从 HTTP 头部获得。您使用消息过滤器(路由器),根据 URL 以及任何其他消息头部内容来执行路由。您还可能通过一个端点查找原语来具体化路由。您可以通过服务调用和调出(callout)原语中的提升属性来配置和管理备用端点。
  • 流/并发性控制:下游系统在接收到的请求的数量方面存在限制。可能在一天当中的某些时候,请求必须被发送给备用端点,必须进行异步处理,甚至是被拒绝。您可能需要提升那些能够对调用方式、备选路由和重试配置等等启用管理控制的属性。
  • 审计:谁在这个时刻执行事务?他们执行了哪些其他事务?这将为遵从性或其他目的(比如收取服务使用费用)提供一个审计跟踪。您很可能使用消息记录器、事件发射器原语或者调用审计服务或 JDBC 适配器来实现此目的。
  • 访问控制:细粒度的访问控制可能是必须的,通过一个数据库查找原语或对特定于应用程序的授权服务的调用实现。
  • 语义映射:如果您将对其公开服务的用户数据模型不同于 ESB Gateway 中常用的数据模型,那么您需要使用业务对象映射或 XSLT 转换原语来执行转换。需要注意不要把复杂的条件映射卷入到 ESB Gateway 中。绝对不应对非标准格式进行数据格式化或解析。

上面的某些功能组合可能被编码到服务网络流中。所有请求都经过流,但是一个策略查找原语为所有相关的提升属性设置了特定于操作值,这样针对每个具体的情况就会有不同的行为。

然而,在服务网关流中不应当执行的行为就是按照操作名称过滤,并开始创建大量特定于操作的逻辑的分支。这些内容显然不是 标准化的。它们应当在一个普通中介流中执行,这正是普通中介流的设计意图,并且普通中介流为每个操作清晰地分离了流。换而言之,这些内容没有包含在 ESB Gateway 组件中。

标准化请求处理的其他方式

如果您无法让所有请求通过相同的服务网关组件,但是您仍然希望向每个请求添加一些标准化代码,该怎么办?还有一些其他的替代选择,您可以单独使用它们或者结合服务网关来提供其他形式的标准化。

使用中介子流来标准化请求处理

通过将所需的原语序列嵌入到中介子流中,您可以简化开发人员对标准化代码的使用。您可以将代码存储到一个库中,如图 14 所示,这样它们就可以用于许多不同的操作,甚至用于其他模块中。

图 14. 在库中创建一个中介子流
在库中创建一个中介子流

Process Server 和 WESB v6.2 中引入的子流指一种在可重用流片段中捕捉一组中介步骤(原语,如图 15 所示)的方式。

图 15. 子流中捕捉到的一组常用操作
子流中捕捉到的一组常用操作

您希望子流尽可能地实现重用,因此需要将它设置为可以接收有可能要使用的最常见的操作类型(图 16)。这需要在接口设计阶段进行一些思考。

图 16. 为子流设置消息类型
为子流设置消息类型

您可能期望在子流中找到策略查找 原语,但目前来讲,这实际上是 可能的。如果仔细思考一下,答案就会很明了。子流不知道它此时正在执行什么操作。然而,子流的提升属性对实现它的父流来说开始变得可见,因此您应该在父流中执行策略查找

自定义原语和自定义可视化片段

值得一提的最后几个标准化流实现的选择是使用 自定义可视化片段(custom visual snippets)中介原语插件。这两者都允许实现者使用常见的复杂功能,就好像把这些功能当作可视化片段或中介流中的另外一项内容。这在一致性和维护性方面带来了优点。这并不是特定于 ESB Gateway 的。这是一项通用的良好实践,可以以这种方式将常见的复杂代码封装起来,从而供实现者更容易地遵循您的开发标准。在前面的 Information Center 链接中,可以找到有关此主题的大量 developerWorks 文章

其他帮助实现标准化请求处理的工具

不要忘记有大量钩子已经可用于产品中,或是使用相关的产品。下面是其中一些选择:

  • WebSphere 管理控制台中提供的标准 Java 日志和记录功能允许针对特定组件类型设置日志记录。
  • Performance Monitoring Infrastructure (PMI) 和 Tivoli Performance Viewer 是底层 WebSphere Application Server 产品的一个标准组成,提供了大量统计数据,例如组件响应时间。Application Response Measurement (ARM) 统计数据也同时可用。
  • 来自 v6.2 的 Business Process Choreographer Explorer 也包含了 Business Process Choreographer Observer 报告,提供了有关通过 WebSphere Process Server 的请求的历史统计数据,如果请求与长期运行的业务流程有关的话。
  • 使用 远程测试客户机跨组件跟踪 工具,可以提供复杂的调试功能,从而避免了在许多情况下对诊断记录的需求。然而,人们认为这些工具不太适合用于生产环境。
  • Tivoli ITCAM for SOA 提供了有关 Web 服务请求的更复杂的系统监视,并且集成了 WebSphere Services Registry 和 Repository。

什么情况下会触及 ESB Gateway 的底线?

除了我们已经详细讨论的 ESB Gateway 外,SIMM 级别 4 图表中还出现了集成 “集线器”(参见 图 2)。它是做什么的?我们在什么情况下需要它?换句话说,您在 ESB Gateway 中不应该 做什么?

如果您的特定于操作的需求完全是针对操作自定义的,那么此时您就需要求助于与 SIMM 级别 3 中的所有技巧的传统集成。这需要在集线器中执行,而不是 ESB Gateway。您不希望这些高级集成问题加重 ESB Gateway 的负担。尽管这些高级集成模式属于后面一篇文章的主题,但是这里将给出一些例子,了解一下在 ESB Gateway 中绝对 应执行的特定于操作的处理:

  • 非标准化协议/格式:ESB Gateway 只应与标准协议通信。它不应该和非标准的协议、低级 API 或数据格式通信。因此,您可以认为,它不应该使用适配器。
  • 编制(Orchestration)/编排(choreography):永远不要要求 ESB Gateway 发出多个调用来满足一个请求。始终应当遵循一个 “一个请求传入,一个请求传出” 的原则。
  • 状态逻辑:永远不要要求 ESB Gateway 在请求之间持久化或拥有任何形式的状态。

结束语

本文主要讨论以一种一致的方式公开服务,并详细地介绍了 ESB Gateway,因为它对于企业成功实现其 SIMM 级别 4 成熟度十分关键。在 SOA 中正式地定义 ESB Gateway 的概念将提供标准化的服务管理和可视性,这是一个成熟 SOA 所必需具备的。如果您在 SOA 扩展期间有机会管理治理它的话,那么保持服务公开的一致性至关重要。

我们已经分离出 ESB Gateway 的角色,因此将它放到架构的单独层中是有益的。这样做越来越常见。另一个常见现象是,一个大型 SOA 中的独立产品(比如 WebSphere DataPower)使用 ESB Gateway 替代集成 hub 以关注更深度的高级集成。尽管这已经超出了本文的讨论范围,但是在 IBM® 红皮书 Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB 中的第 9 章中,讨论了 WebSphere DataPower 在 SOA 中的位置。

尽管我们主要讨论的是服务公开,但是我们忽略了在连接到真实的(并且常常是陈旧的)后端系统时出现的深度集成挑战。在后续文章中,我们将研究集成 hub 中发生在 ESB Gateway 以外的所有神奇的高级集成模式。在成熟的 SOA 中,与这些非标准后端系统的复杂集成常常占据了项目的很大一部分。

我们在本文中还忽略了 WebSphere Process Server 的 “处理” 部分。我们将在下一篇文章中回到这个主题,并查看不同的处理实现类型、它们的用途,以及它们的实现方式。


致谢

本文观点主要由我和 Brian Petrini 共同提出,他将参与撰写本系列的其他文章。

本文中的结论来自于我们与相关人员对设计、项目经验的讨论,也有部分结论来自于我们与产品创建人员的对话。特别感谢以下人员:(按姓名字母排名):Andrew Ferrier、Andy Garratt、Bobby Woolf、Callum Jackson、Chris Markes、Geoff Hambrick、Greg Flurry、Helen M. Wylie、Jonathan Adams、Peter Lambros、Rob Phippen、Stephen Cocks 和 Paul Verschueren。实际上,还有很多人值得感谢。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, SOA and web services
ArticleID=430881
ArticleTitle=WebSphere Process Server 和 WebSphere ESB 中的解决方案设计,第 2 部分: 在 WebSphere Process Server 和 WebSphere ESB 中设计一个 ESB 网关
publish-date=09282009