基于SOA的KDA的研究和实现

摘要：本文针对面向服务架构（SOA）在当前企業应用中存在的问题，对SOA的通信方式和服务编配进行分析与研究，结合事件驱动架构（EDA）的优点，提出使用基于SOA融入EDA事件驱动架构的解决策略，并论述了基于SOA的EDA事件驱动架构的设计和实现。

关键词：面向服务的架构；事件驱动架构；网络服务；通用发现与规范

中图分类号：TP315 文献标识码：A DOI：10.3969/j.issn.1003-6970.2012.07.022

引言

面向服务架构（Service Orientated Architecture，SOA）已普遍作为实现企業IT设施商業价值的有效途径，通过将信息和事务以抽象、基于标准的方法呈现为服务，SOA为基于现有的和新的業务逻辑创建新的業务应用系统提供了基础。SOA能把那些线性的、可预测内容的服务连接起来，但SOA缺乏对动态实时業务做出应答的能力。而用事件驱动架构（Event Driven Architecture，EDA）模式建立起来的系统可对动态实时業务做出有效的处理，它却允许复式、不可预测、异步的事件并行地发生和在一个单一的活动中被触发，并且由于服务可以像事件一样被触发，因此EDA实际上是SOA的一种有效补充。

1.SOA面向服务架构及其存在的不足

如图1所示，核心的業务操作代表了SOA应用模型的成功。数据仓库中的服务显示了哪些潜在客户最有可能更换他们的服务。服务使得插入客户名称、电话号码和其他信息到CRM/呼叫中心应用系统中这些功能的集成变得可能。另外一个服务访问联系人，然后用账单系统处理它。最终，订单流程被调用，它使用服务来调用库存/仓库操作和物流流程来发送新的手机和资费合同给客户。然而问题还是存在的，如果广告很成功，某个品牌的手机销售一空，导致库存不足，而此时该手机的订单又来了，仓库中没有该品牌的手机。手机没有发送给客户，订单处理被悬置并发出送货未完成的警告。但此时已太晚，客户服务代表只能联系客户要延时或定其他型号的手机。这使得客户忠诚度降低或流失客户。这只是企業不能察觉和快速应答瞬息万变的業务和形势的一个例子，显示库存手机短缺的事件被淹没在了众多的其他事件中了，由此说明SOA必须被实时的業务事件所驱动。

1.1SOA的请求/应答通信方式的缺陷

SOA是一个抽象的分布式架构，它对在网络上具有相应安全授权的所有用户或应用系统开放可用。可以被其他系统使用的数据和功能展现为可重用的服务，服务通过标准的格式所描述（WSDL，SOAP，XML）和传输（HTTP，JMS）。基于Webservice的SOA使用典型的消息交换模式请求/应答（request/reply）方式通信。该模式中包括服务和有权访问该服务的消费者。消费者要求获取和给予在特定时间内的信息或处理能力的特别服务。服务和消费者的关系通常是松耦合的，但由于请求/应答的本质，服务和消费者是同步的，这是一种被动的基于需求的结构，这是SOA的缺陷之一。

1.2SOA的服务编配的缺陷

大多数Web service应用系统通常使用服务编配（service orchestration）。服务编配现在是多数SOA工具集和架构的核心能力。服务编配是图形化连接的一些用于自动化系统到系统的信息处理服务。例如，如果業务目标是将客户信息写入CRM系统，这可能要先访问数据仓库获取客户档案信息、账单信息和地址/电话信息，然后写入到CRM系统。这个过程可能需要进行数据转换和使用一些用于处理简单规则。通常这个过程开始于一个事件，它引发一系列请求/应答交互。这是基于事件的，但却是基于明确的过程，事件开始于事先安排好的过程，而不是先确定一系列服务目标，然后基于事实流程开始并运行来实现这些目标。现实中触发编配好的業务流程或调用Web service的業务事件通常是不可预测和不是被请求的，此外一些情况下事件被随机的業务活动触发，这也是当前SOA所面临的问题。

2.基于SOA融入EDA的改进策略

2.1EDA事件驱动架构的特点

EDA事件驱动架构是一种软件构架模式，这种模式更加强调事件的产生、检测、接收和响应等。事件可以定义为“状态的一种重大改变”。例如，当一个消费者买了一辆车后，这辆车的状态就从“待出售”状态变为“已出售”状态。而相应的汽车数据处理系统就会使用EDA框架的应用系统来对这种改变作为一个事件加以检测、声明、和处理。

