灵活性革命：通过面向服务的架构实现业务集成

灵活性革命：

通过面向服务的架构实现业务集成

Oracle 白皮书

2008 年8 月更新

灵活性革命： 通过面向服务的架构 实现业务集成 简介 在当今快速变化的业务环境下，各类组织同时面临一项共同的持续挑战：如何变得足够灵活并保持灵活，以便满足不断提高的客户期望和适应新的合规要求，做到这一切的同时还要在竞争中保持领先。 其解决方案就是业务集成。通过将业务流程管理 (BPM) 和面向服务的策略组合到 IT 管理中，业务集成可以提升所有流程的效率和自动化程度，确保现有的 IT 资产支持实际的业务流程，并将新的 IT 投资集中于最大收益方面。尽管概念非常简单，但业务集成一直难以实施；但是，利用如今基于面向服务架构 (SOA) 的策略（该策略将业务和 IT 置于同一基础上）和 Oracle 的解决方案与专业知识，这已经不再是一个难题。通过采用本白皮书中所述的策略，各类组织确保能够完美地、逐步地、成功地过渡到全面的业务集成。 挑战 各个组织日益希望 IT 能够为其提供工具，以便将解决方案映射到其复杂的业务问题中去，反之，这意味着为他们提供所需的灵活组件来支持该流程。但是，过去这类业务集成一直面临着两大挑战：在业务和 IT 领域之

间架设一座桥梁，并为这座桥梁提供灵活有力的基础结构以支撑桥梁。各个组织通常采用自顶向下或从底至上的策略来完成该任务，但这两项策略取得的效果都微乎其微。自顶向下的策略分割了业务流程，使其达成特定的计算操作，但其中许多操作与现有软件功能已经没有相似之处。相反，从底自上的策略构建在更抽象的计算操作上，达成的操作通常与连贯的业务操作相去甚远。更糟糕的是，链接独立操作的基础结构往往太过刻板，导致各组织无法足够迅速地改变其业务和 IT 映射来提高其竞争力。

通过将业务流程管理和面向服务的策略

组合到 IT 管理中，业务集成可以提升所有

流程的效率和自动化程度。

过去业务集成一直面临着两大挑战：在业务和

IT 领域之间架设一座桥梁，并为这座桥梁提

供灵活有力的基础结构以支撑桥梁。

解决方案

通过为组织提供业务方面的工具，使其从概念上映射其流程，并为IT 部门提供映射现有服务、数据和应用程序到这些要求的工具，BPM 和SOA 让业务集成成为可能。总之，它们可为业务和IT 提供统一的工作理念：原子业务服务。在此模型中，业务将流程分解为微小但可辨别的业务服务，同时IT 将现有资产和新组件组合成相同的组件，从而使得组织的两个方面在中间会合。此外，业务和IT 采用称之为企业服务总线(ESB)

的灵活构架进行链接，以帮助进行适应。其结果是灵活的基础结构让公司可以迅速增加新服务、将内部服务转换为外部服务、从旧服务过渡到更新的服务、重新排列服务顺序、执行管理策略并监控服务执行情况。

实施

成功的业务集成需要完善的平台，包括

BPM 套件。这些套件可让每个流程表述成一个“故事”（如订单

履行）。

启用服务的数据集成基础结构。这可让IT 员工提供必要的“名

词”（如客户和服务）。

启用服务的应用程序整合基础结构。这可让IT 员工提供必要的

“动词”（如采购和装运）。

聚合器/ESB。这是连接名词和动词到所需故事的纽带（并可让公司

持续编辑该故事）。

业务集成的其中一项巨大优势是企业可根据其境况和需求按照不同的路径

进行实施；例如，如果业务方面能够带动改善可见性、控制力和灵活性，

企业则可从BPM 软件开始。但是，如果这些功能很可能针对当前的问题

带来最大的即时投资回报(ROI)，另一家公司则可能从数据或应用程序整

合开始。最后，ESB 可以代表企业的第一步，其中基础结构满足整个现有

整合项目的共同需求。

不论公司从何处开始，通过结合SOA 和BPM，它都能够完美地整合其

业务组合。一种方法不能解决所有问题，为满足每位客户的特定需求，

Oracle 提供一系列全面的产品和专业知识，以拓展现有基础结构和应用程

序的价值。

Forrester Research 找到了SOA 和

BPM 之间的强大链接。实际上，该组织最近

开展的一项调查显示，92% 的受访者在实施

SOA 的同时也意识到了BPM

对其组织未来的重要性。

不论公司从何处开始，通过结合SOA 和

BPM，它都能够完美地整合其业务组合。

