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的所提供的功能可以被更加有效的利用。如果事件驱动的设计方法被得到合理的使用，它将使得服务之间的通讯更加畅通，并且加强服务的质量。

查看本文国际来源