铁手剑谱

上善若水
数据加载中……
企业服务总线(ESB)(2)

16.1ESB 的特性

由于试图快速进入成长中的 ESB 范畴的厂商的慌乱,以及大量行业分析师和记者在分析报告中分别展示他们各自的观点,可以理解,这其中对于ESB 到底是什么还具有很多混淆。这一节将概略说明 ESB 的主要特性。

1.6.1 普遍性

如第 1 章所示, ESB 能形成普遍的网格的核心。它能够跨越和超过扩展企业,并且横跨部门组织、业务单位和贸易伙伴形成全局的范围。ESB 也能很好地适合于局部的集成项目,并且对促进它们采用任何类型的集成环境提供柔性的支撑。

clip_image002

图表 1‑2 ESB 形成一个能跨越了一个全球企业网络的普遍网格

应用可以按需插入总线,并且具有可视性,以及能够与其它已经插入到总线中的任何其他应用和服务共享数据。虽然Web Services是 ESB 架构的一个有机组成部份,但是所有的应用并不是一定要被修改成为真正的Web Services才能参与到 ESB。连接性是通过多种协议、客户端API 技术、遗留消息环境、以及第三方应用适配器来达到的。

1.6.2 基于标准的集成

基于标准的集成是 ESB 的基本概念。对于连接性,ESB 可以使用J2EE组件,比如使用Java Message Service (JMS)来进行MOM连接,使用J2EE 连接器结构 (JCA 或 J2CA) 来连接应用适配器。ESB 也能够非常漂亮地与使用.Net、COM、C#、C/C++构建的应用进行集成。除此之外,ESB 也能集成支持SOAP和Web Services API的任何组件,这其中包括事实上的标准Web Services工具箱的实现,比如Apache Axis。为了处理数据操纵, ESB 可以使用XML标准,比如XSLT、XPath 和 XQuery 来提供数据变换、智能路由、以及在数据流过总线的时候提供“空中”查询。为了处理 SOA 和业务流程路由, ESB 可以使用 Web Services描述语言 (WSDL) 来描述抽象的服务接口,使用针对Web Services的业务流程运行语言(BPEL4WS)、WS- Choreography或者一些其他基于XML的词汇表,如 ebXML BPSS,来描述抽象的业务流程。

如果你还不懂这些深奥的词汇的含义,也不要担心。虽然本书并不想作为是这些各个技术的详细参考或个别指导,我们也会在他们如何与 ESB 有关的语境中足够详细地解释它们。

这些基于标准的接口和组件被整合到一个意义非凡的包含开放端点的可插入架构之中。ESB提供了一种基础设置来同时支持基于工业标准接口集成组件和使用标准化接口来实现的专有元素。下图展示了一个使用JMS和JCA集成一个 J2EE 应用、使用JCA应用适配器集成第三方打包软件、使用C#客户端程序集成一个.NET应用、使用Web Services集成两个外部应用的案例的高阶视图。

clip_image004

图表 1‑3 ESB 整合多种不同的技术

1.6.3 高度分布的集成和选择性部署

ESB 在其中借鉴了传统EAI Broker的许多功能,比如从它提供集成服务 , 像是业务流程编排、数据路由、数据变换、以及应用适配器。然而,集成中介者通常是高度集中和单一的形态。ESB 将这些集成能力提供为独立的服务,能够以一种高度分布的形态一起工作,并且能够彼此间独立伸缩。在第 6 章中,你将会学习更多有关 ESB“服务容器”,ESB 的一项核心概念的内容,它允许对集成服务进行选择部署。

1.6.4 分布式数据变换

任何集成策略的一个关键部分就是能够轻易地在应用之间转换数据格式的能力。许多应用对描述相似的数据并不共享相同的数据格式。

数据变换是一个 ESB部署的一个固有部份。变换服务特别针对那些被插入总线的个别应用能够在总线的任何地方被定位和访问的需要。因为数据变换是ESB 本身的一个有机组成部份,解决应用之间的阻抗失配问题便可以想到ESB。

1.6.5 通过分层的服务来达到可扩展性