业务集成与面向服务的基础结构

25 年多以来，众多企业一直尝试着将 IT 资产与业务目标结合到一起——实际上，往前可以追溯到 Clive Finkelstein 发展以及 James Martin 普及信息工程这一概念的时期。对于这一任务，大多数早期的策略都采用了自顶向下的流程，其中企业会将其当前的业务模型分解衍生成其所需的 IT 功能。但是，导致的“空白黑板综合症”产生了一系列过于具体的要求，很难与任何现有系统的功能匹配——这意味着实现这种预期调整的唯一办法就是在软件开发方面做出大量投资。当然，业务目标的任何变化都会形成一系列新的功能缺口和另一笔巨大投资。 为应对这种策略的限制，许多公司反过来尝试了从底至上的策略——这导致了点解决方案的扩散。这些策略的难题在于它们很难支持整个流程的连续执行，从而导致了“烟囱综合症”；也就是说，在地理上分散的公司很难将数据从公司的一个分部与其他分部进行交换。这意味着使用集成工具的每个项目要将现有的低级软件功能集合到仅符合直接业务需求的抽象操作中。反之这意味着实现这种预期调整的唯一办法就是执行永不结束的分散的系列整合项目，其中每个项目都将造成出现一根新的烟囱管。因此，与达成连续的业务模型状态相反，各公司发现自己面临的是看不到头的整合项目。 基于 SOA 的业务集成解决了这些问题，办法是引进两项重要的创新：链接业务和 IT 的概念工作单元，以及在工作单元间灵活调停的构架。这种情况下的统一工作单元是原子业务服务——对企业的业务和 IT 方面都起作用的一个概念。对于业务方面的工作单元，此原子业务服务代表一系列

类似任务，这些任务对应小部门（如付款处理）在现实世界中可能提供的服务。对于 IT 方面的工作单元，此原子业务服务代表一系列相关功能，这些功能对应应用模块（如付款处理器）在旧客户端/服务器领域可能已经提供的一些功能。

从业务方面来看，原子业务服务是最低级的有用服务——无需利用任何特定的 IT 级别架构或设计。而从 IT 方面来看，原子业务服务代表着最高级的有用服务——无需利用任何特定的业务级别流程。显而易见，根据公司和行业，这些定义足够灵活，可以适用于各种不同的解释；例如，某家制造公司可能会将付款流程视为原子业务服务，但第三方付款流程公司几乎肯定会将更低级别的概念作为原子业务服务。同样，相对信息密集程度较低的行业（如建筑公司），高信息密集型行业（如金融服务）将采用更加细致的原子业务服务。这种概念级别的灵活性正是业务服务的优势所在：每个公司都可发展其自身的传统，甚至是那些长时间的传统，而又不会打破这种模式。

基于 SOA 的业务集成解决了这些问题，

办法是引进两项重要的创新：链接业务和

IT 的概念工作单元，以及在工作单元间灵活

调停的构架。

图 1 阐释了此概念工作单元如何桥接了业务和IT 之间的鸿沟。业务朝原子业务服务层向下分解其业务流程模型，而IT 朝着使用面向服务的整合层向上聚集软件资产。然后它们在中间会合，并协商达成必要的原子业务服务共识。

图1：聚集在原子业务服务上

基于SOA 的业务集成后的第二大创新是ESB，它可让该机制不断适应现有服务组合，从而满足不断变化的需求。任何服务组合都不可能完全适合所有情况；但是，ESB 可以在其中适应性地调停，而无需不断更新成分服务；例如，如果两项服务使用稍有不同的格式传送其消息，ESB 即可在其间担当翻译。或者，如果在某个区域中有了变化的业务需要新型服务，ESB 即可将需要强化功能的请求发送到新型服务，同时将假定只有基本功能的请求发送到旧版服务。因此，除了为业务和IT 提供共同点，SOA 还能为部署的解决方案提供变通的灵活性，使之不受限制。

面向服务的架构平台

虽然ESB 不是基于SOA 业务集成的唯一组件，但它确实是整个平台的支柱。图2 展现了整个画面，但简言之这是SOA 平台的外观和工作原理：

此业务集成平台位于流程参与者和现有IT 资产之间，它在其间对

两者的工作起协调作用。

业务流程管理层与流程参与者相接，按顺序排列其任务并通过ESB

提供自动化帮助。

除了为业务和IT 提供共同基础，

SOA 还能为部署的解决方案提供变通的

灵活性，使之不受限制。

应用程序和数据集成层与现有资产相接，将必要的数据和功能提取到原子业务服务中，再通过ESB 发布。

图2：基于SOA 的业务集成