EDA的框架模式主要体现在一些事件的松耦合的软件组建和服务之间传递及系统的设计和实现中，一个EDA系统的2个典型组成部分就是事件生产者和事件消费者。事件的消费者在一个时间按处理中介上订阅事件，而事件生产者则在上面事件。当事件处理中介收到一个事件生产者的事件时，它会把事件传递给订阅了此事件的消费者，如果此时事件消费者不能接通，事件处理中介会把事件暂存并稍后再次测试向消费者传送。在消息基础系统中，事件的这种处理方式被称为“存储与传送”。

2.2EDA事件驱动架构和SOA的结合

用EDA模式建立起来的系统会对响应进行更加有效的处理，这是因为事件驱动系统的设计主要是为了让那些不可预测的和异步的环境更加正常。由于服务可以像事件一样被触发，因此EDA实际上是SOA的一种有效补充，可以将EDA和SOA结合到复杂的消息交换模式中。

计算机和感应系统能够检测到一个对象或者是条件状态的改变而产生一个可以通过服务或系统传输的事件，事件触发的基础就是事件的产生条件，融入EDA的SOA驱使服务的交互更加互动，而SOA的SOAP的Web service的技术使得和其他异构系统的连接变得很容易（如图2所示），包括SOAP包装的遗留系统、商業现货供应软件（cOTS）、ERP系统和外部系统的网关等。

3.基于sOA的EDA事件驱动架构设计

EDA框架的实现需要用到Web service的技术，也要用到SOA的技术，同时还要引入事件的概念作为一个主线贯穿系统的始终。实际运用中，根据業务功能上的独立性，一个EDA框架可能复杂一些，但是基本的原则和细节都是一

样的。

图3给出了基于SOA的事件驱动架构的设计，一切的动作都从事件发送者开始，所以在流程图的最上层、发源端是事件的产生者。由于EDA实际上是SOA的延伸版本，因此还要继续使用service的内容以便系统能充分发挥其松耦合性的特点。所以在事件的订阅者与事件者之间要通过服务和事件的注册中心来连接。事件的订阅者由于事先并不知道事件者到底会什么事件，因此在订阅的时候它要主动地到“服务注册中心”去调用事件者提供的服务来查看的事件种类，然后根据自己的需要到事件管理中心去订阅。事件者在事件发生的时候会通知事件管理中心，事件管理中心会进一步把这些事件数据传递给事件的订阅者，以便事件订阅者收到这个事件信息后采取相应的动作。

架构设计中各部分的内容如下：

（1）事件者。事件的者内部实际上包含一系列的组件，最基本的是Web service（网络服务），事件的者应该也是一个服务的提供者，EDA本身就是要以service为基础的。事件的者最基本的service需求就是告诉订阅者们这里会发生的事件，也就是它在“事件管理中心”上注册的事件。事件者将此服务在UDDI注册中心，这样订阅者就可以找到这些事件，并选择它们感兴趣的事件。

事件者内部还包括了其他一系列的应用——Web应用和其他应用，这些应用本质上是完成本模块的功能要求，因为作为EDA，事件只是个起因和导线，并不能起到功能性的作用。例如一个B2B的电子商务系统，客户下订单的部分还是要实现下订单的功能的，至于下了订单会触发的事件只是会引起接下来一系列动作的一个导线。在Web应用及其他的这些应用中，甚至包括Web service的使用过程中，这些都是真正的事件源，这些事件源在发生事件后会通知事件管理中心。

（2）UDDI（通用发现与规范）事件注册中心。作为以SOA为基础的系统，UDDI是不可少的一个重要部分，服务的消费者都要通过这里来获得想要的服务。而在EDA框架中，事件的也是以service的形式实现的，不管是事件者事件列表、注册事件到事件管理中心、通知事件管理中心事件的发生，还是订阅者查找事件、订阅事件，甚至在事件管理中心上订阅等，这些都是要通过service来完成的，所以这里的UDDI是必不可少的内容之一，也是对SOA框架的一种继承和延续。