ESB 能够为你提供本质上针对任何集成项目所必需的核心能力,并且可以通过使用分层的服务来处理特定的用途来增加。例如,特殊的能力,比如业务流程管理 (BPM) 软件能处理工作流相关的业务流程,而协作服务器能够提供对伙伴业务流程管理的特殊服务。专门的第三方翻译器能够将外部数据,比如EDI,转换到能进入目标企业资源规划 (ERP) 系统之内的格式,或者在通用总线之上的规范XML表现。

1.6.6 事件驱动的 SOA

在 ESB驱动的、事件驱动的 SOA中,应用和服务被当做抽象服务端点,能够轻易地对异步事件做出响应。SOA 对其底层的连接性和管线细节提供了一个抽象的方式。服务的实现不需要理解协议。服务也不需要了解消息是如何路由到其它服务的。他们只是简单地将接收自 ESB 的一个消息作为一个事件,然后处理该消息。ESB 可以把消息发送到它想要去的其他任何地方。

在 ESB SOA 中,用户定制服务可以被创建、扩展,并且被重用为ESB 功能。被暴露为服务的应用端点,可以同特殊的集成功能一起构造成复合业务服务和业务流程,并且它们可以根据不同目的重新组合,其目标是在一个即时企业中提供自动化的业务功能。

第 7 章将会更详细地讨论 ESB 中的 SOA 。

1.6.7 处理流

ESB的处理流从简单的优先步骤序列到使用条件分支和联合来并行执行的综合业务流程编排。这些特征可以使用简单的消息元数据或者通过使用诸如BPEL4WS 之类的业务编排语言来控制。

ESB 的处理流能力使得定义属于某个部门或者业务单位局部的,或者共存于一个较大的集成网络中的业务流程成为可能。这点却是一个集线器-插头中介者或一个 BPM 工具自己所不能很好地自己解决的问题。第 7 章将会详细讨论分布式的流程能力,它能提供高度分布的流程编排能力而不需要中心化的流程和规则引擎。

ESB的业务流能力也涉及到基于内容的消息的智能路由的特殊集成服务。

因为ESB 的业务流能力构建于分布式的SOA之上,它也能够跨越高度分布的物理部署拓扑(甚至扩越大洋)而不用痛苦地忍受总线上各种应用和服务之间的物理边界和多协议的鸿沟。

clip_image005

图表 1‑4 跨越物理和逻辑边界之上的部署拓扑的编排和业务流

1.6.8 安全和可靠性

在 ESB 上的节点之间的连结是具有防火墙能力的。应用和 ESB之间的安全性,甚至在 ESB 节点自身之间的安全性,能够建立和维护最高强度的认证、凭证管理、和访问控制。

可靠性是通过处于ESB核心的企业级MOM来达到的。MOM核心提供异步通信能力、业务数据的可靠传输、以及事务的完整性。你们将在第 5 章中学到,这已经不是十年以前的传统MOM技术了。需求从那时以后开始进展,并且已经成熟,而 作为ESB 的核心的MOM必须符合今天的需求。

1.6.9 自治但联邦的环境

传统的集线器-插头中介者方式往往具有组织性的边界问题,这主要是因为EAI Broker对跨越防火墙和网络域的无能的实际限制所引起。更重要的是,即使一个集线器-插头架构能够被伸展而跨过组织的交界,它仍然不允许各个业务单位彼此半独立地运行所需要的局部自治。与不断扩展的集成范围延伸超过部门层次所相关的最大问题之一是自治和集中控制之间的问题。

作为大多数大型公司环境的业务文化的一部分,每个部门或业务单位需要彼此独立地运作。 然而,他们仍然依赖于共享资源,以及输入到通用业务功能之中的报告和帐户信息。

在这样一个环境中,需要所有的消息流量都流过位于总部的一个集中的消息Broker的集成策略是不合理的。 这不只是一个技术上的障碍;它也是公司文化的问题。在一个松散耦合的业务单元环境中,诸如本地应用之间的业务流程,或者安全域,被一个集中化的公司IT功能管理简直没有一点道理。组织中的松散耦合业务单元需要彼此独立地运作。他们每一个都应该有其自己的IT功能,而不必须路由所有的消息流量,或代表它的业务规则和安全域的控制, 经过一个集中的集成经纪人在一个位置或另一个(第 1 章)。