业务流程管理

从企业的角度来看，业务集成平台可见性最强的部分是业务流程管理层，这一层提供流程建模、执行和管理组件。

建模组件允许业务分析师使用惯例（如业务流程建模标注）写每个业务流程的故事。这些组件还可让分析师记录流程步骤，并模拟用户界面屏幕来阐释人们如何使用这个流程。最后，这些建模组件可以模拟自动和手动任务流程来帮助分析师细化故事，直至下降至一组优化的原子业务服务。

执行组件将流程转换为可执行指示，然后调用必要的原子业务服务，这通常通过ESB 执行操作。它们还提供基于Web 的工作空间，供用户执行任务并手动处理异常情况。监控组件追踪实时流程和长期流程指标，以最大程度地缩短对突发危机和不断变化的环境的响应时间。Oracle 业务流程管理套件将所有这些建模、执行和管理组件集合在一个包装内提供给客户，其可靠性、可用性和对所有权变化的可扩展性都已经过验证。

数据集成

信息关乎企业的存亡。当企业能够得到准确的实时整合信息时，它就可以作出正确的决策。在合适的时间、合适的地点获取正确的数据正是开启这类实时信息流的关键所在。

正确的数据。这些数据不仅要适合指定用途，更必须准确而可靠。

合适的地点。整个信息生态系统包括多个操作和分析系统。不论在

哪个位置，每个系统都需要利用其他系统中的数据，并从中获益。

合适的时间。数据很容易失效。不能及时获得数据的决策支持系统

毫无用处。不能在截止时间前获得订单信息的装运应用程序是没有

效率的。在合适的时间获取数据——具有适合此数据指定用途的延

迟时间——是如今的企业面临的其中一个最重要的挑战。

Oracle 提供Oracle Data Integration Suite，这是一个全面的数据集成产品，能在合适的时间、合适的地点提供正确的数据。凭借着过硬的性能，Oracle Data Integration Suite 解决了所有数据集成需求，如更改数据捕获；数据质量；数据配置；以及提取、转换和载入。与Oracle Fusion Middleware 配合使用时，该套件可用作端到端的IT 架构的中央组件，

并为整个企业提供顶级共享数据服务。

企业服务总线

在担当运输工具之外，ESB 还可用作智能路由器、翻译器、策略执行器、聚合器与监控器。除了管理各服务间的消息流，应用管理和安全策略，以及支持整个企业的SOA 管理，ESB 还能促进低级别数据和应用程序服务之间的合作——所有这些都突出了使用ESB 时采用最佳做法的重要性。

Oracle 的ESB 产品Oracle Service Bus 专门用于连接、调停和管理整个企业服务网络内混合型服务、传统应用程序、打包应用程序和多个ESB 实例间的交互。Oracle Service Bus 是Oracle SOA Suite 的核心组件，它与Oracle 的SOA 管理解决方案集成为更好的企业级SOA 管理，从而促进对最佳实践的遵从性。

服务存储库和注册表

随着基于SOA 的业务集成基础结构在企业内逐步发展壮大，在服务的开发和部署过程持续应用策略，以及所有关键方全面了解这些服务就变得日益重要，也就是说，哪些可供使用，服务的作用，以及哪些客户和业务流程需要使用这些服务。

业务分析师需要了解在设计新流程时哪些原子业务服务可供使用。

IT 架构师必须了解有哪些服务依赖性，以便确定任何变化产生的

影响。

运营经理需要全面了解服务用途和负载特性，以便确保实现服务水

平协议承诺。

Oracle Enterprise Repository 和Oracle Service Registry 通过在整个业务集成平台中的业务流程和服务中提供设计时间和运行时的可见性来支持这些服务管理活动以及更多方面。

