各种机构趋向于频繁的改变他们自身的结构。对面向服务和全球化的日益重视加强了这种趋势。结果，世界上大部分的组织都准备好迎接以独立、自治的服务供应商和服务消费者为特点的、以网络为中心的商务结构。现有的部分商业流程将被外包给外部的合作伙伴，同时组织的各个部分和业务单位被转型为服务供应商。这些服务供应商不再仅仅只关注机构的内部，而且同样会在外部市场中寻求一席之地。

　　所有的一切都朝着随需应变(on-demand)的商业模式发展，在这种模式下，服务供应商对来自于外部环境的刺激——事件——做出反应。为了在一个充满竞争的市场中胜出，他们需要一种高层次的自治性，包括能够自由的选择合适的支持系统。分离程度的扩大能够产生出对于敏捷性的需求，当组织的构成不断变化时候，在服务之间的松耦合能够支持业务的连续的、不受阻碍的发展。

　　为了达到“真正的”敏捷性，支撑的应用系统必须做到对于机构的各种改变不可知，这些变化包括变化的责任和角色，外包或者内包，部门的拆分或者加强等等此类的重组。此外，业务流程适应机构变化的敏捷性必须不会受到支持它们的IT系统的限制。所有这些要求都可以用松耦合来满足。降低耦合的服务更容易在不干扰现有IT支持系统连续性的基础上，改造组织的结构。这就是所谓的机构敏捷性的基础。

　　应用搭建上的灵活性可以通过在定义良好的功能边界内使用共享的服务来完成。基于标准的技术对于敏捷性做出贡献，主要是能够解决对应用快速交付市场的担心(只要这些标准已经成熟并且采用了合适的工具)。敏捷性紧紧依赖于为了重新设计商务流程而对应用进行重构增加敏捷性的能力。最终的结果是降低的IT成本和更快的项目交付周期。

　　EDA和SOA都承诺能够增加整个机构层面上的敏捷性，但是两者采用不同的方式来做到。

　　EDA和SOA的关系

　　虽然EDA和SOA拥有共同的目标，我们如何知道何时使用事件驱动或面向服务的方法呢?那么让我们仔细想想在什么情况下，这两者种构架方式是最合适的。

　　和传统的分布式架构不同，EDA并不提倡同步的、命令-控制的消息交换模式。相反，它采用了基于异步的、发布-订阅模式，在这种方式下，发布者完全不知道订阅者的存在，反之亦然。服务的松耦合就意味他们只共享消息的语义。

　　假如你试图做到商业流程中各个步骤之间的独立性，那么EDA可以提供巨大的好处，尤其在联合的、自治的处理环境中。EDA被公认合适处理以下的情况：

　　·流程链中各个层之间的水平通讯
　　·需要跨越公认的功能单位边界的流程(包括内部和外部的边界)
　　·需要跨越物理单位界限的流程

　　然而，当试图利用商务流程中的内聚性的情况下，SOA则可以提供巨大的好处。它可以适用于以下的一些情况：

　　·功能分解之后上下等级之间的垂直交互
　　·功能上属于请求-应答类型的流程，比如人机对话的时候，用户等待应答
　　·具有交易特点的、具有提交及回退性质的流程

　　类似于EDA，SOA被经常通过消息框架来实现，该消息框架同样是利用异步消息模式来实现的请求-应答通讯。通过将请求的发行者和应答的消费者分离，同样将请求的消费者和应答的发行者分离，让系统的松耦合。但是，由于存在着一种普遍的误解，认为采用SOA就意味着使用Web Service所采用的那种(紧耦合的)RPC类型的架构，因此很多SOA实现采用了传统的、根生蒂固的同步交换模式。

　　为了建立一个SOA和EDA和谐共处的环境，有必要进行一些前期的分析。一个具有建设意义的准备步骤如下：

