轻松搞定应用程序集成（转载）

作者：Rag Ramanathan

有限的可重用性、多种数据格式、紧密耦合以及许多其他问题妨碍着应用程序的集成，但 SOA 可以改变这一切。 　　应用程序集成是企业信息技术管理人员所面临的最为关键问题之一。企业使用了许多定制的和现有的打包应用程序来运行其业务流程。这些应用程序必须进行集成，以实现信息共享和创建新的应用程序。 　　传统应用程序开发和集成的方法不具备灵活性，并且不是基于标准的；因此，就可支持动态组织的不断变化的需求的灵活的企业 IT 环境而言，它们起不到推动作用。 开发和集成 　　在大型企业中，应用程序必须能够和来自一个或多个数据源的业务数据进行交互，其中的一些数据源可能就是别的应用程序。换句话说，没有集成就没有应用程序的开发。 　　另一方面，应用程序的集成要求一定的应用程序开发任务，例如开发和装配组件、将组件连接到后端系统、实现流程流和工作流、开发用户界面以及测试和调试。将应用程序的开发和应用程序的集成分开考虑的做法已经过时，而且毫无益处可言。 　　随着应用程序开发和集成方法学的发展，现在的 IT 已经可以跟上业务快速增长和变化的步伐了。然而，技术更新的速度落后于业务变化的速度。在大多数的企业中，IT 部门灵活性的缺乏阻碍了企业就客户的需求做出实时的变化。 　　应用程序集成的三个最常用的方法学分别是点对点的集成、企业消息总线或中间件集成（即 EAI）以及基于业务流程的集成。 　　在点对点的集成方法学中，应用程序根据需要和其他应用程序进行集成（见图1）。图中所显示出来的相互连接也可以用 Web 服务来构建。这并不能使它变成基于 SOA 的系统，原因是它缺少其他的特性例如松散耦合、一个中间基础以及共享的基础架构。 图 1. 在典型的点对点的集成当中，各个链接是私有 API 和协议。没有使用 Web 服务。 　　由于点对点的集成方法很复杂、成本高、而且难于维护，于是引入了另外一种集成方法。这种方法称为企业应用集成（EAI），它基于消息总线/代理或者中间件。在这种情况下，应用程序和消息总线之间的连通性是用私有总线 API 和应用程序 API 来实现的（见图2）。 图 2. 企业应用集成 (EAI) 基于消息总线/代理或中间件。 　　基于业务流程的方法改进了 EAI。在这种情况之下，业务流程流引擎用来和消息总线或中间件一起运行流程流，这些流程流执行不同系统的多步事务处理。 　　缺点： 　　这些传统的集成方法中没有一个是很理想的（见图3）。存在的问题包括： 图 3. 应用程序集成的三个最常用的方法学分别是点对点的集成、企业消息总线或中间件集成（即 EAI）以及基于业务流程的集成。然而这些方法没有一个是理想的。 消息总线和应用程序之间自定义的或私有的集成。与点对点的集成方法相比较，EAI 和基于业务流程的集成方法减少了集成点的数量。然而，这三种方法都需要在消息总线和每个应用程序之间进行自定义的或者私有的集成，而且每一个集成点都含有不同的以及私有的数据格式。 消息总线和应用程序之间的紧密耦合。所有的应用程序都需要了解与其集成的其他应用程序的内部工作方式。系统之间的集成都是粒状的，并且通过消息类型紧密耦合。传统 EAI 实现中所使用的业务流程管理工具是私有的。这阻碍了最优产品的应用。 程序化的而不是抽象的数据访问。访问、集成以及转换数据（企业信息集成）的挑战主要由开发人员通过手工编码来执行。不同数据源的存在是企业 IT 环境中实实在在存在的现实情况。开发人员用适配器来访问数据源，用转换引擎来对数据进行重新格式化以及用复制来从物理上加固数据。要集成数据源，开发人员将使用这些工具来将集成需求编入应用程序。尽管这个方法起作用，但它既无效率也无灵活性，原因如下： 缺乏抽象。 编程人员必须使用低级 API 来实现集成需求，这大大地增加了开发和维护成本。 多数据格式。每个数据源都有其自己的 API 和数据格式。开发人员必须详尽了解每个数据源以管理数据集成。这往往需要多位专家来实现和维护集成，结果增加了复杂程度和成本。 自定义信息集成框架。开发人员必须处理所有的集成问题，例如数据源和数据格式之间的关系。这就导致了一次性的解决方案和难以维护的不一致性。 紧密耦合。编程造成了应用程序和数据源之间的硬编码依赖关系。数据源的更新会中断许多应用程序，这不利于维护。 有限的重用性。集成代码往往专用于每个应用程序和数据源，这使它难于重用。 为什么选择 SOA? 　　所有三种传统的应用集成方法都很复杂，成本高，而且不具备灵活性。此外，它们也不支持业务变化的需要。然而，基于面向服务架构（SOA）的应用程序的开发和集成解决了这些问题中的许多问题。 　　由 SOA 所定义的一组基于标准的交互模式使得消费者应用程序能够利用服务。这些方法定义了如何描述服务、如何为服务做广告和如何发现服务以及如何与服务通信。 在 SOA 中，与先前的方法不同的是，围绕服务的所有模式都是利用基于标准的技术来实现的。大多数的通信中间件系统，例如远程过程调用（RPC）、公用对象请求代理结构（CORBA）、分布式组件对象模型（DCOM）、企业 JavaBean （EJB）以及远程方法调用（RMI），都依赖于类似的模型。没有哪个实现是完美无缺的，问题存在于互操作性以及定义可普遍接受的标准。 　　SOA 企图消除这些弱点。例如，每一个中间件系统都有固定的粒度：RPC 函数、CORBA 对象等等。然而，服务可被定义为函数、对象、应用程序或者其他。这使得SOA 可适用于任何现有的系统，并且不强制要求这些系统符合任何特定级别的粒度。 　　SOA 有助于信息系统移向一个“leave-and-layer”架构，意味着不是对现有的系统进行改变以提供一个基于标准的服务接口，它们被包装到一个层中，由该层来提供服务接口。Web 服务是实现这一层的一个方法。SOA 不是去替代现有的架构，而是将现有的系统和应用程序转换成灵活的服务。SOA 不仅包括来自打包应用程序、定制应用程序以及遗留系统的信息，而且也包括来自 IT 基础架构如安全、内容管理和搜索的功能和数据。基于 SOA 的应用程序的创建速度很快，这是因为它们可以很便捷地添加来自这些基础架构服务的功能。 　　图4显示的是使用了基于服务的集成方法的企业应用程序的高级视图，这和图2所示的结构有很大的相似。然而，关键的不同之处在于，这个系统使用了基于标准的服务并包含了流程/数据服务、编排（orchestration）以及合成（composition）。基于标准的服务成为了应用程序之间的集成点。服务的编排（orchestration）以及合成（composition）增加了灵活性、可重用性以及服务的集成。 图 4. 使用基于服务的集成方法的企业应用程序的架构类似于图 2 中所示的架构，但是这个系统使用了基于标准的服务并且包含有流程/数据服务、编排以及合成。 　　现在，您对 SOA 已经有了一个简要的了解，让我们再深入探讨一下 SOA，看它是如何使集成变得轻松自如的。 SOA 设计 　　SOA 可让企业在其应用程序的开发过程中集中精力于业务流程，而不是去关注有关集成或应用程序的低级问题。SOA 是可重用网络服务的一个集合，通过定义良好的，且平台独立的接口进行通信。这些服务提供了对数据、业务流程以及 IT 基础架构的访问，并允许对服务供应、消费以及生命周期进行管理。 　　表1 突出了分布式组件架构和 SOA 之间的区别。SOA 提供了许多传统方法所没有的优点；这些优点是： 基于标准。 松散耦合。 针对共享服务。 粗粒度。 面向联合控制。 分布式组件架构 面向服务的架构 面向功能的 面向流程的 持久性设计 变化性设计 较长的开发周期 交互式的和迭代式的开发 以成本为中心的 以业务为中心的 应用程序块 服务编排 紧密耦合 灵活的且具有适应性的 同构技术 异构技术 面向对象 面向消息 已知实现 抽象 表 1 分布式架构和面向服务架构之间存在许多不同之处。 　　基于 SOA 的解决方案需要来自 SOA 基础架构的一组特定的特性；这些特性在了表2中列了出来，同时也列出了管理和支持 SOA 基础架构所需的属性。 特点 描述 优点，应用性能以及注解 松散耦合 服务提供者和消费者可以用定义良好的接口来独立开发。服务实现者可以更改服务中的接口、数据或者消息版本，而不对消费者造成影响。 松散耦合消除了对系统两端进行紧密控制的需要。就系统的性能、可伸缩性以及高可用性而言，每个系统都可以实现独立管理。 它并没有消除任何的运行时依赖性。它可以划分众多服务提供者的依赖性，但如果该运行时系统需要 24x7 的可用性以及每秒 50000 的吞吐量的话，那么对服务提供者的这些需求必须得到满足。 实现的改变被隐藏了起来。松散耦合给服务提供者和消费者提供了独立性，但要求基于标准的接口和中间物来积极地管理和代理终端系统之间的请求。 基于行业标准 真正的行业标准是由技术旗舰如BEA、IBM、Microsoft、Sun、Oracle、W3C 以及 Oasis 所认可的。SOA 由于其可以用基于标准的技术来实现，所以它被广泛接受。 消除了拥有私有客户的需要。 使用基于标准的技术可打破行业垄断并促进供应商产品的最优组合。松散耦合层的概念依赖于在内部和外部对标准的广泛支持。 可重用的服务 由于服务是在目录中发布并且在整个网络中都可用，所以它们变得更加容易被发现和重用。如果某个服务不能被重用，那么它可能根本不需要服务接口。 为了不同的目的再次将服务组合，这种方式也可以实现服务的重用。 服务重用避免了重复开发之苦，同时提高了实现中的一致性。 服务的重用比起组件或者类的重用更容易实现，在过去曾尝试过组件和类的重用，但很少成功。 同步服务调用 (RPC 方式) 在同步服务调用中，调用方进行调用、传递所需的参数、中断并等待响应。 如果服务提供者可用，那么同步服务调用可为请求提供立即响应。 同步服务对于要求实时响应的应用程序来说是至关重要的，例如 Portal 或者 Query。 异步服务调用(文档方式) 在异步服务调用中，调用方向消息收发服务发送一个包含完全上下文的消息，收发服务将该消息传递给接收者。接收者处理该消息并通过消息总线向调用方返回响应。在消息正在处理的过程中，调用方不会中断。 由于粗粒度消息和消息收发服务的使用，可以对服务请求进行排队并以最合适的系统速度来处理它们。这种方法具有高度可伸缩性，原因是队列允许的长度是多少，消息收发系统就能够对多少请求进行排队。调用方并不在处理过程当中保持网络连接，并且由于调用方并不会中断，所以它们不会受处理延迟的负面影响，也不会受异步服务执行中所存在问题的负面影响。 本实现采用回调的支持，这本身并不是 Web 服务标准的一部分。 无干扰开发 （通过使用现有的软件组件来开发服务） 现有的软件组件并不需要修改就可以将其功能作为服务提供出来。服务是用组件的接口定义开发或生成的。 消除了修改、测试以及维护现有软件的需要。 有了组合服务，来自现有投资的功能可以被重用并重新组合来为企业创造新的价值。 一个示例是为现有的 EJB 创建 WebLogic Workshop 控件。 策略管理 当把共享的服务应用于应用程序中时，针对每个应用程序所特有的规则被外化为策略。 在设计和运行时，必须就每个服务进行策略的管理和应用。 基于策略的计算可以促进普通的可重用服务的创建。随着特定应用程序服务定制的外化，应用程序实现的变化被减少到了最低限度。 通常实施策略的是一个组织的操作和支持小组，并非开发小组。如果不使用策略的话，应用程序的开发人员以及操作和支持小组不得不在应用程序开发过程中并肩工作来实现并测试策略。策略的使用使得开发人员能够集中精力于应用逻辑，而使操作和支持小组专注于规则。 数据访问服务 数据访问、集成、转换以及重用服务。 隐藏数据源的复杂性，同时加强跨数据源的一致性、完整性以及安全性。 组合服务 组合服务将新的现有的应用程序逻辑和事务处理进行了合并。 充分利用现有的 IT 投资。适用于绿地和遗留实现。 装配或者编排产品简化了异构系统的集成。 共享的或企业的基础架构服务 基于 SOA 构建的所有应用程序所使用的公共服务称为共享的基础架构服务。使用共享的基础架构来提供公共服务可以避免每一个应用程序构建类似的服务。 使用共享的基础架构服务可提供一致性，并允许单点管理。 其他的共享服务（例如与安全相关的服务）可以通过将现有的产品作为服务直接提供出来的方式创建。 细粒度服务 细粒度服务实现最小的功能，同时消耗并返回最小量的数据。 细粒度服务可以用 Web 服务来实现，也可以利用基于 RMI、 .Net 或者 CORBA 的分布式对象来实现。 细粒度服务的优点是可在粒度级实施严格的安全和访问策略。 实现和单元测试很简单，而且相互独立。 粗粒度服务 粗粒度服务比细粒度服务实现更多的功能，并消耗不同数量的结构化数据或者消息。它们返回类似的数据或者消息，可能还含有内嵌的上下文。 粗粒度服务不需要通过网络多次调用来提供有意义的业务功能。 表 2 基于 SOA 的解决方案需要来自 SOA 基础架构的一组特定的特性。这里是一些典型的 SOA 特性。 SOA 服务 　　图5显示出来的是一个 SOA 的三个基本角色（服务提供者、消费者以及代理）以及它们的一些工件（artifact）和操作。 图 5. 一个 SOA 有三个基本的角色：服务提供者、服务代理以及服务消费者。 　　服务是网络上可用的软件资源。服务提供者通过标准机制来提供服务，同时服务消费者通过网络有计划地消费服务。服务代理发布服务的所处位置，并且当消费者发出服务请求时对这些服务进行定位。消费者和提供者的角色并不是独占的；服务提供者也可以是消费者，反之亦然。 　　服务提供者在一个服务协定中用标准语言来描述它们的服务，并用服务代理进行发布。客户查询他们所需服务的服务代理（或注册表），并在访问该服务时接收到协定和信息。然后客户或者消费者绑定该服务并直接调用该服务的提供者。 　　一个服务有两部分：接口和实现。接口定义了消费者和提供者之间的程序性的访问约定。一个服务接口必须含有该服务的身份、该服务的输入和输出数据的细节以及与该服务的功能和目标有关的元数据。 该服务实现含有该服务的功能性的或业务性的逻辑。该实现对服务消费者来说应该是一个“黑箱”；消费者无需了解服务的功能实现。 服务的类型有 5 种，它们是： 数据访问：允许统一访问不同的数据源。 组件：提供对打包应用程序服务的访问，如对企业资源规划（ERP）的访问。 业务：提供复杂的服务，这些服务使用多个打包或定制应用程序的功能。 合成：使用上述三种类型类创建一个新的服务。该服务既含有新的功能，也含有现有的功能。 共享的或企业的基础架构服务：低级服务，例如消息日志记录，其重用可快速创建新的高级服务。 　　 数据访问服务。数据访问服务允许用户访问、集成、翻译以及转换整个企业的各种关系型和非关系型的数据资源。这些服务通常隐藏了对资源的直接访问，隐藏了基本格式的复杂性，也隐藏了数据的直接转换和操纵。它们提供了一个统一的 API 、松散耦合、一个公共的数据模型以及整个应用程序中一致信息的重用。 　　数据访问服务是 SOA 架构中最常见的，使用最广泛的，同时也是最容易实现的服务，数据层和应用层的分离通常是很直接的。随着数据资源的广泛访问和共享，它们已成为服务实现的首要目标。 　　XML 广泛应用于应用程序间的数据交换。一个可以对任何数据源进行抽象的、统一的数据访问的基础架构对于 SOA 实现是很有价值的。XML 数据服务（XDS）提供了对多种数据资源的访问，数据建模功能，物理数据向逻辑数据的翻译和转换以及对逻辑数据的基于 XML 的访问。 　　组件服务。组件服务是粗粒度服务，无论这些服务是否是打包应用程序（例如，企业资源规划[ERP]、客户关系管理[CRM]或者供应链管理[SCM]），它们都可以从一个单一的企业资源来发布。组件服务的一个示例可能是“向 ERP 中添加客户”。这些服务被认为有足够的价值，所以可以直接发布。 　　组件服务实现的方法是用各个应用程序 API 来提供可重用的功能的。这些服务可以用分布式计算技术（例如 J2EE EJB、COM/DCOM 以及 CORBA）来实现。 　　业务服务。业务服务的功能（由业务应用程序提供）执行一个或者多个业务操作。业务服务通常是由多个应用程序的多个业务事务处理构成。它们可以是端到端的业务流程，例如，Process New Hire ，或者它们可能需要成为一个更大的业务上下文的一部分，例如在 Provision New DSL Line 或者 Add New Employee 中的情况。Provision New DSL Line 需要成为一个更大的业务上下文例如 DSL Order Processing 的一部分，要求该流程的信息来完成其业务功能。 　　组合式应用程序. 组合式应用程序是通过将新的逻辑与事务处理进行合并创建而成的，现有的应用程序将这些事务处理作为如业务或者组件服务提供出来。应用集成技术和业务流程管理工具在创建复合应用程序中扮演着关键的角色。 　　特定于功能的门户例如 Sales Portal 和 Employee Portal 是组合式应用程序的示例；它们需要业务、组件以及数据服务。 　　共享的或者企业的基础架构服务。SOA 所提供的最大的价值在于它能够通过重用现有的服务快速一致地合成应用程序。这些可以称为共享服务、公共服务或者企业基础架构服务。 　　基础架构服务可以分为四类： 共享的应用程序服务 消息和代理服务 门户服务 共享的业务服务 　　 基础架构服务的一些示例是服务存储库、服务查找程序和代理、单点登录、内容代理、日志记录服务、惟一ID生成器、数据服务以及安全服务。 　　服务粒度。可以基于服务功能以及发送和接收的数据量把服务定义为细粒度的、粗粒度的或者组合式的。 　　服务的粒度在 SOA 中有两个相关的含义：即该服务是如何实现的，以及该服务要消费和返回多少数据（或者说多少消息）。细粒度服务实现最小的功能，且发送和接收少量数据。粗粒度服务实现较大的业务功能，并交换较大量的数据。 　　细粒度服务可以很好的被粗粒度服务或者复合服务所消费，但不能直接被终端应用程序所消费。如果某个应用程序是用细粒度服务创建而成的话，那么该应用程序将不得不通过网络调用多个服务，其中的每个服务交换少量的数据。粗粒度服务的消费者不会暴露于他们所使用的细粒度服务。然而，粗粒度服务不能提供粒度级的安全和访问控制，因为它们可能会使用多个细粒度服务。 　　组合式服务（composite service）可以从粗粒度或者细粒度服务组合而成。粗粒度服务和复合服务的区分并不依赖于数据量。一个粗粒度服务可能是 Create New Customer ，它将需要用外部服务来验证客户的有效性，并在一个 CRM 应用程序中创建该客户的记录。 　　一个组合式服务可能是 Provision New DSL Line，要求服务调用来验证订单的有效性、创建或验证客户、检查产品的可用性以及为该 Line 分配资源。 高级 SOA 解决方案模型 　　企业基础架构或者共享服务为 SOA 增添了很大的价值。共享服务通常是基于其功能和位置而在逻辑层来实现的。图6显示的是一个 SOA 解决方案模型的高级视图，该模型应用了表2中所示的特性。这些特性是由共享服务层实现的，共享服务层从逻辑上被分组为若干服务层。本图使用了 BEA Information Technology 小组开发的一些应用程序和服务来作为示例。 图 6. 这里是SOA 解决方案模型的一个高级视图。 　　图7展开了每个服务层并显示出了每层中的一些公共服务；很明显，这些服务会随着企业的不同而有所不同。这些服务示例是由 BEA Information Technology 小组设计并实现的。 图 7. 当然，每个企业都会有不同的企业基础架构服务 SOA 和 Web 服务 　　SOA 不要求实现 Web 服务，同时 Web 服务的部署并不能产生一个 SOA。然而，Web 服务是服务的一个很好的示例，同时也是企业 SOA 的一个组件（不是一个必需的组件）。 　　SOA 为基于服务的分布式系统提供了概念性的设计模式。Web 服务所提供的基于标准的技术利用了当今无处不有的通信方法，因此可以用较低的成本实现 SOA。当用 Web 服务定义语言（WSDL）来定义服务接口时，那么该服务就是一个 Web 服务。 　　在 WSDL 为人们所普遍接受之前，常见的服务定义语言有 CORBA IDL、Tuxedo FML（与其说是接口定义语言，不如说是数据格式定义）、COM/DCOM Microsoft IDL 以及 CICS common area (COMMAREA)。 在过去， CORBA、EJB、COM/DCOM、CICS 以及 Tuxedo 提供了基于服务的应用程序开发和集成技术来实现 SOA。CORBA、EJB 以及 COM/DCOM 提供了基于对象的分布式系统，其中的对象提供了执行特定服务的函数和方法。 　　对于用 Web 服务或者其他类似技术开发而成的许多松散耦合的服务而言，SOA 提供了一个对它们进行管理的架构。Web 服务的实现可以利用基于 J2EE 的应用服务器、企业服务总线（ESB）或者.Net 框架。 　　基于 J2EE 应用服务器的 Web 服务实现使用基于 J2EE 规范（例如 EJB、servlet以及 JDBC）开发的组件和应用程序，并使用基于 HTTP 或者 Java 消息服务（JMS）的 SOAP 将它们作为 Web 服务提供（JAX-RPC）出来。异步的粗粒度的 Web 服务是用应用服务器所提供的 JMS 服务来实现的。 　　除了纯粹的基于 J2EE 的 Web 服务实现之外，BEA 平台也提供有附加值的、抽象的、基于控件的、基于流程流的以及带有 Web 服务确认（WS-acknowledgement）规范支持的 Web 服务实现。 SOA 和企业服务总线 (ESB) 　　ESB 综合了发布/订阅消息、同步（RPC）和异步消息、基本转换、基于内容的路由以及本机Web 服务支持。此外，ESB 支持众多的应用服务器。ESB 可担当连接应用程序和整个企业中其他服务的共享消息收发层。ESB 最初是由 Gartner 的分析家所定义的，它逐渐被看成是面向服务的基础架构的一个核心组件。 　　基于J2EE 连接器架构 (J2EE CA) 的适配器通常用于集成 ESB 和企业系统。ESB 用智能转换和路由来补充其核心的异步消息收发中心，目的是确保消息的可靠传递。参与 ESB 的服务要么使用 Web 服务消息收发标准，要么使用 JMS。 　　JMS 和 Web 服务之间的一个重要的区别是，JMS 是一个 Java 编程 API，而 Web 服务提供了一个标准的 wire-level 协议（基于 HTTP 的 SOAP）。这说明 JMS 并没有消除与私有消息收发解决方案相关的互操作性问题。每个 JMS 提供者（例如 WebLogic、Sonic 和 Fiorano）都在 JMS 客户和 JMS 服务器之间实现了一个私有协议。因此，JMS 客户和服务器之间没有互操作性，例如，Sonic JMS 服务器只能被 Sonic JMS 客户来访问。 　　ESB 本身并不能为 SOA 提供完整的基础架构。例如，用 ESB 很难或根本不可能来实现应用逻辑、组件、流程流逻辑以及工作流，但是它们可以通过 BEA 平台来迅速实现并提供服务。对于一个地理上不是分布式的企业而言，不需要用 ESB 来实现 SOA。 SOA 和事件驱动的结构（EDA） 　　在企业中，系统会经历状态的改变。事件是由状态改变所触发的，并将与改变有关的数据传递给其他系统或人。 　　业务可以从处理那些由实时系统状态改变而引起的事件中受益。例如，不是去定期检查来决定是否为某仓库再订购货物，而是当货物数量低于临界值时，由仓库管理系统触发一个事件。然后该事件可以向再订购系统发送报警通知。 　　根据 Gartner 的观点，现代的、灵活的企业 IT 的基本架构模式是面向服务的和事件驱动的。 　　事件驱动的架构是设计和创建应用程序的方法，这些应用程序中的事件所触发的消息可以在独立的、非耦合的模块之间传递，这些模型彼此并不知晓对方。事件源通常向含有注册该消息的订阅者的中间件或者消息代理发送消息。由于事件消息是通过消息代理用发布/订阅的方法来传递的，所以一个事件就有可能传递给多个消费者。这是 EDA 和 SOA 的主要不同：在 SOA 中，生产者和消费者有一个一对一的关系，在 EDA 中，基于消息代理所注册的订阅规则，EDA 事件生产者可以最终向任何数量的消费者传递一条消息。 　　高级 EDA 实现必须支持复杂的事件处理，其中多个相关的事件用基于策略的规则积聚在一起，同时触发一个单一的业务事件或者服务。BEA 的商业伙伴 iSpheres 提供了这个功能的一个实现的示例。也可以利用 BEA 平台来自定义构建这一功能。 　　EDA 和 SOA 是两个互补的架构。EDA 源可以是一个 SOA 消费者或者服务器应用程序，而且EDA 消费者也可以是一个 SOA 客户程序。BEA WebLogic Integration 的消息代理、各种事件生成器以及适配器与 BPM 一道完全有能力将基于 EDA 的和基于 SOA 的实现捆绑到一起。 　　SOA 使用的时机是，业务问题需要一个请求/响应或者实时解决方案，同时客户事先知道该服务提供者。EDA 使用的时机是，业务需要单向消息收发，涉及长时间运行的异步流程，同时事件源不需要知道事件接收者是谁。 SOA 的适用性及其缺点 　　SOA 的使用需要额外的设计和开发工作以及基础架构，它可转化为额外的 IT 成本。因此，SOA 并非适用于所有情况。 　　就下面的应用程序而言，SOA 和 Web 服务可能不是推荐的架构： 不需要组件或者应用集成的独立的，非分布式的应用程序；例如，文字处理应用程序不需要基于请求/响应的调用。 有限作用域的或者短命的应用程序；例如，作为临时解决方案而创建的应用程序，本身并不打算为将来的应用程序提供功能性或者重用。 需要单向异步通信的，同时不需要且不希望松散耦合的应用程序。 同构应用程序环境；例如，在一个所有应用程序都是用 J2EE 组件创建而成的环境中。在这种情况下，采用基于 HTTP 的 XML 来实现组件之间的通信并非最佳选择，最好采用 Java 远程方法调用（RMI）。 需要丰富的，基于 GUI 的功能的应用程序；例如，一个含有许多地理数据操纵的地图操作应用程序不适用于基于服务的大数据量交换。 　　这些情况中的大多数不适用于企业应用程序。SOA 是以网络为中心的，所以它需要对服务进行复杂的监控和审核。因为服务重用和共享是 SOA 的主要特点，服务消费者的数量将会很多，这引起了版本控制、变更管理以及测量问题。这些问题所需要的管理基础架构对于一些项目而言可能太过昂贵。 　　SOA 是一个战略性的解决方案，带有大量战术级的应用程序和好处；然而，要完全获得 SOA 的好处，还需要跨越一个门槛。SOA 通常需要对成本和收益进行分析。 　　SOA 能够使应用集成变得轻松自如吗？只需要问一问那些利用 SOA 来将其定制的、商业的以及遗留的应用程序捆绑在一起的管理人员就行了，他们会告诉您的。这种捆绑可以改善任务关键型业务流程。 　　与传统的集成方法相比，SOA 向组织提供了许多优势，即可重用、平台独立的业务服务、基于标准的开发以及为跟上业务发展的速度而迅速变化的能力。 关于作者 　　Rag Ramanathan 目前是 BEA 全球企业咨询小组一名企业设计师，该小组主要为 BEA 顾问、伙伴以及客户开发 SOA 最佳实践指南，并提供 SOA 的业务价值评估。他有 12 多年的行业经历，其中 6 年多的时间在 BEA 的研发部门担任软件工程师和专业服务顾问。联系电邮是：soa@bea.com。 　　原文出处： http://www.fawcette.com/weblogicpro/2004_09/magazine/features/rramanathan/