（计算机应用技术专业论文）面向soa的事件信息组件.pdf

- v - 面向 soa 的事件信息组件 摘 要 面向 soa 的事件信息组件 摘 要 面向服务架构(soa)已被广大企业所接受，为其提供有效的 it 解决方案，使企业能够对市场做出快速反应。现有的 soa 平台多是 以 web 服务为基础，建立在企业服务总线(esb)上的一种技术实现。 但其缺少语义表达能力，在协同工作、服务组合编排、个性化定制和 智能化建模上都无法满足灵活快速的要求。 将事件驱动架构(eda)整合到 soa 中，为在现有 soa 上实现协同 工作提供了架构性解决方案。eda 主要特性是一种异步消息的通知机 制，补充了 web 服务的 rpc 同步调用方式，使 soa 中的构件更加满足 松耦合要求。另外，事件可以作为 soa 中通信消息的语义载体，其所 携带的信息，将会被用来进行智能化处理。事件驱动架构的松耦合特 性，使其能与 soa 完全整合，达到互相补充的目的。 本文提出的面向 soa 的事件信息组件，采用了 eda 架构，是一 个事件信息全局感知的应用实现。 事件信息组件以事件引擎为中心展 开工作，各个模块部署于不同的节点，呈现了松耦合的结构，其最终 目标是整合到 soa 平台。 为了达到系统信息的全局感知，信息组件收集来自 web 服务容 器的信息，经过复杂事件处理，最后将处理后的信息发送给相应的订 阅者。 - vi - 事件的复杂处理由一个事件引擎完成， 其工作是将简单事件组合 成复杂事件。通过对简单事件数据的整理，更有价值的信息将会被放 入复杂事件之中。 事件信息组件对事件的核心元数据进行了抽象和整 理，组建了一个元数据层，用于事件引擎的配置。通过这个事件元数 据层，外部构件能够对事件定义、事件模式、事件生成规则等进行控 制。这为事件信息组件与 web 语义控件的整合提供了基础。 最后，本文给出了关于事件元数据的文档设计方案、事件信息组 件的整体设计和实现， 并且给出了案例来帮助理解事件信息组件的实 际运用。 关键字关键字：soa，事件驱动架构，复杂事件处理，事件元数据，web 服务，协同感知 - vii - abstract soa (service oriented architecture) has been widely accepted to provide the enterprise it solution and help them rapidly response to the market. the most implementation of the soa platform is based on the web service and esb (enterprise service bus). but in the recent, the lack of semantic in web service makes many difficulties in the service collaboration, composition, orchestration, customization and intelligence automation. in order to provide an institutional solution to facilitate the collaborative work based on soa, the eda (event-driven-architecture) has been integrated into the soa. eda uses the asynchronous message notification model, which is opposed to the web service prc sychronouse invocation and makes the soa component more loose-coupling. in the other hand, the events can take the semantical data of the message which will be processed for the intelligence. eda is loose-coupling as well as soa. it will not replace the soa rather improve it. the soa based event infrastructure adopts the eda and provides the global awareness of the web service invocation. the event infrastructure is loose-coupling and each component will be deployed in the different nodes. its final goal is integration into the soa platform. - viii - in order to achieve the global awareness, the event infrastructure collects the data from the web service container and sends it to the cep (complex event engine) engine to process. finally, the subscriber will obtain the more powerful information from the complex event. the cep technology attributes to composite the simple events to the complex event. through this process, more powerful information will be put in the complex event. the core event meta-data of cep will be abstracted and analyzed. the event infrastructure controls the event engine through an event meta-data layer. this layer provides the capability of extension in the event semantic and makes it possible to distributedly collect the event date. in this thesis, the design of the event meta-data will be described, and the design and implementation of the event infrastructure will be presented. in the end, a study case will be given in order to understand the using of this event infrastructure. key words: soa，event-driven-architecture (eda)，complex event process (cep)，event meta-data，web service，collaborative awareness - iii - 学位论文原创性声明学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师的指导下， 独立进行研究工作所取得的成果。 除文中已经注明引用的内容外， 本论文不包含任何其它个人或集体已经发表或撰写过的作品成 果。对本文的研究做出重要贡献的个人和集体，均已在文中以明 确方式标明。本人完全意识到本声明的法律结果由本人承担。 学位论文作者签名：刘思中 日期： 2007 年 9 月 21 日 - iv - 学位论文版权使用授权书学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规 定，同意学校保留并向国家有关部门或机构送交论文的复印件和 电子版，允许论文被查阅和借阅。本人授权上海交通大学可以将 本学位论文的全部或部分内容编入有关数据库进行检索，可以采 用影印、缩印或扫描等复制手段保存和汇编本学位论文。 保密保密，在 年解密后适用本授权书。 本学位论文属于 不保密 不保密。 （请在以上方框内打“” ） 学位论文作者签名：刘思中 指导教师签名：曹健 日期： 2007 年 9 月 21 日 日期：2007 年 9 月 21 日 - 1 - 第一章第一章 引言引言 1.1 课题目的和意义 随着异常激烈的竞争和多变的客户需求带来的巨大挑战，协同工作得 以成为一个企业专业的信息化应用领域。全球化趋势使得企业必须与其他 企业协同工作，才能在市场上发挥竞争优势。互联网的发展使协同工作方 式进一步发生着巨大变化，客户分散、上下游业务伙伴关系紧密，还要面 对结构动态松散耦合、地理位置分散的挑战。 如同达尔文所说，最终能够生存下来的并不是最强最优的，而是适应 环境变化最快的物种。激烈的市场竞争要求现代企业具有良好的敏捷性， 以便根据市场、商机、合作环境的变化快速做出业务调整。同时，时间、 质量、成本永远是企业所要考虑的三大要素。soa 作为一种面向服务的 it 架构，主要通过复用性、灵活性和共享性从技术上满足企业的需求1。从 soa 提出至今，已被多数需求引导企业广泛认可采用。国内外大型企业都 试图将 soa 架构引入其原有系统，由此和合作伙伴组成虚拟组织，以形 成在专业领域中具有竞争优势的价值链。 现在市场上已有许多成熟的 soa 产品，如 ibm 的 websphere，bea 的 weblogic，microsoft 的 biztalk 等产品，soa 已经度过了由理念转向 实践的第一步。可是，现有 soa 中所包含的缺陷也暴露了出来，要完全 满足动态业务协同的需求，依旧还有许多有待解决的问题2。其主要表现 在：web 服务缺乏自主性和相互协同的能力；web 服务缺乏语义表达的能 力；服务过程模型不能满足动态业务环境要求；支持用户进行个性化协同 业务开发的能力不足等。 其问题的核心是， 现有的 soa 着重于下层的 web 服务的开发、定义和运转，而面对 soa 各构件的协同工作，缺乏对服务 动态的、可扩展的组合编排能力。 例如，关于服务的组合，现有的 soa 多数采用 bpml 和 bpel4ws 技术。bpel4ws 技术是以一种中心协调者的方式运作，由于不是基于语 义表述，其部署起来非常硬性，不能满足 soa 动态敏捷的需求。 为了解决这些问题， 许多学者提出了针对性的方案。 例如， 通过 owl-s 扩展 web 服务的语义表达能力3；引入 agent 来进行服务匹配、选择和 - 2 - 复合2；通过在运行时为各个活动动态选择服务的服务过程，提高过程模 型的适应性；利用人工智能和规划的方法进行自动服务复合等等。但这些 个案，都是针对 web 服务智能发现、发布、搜索、组合和编排的技术，没 有指出如何将这些技术引入现有的 soa 实现。 有学者曾经提出，将协同系统中的其他技术引入到 soa 中，以解决 上述问题。因为 soa 的最终目标就是使企业针对外部变化做出快速反应， 这种外部变化体现在全球化产业链的协同活动之中。计算机支持的协同工 作技术(cscw)有三个基本要素：通信、合作和协调，soa 作为一种底层 的通信技术，首先必须有效地支持 cscw 的工作。而在 soa 发展过程中 所遇到的问题，包括 web 服务的智能组合、编排等，都是与协同技术领域 密不可分的。协同感知作为 cscw 核心技术之一，其事件机制为感知系统 各个活动的进展、各种信息和环境的变化提供了理论和技术保障。 在此思想的指引下，将 eda 与 soa 结合的技术思潮孕育而生。事件 驱动构架(event driven architecture, eda)被用来发现系统或者周围环境之 中所发生的特殊性事件4，并且快速的发布通知给对此事件感兴趣的订阅 方（可以是操作人或者智能组件），以使订阅方能够快速地做出反应。 eda 是专门为分布式系统所定制，由此采取一种非常松耦合的结构。 事件源仅仅感知基本事件的发生，并且负责传送这些事件信息，而无须关 心事件的订阅方以及事件的后续处理。因此 eda 非常适合异步工作信息 流的处理，与 soa 有天然的兼容性和互补性。 在企业环境中，感知各个活动的进展，各种信息和环境的变化，是实 现快速决策和行动的基础5。为了形成有效的协同感知环境，需要采集各 种事件信息。soa 环境为统一采集各种信息奠定了技术基础，然而，由于 管理资源众多，事件数量非常庞大，eda 必须提供有效的机制来进行事件 的抽象和过虑。 在 soa 框架下，将 eda 技术用作协同感知，此类研究在国内外都还 处于起步阶段。本文就试图设计并实现一个事件信息组件，将 eda 引入 soa 服务平台。其中，web 服务的调用本身作为一个事件源，而信息订阅 方则是 soa 中的其他构件。这些构件根据所获取的 web 服务调用信息， 执行其内部定义的逻辑，这为 soa 智能化管理打下基础。 - 3 - 1.2 本文研究内容 本文描述的事件信息组件采用事件驱动架构，在 soa 环境下，收集 web 服务调用时所产生的基本信息，并把处理后的信息发布给订阅方。部 署于 soa 中的各个构件，根据收到的事件的内容，得知协同系统中的全 局信息，根据各自的协同协议做出反应，以完成协同工作。 图 1.1 是此事件信息组件的部署和结构图。 当分布在 soa 各个节点的 web 服务被调用时，调用信息将被发送给事件捕捉器。事件捕捉器将所得 到的信息，生成简单事件放入到事件通道之中。事件引擎从事件通道中以 流的形式获得简单事件，根据事先定义的模式匹配条件，激发处理行为。 当发现有被订阅的复杂事件时，处理行为便会将复杂事件发布给订阅代 理，由订阅代理负责发送给相应的订阅者。 图 1.1 事件信息组件 figure 1.1 the event infrastructure 在我们的系统模型中，事件源是 soa 环境中各个 web 服务容器。为 了在每次 web 服务被调用时，发送调用信息给事件捕捉器，每个 web 容 - 4 - 器都须植入相应的代码。 事件捕捉器的功能是根据从其他 web 服务容器处 得到的信息生成格式统一的简单事件，并将其放入到事件通道之中。事件 捕捉器本身是一个 web 服务，其提供统一的接口供其他 web 服务容器调 用。 事件通道通常是一个消息传递网络，在事件源和事件处理引擎之间传 递着格式标准化的事件消息。因为考虑到 soa 平台多样性，以及其最主 要的实现方式为企业服务总线（esb），本文描述的事件感知模型采用消 息中间件来实现事件通道。其主要功能是使事件处理引擎分离于部署事件 捕捉器的 web 服务容器，使事件处理成为一个独立的模块。 事件处理是事件驱动架构的核心，也是协同感知中信息管理的实现。 它将搜集到的基本信息进行处理，以得到更有价值的或为用户所感兴趣的 信息。为了完成这一功能，必须使用一个复杂事件处理引擎。第二章将介 绍复杂事件处理引擎的基本工作原理。 事件感知模型中的下游事件驱动活动主要是将得到的复杂事件信息 发送给各个订阅者。订阅代理从订阅模型中获取与复杂事件相符的订阅者 名单， 并且订阅者必须实现某个接口， 以接收订阅代理发送来的复杂事件。 在 esb 方式的 soa 实现中，一个订阅适配器可以接受复杂事件，然后转 换为相应的消息，发送到服务总线上，以通知其他 soa 构件。 1.3 论文各部分主要内容 第一章 引言 本章简要介绍了 soa 发展现状以及遇到的问题，说明了将事件驱动 机制（eda）引入 soa 管理平台的重要性和意义。在此基础上，本文提 出了一个事件信息组件原型模型，为 soa 平台上的协同工作提供了支持。 第二章 相关技术 本章概述了文中所涉及的 soa 的基本概念， 介绍了 eda 的整体结构、 运作原理、各个组成部分以及其与 soa 的相关联系，着重展示了 eda 的 核心复杂事件处理技术及其运用。 第三章 相关组件的研究 本章针对所提出的原型系统实现，研究各个相应的组件规范。在事件 源方面，axis 作为 web 服务的装载容器，必须有加载捕捉基本事件的能 力。事件通道的实现，openjms 作为一个通用性强、被广泛使用的消息中 - 5 - 间件而被采用。复杂事件处理使用 esper 事件引擎，关于 esper 引擎的规 范也必须得到整理，需要特别对和事件有关的元数据进行研究。 第四章 事件信息组件的设计与原型实现 本章阐述了事件信息组件实现的基本框架设计，特别是针对 esper 事 件引擎，提出了以 xml 文件存储事件元数据，并用此元数据配置事件引 擎的方法。这种框架的主要优点是，不仅事件元数据是可扩展、可配置的， 同时也使整个事件信息组件设计趋于松耦合，组件本身也呈现一种可扩展 的结构，为事件信息组件进行分布式部署提供了条件。 第五章 事件信息组件的整合与案例验证 本章介绍了基于案例的 soa 事件信息组件的具体运用，包括事件元 数据的定义和管理。在案例描述的 soa 环境下，web 服务被调用后，定 义的事件将被送往相应的订阅者处。根据事件信息，soa 构件完成协同任 务。 第六章 结论与展望 本章介绍了本实验室开发的 soa 事件信息组件中所取得的事件技术 研究成果，以及其在相关领域中的其他技术。最后，将会介绍事件信息组 件的下一步设计改进以及在整个 soa 环境中部署计划。 - 6 - 第二章第二章 相关技术相关技术 2.1 soa简介 面向服务架构（soa）自 2000 年之后，受到越来越多大型企业的关注 和追捧，成为企业 it 处理领域中一个具有特殊地位的角色。 企业界之所以如此青睐 soa，有个重要原因就是在过去的数十年 间，大型企业在 it 领域逐渐累积了大量各式各样的软件应用。这些应用 往往随着 it 技术的变迁，使用不同的语言开发，运行在不同的平台，并 且还可能经过数次不同目的的结构性修整，由此加大了对这些应用调用的 难度。 而反观今天的 it 技术，网络技术渗透到世界的各个角落，连接起了各 色的信息。商业领域的外部项目，供应链与销售链的协同工作和不断增加 的竞争压力， 使得企业加速了信息数据的交换， 以换取更有效的产品生产。 然而，前述的大量遗留软件应用以及其带来的高额接口制造花费，大大阻 碍了这种要求高效的信息交流。 正是在这种背景下 soa 孕育而生。相对于其他的软件架构，它能够非 常简单有效地使企业在技术层面做出快速反应，保证信息交换的安全性与 正确性。 2.1.1 soa 定义定义 关于软件架构的定义，在各种文献中有不同的定义。例如，“软件架 构是对于系统构件的横向和纵向结构的整理，以及构件关系的描述”8， “软件架构是一个软件系统的结构，描述了其中各个构件、构件的对外属 性以及构件之间的关系”。9从中可以看到，软件架构最重要的定义核心 是构件结构、构件属性以及构件之间的关系。 软件架构的选择在软件开发过程中扮演了至关重要的角色。它决定了 软件的可修改性、可管理型、可靠性以及运行性能。一个不出色的软件架 构，可能导致在之后的开发过程中大量的金钱花费和时间开销。 面向服务架构的核心是对于服务的使用，以满足开发者对于软件结构 - 7 - 不断增加的要求。按照之前对于软件架构的定义，面向服务架构可以由以 下几个关键构件组成： 1) 前端应用 这里主要指服务的调用者，可以类比于客户端-服务器架构中的客户 端。 2) 服务 服务是 soa 的核心，其表示了一组封装好了的应用逻辑，提供对外规 范一致的接口，能够互相通讯，并且互相关联。 3) 服务供应平台 服务供应平台保障了服务之间的通讯通道，提供了服务调用的底层技 术保障。严格地说，它是 soa 中的一层，可能由多个构件组成，例如企 业服务总线(esb)、服务仓库等。 4) 服务管理平台 管理平台构建在供应平台之上，在基本 soa 中，并没有被明确定义。 但是随着服务数量的快速增加、对于服务质量要求的提高，管理平台成为 soa 初期部署之后，下一个最急需解决的技术问题。关于 soa 服务管理 平台的现有设计模型，将在 2.1.5 节介绍。 2.1.2 服务的核心概念与特征服务的核心概念与特征 soa 中，服务被定义为：“一个封装的无状态的功能，它能够接受来 自于前端或者其他服务的请求，并返回一个或多个回应。其中，请求和回 应的形式应该以某种形式定义。”31由此，我们可以总结出，服务的定 义由以下几点核心内容： 1) 服务是封装的逻辑 服务作为一个个体概念，需要保持其独立性。服务是针对某一业务任 务、业务实体或一些其他逻辑或大或小的逻辑功能所进行的封装，同时服 务可以代表的语义范围和颗粒度也是可变的。其中，粗颗粒度的服务逻辑 往往包含其他服务提供的逻辑。对于封装逻辑的服务而言，他们可以参与 各个级别的企业业务活动。在一种清晰的关系下，这些服务被其使用者所 调用。 2) 服务是交互的 在 soa 内，服务可以用于其他服务或程序。作为调用服务的基础，服 - 8 - 务之间必须通过特定的服务合同（服务描述）相互知晓，并且达成理解上 的一致。 最基本的服务合同描述了服务的名称和服务的位置，以及要求交互的 数据。服务用服务描述的方式导致了松散耦合的分类关系。 3) 服务有特定的通信方式 服务为了相互作用并完成一些有意义的任务而必须交互信息。因此需 要一个可以保留其松散耦合关系的通信框架。在这个框架下，服务进行消 息传递。 服务以自己的方式发送一个消息后，他对消息此后发生的一切都将失 去控制。这意味着，消息和服务一样有自治性其中要具备足够的智能 以自控其处理逻辑部分。在现有的实现中，服务通信采用和过去分布式系 统类似的架构，即由消息和处理其逻辑的接口所构成。 以上定义，总结了服务的三个核心概念：设计实现、描述和消息。服 务将其控制的逻辑进行封装，对外遵循一个通信协议，只保持了最少服务 特定信息的接口。使其即维护了最小的依赖关系，又能够反复地被使用， 以形成组合服务。正是这三点，决定了 soa 的总体特征：松散耦合、复 用性强、灵活度高。 1) 松耦合性 构建松耦合服务的技术架构的最大优势在于他所形成的服务逻辑的独 立性和自主性。服务只是在其接口上互相知晓，而在内部却是独立发展。 这给企业带来的好处主要体现在，使得业务建模和技术设计分离。其影响 已远远超出于技术领域，而是将整个企业部门职能划分的更为清晰，减少 了部门间的互相干扰，提高了整体的运行效率。 2) 组织敏捷性 松耦合带来的是企业各单元的快速应变能力的提高。企业组织适应变 化的能力决定了其应对突发事件的效率。组织业务逻辑的变化会影响其底 层基本的技术实现，而反之，底层技术基础的变化同样会影响使用其的上 层业务逻辑。企业的这两部分之间存在的依赖越多，变化导致的消耗和代 价就越大。soa 通过标准化接口使其依赖最小化，并增强对变化的整体反 应力。 3) 复用性 服务间使用统一接口互相交互调用，使得企业 it 组件呈现高度的复用 性。其表现为：对于根植于不同平台、采用不同技术开发的企业遗留应用， - 9 - 不需要重新开发就能被再次使用；对于企业没有能力开发完成的功能，可 以以最小的代价“外包”第三方的应用，但同时又不存在强依赖关系；在 面向服务设计的指导下，企业将来的应用开发也将遵循高复用性标准。这 些都将直接地减少企业成本，避免发重复性的工作。 2.1.3 web 服务的定义和技术体系服务的定义和技术体系 web 服务是由 uri 标识的软件系统，w3c 对 web 服务的定义是：由 uri 标识的软件应用，其接口和绑定可以用 xml 来定义和描述并且可以 被发现， 与其他软件通过基于 internet 的协议以 xml 消息交换的方式直接 交互32。 web 服务作为一种特殊的服务实现继承了服务的自治性、开放性、自 描述性和实现无关性，同时 web 服务是通过 internet 实现远程访问的。理 论上将，soa 只是一种软件结构风格，以服务为中心，其中的服务并没有 特指是 web 服务。然而由于 internet 网络的迅速发展，web 服务实际已成 为 soa 所采用的主要技术，并且因其自身的特点而影响着 soa 的发展。 图 2.1 web 服务技术体系结构 figure 2.1 web service technologies 由定义可以看出，web 服务主要包含了三项核心技术： （1）通信：web 服务之间的通信是通过互相传递符合 soap 协议的 xml 消息实现的，其包含一个真正的数据负载，和一个附件任意控制信息 的头信息。 （2）描述：web 服务的接口和绑定由 wsdl 来描述和定义，其中定 - 10 - 义了 web 服务的功能以及其访问方式； （3）发布和发现：web 服务消费者可以通过中介发现 web 服务，而 web 服务的元信息要发布到中介上，uddi 是目前主流的 web 服务注册中 心规范。 web 服务技术体系的最下层的传输协议是被 internet 或者其他分布式 计算平台广泛使用的标准， 这表明 web 服务技术可以构架在多种分布式平 台之上。其上的部分，包括 soap、wsdl 和 uddi，构成了 web 服务的 核心技术规范，其他规范是在它们的基础上扩展形成的。消息扩展规范的 主要作用是提供服务实例寻址以及在消息层提供可靠、安全、事务等质量 保证。最上层是服务组合规范和服务协作规范。服务组合规范提供了一种 服务编程语言，用该语言可以组合基本服务形成支持业务过程的复合服 务。服务协作规范提供了定义服务之间协作协议的语言。另外，安全和管 理规范也是 web 服务技术不可或缺的重要部分，它们是所有层次都需要 的。 2.1.4 soa 管理平台和管理平台和 esb 图 2.2 soa 平台结构 figure 2.2 soa platform architecture - 11 - 如在引言中所述，soap、wsdl 和 uddi 作为支持 web 服务的三大 协议，已经被广泛的接纳并付诸于实施现有的 soa 部署。但是随着 web 服务规模的增加，仅仅依靠以上三个协议已经不能满足 soa 所提出的松 耦合、复用性和敏捷性承诺。 soa 的第二次部署的核心，是构建 soa 管理平台，能够支持 soa 的 有效管理，实现和上层业务逻辑的无缝连接。目前，有许多关于 web 服务 管理平台的技术已被提出，如一系列的 web 消息扩展、支持 web 组合的 bpel4ws、 用于安全的 ws-security 以及关于 web 语义服务的 owl-s 等。 虽然，有些规范还属于不成熟阶段，只在小规模的实践中被运用，可是对 于 soa 管理平台的层级结构已经逐渐清晰起来。 如图 2.2 显示了现有 soa 管理平台的层次结构。 在原有的 web 服务标准之上，是 web 服务组合层，主要用于服务的组 合。服务组合指的是以特定方式(服务组合语言)，按给定的应用逻辑将若 干服务组织成为一个逻辑整体的方法、过程和技术。主要表现为，将较为 底层的成员服务组织成复杂的复合服务。 服务协作与服务组合有相似处，但是较服务组合有更高的要求。服务 组合，是由一个中心者进行协调，将简单服务组合成复杂服务。而服务协 作并没有一个中心协调者，所有的服务都是以对等的方式互相协作，服务 与服务之间是弱依赖关系。 之所以要将服务协作与组合加以区分，因为协作较组合更为松耦合， 可以表达的语义更强，也更加灵活。针对业务逻辑而言，需要的是较为高 层的复杂服务接口描述，而底层业务实现是透明的。服务协作能够更好的 为业务逻辑所使用。 这里值得一提的是企业服务总线(enterprise service bus, esb)。虽然， web 服务技术结构中，并没有明确定义其实现的具体结构方式，但是 esb 已经被多数 soa 生产厂商所接受和使用，例如 bea aqualogic service bus，ibm sibus 等。这主要是因为，作为一个理想的 soa 架构平台，应 该有无限的服务扩展性，任何新的服务都能以插件的方式加入此 soa 架 构平台，马上对外发布。esb 作为一个 soa 实现平台标准，能够在所管 理的服务之间实现消息路由、在服务请求者和服务提供者之间实现传输协 议的转换及消息的转换，且总线式的结构满足了 web 服务快速部署的要 求。 - 12 - 2.1.5 soa 和和 web 服务的不足服务的不足 尽管 soa 提供了良好的技术手段，但是要完全满足动态业务协同的需 求，依旧还有许多需要深入研究和扩展的地方2，例如： 1）web 服务缺乏语义表达的能力，查询和集成服务以构造各种协同业 务应用依旧需要人工去做不少的开发工作； 2）web 服务缺乏自主性和相互协同的能力： web 服务只能被外界调 用，无法依据各种变化主动发出通知或者请求；web 服务之间无法直接协 同，而必须通过流程方式进行组合，从而影响了服务系统的响应能力和柔 性； 3）服务过程模型不能满足动态业务环境要求：通过流程定义语言如 bpel4ws，bpml 等将服务聚合在一起，作为一个复合服务提供给用户 是实现协同业务应用开发的有效手段，也是 web 服务的一大优点。然而， 现代企业环境中， 支持 ad-hoc 过程和动态过程模型对一个成功的企业而言 是必不可少的，目前的服务流程在这一方面是不够的； 4）支持用户进行个性化协同业务开发的能力不足：单个服务的业务逻 辑封装在代码中，无法提供个性化业务定制能力；复合服务通过依附在服 务之间逻辑流上的控制条件在各个实例运行时可以表现出某些区别，但是 这种区别非常有限，也称不上可以支持个性化业务开发，目前缺乏方便而 有效的支持用户直接进行协同业务应用开发的机制。 上述不足不仅仅影响协同管理平台的开发，也制约着该技术在其它领 域的应用。其核心问题是：缺乏数据、过程和消息语义描述的 soa 无法 满足灵活和动态的要求。服务组合基本还是基于 wsdl，但其并不提供足 够的语义描述，自动处理的能力也大大受限。因此，学术界和工业界目前 正在开展大量的研究工作，以增强 web 服务的功能：例如，通过 owl-s 扩展 web 服务的语义表达能力； 引入 agent 来进行服务匹配、 选择和复合； 通过在运行时为各个活动动态选择服务的服务过程，提高过程模型的适应 性； 利用人工智能和规划的方法进行自动服务复合等等。 随着研究的深入， 业界逐渐将目光转移到了事件驱动架构(eda)上，试图将 soa 与 eda 整 合以获得最为有效的解决方案10。 - 13 - 2.2 事件驱动架构 事件驱动源于硬件领域，已有几十年的历史，远远早于软件设计。事 件概念与现实模型吻合，易于理解，也容易应用于建模。软件的发展史远 不如硬件，对于将事件模型应用于软件开发，在一些软硬件相交的 it 领 域最早出现，例如在协同感知领域，出现了关于在软件开发中的事件基本 模型。 2.2.1 协同感知协同感知 协 同 感 知 (collaborative awareness, ca) 是 计 算 机 辅 助 协 同 工 作 (computer support collaborative work, cscw) 中的重要研究对象之一。 协 同感知的目标是提高系统和用户的合作能力，并使其在协同系统中的交互 更流畅高效。它帮助协同系统各个组件之间分享有价值的信息、了解环境 的变化或者交换其自身做出的行为信息，以做出及时的反应。1992 年， cscw 学者 dourish 和 bellotti 引入了协同感知的概念：“行为者提供关 于行为的场景信息，而其他人根据此信息理解行为者的行为。”11 在现有的协同感知研究中，主要围绕三个重要部分：协同感知的信息 源、协同感知信息管理以及协同感知的信息效果表示。感知信息源往往关 系到如何在协同系统中集成实现协同感知，而信息效果表示一般涉及协同 感知给协同系统所提供的接口技术。 协同感知的接口技术影响着如何显示协同信息的效果，如可以用显示 屏展示给用户、用声音通知用户或者传递基于元信息的消息给系统其他组 件。协同感知信息的显示要求将信息压缩，用尽可能小的显示资源得到尽 可能大范围的信息。 协同感知信息管理（ca information management, caim）是协同感知 的核心， 它大大帮助提高了协同感知的效率， 避免了不必要的 “信息骚扰” 。 它使用户只需要了解自己感兴趣、有切实关联的信息，这提高了系统的协 调性、减少了协同工作中的失误率、也减少了实际的通信量减轻了网络带 宽的负荷。特别像是在网格运算中，数据的传输将成为一大瓶颈，caim 对于此就提供了一个有效的解决方案。caim 的主要功能是：针对不同的 用户制定特有的策略，以过滤掉不必要的信息。 事件机制为此提供了技术基础12， 协同感知系统自动地捕捉各个协同 - 14 - 应用中所产生的事件信息，生成事件。事件机制打破了原来的层级结构， 从底层到高层均可以捕捉到感知信息，能够更为简单地将协同感知集成到 协同系统中，并由此可以产生全局环境感知的能力。可以清晰地看到，事 件模型完整地覆盖了协同感知三个主要部分。 2.2.2 事件驱动架构的定义和概念事件驱动架构的定义和概念 事件是发生在系统内部或者外部值得关注的事情。一个事件可能表示 着一个即将发生或已经发生的问题、 一个机会、 系统状态越过了某个极限、 或者系统发生了偏离。每个事件之间并非独立的，而是相互关联，并且包 含着关联数据信息13。 每次事件的发生(occurrence)被看作产生一个事件实体(instance)，该实 体中含有事件各个属性的值。事件包括了事件头(header)和事件体(body)。 事件头中有描述事件实体的元素，例如：事件特定 id、事件类型、事件名、 事件时间邮戳、事件产生者等。这些元素对于每个事件都是固定的，相反 在事件体中需要包含针对各个类型事件的其他信息。 事件驱动构架(event driven architecture, eda)被用来发现系统或者周 围环境之中所发生的特殊性事件13，并且快速的发布通知给对此事件感 兴趣的订阅方（可以是操作人或者智能组件），以使订阅方能够快速地做 出反应。 eda 是专门为分布式系统所定制，由此采取一种非常松耦合的结构。 事件源仅仅感知基本事件的发送，并且负责传送这些事件信息，事件的订 阅方可以是系统中的任一组件或者是系统外的控制模块，其不和事件源产 生直接联系。因此 eda 非常适合异步工作信息流的处理。 事件处理的方式可以分为三类：简单事件处理、事件流处理和复杂事 件处理。在成熟的事件处理系统软件中，这三类处理方式往往以混合的形 式出现。 简单事件处理简单事件处理(simple event processing, sep)： 在简单事件处理中，只要一个值得关注的简单事件发生，一个下游 (down- stream)组件就会做出反应。简单事件处理往往被用在有实时需求的 工作流中， 因为考虑到时间花费上的严格要求， 事件处理过程会非常简单。 事件流处理事件流处理 (event stream processing, esp): 在 esp 中，不仅是值得关注的事件会被侦听，普通事件也会被捕捉到， - 15 - 并且发送给下游的信息订阅方。事件流处理也常被用来处理关于企业的实 时信息流，以助于快速的决策制定。 复杂事件处理复杂事件处理(complex event processing, cep): cep 主要用来处理评估事件的聚集，发现复杂事件，以采取相应的行 为。这些事件（简单事件和复杂事件）实体根据定义的事件类型而被描述， 而事件发生的周期被认定为相当长的一段时间。事件关系可以是因果关 系、时间性关系以及空间性关系。cep 需要大量的分支技术支持，包括： 事件的表达、事件模式的定义、事件匹配以及事件关系定义。cep 一般被 用来侦察发现业务中反常态的现象、危机以及特殊机会。 早期的 esp 是由数据流管理(data streams management, dsm)技术发展 而来的，主要负责实时数据的处理，以解决数据库快速响应等问题。其中， 并不包括 cep 涵盖的事件定义、事件模式匹配及发现等技术。随着 esp 本身的成熟，esp 更多的与 cep 结合起来，采用了事件分层的概念，用于 发现响应复杂事件。esp 与 cep 最为本质的不同是：esp 主要为处理实时 数据流进行服务，事件信息以流（stream）的形式被处理，在处理时具有 时间有效性的要求。 而 cep 针对的情况是事件信息长期地被保存于事件云 (event cloud)之中，复杂事件的发现是基于大量事件实体集合之上，往往 采用反复的迭代算法，其中事件的发生并没有实时性的特点。 2.2.3 eda 的层级功能模块的层级功能模块 在 eda 结构中，事件处理的流程按照逻辑被分为了四层14，基本组 件的实现也可以按照这四层结构依次划分为四个功能模块。下面首先对这 四层结构进行介绍，然后用一个简单的实例来介绍这四层功能模块是如何 整体运作的。 事件源事件源 事件由事件源产生，事件源可以是企业中的各项资源，并且部署于系 统中的各个层级。感兴趣的简单事件必须被事先定义，事件捕捉器通过一 定的手段从事件源中获取这些事件实体。在获取事件实体之后，事件捕捉 器可能还需要根据具体实现的要求，将事件转化为特定的格式，放入到事 件通道之中。 - 16 - 图 2.3 eda 事件处理流程 figure 2.3 eda event processing flow 事件通道事件通道 事件通道通常是一个消息传递网络，在事件源、事件处理引擎、事件 下游订阅方之间传递着格式标准化的事件消息。事件通道隔离了各个层级 模块，是实现 eda 松耦合的关键所在。 事件处理事件处理 在事件接收之后的事件处理层，事件按照所定义的事件处理规则进行 处理和评估。这个处理的过程，是将简单的事件组合生成为复杂事件，称 之为复杂事件处理，将在 2.3 节具体介绍。事件处理的核心是处理引擎和 事件实体数据。处理引擎包含了一组算法，用以根据定义的事件模式发现 复杂事件。 其中关于事件处理，必须事先定义和输入相关的事件元数据。好的 eda 会有一个非常清晰的元数据结构。事件元数据包括了事件定义语言 (specification)和事件处理规则(rules)。事件定义语言必须被事件源、事件 格式转换器(format transformer)、事件处理引擎和订阅方所理解。这些元数 据都是有订阅方所定义的，而和事件源无关。 当复杂事件被生成后，相应的行为将激发。这些行为可以是多样的： 调用一个服务、初始化业务处理流程、发布此事件、直接通知订阅方系统、 生成一个新的事件、甚至从事件库中重新捕捉历史事件。 - 17 - 下游事件驱动活动下游事件驱动活动 一个简单事件或者经过处理后得到的复杂事件将会产生一系列的下 游活动。下游事件的激发，可能是由于事件处理引擎的主动通知，或者由 事件订阅方定期地在事件发布处寻找到自己所要订阅的事件。事件应该以 标准化的事件格式进行发布，而事件订阅方也应该实现统一的接口，用来 接收来自事件处理模块的事件消息。 图 2.3 是一个完整的 eda 架构下的各个功能模块运行实例。 事件捕捉 器负责侦听在系统中发生的基本事件，当事件发生时，事件捕捉器将其转 化为特定的事件格式，放入事件通道之中。事件引擎从事件通道中提取固 定格式的事件，根据在事件元数据中定义的规则和模式，由模式匹配器做 出相应的行为。这些行为包括了生成新的复杂事件，复杂事件生成后将被 回放到事件通道之中。因为复杂事件是有层级结构的，所以这个过程需要 反复递归进行。所产生的行为还可以是发布一定的事件处理信息、通知特 定的操作者、调用其他服务以及启动新的业务流程。其中，订阅事件将被 发送给特定的事件发布点，由发布点发布有关事件。 2.2.4 事件驱动事件驱动 soa eda 定义了一种用于设计和实现应用程序的系统性方法。其中，事 件在各个分解的软件构件和服务间进行传递。 eda 的显著特征是其松耦合 的特性，与 soa 设计思想不谋而合，某种程度而言，其比现有的 soa 实 现更为松耦合，也更为灵活。eda 并不会替代 soa，而只是对 soa 形 成补充，将会对 soa 的整体结构发展产生深远的影响。采用 eda 架构开 发的 soa 也被称为事件驱动 soa(event-driven soa)。 从 soa 横向结构上而言， 现有的 soa 是通过简单的请求/响应这种同 步的方式来完成交互的，其历史源于分布式系统的远程过程调用（remote process call, rpc）。在这种环境中，esb 作为数据传输和转换的中介可 以很好地完成这一任务。 但是，在进行跨多个应用、大范围的集成时，成功的关键是有一个灵 活的架构，面向流程、事件驱动的架构就是这样的架构。rpc 的调用原理 主要是同步调用，在 web 服务质量参差不齐的情况下，性能间的依赖性会 使 soa 整体运行效率下降，无法做到各个 web 服务节点更有效的自主运 行。 - 18 - eda 的交互模式是一种异步的调用方式， 正是这一点大大补充了原有 soa 的不足。eda 中的每