企业集成与 Web Services 和 BPEL

---寻求巩固和现代化其应用程序的企业有了 EAI 的一个替代方案

许多公司花费巨款并收集大量的数据以维护他们的遗留系统。因此，对于公司来说，找到一个快速而高效的方式来保留和重复利用这些遗留系统而不是把它们扔到一边是非常重要的。传统上，为提供跨各种不同应用程序和操作系统的通信和集成，公司会求助于企业应用程序集成(EAI)。

然而，由于EAI 解决方案的高成本和专有特性，许多公司正在寻找一种更加简易、灵活的方式来巩固和现代化他们的应用程序。为了提供服务和与业务合作伙伴、顾客及其他信息系统共享数据，企业必须以当前的技术更新他们的遗留系统。一个解决方案便是利用Web services 和业务流程执行语言（Business Process Execution Language，BPEL）。这些技术提供开放的、基于标准的集成，该集成通过组合消息传递技术和 XML 及各种Web services 标准来提供互操作性。一旦开发了Web service 接口，您就可以使用BPEL 来定义和编排业务事务，最终使遗留系统转变成全新的现代信息系统。

本文讨论在集成遗留系统和Web services 过程中遇到的问题, 以及在公司的集成工程中，BPEL 如何扮演重要的角色。

遗留系统的集成问题

当今许多大企业现有的遗留系统由各种各样不同的语言写成，比如COBOL 和C++。另外，还可能存在不同的遗留系统来完成相同的功能，从而导致混乱、分散的IT 基础架构，这使得将来的集成变得困难。

例如，典型的企业通常由许多分散的不同部门组成，各部门有它自己的流程来履行具体的职责。考虑一家提供旅游服务的大型连锁旅馆，它包括企业、部门和应用程序之间的多个信息系统。各个旅馆有它自己独特的售票系统，允许顾客完成某些操作，比如查看旅馆介绍和入住率，以及进行和取消客房预订。然而，由于各个系统的独特性，公司在跨企业维护和交换相关数据（比如必须连接到记帐系统的信息）方面有些困难。

过去，公司也许是求助于专有的解决方案来补救通信问题和跨系统进行集成。因此，经过几年的在专有集成方面的努力，现在企业中并存着各种各样的集成工具和解决方案。尽管使用专有通信技术（即 CORBA、EDI 或其他消息传递技术）来集成孤立的系统是可能的，但公司变得依赖于供应商。因此，由于需要另外的相当数量的资源来维护专有的标准和协议，系统的扩展变得越来越困难。

创建Web Services 接口

企业需要可伸缩的、可靠的应用程序。由于涉及如此多的数据并且需要很多的资源，所以我们例子中的连锁旅馆无法简单地从头开始和重新构建。它必须找到一种方法来扩展它的遗留系统并在这之上构建新的系统。在如今这个快速变化、前瞻性思考的世界，公司必须现代化和巩固他们现有的信息系统。他们还必须保证，这些系统集成以后，能够为将来长期的发展提供支持。为适应这些需要，相关组织必须建立灵活的、基于标准的架构，而不是局限于专有的规范。

对于部署了多种销售方案和要将现有系统用于新应用程序的企业，实现Web services 无疑是企业的一个理想选择。Web services 正在获得行业范围内的认同和使用。它们正在从概念验证部署转向任务关键型企业应用程序中的实际使用。

由于Web service 标准的发展，比如XML、SOAP、Web Services Description Language (WSDL)和 UDDI，一个促进和鼓励互操作性和系统再利用的标准化集成接口是可用的。所以，可以使用新技术来巩固和现代化遗留系统，这使得没有供应商参与的快速集成成为可能。通过构造Web services 接口，可以在遗留系统的基础之上开始构建；而不是取代它们并从头开始。这一架构为将来的扩展提供基础，由于有一个灵活的、基于标准的接口，企业因此可以轻易地增加或插入新的应用程序。

用BPEL 编排业务流程

为使企业最大化Web services 带来的好处，他们需要一种在模仿实际业务流程的自动化业务流程之内使用这些服务的方式。他们必须编排业务事务发生的顺序以提高企业日常业务的效率。BPEL 最初叫做BPEL4WS (Business Process Execution Language for Web Services)，明确设计为用于定义和自动化这些类型的支持Web service 的业务流程。