clip_image006

图表 1‑5 如果使用一个集中的集线器,分开业务单位缺乏必需的自治-和-了集成经纪人

本地业务单位和部门需要有对他们自己的局部IT资源的控制,比如在其站点运行的应用。集成基础设施应该支持部署拓扑来支持具有实用性的业务模型。ESB 也提供这种部署模型, 允许本地流量、集成组件以及适配器能够被本地安装、配置、加固和管理,并且仍然能够以一种集成的安全模型一起将本地集成域插入到一个更大的联邦集成网络之中。

clip_image007

图表 1‑6 自治的而且公布联邦制,ESB 允许横过组织的交界对合作地同盟的运算组织

ESB 的分布式特征是通过从实际的部署细节和底层的连接协议中抽象出来的将端点定义,以及在那些端点之间的数据的编排和路由来达到的。联邦特征则是通过 ESB 能够隔离和选择地横过应用域和安全边界的能力来达到的。

1.6.10 远程配置和管理

在一些业务模型中,在每一个远程地点都安排有本地的IT职员是不大可能的,虽然仍然需要松散耦合的、自治的联邦的集成网络。举例来说明这一个点,我们来想象一下部署在零售行业中的ESB 的案例。一个视频租借链可能有数百或数千个包含相同应用的地点,所有以相同的形态运行的操作涉及到目录管理、会计和报表等。

clip_image009

图表 1‑7 和数以千计遥远的储存一个视像零售链,所有的包含应用程序的相同组

使用 ESB,可以建立一个集成蓝图来处理远程店铺中的局部应用之间的通信。这包括店内应用的接口定义、消息流量的路由、消息通道的管理、以及安全许可。它还可能包括集成组件,比如应用适配器、协议适配器或者数据变换器。这个集成蓝图,或称模板,可以在所有地点进行部署和定制,并且独立地扮演所有其他店铺。

clip_image011

图表 1‑8 ESB 配置蓝图在每个遥远的位置和很远地展开配置而且处理

这个远程部署蓝图的能力并不单针对零售行业,它也可以扩展到所有其他行业的应用。联邦的集成域的远程管理对于在一个高度分布的环境中的任何ESB的成功部署都是非常关键的。

安全、可靠的消息联结

除了在每个店铺的本地应用之间共享数据之外,这些远程店铺还需要同总部共享信息以便进行帐务处理和报表、信用管理以及职员数据的追踪。远程店铺还需要彼此之间共享信息。举例来说,一个大型的音像连锁店可能会提供这样的服务,顾客可以选择从离家近的店租赁影碟,然后在离办公室近的另一个店归还。因此,在同一个地理区域内的店铺之间可能会需要以近乎实时的状态共享有关租赁的数据。因为在远程店铺和总部之间的卫星网络通信连接存在较大的反应期和弹性,要在总部维护一个有关所有租赁信息的实时集中访问点是不现实的。那些有关你只是在两个小时之租借的数据需要共享,或者通过远程店铺之间的一个集成的数据共享连接来进行访问。

因为总部和远程店铺之间的连接是通过可靠的消息来达到的,因此由于不可靠的卫星电路所造成的网络服务终端可以从消息层得到补偿。也应该注意到,对于远程店铺之间来说,通过Internet来建立一个安全和可靠的消息通道也是可以的。

1.6.11 作为ESB的“原生”数据类型的XML

当数据通过ESB 在应用之间流动的时候,XML是一个表现它们的理想基础。被应用程序的一个巨大的行列生产而且耗尽的数据能以多种的格式存在和包装方案。有大量的应用产生和消费的数据,可以以各种格式或者打包的Schema存在。对ESB来说虽然的确可以依你喜欢的打包形式或者封装方案来承载数据,但将途中数据表现为XML具有莫大的好处,包括使用能够结合来自于不同的源数据以创建一个新的数据视图的产生数据的特殊 ESB 服务, 以及针对应用间高级数据共享的浓缩和重定目标。第 4 章将会探究使用XML功能本好处—将避免一个组织的应用间同步升级的需要—并且更详细地讨论分布式XML变换之后的基本原理。

1.6.12 业务数据的实时吞吐