（3）事件管理中心。这是EDA框架中新引进的一块内容，它对事件进行统一管理。在EDA各个模块的开发过程中必须树立起以事件为中心的概念，但到底事件发生后如何去通知订阅者，对于事件数据信息如何去进行管理等这些内容都不应该由事件的发生者去关心，事件的发生者只关心将事件注册到中心并在发生时通知中心就可以了。同样，事件的订阅者也不必去关心事件者如何在事件发生时通知它，这一切都会由事件管理中心去完成。如此设计最主要的原因有2个方面，一是事件的处理过程是一个统一而相似的过程，可以在一个地方统一完成，这样也更容易建立统一的标准。另一方面是为了方便对事件数据信息统一管理，在事件数据化以后就牵扯到事件数据存储分析等一系列问题，而这都由事件管理中心来统一处理。

（4）事件的订阅者。它实际是EDA框架的下游和终端，事件订阅者只需要知道在事件管理中心是如何订阅事件的，以及告诉事件管理中心在事件发生后执行什么样的动作就可以了。所以事件订阅者在对于事件方面做的事情并不是很多。但在图中只是简单地把它作为一个事件订阅者来看待的，而在实际的运用过程中事件的订阅者也是要完成其内部一系列的業务需求的。同时，事件者和事件订阅者的划分只是在一次事件过程中划分，至于实际应用过程中，这2个部分都是交错兼顾的，事件的者同时可能也是事件订阅者，同样，事件订阅者同时也会是事件的者。

4.基于sOA的EDA事件驱动架构的实现及应用

4.1基于SOA的EDA事件驱动架构的实现

系统中最重要的就是UDDI注册中心和事件管理中心的实现，对于UDDI可以使用JUDDI，JUDDI是服务于Web services的UDDI的Java实现开源包。DDI需要有一个地方来存储注册的数据（注册事件表、待发事件表、历史事件表、订阅事件表），因此首先要选择一个关系数据库安装。JUDDI可以使用任何支持ANSI standard SQL关系数据库（例如MySQL，DB2，Sybase等），可以将JUDDI直接部署到Web服务器上，并配置好数据库连接。

事件管理中心在事件管理中心内部，实际上就是事件数据信息的流动管理问题，在事件管理中心内部主要有上述4个数据表，所以在事件管理中就以这4个表为基础设计出了4个实体：注册事件，待发事件，历史事件，订阅事件。如图4所示，事件者在通过eventReg（）方法注册事件后，注册事件实体就会把这些数据保存到注册事件表中并产生一个事件唯一标识返回。同样，事件订阅者在调用方法eventSubscribe（）订阅事件后，订阅事件实体就会把订阅的信息保存在订阅事件表中以保存。

在事件发生后，事件发生者调用publishEvent（）进行，此方法会先去事件订阅实体那里找到订阅了此事件的订阅信息，并调用历史事件主体的eventLog（）把此事件的发生和订阅情况作为日志信息写入到历史事件表中。但是事件订阅主体并不会直接去通知订阅者，而是根据订阅信息调用待发事件实体的makePublishQueuen（）方法生成一个待发序列放入到待发事件表中。至此，一个事件的准备工作已经做完了，publishEvent（）方法可以结束了。

系统有一个后台的进程会循环地去查看待发事件表中有没有待发的信息，如果有，它负责将这一事件给相应的订阅者，这里调用的就是overOne（）方法，通知给订阅者成功与失败或者是迟后通知，这些信息都会补充到事件日志中以便将来对管理中心管理过的事件加以统计分析。

4.2基于SOA的EDA事件驱动架构的应用

对于事件这种新的信息载体格式加以规范，尽管JMS对信息传递己经有了大致的定义，但是毕竟它不是为EDA量身订做的，它只是一种借用的形式，所以这方面的规范还得进一步来完善。像SOA的UDDI一样，对于事件管理中心的服务方式：/订阅，这就要订阅者能够找到订阅的地方，找到一个列表来查找自己感兴趣的事件。当然，像这样的事件标准出来后，自然会开发出像JUDDI这样的组件供大家直接使用。同样，和服务的WSDL一样，如果事件描述信息标准能够尽快出现，事件就能用XML这样通用的、跨平台的语言加以传递和存储。从而才能更加适应时下多种平台的需求，形成一种通用件。

5.结束语

随着随需应变（on-demand）的商業模式发展，在这种模式下，服务供应商必须对来自于外部环境的事件快速做出反应，基于SOA的EDA事件驱动架构提供了一种强大的方式连接起过去彼此孤立的环境，并且驱使服务的交互更加互动，它使得服务之间的通信更加畅通和敏捷，并且加强服务的质量。