BPEL 支持的面向Webservice 的业务流程自动化的方法为当今企业所面对的两个挑战提供了解决方案：

•如何以一种不但最大程度地降低成本而且增加企业在快速变化的市场环境下的敏捷性的方式来使企业实现自动化。

•如何以一种自动化实际业务流程的方式聚集不断增加的Web services 并对它们进行编排。

BPEL 还提供一种语言，可以表示用于在多方之间交换交互模式的流程（业务协议）和意在转换内部逻辑的流程（可执行流程）；它也可以缓和从一个流程到另一个流程的过渡。BPEL 可以用同一种语言表达两种类型的流程，且以很小数量的扩展来区别业务协议（称为抽象流程）和可执行流程。这两种类型的流程之间的区别不需要很明显。实际上，BPEL 的一个主要特点就是，它表示两种类型流程的能力使得一种类型的流程到另外一种类型的流程的转换过程变得容易（例如，把一个内部业务流程的部分作为抽象流程暴露给业务合作伙伴，当然，任何敏感的信息除外）。

BPEL 另外所关心的是，流程是如何受控的。流程模型化方面的两个主要控制方法是分级控制和类图控制，前者与结构化编程语言中的一样，而对于后者，活动的执行主要受控于表明活动间的显式依赖关系的链接。BPEL 支持这两种类型的控制方法，并允许在流程内交替使用这二者。在流程的表示方面，这给予作者高度的灵活性，他可以选择任何对任务来说是最自然的方式。

最后，BPEL 应对的是与长期运行的业务流程相关的挑战。大多数的业务流程会持续相当长的时间，因而需要一个长期运行的事务模型。BPEL 使用一个具有隐式和显式补偿的模型，因此故障可以被轻易地处理，无需做不切实际的假定——即能够将事务锁定一段不定的时间。对补偿处理的内在支持和良好定义的原子活动是该模型的关键。

用BPEL 搭桥

BPEL 包括对生产和消耗Web services 的内在支持。实际上，每个可执行的BPEL 流程是作为一个Web service 展示给世界的。虽然Web service 技术（比如WSDL 和XML）被设计为平台中立的，但是包括一些关键Webservice 概念的集成语言可使公司节省大量的时间和资源。此外，BPEL 还严重依赖于WSDL，并把由WSDL 提供的关键抽象作为它自己的关键抽象。这使得BPEL 成为一种操纵Web services 的自然语言。所以，对应用程序集成来说，企业中可用的Web services 越多，BPEL 就越重要。

有了Web service接口，BPEL 可用作扩充遗留系统的桥梁，同时可为新技术提供实现和集成的方式。因此，多个应用程序（新的和旧的）通过这座BPEL 桥梁可以利用现有的业务流程。通过使用BPEL 编排业务流程，企业能够替换或升级一个业务流程中旧的部分，而不影响运行良好的新系统。

所以，一个全新的信息循环将最终形成，其中的遗留系统部分将缓慢迁移。随着时间的推移，整个遗留系统将迁移到新的信息循环中，并将最终消失，被合并到现代化的BPEL 循环中。例如，在我们的旅馆场景中，公司能运用BPEL 来更改其客房预订系统中的流程，而无需改变它的会计系统，即使两者也许会在其他的业务流程中相互作用。通过转变旧的业务流程，BPEL 可以伸缩和现代化旅馆的基础架构。

在集成扩展的企业里，灵活的、基于标准的架构作为可选的设计模型正在涌现。其中Web services 和 BPEL充当了重要角色，提供强有力的手段使得业务逻辑可以在为集成任务提供服务的抽象级别被明确表达和执行。

我们已经看到许多对多数业务流程应用程序来说是共同的属性，包括长期运行的流程；对可靠的异步通信的需要；以及大量使用Web service技术。尽管任何这些属性都能用通用编程语言编写代码来实现，但是创建Web service接口和使用BPEL 的主要好处是，它们提供对遗留系统集成的常见困难任务特别适合的抽象和基础架构。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友