　　1. 为商业需求建立一定粒度级别的功能模型，该粒度级别能够满足预期的自治性
　　2. 勾画出该应用的地形图以便识别出受到影响的系统
　　3. 将应用的地形图映射到对应的商业功能模型
　　4. 鉴别出那些跨越功能边界的应用，它们是潜在的“敏捷性瓶颈”(对于那些需要跨越机构的外部边界的应用请给予较高的优先级)

　　其中第4步是在下面的章节中将会进一步讨论的解耦合服务边界(decoupled service boundaries)的基础。当我们寻找系统中的某些位置，在这些位置上EDA的发布-订阅模式可以作为连接这些边界、同时允许各个边界保持自己解耦合的状态的一种方式的时候，这些跨越边界的通讯正是我们感兴趣。

　　完成这样一个简单的流程，可以为引入一定程度的松耦合奠定基础，同时确定一个好的开始点，将这张技术地形图改进成兼俱SOA和EDA优点的、现代的、灵活的、可适应的环境。

　　松耦合和“解耦合点”

　　松耦合意味着独立。简单的说，松耦合的服务对彼此的依赖要比紧耦合的服务小。这个规则同样适合于功能和数据。当某个服务相关的数据被仅仅局限在该服务的功能边界内的时候，服务之间的耦合度就会增加(拉紧)。这种设计方法会增加服务之间为了访问被孤立的数据而形成对彼此依赖的概率。当以数据复制、避免保证数据传输和语义一致性的共享层之外的其他层共享等机制实现的数据冗余被允许的情况下，服务之间的耦合程度会降低(松开)。

　　保证跨越解耦合边界的数据冗余让松耦合更加强健。EDA适合这种情况，由于它支持在冗余环境中的数据的自动一致性。

　　当使用SOA和EDA的时候，找到“解耦合点”通常被证明很多帮助。这是通过寻找某些经常同时出现的商业流程部分，这些部分你可以确认它们会一起出现在任何一个组织单位中(具有强烈的内聚性和原子类型的业务功能)。它们就是“解耦合点”。这样，商业流程的功能构成会变得清楚。在各个业务功能之间的边界就是解耦合点。如果原子交易跨越了解耦合边界，那么回滚交易就需要在这些解耦合点实现。

　　图1：如何安排事件来跨越解耦合服务的边界

　　图1阐明了SOA和EDA之间一种可能的关系。在顶上的圆圈表示连接单个松耦合系统的解耦合点(事件)。无论在这些解耦合点上的服务是连接还是断开，都不会影响被连接的系统。不同域之间的所有的数据交换都发生在这些点，而不是在底下的层次。

　　在一个可重用的域(在图1位于底层)中，EDA的粒度可以进一步精细。EDA的粒度越精细，系统的灵活性也就好，尽管可重用的域也就越小。

　　假如在解耦合点使用基于SOAP的Web Service的技术，同时结合通用的基础架构(例如企业服务总线，enterprise service bus)，那么和其他异构系统系统的连接将会变得很容易，包括SOAP包装的遗留系统，商业现货供应软件(COTS)，ERP系统和外部系统的网关等(如图2所示)。

　　图2：服务不再被直接耦合，而是通过由事件表示的解耦合点来连接

　　当谈到EDA和SOA，为了松耦合而奋斗——也可以说是为了灵活性和敏捷性——从所有的粒度级别来讲，都不失为一个好主意。当然，松耦合必须在现实的条件下慢慢实现，尤其是考虑到运行效率的时候。

　　ESB的注意事项和全局数据空间

　　如今使用Web Service技术实现EDA的时候，需要一个额外的、能够处理SOAP的消息队列基础框架。之所以需要这个消息队列并不是由于SOA实现是通过Web Service的原因，考虑到最本质的SOA只需要在已有的网络基础(比如HTTP层)上通过Web Service就可以实现。