ESB通过为途中数据在总线之上的应用间传输的时候提供实时吞吐消除了潜伏反应问题。目前,最流行的集成方法之一是每夜进行批处理。 然而,打包的成批处理集成策略,不管是每夜还是其它,都具有较高的边际错误率,并且造成信息获取的延迟。其结果是高反应期产生获取了过时数据将使代价高昂的。第 9 章将详细讨论这个问题,并且研究 ESB 可以如何用来将你的业务数据从每夜批处理模式重构为实时吞吐模式。

1.6.13 运行感知

运行感知意思是业务分析师能够获得对业务运行的状态和健康情况的洞察能力。 一个允许对数据在其以某个业务流程中的某个消息形式在组织中流动时进行实时跟踪和报告的基础设施,对于帮助建立运行感知是一个无价的工具。一个称为是业务活动监控 (BAM)的产品门类已经出现来解决运行感知的这些问题。

使用XML作为ESB的原生数据格式的好处之一就是消息没有被处理为不透明的数据块。如果应用和服务之间的所有数据都被格式化为XML文档,ESB提供的基础支撑便允许你在ESB之上再构建一层高级能力,以获得对流过你的企业的业务数据的实时洞察能力。这些能力,不管是否是ESB的固有组成部分,还是有一个扩展来驱动,都表现为包括了路由、处理流、以及下层的管线,并且不需要再在其上锁定一个第三方的BAM产品的一个通用基础设施的一个有机组成部分。

作为ESB的一个基础部分的审计和跟踪能力允许对在SOA中的所有流动的业务流程和消息流的健康状况进行监控和跟踪。诸如数据缓存、数据收集和聚集、以及XML数据的可视化表现之类的增值服务,可以用来创建一个基础服务,该基础服务可以在数据在企业中流动时,产生对业务流程的状况洞察的警告、提醒和报表能力。

clip_image012

图表 1‑9 增值型服务促成操作的觉察提供对活的业务数据的即时洞察

对ESB中的数据的根踪和报表是通过在业务流中定义审计点来达到的,然后再对从业务消息中收集的重要内容在ESB中流动时提供插入点。可追踪数据例子是业务消息自身,以及指示某业务消息是否通过了某个特定的业务处理步骤的业务事件。

高级的增值服务可以提供数据收集服务、查询机制以及报表能力,它们能够讲所有数据进行收集、进而表现为各种具有意义的形式。XML持久性服务可以提供缓存和聚集点,这样可以收集将要转换的数据从而向其他应用提供数据输入,或进入到可以被业务分析师使用的人可读的报表机制之内。这意味着流经ESB的数据可以进行实时分析,以提供有关你的业务状态的实时信息—比如,可以随时提供有关你的供应链中的存货的状态快照。

1.6.14 逐渐采用

区别是否真正是 ESB 的一个主要方面是看其是否具有逐渐采用的能力,相对于另一个“全有-或-全无”的论断。在 Y2K 之后的开支削减中,数百万美元预算的项目数目已经今非昔比。有一些迹象表明,预算资金筹备正在开始释放以解决短期的战术性集成需要,但是预算仍然谨慎地处于一个执行层面。,然而,同时仍然有一些期望实现较大的公司范围集成策略计划—这些计划严重依赖于集成和现有IT资产的重用。

图1-10说明了 ESB 可以如何用于小项目中,然后它们都可以进入到一个更大的集成网络之内。 当我们深入阅读本书的时候,我们会详细研究这是如何实现的。

clip_image013

图表 1‑10 ESB 支持逐渐采用的集成,同时向着一个策略目标工作

ESB 的联邦/自治能力也对一次一个项目采用 ESB的能力有助益。ESB 集成项目渐进式的分布部署能够在朝着一个更广的企业层面的计划目标的前提下得到立即价值。

逐渐采用的观念将进一步通过桥接到一个已有的集成Broker集线机器和遗留系统Broker来得到进一步支持。集成Broker集线器和他们的特点将在第 2 章中详细研究。

posted on 2007-08-09 09:26 铁手 阅读(1847) 评论(0)  编辑  收藏 所属分类: 企业架构WS/SOA/ESB


只有注册用户登录后才能发表评论。


网站导航: