企业服务总线(SOA与ESB)技术方案建议

dlwyh 贡献于2011-11-28

作者 luqiangm  创建于2007-10-08 01:58:00   修改者ZC  修改于2008-07-09 12:56:00字数27864

文档摘要:预期阅读人员包括负责科技管理的各级领导、负责科技管理的业务人员、ESB项目管理人员、ESB平台实施人员、ESB平台运维人员和其他需要阅读本报告的项目经理、IT架构师等。
关键词:

企业服务总线技术方案建议 目 录 第1章 概述 1 1.1 读者对象 1 1.2 定义 1 第2章 面向服务的体系架构简介 2 2.1 SOA的业务驱动力 2 2.2 什么是面向服务的体系架构 4 2.3 面向服务的体系结构所带来的好处 5 2.4 应用系统的的整合与ESB 6 2.4.1 企业应用整合与ESB 7 2.4.2 ESB的要素 9 2.4.3 ESB的功能 10 2.4.4 ESB的实现模式 12 2.5 应用系统整合的国内外现状 14 2.5.1 项目案例 16 2.5.1.1 某国内著名通信公司方案概述 16 客户需求: 16 建设方案: 16 产品选择: 17 2.5.2 某较大型商业银行ESB项目简介 17 第3章 关键技术分析 19 3.1 与现有系统的集成 19 3.1.1 与基于J2EE系统的集成 19 3.1.2 与基于MQ系统的集成 20 3.1.3 与基于CICS系统的集成 21 3.1.4 与基于邮件系统的集成 22 3.1.5 与基于C/S架够系统的集成 22 3.2 平台扩展性与高可用性的实现 23 3.3 平台安全性的考量 24 附录A:产品技术文档和白皮书 26 A.1 WebSphere MQ 产品简介 26 什么是WebSphere MQ? 26 WebSphere MQ重要特点: 28 其它特点... 30 为什么要用WebSphere MQ产品? 31 A.2 WebSphere Message Broker 产品简介(Gu) 33 WebSphere Messages Broker 亮点和概括 34 WebSphere Messages Broker 产品商业应用范围和功能 34 实时与您无处不及的企业共享信息 34 可靠、一致地管理业务事件 35 利用定制的信息流优化响应 35 集成无界限 36 图形化的开发环境加快部署速度 37 快速启动 37 利用市场领先的业务集成解决方案满足要求 37 MESSAGE BROKER 是一个战略性的开放框架 38 应用程序格式转换和智能路由功能 38 企业服务总线技术方案建议 强大的数据处理功能 39 对各种应用系统的接口功能 39 WebSphere Messages Broker 产品特点 39 IBM WebSphere Message Broker解决方案的优势 41 产品构架优势 41 网状结构到星型结构的改变,大大简化MQ的配置和管理 41 不同格式的数据转换 42 WMB全面支持XML 42 各种"Processor Node"组成的Message Flow 42 与Database紧密集成 43 功能强大的发布预订系统 43 企业服务总线技术方案建议 第1章 概述 1.1 读者对象 预期阅读人员包括负责科技管理的各级领导、负责科技管理的业务人员、ESB项目管理人员、ESB平台实施人员、ESB平台运维人员和其他需要阅读本报告的项目经理、IT架构师等。 1.2 定义 SOA—Service Oriented Architecture 面向服务的架构 ESB—Enerprise Service Bus 企业服务总线 WMB—WebSphere Message Broker IBM 高级ESB产品 第2章 面向服务的体系架构简介 目前,大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。同时,网络的发展,使得跨机构和组织的应用系统越来越普遍。另一方面,政策和业务方面的压力要求IT系统能够方便灵活地适应不断的变化。如何集成来自多个厂商跨不同平台的产品和应用系统,以满足业务上灵活多变的要求,一直是企业IT部门的主要挑战。面向服务的体系结构(Service Oriented Architecture, SOA)为解决这一问题提供了良好的途径。 2.1 SOA的业务驱动力 虽然 IT 经理一直面临着削减成本和最大限度地利用现有技术的难题,但是与此同时,他们还必须不断地努力,以期更好地服务客户,更快地响应企业战略重点,从而赢得更大的竞争力。 - - 企业服务总线技术方案建议 在所有这些压力之下,有两个基本的主题:异构和改变。现在,大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自多个厂商跨不同平台的产品简直就像一场噩梦。但是我们也不能单单使用一家厂商的产品,因为改变应用程序套件和支持基础设施是如此之难。 在当今 IT 经理面临的问题之中,改变是第二个主题。全球化和电子商务加快了改变的步伐。全球化带来了激烈的竞争,产品周期缩短了,每个公司都想赢得超过竞争对手的优势。在竞争产品和可以从 Internet 上获得的大量产品信息的推动下,客户要求更快速地进行改变。因而,在改进产品和服务方面展开的竞争进一步加剧了。 为了满足客户提出的越来越多的新要求,技术方面的改进也在不断地加快。企业必须快速地适应这种改变,否则就难以生存,更别提在这个动荡不安竞争激烈的环境中取得成功了,而 IT 基础设施必须支持企业提高适应能力。 因此,企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部门,到上世纪八十年代和九十年代关注业务流程的水平结构,向新的生态系统业务范例发展。重点是扩展供应链,支持客户和合作伙伴访问业务服务。下图展示了企业的这种发展。 我如何使我的 IT 环境更灵活且更快地响应不断改变的业务需求呢? 我们如何使这些异构系统和应用程序尽可能无缝地进行通信呢?我们如何达到企业目标而不使企业走向破产的深渊呢? IT 响应者/支持者是随着企业的这种发展而并行发展的,如下图所示。现在,许多 IT 经理和专业人员都同样相信,我们真的快找到了一种满意的答案——面向服务的体系结构。 - - 企业服务总线技术方案建议 为了减少异构性、互操作性和不断改变的要求的问题,这样的体系结构应该提供平台来构建具有下列特征的应用程序服务: l 松散耦合 l 位置透明 l 协议独立 基于这样的面向服务的体系结构,服务使用者甚至不必关心与之通信的特定服务,因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能多的技术。特别地,来自不同实现技术(如 J2EE 或 .NET)的技术规范不应该影响 SOA 用户。如果已经存在一个服务实现,我们就还应该重新考虑用一个“更好”的服务实现来代替,新的服务实现必须具有更好的服务质量。 2.2 什么是面向服务的体系架构 面向服务的体系结构是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。 这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。而另一方面,紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的,因而当需要对部分或整个应用程序进行某种形式的更改时,它们就显得非常脆弱。 - - 企业服务总线技术方案建议 对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活,以适应不断变化的环境,比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素,这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为随需应变的(On Demand)业务,在随需应变的业务中,一旦需要,就可以快速地对完成或执行任务的方式进行必要的更改。 值得注意的是,Web Services并不是实现 SOA 的惟一方式。例如 CORBA 是另一种方式,同样,面向消息的中间件(Message-Oriented Middleware)系统(比如 IBM 的 MQ)也是一种选择。但是为了建立体系结构模型,用户所需要的并不只是服务描述。用户需要定义整个应用程序如何在服务之间执行其工作流。尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此,SOA 应该能够将业务的商业流程与它们的技术流程联系起来,并且映射这两者之间的关系。例如,给供应商付款的操作是商业流程,而更新您的零件数据库,以包括进新供应的货物却是技术流程。因而,工作流还可以在 SOA 的设计中扮演重要的角色。 此外,动态业务的工作流不仅可以包括部门之间的操作,甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此,为了提高效率,您需要定义应该如何得知服务之间的关系的策略,这种策略常常采用服务级协定和操作策略的形式。 最后,所有这些都必须处于一个信任和可靠的环境之中,以同预期的一样根据约定的条款来执行流程。因此,安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。 2.3 面向服务的体系结构所带来的好处 如前所述,企业正在处理两个问题:迅速地改变的能力和降低成本的要求。为了保持竞争力,企业必须快速地适应内部因素(如兼并和重组)或外部因素(如竞争能力和顾客要求)。需要经济而灵活的 IT 基础设施来支持企业。 我们可以认识到,采用面向服务的体系结构将给我们带来几方面的好处,有助于我们在今天这个动荡的商业环境中取得成功: - - 企业服务总线技术方案建议 利用现有的资产 SOA 提供了一个抽象层,通过这个抽象层,企业可以继续利用它在 IT 方面的投资,方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值,而不必重新从头开始构建。 更易于集成和管理复杂性 在面向服务的体系结构中,集成点是规范而不是实现。这提供了实现透明性,并将基础设施和实现发生的改变所带来的影响降到最低限度。通过提供针对基于完全不同的系统构建的现有资源和资产的服务规范,集成变得更加易于管理,因为复杂性是隔离的。当更多的企业一起协作提供价值链时,这会变得更加重要。 更快的响应和上市速度 从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的组织提供了独特的优势。通过利用现有的组件和服务,可以减少完成软件开发生命周期(包括收集需求、进行设计、开发和测试)所需的时间。这使得可以快速地开发新的业务服务,并允许组织迅速地对改变做出响应和减少上市准备时间。 减少成本和增加重用 通过以松散耦合的方式公开的业务服务,企业可以根据业务要求更轻松地使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增加。 说到做到 通过 SOA,企业可以未雨绸缪,为未来做好充分的准备。SOA 业务流程是由一系列业务服务组成的,可以更轻松地创建、修改和管理它来满足不同时期的需要。 SOA 提供了灵活性和响应能力,这对于企业的生存和发展来说是至关重要的。但是面向服务的体系结构决不是灵丹妙药,而迁移到 SOA 也并非一件可以轻而易举就完成的事情。请别指望一个晚上就将整个企业系统迁移到面向服务的体系结构,我们推荐的方法是,在业务要求出现或露出苗头时迁移企业功能的适当部分。 - - 企业服务总线技术方案建议 2.4 应用系统的的整合与ESB ESB(Enterprise Service Bus,即企业服务总线)是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢,是构筑企业神经系统的必要元素。 企业服务总线ESB就是一种可以提供可靠的、有保证的消息技术的最新方法。ESB中间件产品利用的是Web服务标准和与公认的可靠消息MOM协议接口(例如IBM的WebSphere MQ)。ESB产品的共有特性包括:连接异构的MOM、利用Web服务描述语言接口封装MOM协议,以及在MOM传输层上传送简单对象应用协议(SOAP)传输流的能力。大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。 企业服务总线(Enterprise Service Bus,ESB)的概念是从面向服务体系架构(Service -Oriented Architecture, SOA)发展而来的,与以服务为导向的应用架构体系(SOA)紧密连接在一起, 是SOA核心组成部分,是SOA架构中应用整合的骨干。SOA描述了一种IT基础设施的应用集成模型,其中的软构件集是以一种定义清晰的层次化结构相互耦合,其中,一个ESB是一个预先组装的SOA实现,它包含了实现SOA分层目标所必需的基础功能部件。在SOA架构上发布的业务服务是ESB的“用户”,这些基于SOA架构的业务系统所开放出来的服务通过ESB进行交互。它们的交互请求被以事件的方式进行发布和订阅。 2.4.1 企业应用整合与ESB 企业应用整合(EAI)的概念在IT界提出和讨论已经有几年的历史了,最初大家谈到的EAI的概念,相对后来EAI的发展来看,可以说是一个狭义上的EAI,正如其字面上的含义"Enterprise Application Integration",即企业应用整合,仅指企业内部不同应用系统之间的互连,以期通过应用整合实现数据在多个系统之间的同步和共享。 伴随着EAI技术的不断发展,它所被赋予的内涵变得越来越丰富。现在大家谈到的EAI的概念,具有更为广义的内涵,它已经被扩展到业务整合(Business Integration)的范畴,业务整合相对EAI来说是一个更宽泛的概念,它将应用整合进一步拓展到业务流程整合的级别。业务整合不仅要提供底层应用支撑系统之间的互连,同时要实现存在于企业内部应用与应用之间,本企业和其他合作伙伴之间的端到端的业务流程的管理,它包括应用整合,B2B整合,自动化业务流程管理,人工流程管理,企业门户以及对所有应用系统和流程的管理和监控等方方面面。 - - 企业服务总线技术方案建议 EAI的目标是支持对现有IT系统的重新利用,通过EAI技术能够将不同的软件和系统串联起来,延长这些应用系统的生命周期。传统的EAI,往往使用如CORBA和COM等的消息中间件进行分布式,跨平台的程序交互,修改企业资源规划以达到新的目标,使用中间件、XML等方法来进行数据分配。因此,实际上传统的EAI是部件级的重用。很不幸的是,基于部件的架构没有统一的标准,因此,各个厂商都有各自不同的EAI解决方案,你会看到各种各样的中间件平台。如果EAI碰到了异构的IT环境,就必须分别考虑怎样在各个不同的中间件之间周旋,来实现合理的互联方式,你不得不考虑各种复杂的可能性。因此,你所见过的大多数传统EAI解决方案都比较笨重。 如果我们选择传统的Hub模式来构建SOA基础架构,从纯粹逻辑的角度,可能会出现哪些问题呢?首先,整个SOA架构的性能,如果每个服务的请求都经过中央Hub的中转,那么Hub的负担会很重,速度会随着参与者的增多而愈来愈慢;其次,这样的系统会很脆弱,一旦Hub出错,整个SOA架构都会瘫痪;最后,这样的架构会破坏SOA的开放性原则,参与者运行在一个相对封闭的环境中,扩展起来十分麻烦。因此,这也不是理想的SOA架构。 ESB为基础的架构与前面的Hub结构有什么不同呢?首先,它比单一Hub的形式更开放,总线结构有无限扩展的可能;其次,真正体现了SOA的理念, 一切皆为服务,服务在总线(BUS)中处于平等的地位。即使我们需要一些Hub,那么它们也是以某种服务的形式部署在总线上,相比上面的结构要灵活的多。这就是ESB,我们需要给它一个明确的定义:ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于: - - 企业服务总线技术方案建议 ★ 面向服务的架构 -分布式的应用由可重用的服务组成 ★ 面向消息的架构 - 应用之间通过ESB发送和接受消息 ★ 事件驱动的架构 - 应用之间异步地产生和接收消息 用一句较通俗的话来描述它:ESB就是在SOA架构中实现服务间智能化集成与管理的中介。而它与SOA的关系要相对好理解一些:ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构,它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。可以这样说,ESB是特定环境下(SOA架构中)实施EAI的方式:首先,在ESB系统中,被集成的对象被明确定义为服务,而不是传统EAI中各种各样的中间件平台,这样就极大简化了在集成异构性上的考虑,因为不管有怎样的应用底层实现,只要是SOA架构中的服务,它就一定是基于标准的。 其次,ESB明确强调消息(Message)处理在集成过程中的作用,这里的消息指的是应用环境中被集成对象之间的沟通。以往传统的EAI实施中碰到的最大的问题就是被集成者都有自己的方言,即各自的消息格式。作为基础架构的EAI系统,必须能够对系统范畴内的任何一种消息进行解析。传统的EAI系统中的消息处理大多是被动的,消息的处理需要各自中间件的私有方式支持,例如API的方式。因此尽管消息处理本身很重要,但消息的直接处理不会是传统EAI系统的核心。ESB系统由于集成对象统一到服务,消息在应用服务之间传递时格式是标准的,直接面向消息的处理方式成为可能。如果ESB能够在底层支持现有的各种通讯协议,那么对消息的处理就完全不考虑底层的传输细节,而直接通过消息的标准格式定义来进行。这样,在ESB中,对消息的处理就会成为ESB的核心,因为通过消息处理来集成服务是最简单可行的方式。这也是 - - 企业服务总线技术方案建议 ESB中总线(Bus)功能的体现。其实,总线的概念并不新鲜,传统的EAI系统中,也曾经提出过信息总线的概念,通过某种中间件平台,如CORBA来连接企业信息孤岛,但是,ESB的概念不仅仅是提供消息交互的通道,更重要的是提供服务的智能化集成基础架构。 最后,事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式,一种是调用(Call), 即请求/回应方式,这是常见的同步模式。还有一种我们称之为单路消息(One-way),它的目的往往是触发异步的事件, 发送者不需要马上得到回复。考虑到有些应用服务是长时间运行的,因此,这种异步服务之间的消息交互也是ESB必须支持的。除此之外,ESB的很多功能都可以利用这种机制来实现,例如,SOA中服务的性能监控等基础架构功能,需要通过ESB来提供数据,当服务的请求通过ESB中转的时候,ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息。 2.4.2 ESB的要素 ESB连接和企业的IT基础结构,可以跨越不同的地域,支持不同的传输协议,它可以自动路由消息并且提供系统级的功能(例如,消息的格式自动转换),ESB的实现必须是基于标准的规范, 并且这些实现必须是安全的、可靠的,并且在非常高的流量压力情况下可管理。 在 遵循SOA架构的ESB 模式中,服务交互的参与方并不直接交互,而是通过一个总线交互,该总线提供虚拟化和管理功能来实现和扩展 SOA 的核心定义。 因此 ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求,而不知道消息的来源。ESB 本身对使用它的服务请求者和提供者均不可见。应用程序逻辑可以使用各种编程模型和技术调用或交付服务,而无需考虑是直接连接还是通过 ESB 传递的。连接到 ESB 是部署决策;应用程序源代码不会受到影响。 - - 企业服务总线技术方案建议 2.4.3 ESB的功能 ESB 支持许多交互类型,包括单向、请求/响应、异步、同步和发布/订阅。它还支持复杂事件处理(在复杂事件处理中,可能会观测到一系列事件),以产生一个事件作为该系列中的关系的结果。 下图对基本 ESB 模式进行了简单描述。 消息流过将各个通信参与方相互连接在一起的总线,某些参与方会调用其他参与方提供的服务;而其他参与方则会向感兴趣的使用者发布信息。端点与 ESB 交互的位置称为服务交互点 (SIP)。例如,SIP 可以是 Web 服务端点、消息队列或 RMI 远程对象的代理。服务注册表将捕获描述以下内容的元数据:SIP 的要求和功能(例如,提供或需要的接口)、它们希望与其他 SIP 的交互方式(例如,同步或异步,通过 HTTP 或 JMS)、它们的 QoS 要求(例如,首选的安全、可靠交互)以及支持与其他 SIP 交互的其他信息(例如,语义注释)。 将总线插入参与方之间,提供了将它们的交互通过称为“中介”的构造进行协调的机会。中介对请求者和提供者之间动态传递的消息进行操作。对于复杂的交互,可以按顺序将中介连在一起。中介模式部分讨论了实现这些虚拟化、QoS 和管理概念的常用中介模式。 总的来说,ESB的主要功能是: - - 企业服务总线技术方案建议 l ESB提供了服务位置和标识的基础功能:参与方不需要知道其他参与方的位置或标识。例如,请求者不需要知道请求是否可以由某个提供者提供服务。您可以随意添加或删除服务提供者,而不会带来任何干扰。这是IT系统实现灵活的服务框架的基础。 l 交互协议的功能:参与方不需要采用相同的通信协议或交互方式。表达为 SOAP/HTTP 的请求可能由包括 Java 远程方法调用 (RMI)、EJB等的提供者提供服务。 l 独立的接口处理:请求者和提供者不需要就公共接口达成协议。ESB 可以通过将请求消息转换为提供者所期望的格式来处理此类差异。 l 交互的服务质量 (QoS):参与方声明其 QoS 要求,包括性能和可靠性、请求的授权、消息内容的加密/解密、服务交互的自动审核以及如何对请求进行路由(如根据工作负载分布标准将请求路由到可用的实现)。描述请求者和提供者的 QoS 要求和功能的策略可以由服务自己实现或者由进行不匹配补偿的 ESB 实现。因此 ESB 模式使请求者不用了解服务提供者的物理实现——从应用程序开发人员和部署人员的角度来看均是如此。总线负责将请求交付给提供所需功能和 QoS 的服务提供者。提供者接收他们要响应的请求,而不知道消息的来源。 l 保证不同应用系统之间的高度内聚,同时又保持各个应用系统的相对独立性,使得各个系统之间存在着松散的藕合关系。 l 保证在一个异构的环境中实现信息稳定、可靠的传输,屏蔽掉用户实际中的硬件层、操作系统层、网络层等相对复杂、烦琐的接口,最大限度地提高用户应用的可移植性、可扩充性和可靠性。 l 可以将复杂的网状结构变为星型结构,大大简化系统配置;它为各种应用提供一个统一接口,从而大大减少系统间接口的个数;同时,它可以作为一个数据中心,提供各种数据处理服务 l 提供了消息处理、格式转换和消息路由等功能,用于实现系统扩展性和高可靠性。 - - 企业服务总线技术方案建议 2.4.4 ESB的实现模式 从 ESB 的角度来看,所有的服务交互端点都是类似的,因为它们都发送或处理请求/事件;它们都要求特定的 QoS;它们可能都需要交互协助。ESB 模式允许集成开发人员以与处理新业务逻辑、流程编排组件或外部 Web 服务同样(面向服务)的方式对待与用户交互的请求者或提供者。 用于构建基于 ESB 的解决方案的模式大致分为以下几类: · 交互模式:允许服务交互点将消息发送到总线或从总线接收消息。 · 中介模式:允许对消息交换进行操作。 · 组合模式:综合交互模式和中介模式进行更复杂处理。 · 部署模式:支持将解决方案部署到联合基础设施中。 2.5 应用系统整合的国内外现状 IDC的调查报告指出:“应用整合市场全球营业收入已经从2000年的50亿美元上升到2006年的240亿美元,这意味着综合年增长率超过了30%。与此相对应,整个IT服务产业的同期综合年增长率预计只有11%。”IDC还报道,北美和西欧等国家产生90%的应用整合服务需求,而日本和拉美将驱动剩下的需求。因此,他们认为:应用整合仍是是最近几年内IT行业中增长最快的部分。其实,IT系统的整合是一个全球性问题,另据有关机构统计,大型企业每年IT预算的40%投给了整合和集成平台,整合和集成还被全球33%的CIO评为最重要的问题,超过90%的CIO认为它是非常重要的问题。 应用整合的前提是企业已经拥有了较为完善但又相互独立的应用信息系统。经过十几年的努力,我国企业信息化已经得到了很大的发展。随着技术的进步以及Internet和电子商务应用的不断深入,企业对信息化应用的要求也在不断提高。同时,为了适应发展变化的形势,企业应用系统也面临着升级的压力。因此,企业面临着两种选择:第一,完全放弃已有的封闭系统,采用全新的开放技术或产品来开发企业的全部应用;第二,维持已有系统的正常运转,采用整合技术将不同的系统集成起来。如果是稍大型的企业应用,完全更换是不现实的。因此绝大多数人倾向于 - - 企业服务总线技术方案建议 应用整合。 中国应用整合应用行业分布 企业应用整合不仅包括企业内部应用系统的集成,还包括企业与企业间的集成。从集成层面上来讲包括点对点集成、平台集成、数据集成、流程集成以及界面的集成。在电信行业里,去年某省移动成功实施了EAI项目,网通也较早实施了EAI;在金融领域中,某大型商业银行的某省分行应用EAI框架,在金融领域率先完成了EAI项目,将之应用在国际结算业务的单证影像系统中;其他大型商业银行也逐步或者已经用EAI技术构建自身IT架构的信息总线。EAI,如今似乎已成为金融、保险、电信、烟草、保险、石油、电力、航空、汽车等领域愈来愈不可阻挡的技术趋势。 2.5.1 项目案例 2.5.1.1 某国内著名通信公司方案概述 客户需求: 为了适应业务发展需要,面对日益激烈的市场竞争,满足电信多样灵活的产品和服务快速推向市场, 增强电信企业核心竞争力,国内某通信公司计划在高层面上建立新一代电信运营支撑系统, 该运营支撑系统以企业级应用整合平台为架构, 通过平台将不同应用商提供的应用系统整合,实现业务流程自动化和信息共享,为公司的业务发展奠定扎实基础。 - - 企业服务总线技术方案建议 建设方案: 运营支撑系统体系架构以整合模型(企业体系结构集成)为中心,业务工作流应用全面集成,该应用允许各种消息通过通信总线在预定的交易信息流中传输,这使业务、市场营销、运营、安全性决策、政策和流程可以根据运营支撑系统的全方位进行制定。通过建成的体系架构、使运营支撑系统应用独立于业务工作流,从而提供一种“应用即插即用环境”用以支持更灵活地选择和集成当前及将来的应用。运营支撑系统应用可通过从市场上购得的适配器与总线相连,这些适配器用于将总线提供的信息转化为特定应用可以接受的格式。 体系架构框架的另外一个重要组成部分是电信服务供应商的应用服务环境,它在电信服务供应商的网络IT/运营支撑系统环境中可实现由该电信服务供应商及其他第三方内容和应用供应商提供的业务的业务接入和提供。应用服务环境的一个重要特性是它定义了标准的开放互连,以实现将使用供应商网络基础设施的内容和应用集成。需要特别注意的是,许多电信服务供应商正在大力构建这种基于标准的开放平台以提供新业务。 IBM参考应用体系架构说明了帮助电信服务供应商为客户提供以下功能所需的框架: ¨ 产品选择 ¨ 下订单 ¨ 准备服务或产品 ¨ 激活服务或产品 ¨ 提供服务或产品 ¨ 为服务或产品计费 ¨ 中断服务或产品提供 可实现上述流程的体系架构概念是基于服务总线、工作流程引擎、服务目录数据模型(Service Catalog Data Model)和服务代理( - - 企业服务总线技术方案建议 Service Broker)的。 产品选择: 客户选择WebSphere Business Integration (WBI)来构建EAI,具体组件包括: ¨ WebSphere MQ Workflow (MQWF) 实现端到端的业务工作流管理。 ¨ WebSphere Interchange Server (WICS) 完成流程自动化与数据同步。 ¨ WebSphere Message Broker (WMB) 实现数据转换与路由。 ¨ WebSphere MQ 完成事件服务管理。 ¨ WebSphere Business Integration Adapter完成应用连接。 2.5.2 某较大型商业银行ESB项目简介 企业服务总线(Enterprise Service Bus,简称ESB)是该行基于大集中SOA架构的核心,它将传统的系统间复杂的网状结构变为星型结构,大大简化应用系统间的集成和管理。作为一个企业系统的信息总线,可以对消息进行分析判断、处理计算、格式转换以及智能路由等各种消息服务,根据消息的内容进行灵活而高性能的决策,从而将消息发送到相关的目的地。ESB的关键在于把系统间的关系由紧密耦合变为灵活可变的松耦合。 本项目中涉及到的系统和各系统间的关系如图所示。分行层次上,低柜系统通过Client/Server(MQI通道)方式接入ESB系统中,其它分行前置系统接入各总行集中系统中。总行层次上,各开放平台上的总行集中系统(包括:OCRM、对公网银、对私网银、基金、外汇宝、个人信贷、CMIS、综合积分系统、IBP)通过Server/Server(MQ通道)方式接入ESB。对于总行集中主机平台应用:针对核心系统,需开发APPC适配器;对于综合理财系统,考虑通过MQ/SNA通道接入到ESB中;对于贷记卡,可以考虑开发TCP/IP的适配器实现或通过MQ实现。 - - 企业服务总线技术方案建议 根据ESB在系统中的定位,ESB内部功能模块分为三部分: 1. 数据流的处理,负责所有数据流的格式转换、转发 2. 接入系统的配置与Adapter,负责与其他系统的连接 3. 管理模块,负责异常处理,并提供操作画面供查询错误信息、统计信息;提供监控功能,能展现接入各系统的连接情况是否正常。 从安全性方面考虑,通过ESB连接的系统分为该行系统内与该行与第三方系统两类,系统内的连接安全性由网络、系统配置及应用实现;对与系统外的连接系统交互数据时,数据安全性由双方约定,WMB支持与之相连的MQ进行数据加密,确保数据中途不被截取。 - - 企业服务总线技术方案建议 第3章 关键技术分析 3.1 与现有系统的集成 3.1.1 与基于J2EE系统的集成 J2EE平台由一整套服务(Services)、应用程序接口(APIs)和协议构成,它对开发基于Web的多层应用提供了功能支持,他们共同组成了J2EE的完整架构。 J2EE使用多层的分布式应用模型,应用逻辑按功能划分为组件,各个应用组件根据他们所在的层分布在不同的机器上。以下是 J2EE 典型的四层结构: n 运行在客户端机器上的客户层组件 n 运行在J2EE服务器上的Web层组件 n 运行在J2EE服务器上的业务逻辑层组件 n 运行在EIS服务器上的企业信息系统(Enterprise information system)层软件 - - 企业服务总线技术方案建议 与J2EE的系统集成,关键是看应用系统是否按照上面所描述的模型方式来建设,如果系统的逻辑层次分明,则集成会相对容易,反之会麻烦。我们在集成J2EE应用的时候,比较关注的是该系统能抽取哪些服务重用,是通过什么样的方式将服务发布出来。一般说来,在J2EE系统中,Java Bean、POJO、EJB、JMS、Servlet、JCA等是服务的常见封装方式。我们建议在和ESB进行集成的时候,采用JMS、POJO是比较方便、简单的方式。 3.1.2 与基于MQ系统的集成 WebSphere MQ是非常通用、成熟的商业消息中间件,应用系统对外交互的接口为消息队列,同时提供消息/数据传输的可靠性保障。MQ消息中间件一般同时提供同步、异步两种通讯方式。使用消息队列,消息系统可以管理很多通讯细节。此种接口方式为典型松耦合模式,是应用集成普遍使用的方式之一,可以实现接口的重用能力。目前, IT系统中使用消息中间件比较多,技术也比较成熟,因此,采用面向消息队列的集成是非常可行的方案。 下面是采用MQ连接企业服务总线的示意图: - - 企业服务总线技术方案建议 3.1.3 与基于CICS系统的集成 CICS在其客户机端支持JAVA、C和COBOL等语言,也采用统一的应用编程接口(API),客户可以采用两种方式来编制CICS的客户端程序,一种是External Call Interface(ECI),另一种是External Presentation Interface(EPI)。另外CICS也提供了符合J2EE JCA规范的适配器 下面是CICS服务和企业服务总线集成的示意图: - - 企业服务总线技术方案建议 3.1.4 与基于邮件系统的集成 基于邮件(如Domino)的应用提供了多种方式的集成,可以通过Java调用、本地调用、Web Service、消息等方式和ESB进行交互。考虑到我们建议的ESB的技术特点,首先我们建议采用和CICS类似的方式,通过消息的方式和ESB进行集成,可以参考上面的图例。 另外,邮件系统一般提供了比较好的Web Service支持,可以直接接受SOAP的请求,因此通过Web Service调用也是可行的。 3.1.5 与基于C/S架够系统的集成 基于C/S的应用是上世纪九十年代比较普遍的方式,对集成的考虑比较少。由于一般C/S的应用将页面和应用逻辑混在了一起,因此不容易抽象出后台服务给其他系统使用。对C/S的应用改造会有比较多的工作量。C/S方式的应用多数是采用VB、PB、Delphi等工具实现,集成的困难是在页面和逻辑的分离上。考虑到我们建议的ESB特点,建议通过MQ消息中间件的方式进行集成,可以参考CICS的图例。但是和CICS集成的重要区别是C/S系统要通过使用本地语言编程来实现连接MQ的适配器。 - - 企业服务总线技术方案建议 3.2 平台扩展性与高可用性的实现 ESB平台我们建议使用IBM的WebSphere Message Broker实现,它是一个高性能的产品,在国内外许多大型的系统中有成功应用的案例。Message Broker和MQ都提供了Cluster群集解决方案,通过横向扩展提高系统的吞吐能力,下面是示意图: ESB是一个服务于广大后台系统的关键系统,除了要求系统具备足够的吞吐能力外,也要求系统具有相当高的可用性,来支持业务的连续运行。 高可用性的关键在于避免系统的单点故障 (Single Point Of Failure), WebSphere Message Broker完全提供了集群功能,实现了整个系统能够有效支持近似7*24小时不间断运行。当系统需要升级或安装补丁时,可对集群中的成员进行逐一更新,支持系统在升级期间不间断运行。 多个企业服务总线可以共同组成一个 Cluster 环境,实现系统的高可用性。另外,连接外部系统的Adapter 需要服务于固定的系统连接,需要利用系统的 HACMP 实现高可用性。 对于采用软件 Cluster 方式的部分,当其中的一个部分需要升级或安装补丁时,可以让其中的一个成员暂时停止服务,对其进行相应的操作后重新加入 - - 企业服务总线技术方案建议 Cluster 中。按照此方法可以对每个成员逐一进行处理。 需要说明的是,以上两方面都需要对系统、中间件和应用进行仔细的规划。并且在进行充分的测试后,再在生产系统中使用。 3.3 平台安全性的考量 ESB平台是应用集成的核心和基础,对安全性有很高的要求。一般来说,对安全的考虑主要涉及到认证、授权两个方面,认证主要是判断使用者是不是“合法”的ESB用户,授权是判断使用者有没有权限访问ESB特定中的资源。对于我们推荐使用的ESB产品WebSphere Message Broker,对与安全有比较详细的考虑。 WebSphere Message Broker中的安全管理工作包括了配置、运行工具、性能问题确定、资料收集等,参与到上述任务的人员都需要WebSphere Message Broker一定的授权。如果希望可以正确地使用系统授权,管理员必须进行一些操作。同时,由于WebSphere Message Broker涉及比较多的MQ资源,对MQ安全控制也是考虑的重要因素。 对于WebSphere Message Broker,授权主要关注谁有权限存取系统中的资源,确保想访问系统资源的用户是被许可的,例如: · 可以配置WebSphere Message Broker,如使用mqsicreatebroker命令 · 存取系统队列,如放置一个消息到消息流的启动队列中 · 在开发工作台中进行操作,如部署消息流到运行环境中 · 发布、订阅主题 对于系统运行时候的服务,也是需要进行授权才可以访问的。WebSphere Message Broker中的运行对象存在于Broker Domain中,每一个运行对象都有一个存取控制列表(Access Control List,ACL),ACL决定了哪个用户或者组有权限存取运行对象。ACL中的条目明确谁可以查看、修改运行对象。需要说明的是ACL虽然许可或者拒绝用户访问运行对象,但ACL并不对运行对象进行保护。 - - 企业服务总线技术方案建议 使用ACL条目,管理员可以控制用户访问WebSphere Message Broker中限定的对象,例如,用户JUNGLE\MPERRY许可访问修改BROKER A,但对BROKER B可能就没有权限。进一步,即使都在BROKER A中,特定用户也可能有权限部署服务到执行组1中,但对执行组2没有权限。 附录A:产品技术文档和白皮书 A.1 WebSphere MQ 产品简介 WebSphere MQ为系统设计人员提供了一种简单而直接的方法,使得应用程序可以在不同的操作平台之间相互可靠地交换信息,实现企业内和企业间的商务整合。 单一的API,跨越三十余种不同的平台 应用集成中介软件 确保消息传递 更快的应用开发 支持同步和异步的事务处理 支持并行处理的应用 完整的商务整合解决方案 - - 企业服务总线技术方案建议 什么是WebSphere MQ? WebSphere MQ是什么? WebSphere MQ是IBM的商用消息处理中间件(Commercial Messaging Middleware)。WebSphere MQ提供一个具有工业标准,安全,可靠的信息传输系统。它的功能是控制和管理集成的商业应用,使得组成这个商业应用的多个分支程序(模块)之间通过传递消息完成整个工作流程。WebSphere MQ基本由一个消息传输系统和一个应用程序接口组成,其资源是消息和队列(Messaging and Queuing)。 消息:一个信息包含两个因素:消息描述(用于定义诸如消息传输目标等)和数据信息(如应用程序数据或数据库查询等)。程序之间的通讯通过传递消息而非直接调用程序。 队列:一个安全的信息存储区。因为消息存放在队列中,所以应用程序可以相互独立的运行,以不同的速度,在不同的时间,在不同的地点。 消息传输系统:用于确保队列之间的信息提供,包括网络中不同系统上的的远程队列之间的信息提供。并保证网络故障或关闭后的恢复。 应用程序接口:应用程序和消息系统之间通过WebSphere MQ API实现交互操作的接口。WebSphere MQ API在所有WebSphere MQ平台上是一致的。API只有十几个调用,2个关键动词:发送(PUT)和接收(GET)。 WebSphere MQ的工作原理: - - 企业服务总线技术方案建议 如图所示:虽然应用程序A和应用程序B运行于同一系统A,它们不需要直接的通讯。应用程序A向队列1发送一条信息,而当应用程序B需要时就可以得到该信息。 如果信息传输的目标改为在系统B上的应用程序C,这种变化不会对应用程序A产生影响,应用程序A向队列2发送一条信息,系统A的WebSphere MQ发现Q2实际上在系统B,它将信息放到本地的一个特殊队列-传输队列(Transmission Queue)。系统A的WebSphere MQ然后建立一条到系统B通讯联接,传递这条信息到系统B,并等待确认。只有WebSphere MQ接到系统B成功地收到信息的确认后,才从传输队列中移走信息。如果通讯线路不通,或系统B不在运行,信息会留在传输队列中,直到被成功地传送到目的地。这是WebSphere MQ最基本而最重要的技术-确保信息传输。 事实上,WebSphere MQ具有特殊的技术防止信息重复传送,确保信息一次且仅一次(once-and-only-once)传递。 WebSphere MQ重要特点: WebSphere MQ提供给用户许多难得的价值: - - 企业服务总线技术方案建议 统一接口,跨越IBM和非IBM平台:简单的"PUT"和"GET"动词在WebSphere MQ支持35种IBM和非IBM平台上完全相同。使得WebSphere MQ提供了这样的特性:目标应用程序位置的透明性(target application location transparency)。对于一个应用程序的开发者,他需要知道的全部只是队列的名字,这个队列与一个特定的服务有关,而与系统的平台或系统在什么地方无关。 使开发人员避开网络的复杂性:因为WebSphere MQ负责处理所有的通讯,开发人员不必编写任何通讯方面的程序。并且编程和调试非常简单和直接,不需要具体的系统和通讯方面的知识。尤其在开发客户机/服务器模式的应用时,开发人员可以集中精力在与业务有关的客户端和服务器端的应用,而不必考虑操作系统和通讯,特别是底层的网络通讯,节省大约50%到75%的通讯编程工作。 处理不依赖时间的限制:意思是说在信息创建和发送时,信息的接收方或到接收方的通道不需要激活.不受时间的限制增加了处理的灵活性,允许事务处理在它们想做或有时间时做。彼此通讯的程序可以运行在不同的时间。这样程序的运行是独立的,如果逻辑允许,它们不必等待其它程序的应答而继续工作,利用这种异步处理功能,可以更有效的使用资源,更灵活的处理模式,应用处理可以是独立的,并行的,重叠的,从而改进用户服务。 给分布式处理提供的强健的中间件:包括逻辑工作单元支持(logical unit of work),备份和恢复机制,大信息传递和高性能等特点。其中最重要的是确保信息传输,意思是一旦WebSphere MQ接受一个信息传输的任务,会确保信息被传送到目标平台。信息的传输是一次且仅一次。另外,强健的中间件机制保证业务数据一致性,并可在系统发生故障时,及时恢复,业务不会受到影响。 完整的商务整合解决方案:WebSphere MQ是目前唯一提供完整的从消息传递到商务整合的中间件: l WebSphere MQ的消息队列机制提供了可靠的消息传递功能 l WebSphere MQ Integrator提供了格式转换、智能路由等消息代理服务 - - 企业服务总线技术方案建议 l WebSphere MQ Workflow提供了基于消息的工作流机制,实现了跨应用的工作流 总之,WebSphere MQ的技术可实施在广泛的IBM和非IBM平台上,WebSphere MQ提供了一个面向业务的信息技术架构:基于WebSphere MQ的应用程序可以更接近的模拟商业问题,更容易设计,开发和维护。这种技术使得基于WebSphere MQ的应用无结构限制,应用程序之间可以是一对一的关系,也可以是一对多的关系,多对多的关系。应用程序之间的信息传递可以是单向,也可以是双向的。灵活的结构支持平衡工作负荷,并行处理,多路广播以及其它应用程序之间的关系。总之是应用程序可以充分接近业务需求,并且当应用需求改变时,WebSphere MQ的结构可以很容易的跟着改变。 其它特点... 多平台支持:WebSphere MQ目前支持35种系统平台,包括各种IBM和非IBM平台。同时WebSphere MQ支持多种网络协议,如TCP/IP,SNA,SPX/IPX,DECNET……通过WebSphere MQ优越的跨平台性可以将各种不同的软硬件系统整合在一起。 遵循开放的标准:MQI是一个在美国和全球都被广泛承认的接口标准,IBM正与标准化组织一起,制定一个正规的标准。WebSphere MQ和MQI也是IBM网络蓝图中的成员。目前开放应用组织(OAG)已指定将WebSphere MQ应用消息编程接口作为应用集成的标准中间件接口。 应用触发机制:WebSphere MQ应用程序不必总是在运行中的。当第一个或第几个信息到达一个指定的队列时,一个应用可以有选择的被触发起来,这样可以做到应用程序的运行是随机的,基于任务的,并不是可预知的。同时,由于许多不常用的应用不必同时都在运行着,大大地节省了系统资源, SyncPoint机制(在多种平台上):在有syncpoint管理环境中,例如CICS,IMS,DB2,WebSphere MQ允许网络上的一个单独节点上的程序所作的修改延缓提交,直到网络上的所有的部件可以提交时。 - - 企业服务总线技术方案建议 信息浏览:当应用程序想查看某个特定的信息或某种信息类型,它可以只是查看而非取走信息。WebSphere MQ也允许一个应用程序处理一个特定信息之前查看这个信息或相关的标识信息,这样,在某种需要时,信息可以不按顺序而是被指定处理, 支持临时和动态的队列:动态或临时的队列是在应用被处理时才建立的。队列也可以被重新定义和重新配置,应用程序本身不必做任何修改。 客户端支持:WebSphere MQ不但可以安装在主机和服务器上,而且也可安装在客户机系统或工作站上,例如DOS,Windows3.1系统上。 信息优先选项:在处理信息时,除了先入,先出的顺序处理以外,还可通过给信息指定优先级的选项,使得信息在队列中以优先级排队处理。 信息数据转唤支持:在所支持的多种系统中,数据可以不同的代码格式存储,WebSphere MQ支持EBCDIC与ASCII数据之间的相互转换,对于特定的格式,可提供出口作转换。 出口(Exits)允许用户扩展功能:WebSphere MQ也在具有策略性的地方提供其它的出口,使得客户或商业开发伙伴可以提供扩展模块或附件功能。 动态负载均衡:用户可以构建跨越多个系统的多个队列管理器的集群,集群内部共享队列和通道,由此简化了系统定义的工作量,并可以实现集群内的工作负载的动态分配,大大提高了系统的性能、可靠性和灵活性。 发布/订阅(PUB/SUB):WebSphere MQ的发布/订阅功能使得应用程序可以根据不同的主题来发送、接收消息,而不必考虑消息的具体的来源或目的地是什么。这一功能极大地提高了消息传递的灵活性和系统的可扩展性。 同其他管理器的连接:WebSphere MQ可以同大多数支持XA标准的数据库(如DB2、ORACLE、SYBASE等)协同工作,也可以在CICS,Encina等事务处理器的管理下实现全局工作单元。此外,WebSphere MQ还提供了与Lotus Notes、Tivoli、EDI和SAP R/3等的接口,使得WebSphere MQ能够与上述系统协调工作。 - - 企业服务总线技术方案建议 为什么要用WebSphere MQ产品? 鉴于国内网络不稳定的现状,以及分布式业务的分散性和随机性,尤其考虑到各种应用的实时的或随机的数据通信,我们向您推荐IBM的风行世界的新产品──WebSphere MQ产品。它是目前唯一能保证您的数据稳定可靠而且决无丢失或重发的产品,被PC MAGAZINE誉为:MQ是世界上最成功的软件之一。 WebSphere MQ特别适合于这样的业务模式:在差异很大的环境之间实现沟通。而MQSereis是一种优秀的工具,具有多平台支持功能,可以运行于新技术和传统技术组合的非均一环境中。 在竞争激烈的商业行业中,特别是银行业,金融证卷业,全球市场的发展增大了业务处理的压力,从而导致了对发展IT的需求。这使得WebSphere MQ成为业务要求苛刻的应用程序的坚强后盾,在这些应用程序中,数据就意味这金钱。 WebSphere MQ具有简单、灵活的特点,并能满足业务对系统速度、集成性、安全性方面的要求。因此,对关键性的业务行业,如银行,计费系统等都很有吸引力。目前,WebSphere MQ已经成为金融领域独一无二的选择。 其实,WebSphere MQ不仅在金融领域倍受青睐,在其它行业,例如邮电,交通,医疗等,越来越多的处于领先地位的人们认识到,随着来自内部,外部,甚至全球市场不断增长的压力,保持自身的竞争力是事在必行的。因此,许多企业业务的发展面临着四个主要动力:提高竞争力,集成业务处理,改进用户服务,以及高效地管理成本。从信息技术角度说,这四个动力可看作以下四个趋势: 1. 加快投入市场──更快地开发和配置应用程序。 2. 集成应用程序──将传统的和新的应用程序结合。 3. 增强信息访问能力──实现通用的信息确认和回馈功能。 4. 减低成本──减低开发和维护费用。 - - 企业服务总线技术方案建议 不论您的业务应用程序遇到什么样的难题,利用WebSphere MQ,都会迎刃而解。因为WebSphere MQ价值是: l 消除了硬件于网络协议的依赖关系。 l 确保了信息传输,并且支持异步通讯,无需等待接收者的响应。 l 易于使用的API,减少了开发时间和开发成本。 l 可集成不同结构和设计的应用程序。 l 易于在分布式处理结构中继续使用传统的系统。 A.2 WebSphere Message Broker 产品简介 WebSphere Message Broker是WebSphere家族的另外一个重要组成部分,基于WebSphere MQ开发。MESSAGE BROKER采用WebSphere MQ提供的可靠消息服务(不丢失,不复传)在应用系统之间通过基于消息的异步方式集成各应用系统。针对不同系统所处理的消息格式各不相同的特点,MESSAGE BROKER 提供了专门的格式代码转换器(Formatter)在不同的消息格式之间按照预先定义好的转换规则进行自动的格式转换,然后将结果自动路由到目标应用系统。在消息转换的过程中MESSAGE BROKER能够识别XML,C结构,JMS,SOAP等多种消息格式;对消息的各种操作包括消息的来源、消息的目标应用、所期望的消息格式等通过定义各种操作规则(Rules)进行。 每个业务事件的核心是应当被捕捉并向您企业内的人员和应用发布的重要信息。例如,当客户访问您的网站时,您的客户关系管理(CRM)系统将接收到这个人的浏览和购买习惯的信息。根据客户的动作,可能会触发您的制造系统,并通知仓库供货时间计划。会计部门可能需要信用卡编号或购买订单授权,送货部门可能需要一个地址。其它的分析趋势或提供最新的执行概要的内部系统还将需要同时进行更新。 WebSphere Message Broker实时地将来自多种设备和地点的信息传送给您企业内外的人员和应用。快速、高效地分发来自例行业务活动的信息的能力对于您成功运营电子商务来说至关重要。为便于提供快速、富有根据的决定以便提示合适的动作,您必须为正确的人和正确的应用在正确的时间提供正确的信息。当一个信息源被更新时,这些变化必须立即发布给所有受到影响的系统,以便您企业内的数据可以自动更新。 - - 企业服务总线技术方案建议 IBM WebSphere Message Broker多平台6.0版为实施集成消息和事件提供了一个灵活的基础架构。无论这些业务事件在何时、何地发生,您多可以捕捉到目标信息,并将它立即发送到需要它的应用和人员。您可以集成Web交易、与贸易伙伴交换的数据、来自第三方打包应用的数据或时间极为重要的事件的现场数据,例如金融市场上发生的数据。 通过扩大您的集成范围,使您可以集成您企业内的人员、应用和事件,您可以成为随需应变的企业 – 可以智能适应当前的市场环境,快速应对持续变化的商业需要。 WebSphere Messages Broker 亮点和概括 l 实时地向您无处不及的人员、应用、移动和无线和遥测设备提供业务事件信息 l 支持多种传输协议,将您的业务范围扩展到防火墙之外 l 利用一致的图形化开发环境,大幅提升整个WebSphere平台的效率和技能。 l 简单的一次点击即可完成安装,加速部署 l 将集成逻辑与应用相分离,提高业务的灵活性,帮助降低开发成本 l 简化原本不能兼容的应用之间的通讯,并在这一产品中提供了New Era of Networks功能(是IBM WebSphere MQ Integrator的早期产品) - - 企业服务总线技术方案建议 WebSphere Messages Broker 产品商业应用范围和功能 实时与您无处不及的企业共享信息 对于很多业务事件来说,您都需要一个代理来负责在具有相同的消息结构的应用之间的消息协调工作。但是有时您还可能需要与一个使用消息结构或格式与您的接收应用不同的贸易伙伴交换信息。例如,您可能需要在您的CRM和供应链管理数据库之间交换应用,以便确定对于促销事件需要保存多少、哪些类型的商品。 WebSphere Message Broker构建在WebSphere Event Broker 6.0版的基础之上,在基础的代理功能上,增加并丰富了传递中的消息转换功能,还增加了数据库集成功能。这样您就可以与贸易伙伴和客户实时地交换信息 – 通过事件触发的更新同步多个数据库,并为当前的业务状况提供了一份清晰的图象。 带有规则和格式定制器扩展的WebSphere Message Broker增加了一个高性能的规则功能,使用预定义的标准来处理具有复杂结构和多个变量的消息。因此,如果一条消息中包含多个字段 – 例如货币、金额、客户和位置 – 您可以使用New Era of Networks Rules,根据所有这些字段来确定消息的处理。 可靠、一致地管理业务事件 带有规则和格式定制器扩展的WebSphere Message Broker增加和更新接收应用所必须的消息字段,丰富了传输中的信息,使您的业务应用无需更改。例如,您可以将运行在使用结构化数据格式(例如XML)的平台之上的一个应用与使用面向记录格式的应用集成在一起。使用代理可以帮助您: - - 企业服务总线技术方案建议 l 管理放置在分散的分部或分部的独立系统之间的信息流 – 或与您的防火墙之外的贸易伙伴交换的信息。 l 构建一个万能的企业集成总线 – 或一个体系结构框架 – 使您可以针对各种情况、应用和设备,可靠地在安全环境中执行业务。 l 不再需要手工重新键入数据,减少了费用和错误率。 l 快速一致地向正确的应用和人员发送最新的业务信息 利用定制的信息流优化响应 带有规则和格式定制器扩展的WebSphere Message Broker是建立在开放行业标准和行业领先的IBM WebSphere MQ之上的一个灵活的消息基础设施,不管消息位于哪里,以 何种方式存储,它都帮助您有效地利用业务事件信息。它可以在众多的平台上提供可靠的一次并且唯一一次发送信息的功能,使您可以根据在各种类型的业务活动中收集到的信息,优化您无所不及的企业的响应速度。并可以根据策略或业务规则来构建信息流,在人员和应用之间发布信息。 您可以根据需要直接监视来自现场的遥测生产数据,在远程调整管线的流动。您可以精确地发现何时需要转移生产资源以便快速提高送货量。您还可以根据特定的需求向员工或应用发送特定的市场数据信息。通过将消息的路由逻辑与应用相分离,带有规则和格式定制器扩展的WebSphere Message Broker使您可以灵活地更改消息路由的途径,无需更改所涉及到的应用。不管从传统方式上看,信息是在您企业内部生成的,还是在外部生成的,您都可以与您的核心应用集成,让您保持竞争优势。 集成无界限 带有规则和格式定制器扩展的WebSphere Message Broker提供了一种灵活的传输协议 - 包括WebSphere MQ 产品系列中的传输协议 – 将您的企业范围延伸到您的防火墙之外。利用遥测传输,您可以配置任何传感器或控制设备与您的企业集成总线代理通讯。实际环境中发生的事件的相关信息都将被自动捕捉到,并用来推动关键的业务活动。您可以依次控制和管理您企业中实际的活动。 - - 企业服务总线技术方案建议 通过集成多种消息类型,包括简单对象访问协议(SOAP)、电子数据交换(EDI)、C、COBOL和XML,您可以在贸易合作伙伴、客户和员工之间共享数据。您的顾问和服务伙伴还可以定制消息和消息流,使用Java™技术或C代码创建代理插件,采用特定的消息路由、分析或转换算法。 您可以根据您特定的需要,根据主题或内容控制消息的发布,选择多播或单播协议来发送群组消息。要同时向多个员工或应用提供相同的消息,可以使用多播协议来发送消息。但是当您要尽量高效地向个员工或应用发送不同的信息,则需要选择单播协议。 通过在您的网络中放置多个代理,进行集中控制,您可以避免单点故障,方便地管理分散系统之间的信息流。通过集中控制,您可以协调业务事件的处理,采用一致的处理方式,使您的系统更为高效地工作。 图形化的开发环境加快部署速度 使用带有规则和格式定制器扩展的WebSphere Message Broker中提供的图形化开发环境,可以直观地构建消息流模型和代理拓扑。建模和可视化技术可以帮助开发人员发现设计缺陷,从而可以更快地生成更高质量的结果,加速体现价值。这个工具平台建立在IBM WebSphere Studio Workbench的基础之上,它使用开放源码的Eclipse框架,其观感与其它的IBM和第三方工具插件保持一致。 这个工具简化了调试和部署工作,并支持代码库,方便了团队合作。利用WebSphere业务集成产品系列这个完整的工具模型,可以保护您的投资,使用现有资源在众多领先的平台上部署解决方案。 快速启动 利用带有规则和格式定制器扩展的WebSphere Message Broker,您可以快速安装和部署您的解决方案,其易于使用的特性帮助您快速获得价值。这些特性包括: l 一次点击即可完成安装 l 在您使用的过程中随时获得帮助,提供上下文敏感的帮助 - - 企业服务总线技术方案建议 l 预定义的配置和样本配置(仅适用于Microsoft® Windows® 平台) 利用市场领先的业务集成解决方案满足要求 集成:高效灵活地组合资源使您可以优化您企业内外的业务运作。将分散的资源、数据、应用和流程捆绑在一起,您可以创建一个协作的环境来统一您整个的需求链,加速获得投资回报,快速获得价值。 利用IBM的WebSphere业务集成解决方案,您可以连接: l 员工。通过集成业务流程,您的客户、员工、合作伙伴和供应商可以更为有效地与您的企业交互。 l 流程。通过水平地管理和协调您整个的业务,您的IT基础架构可以与需求 —— 与您的商业目标 —— 保持同步。 l 信息。通过实时地访问分散的信息,员工和流程可以充分利用来自多个资源库的数据和内容资源。 在您向随需应变电子商务转型的过程中,您需要提高效率,简化流程,充分利用现有资源,提供及时、动态、个性化的信息,帮助构建长期的关系。WebSphere业务软件系列帮助您的企业更为关注核心业务。灵活。弹性。更好地应对机会 – 和崩溃 – 都将会影响您未来的发展。 MESSAGE BROKER 是一个战略性的开放框架 它以早期版本为基础并对其功能进行扩展,拥有强大的功能以及为整个商业集成领域实现增值的能力,使客户能够更容易地在一个简单、开放而又可扩展的框架内将不同的应用程序连接在一起。这样,供应商就有机会增强自己的产品,进一步增加为客户提供的产品的价值。 在提供这一开放的框架时,IBM使客户能够在一个相对较短的时间内完成基础结构的创建。这样,客户就可以充分利用新的机会来拓展市场,同时增加对现有的应用进行连接时的效率。随着将来出现更多的可用节点,使用本产品创建的消息流能够以更快更容易的方式实现更完善的解决方案。与MQ家族其他新增强的功能一道,MESSAGE BROKER的这一版本能够满足21世纪企业应用集成的需要。 - - 企业服务总线技术方案建议 应用程序格式转换和智能路由功能 作为各个应用的数据吞吐机,提供多种数据格式服务,其中包括:用户自定义格式,用户可以为每一种应用定制自己的消息格式,通过这种消息格式来连接原有的旧的应用; XML格式;面向纪录的信息格式,如C的头文件,COBOL records等。对于这些消息格式,提供相应的剖析器进行解析,实现它们之间的格式转换。如对于用户的bit stream的输入信息可以输出为XML的格式,反之亦然。从而无缝地连接现有的应用,并可以采用XML的新标准开发新的应用。提供检查和过滤功能,根据所传输数据的内容做动态路由。 强大的数据处理功能 作为各个应用的数据处理机,对经过BPI的数据进行各种处理操作,如计算、过滤等,使得数据在从BPI经过时便可以被进行相应地计算,从而发往目的应用系统;支持数据仓库,对各应用系统所传输的数据进行集中记录,便于以后的审计和分析。 对各种应用系统的接口功能 提供强大的连接性,既提供各种与现有商业应用连接的Adapter,可以将企业内部各种应用系统进行无缝连接,如SAP, Notes, Sibel, SWIFT, People Soft, I2 等,支持各种标准数据格式或应用的接口,如XML, JDBC,对于这些应用可以不必开发新的接口,减少开发的工作量;同时提供应用程序接口,以开发客户化的连接件。 - - 企业服务总线技术方案建议 WebSphere Messages Broker 产品特点 IBM WebSphere Message Broker建立在WMQ之上,增加了一个强大的消息流程引擎,它是一个为提供关键任务商业集成工具和过程而设计的框架。由于它能够在不要求改变现有程序和数据的情况下为其增加新的功能,所以可以帮助您创建您自己的解决方案并可增强现有的解决方案。并提供以下功能特性: u 实时地向您无处不及的人员、应用、移动和无线和遥测设备提供业务事件信息 u 支持多种传输协议,将您的业务范围扩展到防火墙之外 u 利用一致的图形化开发环境,大幅提升整个WebSphere平台的效率和技能。 u 简单的一次点击即可完成安装,加速部署 u 将集成逻辑与应用相分离,提高业务的灵活性,帮助降低开发成本 u 简化原本不能兼容的应用之间的通讯,并在这一产品中提供了New Era of Networks功能(是IBM WebSphere MQ Integrator的早期产品) u 提供集中控制,提供可配置的任意数据之间的转换和信息发布,消除繁琐的编程和软件维护 u 底层基于MQ的星形架构,确保消息传输的最简化连接方式 u 消息流程建模:流程控制,流程特殊情况处理(反馈,失败) u 使用集线器和轮辐(spoke)模型可以使应用集成获得更高的连接效率 u 对数据进行转换,同时可以确定应用之间的路由选择 u 将商业逻辑和应用逻辑和数据逻辑分离开 u 提供附加的商业应用功能,如发布/预订 u 可以添加现有供应商和新供应商产品的集成框架,以实现进一步的增值 u 与消息和关系数据库实现无缝的集成 - - 企业服务总线技术方案建议 u 实现XML消息格式和其他数据格式之间的映射 u 在现有MQ Integrator1.0版应用的基础上进行创建,免去了重复的工作 u MQ Integrator能够提供这些公司改造所需要的完善的功能,可以用作商业集成和转换引擎(Business Integration and Transformation Engine),它正在成为一种能够增加多种功能的商业价值的应用程序。 u 格式转换(XML, C, MRM, JMS, TDS分隔符, AL3, DB,SWIFT, ISO8583 等多种格式) u EAI开发支持:支持JMS,有权限管理和Collective支持增强的pub/sub(发布/订阅)机制,内置的XML开发支持,数据库开发支持,分布事务处理,转换和路由的内嵌支持。 u 可靠传输质量保证。 u JAVA 和Web Service 支持。 IBM WebSphere Message Broker解决方案的优势 从信息交换平台的长远发展来看,要形成相互一致的业务基础信息系统和有效运行的信息层次化体系,必然需要将现在建设的和未来要扩建的各个业务应用系统平滑地整合在一起,使得各个业务系统间能够顺畅地传递信息,形成一个有机的整体,在整个系统范围内实现信息的高度共享。 产品构架优势 u 开放性:基于事实上的工业标准的消息中间件,能确保和其他系统的开放连接。 u 扩展性:系统应该具有强大扩展伸缩能力,增加和改进应用不会对原有系统造成破坏。 u 移植性:也就是尽量减少非业务的纯粹特定产品的配置。 - - 企业服务总线技术方案建议 u 子系统的独立性:建立应用信息交换平台的在于连接各个子系统,而各个子系统应该尽量减少功能耦合性。应用信息交换平台和子系统的开发只针对报文,无须了解对方处理的实际过程。 u 便于实现高可用性 (HA)和负载均衡管理(WLM)。 u 可靠传输质量保证。 u JAVA 和Web Service 支持。 网状结构到星型结构的改变,大大简化MQ的配置和管理 WebSphere MQ 消息中间件作为搭建统一的数据传输平台的核心工具,作为WebSphere MQ 家族产品中的一员,WEBSPHERE MESSAGE BROKER和WebSphere MQ的无缝整合不用质疑的。信息平台多套业务应用系统以及进驻各部门的应用系统只需通过本地的WebSphere MQ与统一的数据整合系统的WEBSPHERE MESSAGE BROKER相联来完成数据的发送和接收,而数据的格式转换和智能路由的选择由WEBSPHERE MESSAGE BROKER负责,这样将来不论是增加新系统和删除旧系统都不影响到其它应用系统的配置,使整个综合信息平台的规划和管理得到很好的优化。 不同格式的数据转换 WEBSPHERE MESSAGE BROKER通过消息字典来对来自不同应用系统传来的消息内容进行识别和解析,还可以根据不同的消息通过定制不同的消息流来输送到不同的应用系统。这是非常适合信息平台如何建立一个数据集中、交换,并支持系统平滑地扩展这样的基础数据交换支撑平台的需求,以后对现有系统的扩展将不会影响整个系统的架构。例如:根据输入数据的内容映射到输出数据: { 当输入数据.Complaint.Type = ‘Order’时,输出数据.Admin.Dept=’B01’ 当输入数据.Complaint.Type = ‘Order’时,输出数据.Admin.Dept=’C01’ 输出数据格式=XML } - - 企业服务总线技术方案建议 WMB全面支持XML XML被用于WEBSPHERE MESSAGE BROKER 6.0的核心。产品的所有配置数据都采用了XML格式。一旦一个消息以消息格式的形式被定义到MRM,那么在需要时就可以将消息的输出格式也定义为XML。因此,在消息代理程序内部可以根据非XML的消息格式生成XML消息。 各种"Processor Node"组成的Message Flow 处理节点对消息流内的消息执行不同的操作。消息流由一个输入节点发起,该节点启动一个流经消息流的消息。如下所述,WEBSPHERE MESSAGE BROKER 2.1包含了一个MQInput节点,它可以从一个WebSphere MQ队列中读取一个消息。这一节点将与其他的节点相连。尽管节点之间的连接被称为连接器,但这些构造纯粹是为了帮助将控制中心图形工具中的节点捆绑在一起。消息实际上是通过方法调用请求在节点之间传递的,这些请求中包含了一个指向在节点间被传递的消息对象的指针。 可以对每一个消息流中节点的属性进行客户化处理。这将使节点能够对流经自己的消息执行特定的功能,并执行消息流要求节点执行的处理过程。 与Database紧密集成 WEBSPHERE MESSAGE BROKER提供了与DB操作相关的各种Node, 如INSERT,UPDATE,DELETE等Node,用户可以通过ESQL进行和数据库的操作,如把数据存入数据库,从数据库中取数据等; 信息平台可以将整个系统中产生的大量数据记录在数据中心中,以备进一步决策分析、数据挖掘,实现更深层次的数据利用。作为统一的数据整合平台,WEBSPHERE MESSAGE BROKER可以直接操作不同应用系统的数据库,实现各部门的数据高度共享。 功能强大的发布预订系统 ü 基于内容和主题的过滤 - - 企业服务总线技术方案建议 将发布和预订(Publish and Subscribe)功能添加到信息代理程序中以后,增加了该系统的功能价值。将发布/预订代理程序的优势与WebSphere Message Broker的功能结合在一起,可以获得额外的好处。对于信息的订户,它们将不仅能够接收到自己所要求的信息,而且还可以根据自己的需要在任何级别上对信息进行过滤和格式化处理。作为一个标准的发布和预订系统,向订户提供信息的时候可以不必知道何人将会需要这些信息,因而也不必知道向何人发送这些信息。 发布/预订系统的用途在于,它极大地提高了选择标准的精炼程度。每一个主题当中都包含了大量订户并不需要的信息,即使主题与订户要求的主题相匹配。因此,通过提高发送往订户的消息的选择精炼程度,以及通过基于内容的预订,将可以实现一种选择性更强因而效率也更高的信息发送方法。 WebSphere Message Broker 提供了这种基于内容的预订过滤功能,以及用于发布和预订的基于分级主题的过滤功能。对于基于内容的过滤,将使用SQL表达式评估一个消息内的单元内容,并因而获得内容过滤结果。内容过滤器可以被存储在动态预订表(Dynamic Subscription Table)之中。这些过滤以后的消息与其他的消息代理程序功能相结合,就可以根据不同应用程序的要求对消息进行转换,消息中只有被要求的部分才会被发送到对其进行了预订的应用程序。发布/预订功能被表示为一个节点,被称为消息流内的发布节点。发布/预订节点的最终成果是将一个消息放入一个或多个MQ队列之中。 ü 预订处理 如果在发布之前就可以知道发布数据的预订应用程序是什么,那么这种预订就被称为静态预订,并且可以预先对其路由进行很好的定义。如果可以通过预订应用在预订设置中添加或改变预订,那么这种预订被称为动态预订,它能够很灵活地在系统的运行时间内改变商业请求,而不必预先登记自己感兴趣的特殊消息类型。WebSphere Message Broker能够支持所有这两种类型的预订。 订户对发布/预订功能的请求采用了被称为控制消息的消息格式。这样,订户就能够全面地创建、删除和改变自己的预订内容。这些消息的名称是:登记订户(Registered Subscriber)、注销订户(Deregister Subscriber)和请求更新(Request Update)。对于发布者来说,可以使用不同的消息来满足自己的不同需要。这些消息的名称是:发布(Publish)和删除发布(Delete Publication)。只有当客户机应用正在使用的是MQI编程接口而并非 - - 企业服务总线技术方案建议 MQ应用消息接口(MQ Application Messaging Interface)和MQ JavaTM 消息服务(MQ JavaTM Messaging Service)时,才会要求这些控制消息,因为MQI需要显式地创建调用这些功能的消息头。 - -

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享文档获得金币 ] 21 人已下载

下载文档