采用模型 在业务集成的初期，各公司都曾被迫采用大型平台作为一个广泛的实施项目。然而如今 SOA 已将业务和 IT 置于同一起跑线上——这意味着企业可以顺利平稳地从部分过渡到全面整合。实际上，这种能够顺利实现大规模部署的能力可以增加组织单个项目的投资回报，因为公司可以将其投入到更大型的业务处理生态中，而不仅仅是摊还单个部门或活动的成本。以下小节概述了组织可以采用用来过渡到全面业务集成的策略。 集成作为起点 企业通常使用成功的信息系统整合项目作为业务集成的起点，从而将灵活基础机构的优势扩展到整个企业。其中一个示例是，在动态和过程密集型的房贷行业，一位做次级抵押贷款并提供资金的 Oracle 客户想更好地处理拖欠贷款，并减少没收财产的库存量。要达成这些目标，客户的贷款服务软件模块需要与其他模块更好地协作。客户在海内外共有 500 名员工用户，以及近 1,000 名合作伙伴用户，因此客户需要在其整合解决方案中将灵活性与可扩展性结合起来。 在选择 Oracle SOA Suite 作为其标准中间件平台后，客户开始逐步协调越来越多的内部及合作伙伴模块，因为原子业务服务由以 IT 为中心的流程组成。由于效率在房贷行业至关重要，因此采用 Oracle SOA Suite 缩短的处理时间和降低的财产库存量已经证实对客户是一大优势。因此客户计划采用 Oracle Business Process Management Suite 作为其将来贷款发放项目的 BPM 层，与此同时其项目将继续在业务集成堆栈中向上移。 企业服务总线作为起点 一些已经采用 SOA 的组织使用其 ESB 作为业务集成的起点。一般而言，这类组织都有 BPM 和业务集成孤岛，而他们希望这些孤岛更容易访问，更加强大。尽管这些组织倾向于将 ESB 视为水平基础结构要求，而不是策略业务要求，但实际上投资 ESB 将在灵活性和响应度方面带来巨大的业务收益。 这是因为 ESB 能在整个公司范围内提供每个功能孤岛的可访问性。它还能提供一致的策略执行，包括安全、更高的可用性和更严格的服务水平。配备好 ESB 后，组织可以轻松快速地连接这些孤岛并填补空缺以实现业务集成，带来连续收益，从而使 ESB 成为公司的可靠投资，同时享有现

有的基于 SOA 的功能。

企业通常使用成功的信息系统整合项目作为

业务集成的起点，从而将灵活基础机构的

优势扩展到整个企业。

配备好 ESB 后，组织可以轻松快速地

连接这些孤岛并填补空缺以实现业务集成，

带来连续收益，从而使 ESB 成为公司的可靠

投资，同时享有现有的基于 SOA 的功能。

业务流程管理作为起点

对许多组织而言，尤其是那些希望更好地执行主要业务流程的组织，业务流程建模很明显是业务集成的起点。为支持这些举措并提供最灵活且可扩展的策略，各组织正在自然而然地接着利用基于SOA 的业务集成组件。

Screwfix 就是一个采取了这种方式的公司，这家公司销售紧固件及其相关工具，过去曾遇到过补货流程方面的难题。过去，经销商经常遇到产品脱销，导致销售量流失，配送成本增加——当业务分析师的脑海里只有所有现有流程（以及对流程的任何潜在改进）时，这一直是一个难以克服的困境。通过采用Oracle 业务流程管理套件，Screwfix 才得以程序化这些知识并改善新流程。使用其他Oracle 业务集成平台的概念验证证明，Screwfix 可以迅速将其现有数据和应用程序资产结合到所需流程中去。

当脑海中有了清晰的业务动机后，综合方案的优势也会立刻变得清晰。

结论

通过利用现有的BPM、整合与ESB 计划，各组织几乎马上就可以开始收获基于SOA 的业务集成的益处。只需做出适度的额外努力，就可让各组织达到更好的业务平衡，这类整合能让组织自然地发展其业务集成组合，响应特定商机。

因此，一个公司进行业务集成的益处是不可限量的。业务（在原子业务服务外组成流程）和IT（集合资产到原子业务服务中）都存在自然的网络效应，这是因为新计划自然会想要利用现有的业务服务组合，且添加到该组合只会提升它的价值。

虽然组织可以从几个方向开始基于SOA 的业务集成，但一个完整的平台必须包括BPM、应用程序和数据集成，以及允许公司从解决方案空间的任意点开始整合的ESB 组件。Oracle 正通过行业领先的产品、实践和素质一流的员工在这条灵活的基于SOA 的业务集成道路上引领前行。

灵活性革命：

通过面向服务的架构实现业务集成

2008 年8 月更新

Oracle Corporation

全球总部

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

全球查询：

电话：+1.650.506.7000

传真：+1.650.506.7200

https://www.360docs.net/doc/cc3206218.html,

版权所有? 2008，Oracle 和/或其附属公司。保留所有权利。

本文档仅供参考，若有任何内容更改，恕不另行通知。

本文档不保证无错误，也不受任何口头明示或法律暗示的其他保证或条件限制，包括适销性或其他特定用途的暗示保证或条件。我们特此声明将不会承担与本文档相关的任何责任，且本文档不直接或间接构成任何合同义务。未经我们事先书面同意，不得以任何形式或方式（电子或实物）为任何目的复制或传送本文档。Oracle 是Oracle Corporation 和/或其附属公司的注册商标。其他名称可能是各自所有者的商标。