　　当前的企业服务总线(ESB)构架提供了一种可以将消息队列和Web Service技术结合起来的途径。这就是为什么ESB非常合适于各种基于EDA和SOA的解决方案的原因。

　　另外还需要关注目前出现的几个和EDA和SOA都相关的关键的Web Service标准。其中最有希望被通过的标准包括WS-Eventing, WS-Notification, WS-MetadataExchange, WS-ReliableMessaging, WS-Security和 WS-CDL。一旦它们得到广泛的支持，并且和其他刚刚出现的能够处理SOAP的基础组件相结合，那么自然，它们会提供很多ESB的功能，目前来说这些功能只能由ESB的供应商的产品提供。

　　从EDA的角度来说，ESB非常适合用作容纳已发布的商业事件的容器，因为它允许让这些事件被广泛的用于订阅。结果，ESB可以被放入到整个企业的全局数据空间中，让所有的应用都能够一致的访问到事件信息，无论它们的位置，时间和后端使用技术(图3演示了这一情况)。

　　图3：利用ESB实现的全局数据空间

　　ESB不必依赖于某家公司的产品。在一个联合公司当中，多条服务总线产品可以结合起来提供ESB的服务，这就允许区域的自治。图4就演示了一个企业范围内的服务总线是如何通过运行多个域而成为整个组织的全局数据空间。使用Web Service的技术能够让跨越多个供应商产品的消息传播变得容易实现。

　　图4：通过组合ESB形成的联合ESB结构

　　BPEL的注意事项

　　同样，研究如何在商务流程管理(BPM)和商务流程处理语言(BPEL)的环境中实现SOA和EDA也是非常重要的。目前阶段下，BPEL的实现都是集中在命令-控制模型上——基本上服务的控制和组合都是通过类似面向过程的语法来定义的，这需要一个BPEL的执行引擎。

　　BPEL的使用不会对SOA造成任何的问题，因为它可以构建出一个服务组合的父层次，这个父层次完全抽象了商务流程逻辑。当然，任何一个商务流程并不限于这个层，因为BPEL允许一个流程可以使用服务来进一步封装，或者由其他的服务流程组合而成。

　　但是，BPEL并不是为EDA量身而造的。从本质来说，更加适合EDA的模型应该是声明性的，而非过程性的。这个模型可以让设计者通过点击的机制就可以将事件和发布者和订阅者联系起来。执行环境的实现应该独立于控制引擎，同时基于上面谈到的Web Service标准。即使一些平台正在朝着这个目标发展，但是目前我们还需要依赖于JMS的SOAP或者其他由ESB产品所提供的基于SOAP替代方案来实现。

　　结合EDA和SOA

　　将SOA和EDA结合过程中最大的挑战在于改变方案设计者们的思想。一些和EDA相关的新的理念，比如有目的的数据冗余和显式的使用事件，只有在被充分的理解之后，才可能被恰当的使用。

　　比如，发布-订阅模式背后的动态性以及它与请求-应答模式之间的对立性，都需要被服务设计者和软件构架师理解清楚。只有这样，他们才能够在整体架构中寻找到机会，将EDA和SOA结合到复杂的消息交换模式中。这可能没有说起来那么容易，因为对于决大部分项目组来说，异步消息并不是一个被广泛接受的设计方式。

　　虽然发布-订阅模式并不是新创造的，但是对于那些只通过调用堆栈的方式思考问题的人来说，它还是相当陌生的。让我们据个例子，将记录写到批处理文件或数据库中，类似于发布消息。从文件中读取记录则类似于消费了订阅的主题。这些都是异步设计的实例。

　　结论

　　商业的事件机制提供了一种强大的方式连接起过去彼此孤立的环境，并且驱使服务的交互更加互动。如果EDA所代表的消息模式能够得到被清楚的认识的话，EDA的所提供的功能可以被更加有效的利用。如果事件驱动的设计方法被得到合理的使用，它将使得服务之间的通讯更加畅通，并且加强服务的质量。