您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
visualSTATE第一章.ppt 43页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：100 &&
visualSTATE第一章.ppt
你可能关注的文档：
··········
··········
设计visualSTATE模块 工程分为好几个层次。双击System View窗口中的最高状态矩形，这样就打开了状态表图，在状态图表中我们就可以画我们自己的状态图了。 现在所有画状态图的工具都处于可用状态，即上图中中间的一列。有关其中每一个状态的介绍，参见书本第三章。
设计我们的第一个状态图 在图标工具列中，单击“Simple State”按钮。然后单击右边的图表窗口，这时一个状态就产生了。此时，通过单击右键可使“Simple State”变为无效状态。如果需要的话，我们还可以对画出的状态调整大小或改变位置等。一个简单的示例：
设计我们的第一个状态图 使用下面的任意一种方法都可以改变状态的名称。
单击你所要修改的状态，将会出现一个文本区，此时就可以写状态的名称了。
双击你所要修改的状态，将会出现一个“Compose State”对话框。在Name那一栏中写入状态的名字即可。
更改名称后的状态：
设计我们的第一个状态图 状态之间的转换连接
单击状态图工具列中的“Transition”按钮。其所对应的图示步骤如图所示： 单击你要连接的源状态 移动鼠标到目标状态 然后通过单击鼠标来完成这个转换
设计我们的第一个状态图 就按照上面的画法，画出状态图:
设计我们的第一个状态图 给转换添加事件 在菜单中选择“View-&Element Browser”。在Element Browser中选择MY_TopState作为元素位置。单击“Event”标签来定义事件。
然后在状态图标窗口中，双击“Project browser”的某一状态。双击转换所带的文本框，“Compose Transition”对话框此时就会出现。单击Rule这部分中的“Trigger”。然后在右面的Element框中，双击所要添加的事件到Trigger中。
设计我们的第一个状态图 添加一个初始状态 在状态图工具列中选择“Initial State”按钮，为状态图添加一个初始状态。然后在初始状态和其中的一个简单状态间添加一个空转换：
设计我们的第一个状态图 添加状态机动作 在菜单中选择“View-&Element Browser”。选择“Action Function”标签，这样就可以定义状态机的动作了。选择“New”按钮，完成动作函数的名称、类型和其他的选项设置。然后返回状态图表窗口，添加动作。添加动作的步骤和添加事件相类似。添加了动作函数之后的状态图：
测试模块 在Navigator中，选择“Project-&Validator”。如图1.36所示，这会启动Validator。 双击Event窗口中的“SE_RESET”来启动测试。这时，系统将会进入初始状态。继续双击Event窗口中的事件，观察System窗口中系统的状态组合和动作窗口中事件所触发的动作。
测试模块 在Validator窗口中，选择“Debug & Initialize System”来复位系统。 在Validator菜单中，选择“Debug-&Graphical Animation”，来图形化地测试系统。调整Validator窗口和以仿真的模式打开的Designer窗口的大小，以方便地观察系统的测试仿真。
测试模块 后面的相关步骤，比如在visualSTATE中验证系统、在目标系统中对系统进行测试等，在此，就不一一列举了。有关的应用会在后面做出更加详细的介绍。 本章总结 在本章中，我们首先介绍了基于状态机的嵌入式系统开发平台IAR visualSTATE，简述了这个软件所具有的基本功能以及基本处理机制，并且通过插图，说明该软件的安装过程以及各个模块的设计方法，使读者对该软件有了初步的认识。请各位读者熟练掌握visualSTATE模块的设计流程，这对于我们后续章节的学习非常重要。
思考题 简述visualSTATE事件处理机制。 简述嵌入式系统应具有的重要特点。 一个visualSTATE工程的路径设置为D:\工程\ My_Project，请指出其中的错误。
第一章 状态机建模平台与入门实验 第一章 目录 1.1 基于状态机的嵌入式系统开发 平台IAR visualSTATE
1.2 IAR visualSTATE 安装及入门 实验学习
1.1 基于状态机的嵌入式系统开发
平台IAR visualSTATE
1.2 IAR visualSTATE 安装及入门
第一章 目录 IAR visualSTATE概述 IAR visualSTATE是一组高级的嵌入式设计工具套件，专门用于开发高质量的嵌入式系统软件，可适用于汽车电子、便携式电子产品、家电和人机界面等不同行业领域。visualSTATE能够使软件
正在加载中，请稍后...事件处理系统的概念模型
简介很多领域中的企业过去总是以一种事件驱动的方式经营，且必须每天处理不断增加的业务事件和交易。事件处理（Event Processing，EP）是一个新兴的领域，主要受到企业对这种大量业务和 IT 事件进行快速响应的需求所推动。它通过更有效地处理具有企业意义的事件来满足支持决策制定周期的需求，在面向服务架构（Service Oriented Architectures，SOAs）企业战略中变得越来越重要。本文首先讨论为何需要进行事件处理，不同类型的事件处理，以及企业采用事件处理架构的价值。然后，本文详细介绍一个事件处理概念模型，该模型用于实现一个事件驱动架构（Event Driven Architecture，EDA）。本文将通过讨论三个为改进决策制定而实现事件处理的业务场景来展示这些概念。事件处理概述事件是任何经常发生或认为正在发生的重要事情。一个事件要么完全发生，要么根本没发生，且具有重要意义，因为它可能会影响某个动作。事件被认为正在发生是因为它可能是一个正在变成事实的事件，也可能是真实世界中的一个实体的转变过程。事件可能是一个业务流程的一部分，例如，一个交易订单已经发出；或者，事件也可能关于 IT 基础设施、中间件、应用程序和业务流程的监控信息。图 1 提供了事件处理的一个高级概览。图 1. 事件处理概览一个事件（企业内外部发生的一件重要事情）可能会触发一个服务的调用，一个业务流程的启动，和/或更多信息的发布或聚合。事件处理的任务就是处理一个或多个事件，其目的是识别事件云中有意义的事件。从业务价值角度看，事件处理是探测和响应一些特殊事件的能力，这些特殊事件表明企业内出现了一些会影响业务的情况。例如，一条事件消息可能会表明添加了一个新客户，出售了一个产品，收到了一批货，打开了一扇安全门，通过 GPS 提供一个资产的当前位置，等等。事件创建者（或源）生成事件。事件创建者可以是应用程序、数据存储、服务、业务流程、发送器、传感器或者协作工具，比如即时消息传递或电子邮件应用程序。从创建者接收事件时，这些事件可以直接导致结果，或者针对事件处理模式进行评估。事件处理模式针对有关各方而不是事件创建者的需求定义。事件处理结果包括（但不局限于）调用一个服务，启动一个业务流程，将事件发布到一个订阅中心，直接通知人员或系统，生成一个新事件，以及捕获事件以备用。事件及其与业务服务之间的交互通常称为事件驱动信息系统或事件驱动架构。
概念基础支持事件处理的架构（即事件处理系统）的概念构建块应该提供事件处理逻辑等核心功能，并通过事件连接事件创建者和使用者。用于考虑这样的架构和系统的一个有用的模型是事件处理网络（EPN）构造，这是一个概念构想，用于描述事件处理系统的结构和这些系统都应支持的公共特性。EPN 将事件处理系统描述为相互交互的事件创建者、处理代理和事件使用者的集合。从这个意义上讲，EPN 的主要职责是从创建者接收事件，将事件传递到适当的事件处理代理组合以处理事件，然后将处理后的事件交付给适当的使用者。本文第二部分将详细介绍事件处理网络构造，该部分主要介绍事件处理的概念模型。这个概念模型包含虚拟化、事件数据库、事件驱动的中间件、事件处理语言，以及在从建模和编程到监控和响应的整个事件生命周期中支持事件管理所需的所有组件。事件处理类型根据事件处理的复杂程度，事件处理功能可以宽泛地归为以下两类：简单事务处理：简单事件，即不聚合、表示或预示其他事件的事件，直接被过滤或路由，无需修改。这样，一个明显的事件发生，触发下游动作，每个事件都被独立处理。尽管称为 “简单” 事件，但这样的事件能够提供巨大的价值和大量业务信息。事件被转换，涉及转换和分割事件，然后合并为一个或多个事件。简单事件处理的例子包括：将事件架构从一种形式更改为另一种形式，使用额外的数据增大事件负载，将事件从一个通道或流重定向到另一个，基于单个事件的负载生成多个事件。这种类型的事件处理并不能总是区分为一个单独的类型。 复杂事件处理：跨越多个独立事件的模式受到检测，以便派生新的 “复杂事件”（复杂事件是聚合、表示或预示其他事件的事件）。复杂事件处理包括处理一组事件，以便检测一个具有业务意义的情形。通常，这种处理涉及应用一个评估条件或约束集合到一个事件集合上。这些事件（显著的或普通的）可能跨越不同的事件类型，且可能在一个特定的时间段内发生。事件可能在多个维度上相互关联，包括偶然、临时、空间和其他维度。应该要认识到来自复杂事务处理的信息虽然具有复杂性和丰富性，但是它们对于用户来说并不是（也不应该）是复杂的。 尽管各种编程模型被用于表达这些构造，但是事件处理构造的模型化和实现受到应用程序集成中间件以及各种网络和系统管理平台的支持。复杂事件处理工具和引擎在最近几年才开始出现。事件处理可以结合分析技术来预测事件，挖掘模式并将实时分析嵌入到路由决策和事件派生中。使用这些种类的技术来进行实时事件分析将支持在决策制定周期中做出更明智的决策。业务事件处理业务事件处理以事件处理为基础并进行了扩展，以一种可使用的方式提供给业务用户。业务事件处理将功能和工具扩展到业务用户，允许应用这些技术来构造有利于业务的事件驱动信息系统。感知一个事件或事件模式已经发生或没有发生（这表明一个可操作的业务情形）的能力使业务能够对机遇和威胁做出快速反应。 图 2. 业务事件处理：将业务透视图添加到业务处理功能业务经理和分析师理解可操作的情形，即关键事件或事件组合和为响应那些事件而即将采取的操作。他们每天都要处理这样的情形，并直接负责了解它们发生的时间并管理响应。但是，他们没有可用的解决方案来支持他们自己识别并响应这些情形的数量和复杂性。与此同时，尽管如今有数以百万计的可操作事件正在 IT 基础设施内自由流动，但支持高级事件处理功能需要一组专门的功能；但是大多数 IT 组织没有有效且高效地支持这些要求的技术。Business Event Processing 是专门设计来应对这个挑战的，即，利用流经业务系统的信息来支持业务决策制定流程。Business Event Processing 的功能是：感知一个事件，表明一个可操作业务情形已经出现，并在适当的时间协调适当的响应（操作）。Business Event Processing 提供一组集成的系统和基础设施，在企业范围内监控事件的发生。这种类型的处理在重要事件发生时识别它们，触发警报，并发布关于这个事件的信息来启动适当的响应。作为一个 Business Process Management 解决方案的一个组成部分时，Business Event Processing 提供及时的事件模式检测和动态业务流程执行的强大组合。Business Event Processing 向 IT 部门提供在高性能、可管理和可伸缩的环境中支持高级事件处理要求的功能。另外，通过包含一个非编程的图形用户界面，Business Event Processing 使业务用户能够自己定义事件处理交互和操作。
事件处理的价值事件处理的基本原则已经在应用程序集成中间件和各种类型的系统软件（比如操作系统、网络和系统管理软件）中广泛使用了一段时间。但是，事件处理的重要价值体现在从业务上下文中识别事件的意义，并识别与该事件关联的适当响应。反过来，这可以允许企业对新机遇和竞争威胁做出快速响应，及时将相关信息发布给适当的人员，支持主动问题诊断，并有利于创建业务常规状态的一个实时视图。事件处理可以帮助企业识别趋势和威胁，抓住机遇来减小风险，缩短价值实现时间，并支持快速的感知和响应周期。事件处理在各个行业中的市场越来越大，比如：
资本市场中的交易者希望对细微的价格差异做出反应。军事或情报分析人员评估卫星流和传感器数据来确定适当的进攻和防御行动。运输和后勤企业利用交通工具实时遥感探测技术来更有效地管理车辆和船舶。银行家持续跟踪交易来发现欺诈、洗钱和金融违规行为。通信服务运营商寻求最小化网络中的平均维修时间（mean-time-to-repair）故障。石油公司基于实时操作数据动态确定钻探的深度和宽度。汽车配件供应商利用复杂的制造决策来为制造商实施 “零库存” 生产提供配件在所有这些情形和其他情形中，都有实时处理大量复杂数据的内在要求，而事件处理能够提供这个能力。企业从批处理转变到实时处理以进行快速决策的需求是推动事件处理需求的另一个原因。新兴的工作负载的特征也需要接近实时的复杂事件处理，这不仅涉及数据事件，还涉及源自语音和视频等非常规源的事件。这个观点得到一些行业分析师的支持，比如 Gartner，他指出，几种形式的事件（从简单事件到复杂事件）将在业务应用程序中得到更广泛的应用。实现事件驱动的业务流程有巨大的财务和战略好处，因为它们适合真实世界中的许多方面所固有的事件驱动特性。事件驱动流程不只是运行更快的传统流程；相反，它们拥有区别于 “传统业务” 的特有特征。事件驱动的应用程序允许快速修改流程，从而响应干扰传统流程的错误和异常情况。随着企业致力于降低成本并提高对客户、供应商和整个世界的响应性，事件驱动设计的概念得到了越来越广泛的应用。企业正在通过实现事件驱动的业务流程而获得好处，这不仅因为这种业务流程符合业务固有的事件驱动特性，而且因为这种业务流程向他们提供了成本和价值实现时间方面的竞争优势。
事件处理场景概述为阐述本文表达的概念，我们将在后面各个小节中开发三个不同的事件处理场景，它们将展示在这个概述中描述的部分价值。车队管理（Fleet Management）场景公共健康警报（Public Health Alert）场景通信服务供应商（Communication Service Provider）场景
介绍这些场景之后，我们将把各种事件处理概念映射到各个场景，并解释事件处理对每个场景的附加价值。第一个场景（车队管理）将进行详细介绍，因为我们将在这个场景中介绍一些公共特性。我们首先介绍这些场景的业务上下文，然后在本文后面讨论涉及的事件以及到这个概念模型的各个方面的映射。车队管理场景这个场景描述一个 “快速递送” 公司，该公司通过一个车队专门在相对短的距离内交付小包裹；每辆车都安装了持续广播其位置的 GPS，且包裹粘贴了 RFID 标签。根据承诺的服务水平，要么立即对包裹进行点对点递送；要么将包裹递送到一个发货中心，在那里，（可能）由另一辆车将包裹递送到目的地。每个包裹都有一个承诺的送达时间，超过这个时间将支付违约金。有些送货是固定的（在每月计划中），而有些送货则是客户通过电话（或网站）临时请求的订单。图 3. 车队管理概述这个场景的理念已经基于针对车队优化的 IBM 解决方案进行了优化。对于卡车和小车车队经理而言，下面是他们的一些业务管理和维护目标：
降低燃料成本跟踪车辆和司机向客户提供最新的精确到分钟的信息找到简化装载、卸载和路径规划流程的最佳位置提高资产利用率改善客户服务降低经营成本减少计划外维护成本降低风险以减少保险成本为了以一种及时适当的方式来管理这个车队，该公司选择在他们的系统内利用事件处理。这样，该公司能够做出快速反应，当新的客户要求出现时能够重新分配路线来满足这些要求，同时维持与每个客户的协议。该公司还能对风险做出反应，因为该公司能够通过在违反协议之前进行重新安排来解决问题。借助事件处理，该公司能够对机遇和风险做出反应，其原因是：由于关于车辆、订单等的当前情况被持续监控并通过事件反映出来，因此该公司能够决定如何采取行动（来使前面提到的指标受到控制）。该公司还能够放心地快速做出更改并将更改部署到流程中，这只需更改事件处理逻辑或应用程序，无需完成漫长的、容易出错的开发过程。在下面的小节中，我们将检查这个场景涉及的事件和事件处理概念。
公共健康警报场景这个公共健康警报场景描述了将警报系统用于这样的场合：这些场合能够表明对公众存在风险的真实或潜在事件即将爆发。这样的事件的例子包括 SARS、禽流感（H5N1）或使用生化武器的恐怖袭击等。这个场景考虑禽流感（Bird Flu）和禽流感 A（H5N1），但它也同样适用于其他事件爆发，比如 H1N1。世界卫生组织定义的大流行病的阶段或状态显示从内部大流行状态（没有在人类当中检测到流感病毒）到大流行状态（在普通公众中出现持续的传染）的发展。这个场景主要考虑三个阶段 —— 没有检测到病毒，流行状态和大流行状态。图 4. 公共健康警报概述我们现在描述这个场景中将发生的事情。一个进行血液分析的实验室检测到一个病毒。根据有关规定，检测到一个特定病毒被发布为一个事件。事件接收器（我们称为事件发送器）规范化这个事件并执行一些基本的质量和起源检查，然后将它传递到事件处理代理。这个事件在事件处理代理中被添加一些信息，然后模式探测检查是否需要提交一个流行病爆发警报。如果需要提交流行病或大流行病爆发警报，对应的事件是发送通知。来自外部事件创建者（比如国际健康组织或外国政府）的大流行病爆发警报以类似的方式处理。涉及的事件和这个场景与事件处理概念模型之间的关系将在后面的小节中介绍。
通信服务供应商场景这个场景描述一个通信服务供应商：YourCSP 公司。该公司向国内客户和中小企业提供各种有线通信服务，服务范围包括到 VOIP 的宽带 Internet 接入和虚拟专用网服务等。该公司的核心 MPLS (Multiprotocol Label
Switching) 网络包含来自多个不同的制造商的网络元素，受到各种 Element Management Systems 的支持。他们采用了一系列网络技术来连接客户的经营场所，包括 Dial-Up、DSL 以及支持 Layer 2 和 Layer 3 VPNs 的技术。根据客户购买的特殊服务包，该公司提供各种不同的服务水平协议（Service Level Agreement，SLA）。这些 SLA 包含保证承诺的服务水平的合同，服务水平根据一些指标来度量，比如服务持续性，可用网络带宽等。没有实现的 SLAs 将导致 YourCSP 支付违约金，并且会损害公司声誉。该公司根据对客户的承诺服务水平对客户进行分级。与所有通信服务供应商一样，YourCSP 公司也采用了一个网络操作中心，该中心包含雇员、硬件和软件资产，专门用于保证公司核心网络的顺利运行，提供相应的服务。他们的目标包括：最小化网络故障的平均维修时间，这些故障可能会导致网络停用或向公司客户提供的服务水平下降。根据受影响客户的 SLA 来确定停用和故障的维修优先顺序，从而最小化公司的财务风险。最大化网络资产的利用率。最小化人力成本和能源消耗等经营成本。在发生影响服务的故障时提供与客户的预先沟通，使其与上述故障的修复进度保持同步。
YourCSP 的网络操作中心使用网络管理和事件处理技术来实现上述目的。这些系统处理多种不同类型的事件，包括表示以下问题的事件：网络中检测到的故障网络元素的状态更改包含网络设备的场所中的环境条件和网络设备本身事件自动响应的结果响应网络事件的操作人员的操作故障解决的自动探测
对这些事件数据的访问，以及处理它们的工具允许网络操作中心：监控核心网络包含的元素，获取健康、可用性和性能信息。 将网络事件规范化为一种公共格式，以便实现统一的虚拟化和处理。 向网络操作中心操作人员提供网络中已经发生的事件的最新交互式视图。自动发现和维护核心网络的最新模型以便：
维护已部署资产的可见性 维护物理和逻辑网络拓扑的模型及其与提供的网络服务的关系向操作人员提供网络地图仪表板，以便进行问题诊断和故障排除对网络事件和服务停用执行基于网络拓扑的根源事件分析支持新服务的提供流程执行大量网络失败场景的自动响应、诊断和修补。执行关于事件的模式分析，进行关于原因和业务影响的网络事件推断。执行基于技术、拓扑和业务上下文的网络事件充实。定义在 YourCSP 的服务桌面应用程序中自动创建问题票据（trouble ticket）的策略，从而促进物理维修工作。
YourCSP 与中型企业 MediumCo 签订了一个合同，在 MediumCo 分散的工作场所之间提供 VPN 服务。这个合同带有一个关联 SLA，承诺提供高水平可用性。YourCSP 为 MediumCo 的每个工作场所提供并管理一个专用 Customer Edge Router (CE)，以便连接到 YourCSP 的核心网络。每个 CE 都连接到 YourCSP 的工作场所中的一个 Provider Edge Router (PE)。如果 PE 路由器中出现一个故障，例如一个故障电路板（card），事件处理系统将接收从周边网络中的设备和元素管理系统发送的多个事件，表明出现了一些物理和逻辑故障，包括 ICMP (Internet Control Message Protocol) ping 失败、链接关闭警报、路由协议邻接失败（adjacency failure）等。遇到这种情况，事件处理系统必须：
识别根源事件并向网络操作中心的操作人员突出显示，在本例中为电路板失败。推断是否影响任何客户服务，在本例中为提供给 MediumCo 的 VPN 服务是否不可用。根据适用的 SLAs 和网络中的其他停用确定这个服务停用的优先权，适当确定解决问题的先后顺序。在本例中，由于对 MediumCo 承诺的 SLA 很高，因此应该优先解决这个问题。通知受影响的客户：故障已经确定，发出一个工作项目请求，派遣一位技术人员去解决故障。探测故障的解决情况，通知操作人员和客户：常规服务已经重新建立了。
这个场景中涉及的事件和与概念模型的映射将在下面的小节中介绍。概念模型我们的概念模型呈现两个不同的事件处理系统视图，旨在抽象地描述重要的概念和它们之间的关系，并剔除了所有技术细节。Event Processing Network (EPN) 抽象了一个事件处理系统的输入、处理和输出元素的关键特性。在 EPN 概念的指引下，我们的概念架构识别可用于实现一个事件处理系统的抽象架构元素（或组件）以及它们之间的关系，以便提供业务价值。这个概念架构处在一个抽象层面上，独立于可用于提供这些组件的技术、协议和产品。这个概念架构的目标有两个：构成事件处理系统和事件驱动应用程序的基础；提供一个公共架构来指定、比较和对比不同的事件处理解决方案架构和实现。我们的意图是：这个概念架构在一个概念层面上提供一组充足的组件，事件处理系统的实现可以基于这些组件构造；但是没有必要实现给定系统中不需要的任何组件，也没有任何遵从这个模型的暗含概念。
事件处理网络我们的事件处理系统高级抽象应用来自事件处理网络构造（见图 5）的概念。如前所述，事件处理网路是一个概念构想，描述事件处理系统的结构和应该全部支持的公共特性。图 5. 事件处理网络一个 EPN 包含 4 个组件：事件创建者、事件使用者、事件处理代理（简称为 EPA）以及一个称为事件通道的连接组件。EPN 描述从创建者接收的事件如何通过代理传输到使用者，这些代理通过（例如）执行转换、验证或补充（enrichment）来处理这些事件。从一个组件流向另一个组件的任何事件必须流经一个事件通道，如图 5 所示，图 5 展示了事件通道、使用者、创建者和处理代理之间的关系。事件通道是一些节点，它们将创建者连接到 EPN 中的 EPAs，根据需要将 EPAs 连接到一起，并将 EPAs 连接到使用者，导致事件从事件创建者流出，经过 EPN，到达事件使用者。图 5 还展示：由 EPN 中的事件创建者创建的各种事件可以由通过通道连接的适当的 EPAs 组处理，以便那些事件（或由它们派生的事件）由 EPN 中的各种事件使用者所使用。事件通道事件通道是一种机制，用于将事件或事件流从事件创建者和 EPAs 发送到事件使用者和 EPAs。在这个抽象级别，对于事件通道的属性（比如是否每个通道可以移动一个以上的事件类型）或移动事件的机制没有施加任何约束。事件通道可以从多个不同的事件创建者和 EPA 接收多个事件，也可以将来自几个源的合并事件传输到多个 EPA 或使用者。用于创建合并事件集合的来自不同 EPAs 和事件创建者的多个事件的顺序是特定于实现的，且没有被这个概念模型涵盖；在有些情况下，不需要任何特殊的排序。但是，事件通道的职责是从事件创建者和/或 EPAs 接收事件，排序（如果需要）并合并，然后提供给适当的事件使用者和/或 EPAs。事件通道的另一个职责是：根据决定任意已保留事件的保留期限和过滤条件的保留策略，保留通过的事件的历史，以便进行追溯事件处理。追溯事件处理是在事件历史上发现事件模式，与在线事件处理相反，后者在新事件可用时探测预定义的事件模式。事件通道在 EPN 中表示为节点，带有指向节点和来自节点的线（edge）。每个进入的线表示来自一个事件创建者或事件处理代理的一些事件，这个事件创建者或事件处理代理将这些事件放置到通道上；每个出去的线表示发送到一个事件使用者或处理代理的事件，这个事件使用者或处理代理从通道接收这些事件。
事件创建者和使用者事件创建者通过事件通道创建事件，供有关方面使用。有关方面可以是事件使用者或 EPAs。概念模型没有对从事件创建者或 EPAs 获取事件的机制进行任何限制；如果要进行限制，可能会涉及 “推” 或 “拉” 模型。在一个由节点和线组成的网络中，事件创建者表示为源节点，即这种节点只存在发出的线。从源节点发出的线的数量就是将一些事件从创建者移动到即将接收这些事件的 EPAs 或使用者所涉及的不同事件通道的数量。事件创建者可以将一个事件发布或提供给多个事件通道；但是，作为一种设计实践，最好将路由交给 EPAs 决定，以便更好地控制、设计和理解整个事件处理需求。事件使用者对允许它执行其职责的事件感兴趣。一旦事件使用者接收到感兴趣的事件，它将执行与这个事件关联的一个或多个任务。事件使用者被表示为一个汇点，即只有指向它的线。指向它的线的数量就是将事件移动到这个使用者涉及的不同事件通道的数量。同一个事件可以通过多个事件通道接收；但是，何处、何时以及如何接收事件的逻辑最好留给 EPAs 决定，以便更好地控制、设计和理解整个事件处理需求。这并不是说事件使用者不可以是事件创建者，而是当它充当后面的角色时，它将作为 EPN 中的事件创建者出现。
事件处理代理在分布式和异构系统中，事件创建者可能不会创建事件使用者期望接收的事件。这些事件可能与预期的语法（结构）或语义含义不同，或者与两者都不同。还有这样的情况：单个事件将不会触发由事件使用者执行的操作，相反，这个操作由在不同的时间和不同的上下文中发生的多个事件的一个复杂组合触发。需要 EPAs（有时也称为事件中介）来探测原始事件中的模式，以便通过补充、转换和验证来处理这些事件，最终派生新事件并发布它们。EPAs 负责创建这些派生事件，并决定在何处、以何种方式提供这些事件。EPA 拥有三个可能的阶段：模式匹配：如果需要，这个阶段负责选择将根据一个指定模式进行处理的事件。执行模式匹配的 EPA 称为 “模式探测 EPA”。处理：如果需要，这个阶段负责将处理功能应用到满足模式的选中事件，生成派生事件。发送：这个阶段负责将事件或派生事件发送到一个通道。
EPA 从事件通道接收事件以进行模式探测或其他处理，非常类似于事件使用者从事件通道接收事件并处理事件。EPA 在发送事件时通过事件通道送出事件，非常类似于事件创建者通过事件通道发送它创建的事件。在一个由节点和线组成的网络中，EPA 表示为节点，带有指向节点和来自该节点的线。指向该节点的线的数量就是代理用于它的功能（比如探测模式）的不同事件通道的数量。来自该节点的线的数量就是代理用于根据处理和发送定义发送事件的不同事件通道的数量。总之，Event Processing Network (EPN) 就是通过事件通道连接的事件处理操作的有向图。网络中的 EPAs 提供事件处理服务和中介；即，获取一组由一个或多个事件组成的事件组作为输入，执行一些处理，然后返回一组由零个或多个事件组成的事件组（可能是新的）作为输出。Event Processing Network 的主要职责是从创建者接收事件，将它们传递到一个事件处理代理组合，处理事件，然后将事件交付给适当的使用者。
事件处理网络场景现在我们将事件处理网络定义和组件映射到 “事件处理场景概述” 小节中描述的场景中。车队管理场景以下是一些事件处理网络组件（创建者、使用者、事件通道、事件处理代理以及事件），它们仅仅描述前面提到的 “跟踪车辆和司机” 中的一个方面。这个公司实施了一些规章制度，以便确保司机的安全并避免事故，因此一名司机的一次倒班工作时间不能超过 8 小时。超过这个工作时间的所有司机都会被强制要求休息；为避免向客户延迟交货并支付罚金，递送的货物必须重新分配给其他司机。这个重新分配过程需要在公司的一个设备中设置一个适当的会面地点来实现，以便将货物从一辆车转移到另一（几）辆车上，并重新计算路径，从而使延迟时间（如果有）降到最小。将提供一个司机报告系统，其中生成司机倒班的开始和结束事件。只有基于这些事件和对车辆位置的持续监控，这个重新分配过程才能得以实现。另外，对事件进行补充、“超过驾驶时间” 模式的探测和路径设置还有一些要求，它们被描述为事件处理代理。表 1. 事件创建者表 2. 事件使用者表 3. 事件表 4. 事件通道表 5. 事件处理代理示例 1表 6. 事件处理代理示例 2表 7. 事件处理代理示例 3表 8. 事件处理代理示例 4下面的图 6 以图表方式展示了这个 EPN 的组件。当一位司机开始他的工作时，Driver Report System 创建事件 E1 并将该事件发布到通道 EC1 上。事件 E1 由事件处理代理 A1 补充，生成派生事件 E2。8 小时以后，当该司机超过他的驾驶时间且没有交班时，代理 A2 创建事件 E4。事件 E4 被发送到 Delivery Management Dashboard 以便进行控制。代理 A3 通过通道 EC4 接收这个事件，并将该司机的订单重新分配给其他司机来送货，但是同时避免超过其他司机的驾驶时间。这个重新分配指示通过事件 E5 发送通知，代理 A4 路由这个事件并将其重定向给几个需要通知的使用者 —— 那位超过驾驶时间的司机、需要装载并运送他的订单的一位或几位司机，需要了解送货路径和到达时间更改的客户、以及用于控制的 Delivery Management Dashboard。只有当该司机将他的货物转移给其他司机时，他的这班工作才结束，且事件 E3 被创建（这个事件对前面描述的代理没有影响）。图 6. 车队管理场景的 EPN 的图形表示公共健康警报场景下面的表列示了在 “事件处理场景概述” 中描述的公共健康警报场景的事件处理网络组件。这个场景的 EPAs 没有详细介绍。表 9. 事件创建者表 10. 事件使用者还有一种 “中间人” 的概念，这个中间人实现这个 Event
Processing Network (EPN)，提供事件创建者（不知道事件将由谁使用，如何使用）和事件使用者（不关心事件起源和原始事件的原始形态或意义）之间的分离。除了事件创建者和 EPN 与事件使用者和 EPN 之间的关系之外，我们还可以想象一下这样的例子：创建者（通过一个 Web 页面或提要）公开提供事件且 EPN 检索到这个信息。另一方面，这个 EPN 也将这个事件公开提供（也许通过相同的机制）给事件使用者。这样，创建者和 EPN 与使用者和 EPN 之间就出现了分离，我们还可以想象一个没有中间人的直接分离场景。
表 11. 事件图 7 提供了这个 EPN 的一个图形表示。图 7. 公共健康警报场景的 EPN通信服务供应商场景下面的表列示了在 “事件处理场景概述” 中描述的通信服务供应商场景的事件处理网络组件（事件创建者、事件处理代理、事件使用者和事件）。表 12. 事件创建者表 13. 事件使用者表 14. 事件类型表 15. 事件处理代理示例 1表 16. 事件处理代理示例 2表 17. 事件处理代理示例 3图 8 提供了这个场景中使用的事件处理网络部分的图形描述，截至派遣技术人员这个时点。图 8. 通信服务供应商场景的 EPN概念架构这个概念架构构建在 EPN 的概念之上，方法是定义一个事件处理解决方案中可能涉及的各种组件。在 EPN 层面上，这些组件中的一部分等同于一个 EPA，或者一组互联的 EPAs，而其他组件则与事件流的关系更加紧密，等同于 EPN 中的通道。这个小节后面的图 11 将展示这个概念架构如何映射到 EPN。支持业务事件处理的任何系统架构都应该支持事件处理逻辑的灵活定义：事件模式的探测、新事件的派生、以及基于需要的业务逻辑从创建者到使用者的路由。这样，业务能够对变化做出反应，执行相关的流程，并影响基于这些变化的当前流程。另外，这样的事件处理定义应该容易修改，并根据业务需求（比如业务流程和策略的更改）快速部署。为理解这种业务价值如何从业务处理系统产生，重要的是考虑比事件处理网络更深的一层细粒度，即考虑可用于构造一个事件处理系统的组件及其交互。这个流程的结果即我们所说的事件处理系统的概念架构。除了一个事件驱动系统的三个典型层 —— 事件创建者及其关联组件、事件使用者及其关联组件以及一个中间的事件总线层 —— 之外，这个概念架构还需要包含用于事件和事件流的安全、监控、分析和管理的组件。在最简单的层面上，一组最小的概念组件要求一个事件处理系统包含一个事件发送器层来从事件创建者发送事件，一个事件总线层，以及一个事件处理器层（用于处理事件），以供事件使用者使用。图 9 展示了这个最小的事件处理概念架构，还包含一些事件创建者和事件使用者的示例。
图 9. 最小的事件处理概念架构事件发送器（Event Emitter）层、事件总线（Event Bus）层和事件处理器/接收器（Event Handler/Receiver）层中也许还需要其他功能。在实践中，从事件创建者生成的事件并不总是能立即被事件使用者共享。由于在一个事件处理系统中，事件创建者并不一定具有事件使用者意识，因此，创建者和使用者之间通常需要一个中间件层。这个中间件层执行其他事件相关任务，并允许使用者接收那些感兴趣的事件，或者接收那些事件的派生事件。创建者生成的事件并不一定具有要求的格式，遇到这种情况时，这些事件需要在被发布到中间层之前转换为符合要求的（企业标准）格式。在某些情况下，一个普通事件可能由一个事件预处理器（路由器、过滤器）评估以引起注意，导致生成一个新的显著事件。事件处理代理能够在创建者的领域内过滤和调整原始事件。类似地，并不是所有位于使用者端的事件都具有可以使用的形态。因此，使用者端可能需要一些处理和调整。在使用者端进行处理之前，一个普通事件可能需要由一个事件预处理器（过滤器）进行评估以引起注意。使用者可能会选择不理睬接收到的部分事件。事件处理服务在事件处理器层实现这些预发布和预接收事件处理要求。图 10 展示了这个事件处理概念架构的所有组件。将这个概念架构作为概念层面上的基础组件集，任何事件处理实现都应该能够得以实现，但这并不是说每个实现中都需要所有组件。类似地，对于任意给定场景，并不是所有组件都是必要的。我们稍后将回到上述三个场景，了解它们如何映射到这个概念架构，那时我们将看到，并不是每个组件都会被涉及到，而且这种情况是很普遍的。
图 10. 事件处理概念架构 —— 一个事件处理系统中可能会涉及的组件架构组件这个概念架构中的事件流是从创建者到使用者，上图中展示的组件将按照这个顺序在这里进行总结。下一小节将详细描述这个概念模型中的处理流。在实现层面上，事件使用者通常也是事件创建者；但是在概念层面上，使用者和创建者的角色是分离的。事件创建者。事件创建者在有关事项发生（或没有发生）时发出一个事件。事件创建者没有包含处理事件的逻辑，也不包含有关在何时发送何种事件的决策逻辑，生成的事件可能是冗余或不相关的。典型的事件创建者示例包括：
事件传感器，它探测情况（发生的事情）并生成原始事件，或者从数据流或业务流生成事件 —— 温度的传输就是一个例子。监视器和探测器，它们生成关于系统内的可用性和问题的事件，比如一个 IT 网络中的故障。业务流程，它们在流程中的重要时点（比如里程碑和检查点）生成事件，或者在一个特定的流程任务到达或启动时生成事件。
服务和应用程序，它们在流程中的关键点生成事件，比如当服务被调用或完成，或者当服务失败时。状态机器，它在状态改变时生成事件。
事件发送器（Event Emitter）。它在逻辑上（尽管并不一定在物理上）与事件创建者相关联，负责转换和打包来自创建者的原始事件，以便发送到事件总线（Event Bus）。事件发送器可能包含一个事件实例化器（Event Instantiator），它创建事件的实例，简单事件处理服务（Simple Event Processing Services，比如过滤和调整由单个创建者发出的事件，使用事件发生时可用的信息来补充事件），以及事件适配器（Event Adapter）。事件实例化器从创建者接收事件，执行任意（如果有）必要的操作来使其可用于进一步的事件处理或发送，这些操作可能包含事件的聚合、缓存和序列化。事件实例化器可能需要用于操作事件头部，以便将 “语义元数据” 嵌入到事件消息本身中，从而使其具有自我描述功能（带有时间、日期、工具类型、处理 ID 等信息）。事件发送器可以通过在这个阶段（而不是在事件到达事件总线之后）执行简单的事件处理来提供优化。事件适配器可以提供事件的格式化和协议转换，将其转换为可以被事件处理网络接收的形态，比如将事件记录封装为事件消息并将事件消息发送到事件总线。事件总线。事件总线从事件发送器接收事件（事件的量可能非常大），并通过事件处理器调用使用者，作为事件的结果。事件总线的功能之一是处理事件，从进入的事件派生出事件量更少、信息更丰富的事件。事件总线的组件不必同时位于一个位置。下一小节将详细介绍事件总线。事件处理器（Event Handler）。这个组件准备来自事件总线的事件，以便事件使用者使用，接收事件并决定如何反应。事件处理器拥有一些事件适配器，用于从事件总线接收事件消息，打开消息包装，获取事件记录。事件处理器还能提供简单事件处理服务，这些服务执行使用者端处理，过滤和调整从事件总线接收的事件。事件处理器还能确定将对事件做出反应的适当使用者，使用源自事件的上下文调用那些使用者。最后，事件处理器还能提供事件编排（orchestration）服务，管理对使用者的事件分发。事件使用者。事件使用者执行一些任务，以对事件做出反应。事件使用者不太关心事件的起源，只是意识到它正在被调用，这是事件及其相关上下文的结果。典型的事件使用者示例包括：
事件执行器（Event Actuator），它们被调用来执行一些任务，比如操作阀门、开关或警报。操作人员仪表板，它们显示关于 IT 系统和受影响的服务的行为的信息。
业务仪表板，它们显示关于业务流程的行为的信息。 业务流程，它们可以被启动或恢复，以响应一个事件。服务和应用程序，它们可以被调用以响应一个事件，可以包含外部内容管理系统或事件存储库。状态机器（State Machine），它们的状态可以被更改，以响应一个事件。
这个概念架构视图基于每个组件的角色，但并不是说这个架构中的一个特殊参与者不能执行多个角色：一个事件创建者也可以执行事件处理并能充当一个事件使用者。尤其是，发布和订阅服务只在使用一个 “发布/订阅” 样式的模型时才需要。这个概念架构可以认为是 “嵌套的”，因为任一参与者都可以在其中包含一个具有更多组件的网络。例如，一个事件创建者可以发送一个事件到主事件总线，但是在生成那个事件的过程中，可以想象这个总体模型的一个 “微型” 版本，其中，一个创建者发送一个初始简单事件，以便与一个 “微型” 事件总线中的其他事件进行模式匹配，这个 “微型” 事件总线逻辑上驻留在这个总体事件创建者中。
事件总线组件事件总线将事件从创建者传输到使用者，可以提供其他服务来处理和路由事件。事件总线可能拥有一个关联的事件注册表，可能拥有通过使用一个事件存储库来执行实时（in-flight）事件的（临时或持久）事务性存储的能力。事件总线可以是本地的，也可以在企业层面上实现，接收到的事件需要根据业务要求来处理。这种处理通过使用简单和复杂事件处理服务来实现。这些服务通过一些事件处理代理提供，这些代理通过事件通道连接在一起。事件总线提供的服务（或构建块）包括：
事件通道，它们将事件从事件发送器传输到事件总线，在事件总线的组件之间传输事件，以及将事件传输到事件处理器。发布服务，允许创建者将事件发送到适当的通道。订阅服务，支持创建者和使用者的动态注册，比如允许事件处理器找到适当的通道，并订阅来自那些通道的事件。通知服务，在事件可用时通知已订阅的事件处理器，支持 “推” 和 “拉” 事件。查询服务，允许查询一个存储库，获取事件（和元数据）。事件安全服务，控制事件的访问和授权；例如，控制向/从事件总线添加或删除事件，以及事件内容的隐私和不可否认性（non-repudiation）。事件处理服务，提供事件的过滤、转换和补充，还能提供模式匹配和事件派生。这个服务可以包含复杂事件处理（处理来自多个源的事件），也可以执行多个事件之间的长时间模式匹配事件信息服务，允许管理员添加、删除和组织通道，组织事件类型元数据（语法和语义）以及以关系格式存储事件数据，而不是使用基于事件消息的（即原子的）持久化。一个事件注册表，提供一个事件类型分类系统和一个事件关系本体（ontology）。一个事件存储库，为实现中长期事件持久性而存储事件。下面列示了事件总线中的处理需要提供的最重要的功能类型。转换 —— 通过转化（translate）或分割来转换进入的事件。补充 —— 使用来自多个可能的源的参考数据补充事件的内容。验证 —— 提供针对必要的标准的验证。模式探测 —— 识别实际的和可追溯的模式 — 来自多个可能的事件的组合，描述一个重要的业务情形的特征。过滤 —— 基于事件内容过滤事件的无状态功能；即，消息携带的信息在事件发生时生成。聚合 —— 根据需要对事件分组。路由 —— 根据各种可能的路由模式将事件路由到目的地，比如预先创建的路线、基于日历的路由模式、订阅或 “智能” 路由决策。
这个概念架构还包含事件治理（Event Governance）和安全服务，用于管理和控制事件的生命周期和事件元数据。事件监控和分析基础设施（Event Monitoring and Analytic Infrastructure）用于实现主要的管理目的，通知事件基础设施中的故障，收集并显示关于事件流的统计数据。这些功能需要覆盖整个事件流，因此在 “概念模型” 图表的右边部分展示。 这样，这个概念架构表示将事件发送到事件总线的事件创建器，这些事件在事件总线中处理，最终被事件使用者使用。作为一个事件的结果，一个使用者可以生成另一个事件，或者以其他方式回应另一个组件，结果，这个组件本身又生成一个事件。图 11 展示了这个概念架构如何构建在一个 EPN 的概念之上的示例，其中展示了等同于 EPAs 或者一些互联的 EPAs 的集合的组件，以及提供事件通道服务的其他组件。图 11. 事件处理概念架构使用的 EPN概念架构中的处理流这个小节的目的是描述运行中的概念模型。可以考虑三个阶段：事件发送阶段事件处理阶段事件使用阶段这不是一个单一和统一的处理流，这三个阶段之间有非常有限的耦合，特别是在涉及复杂事件处理的地方；遇到这种情况时，这三个阶段可以在完全不同的时段内发生，而且发出的事件和使用的事件之间只有一个因果关系。为了提供具体的示例，这个小节将引用在其他小节中详细描述的场景。
事件发送阶段这个阶段涉及的概念架构的组件主要是事件发送器的组件。它们在事件发送中的角色可能技术性很强，即，它们主要负责在事件创建者和事件总线之间提供技术连通性层；但它们也可能是面向业务的，即，某些面向业务的事件处理逻辑或本地事件处理代理可以在这里实现。技术角度当一个可能有意义的业务事件发生时，事件创建者使用它的本地事件发送器层发送一条事件消息到事件总线。事件实例化器子层是一个技术组件，负责探测这个特定的业务情况并收集所有必要的信息。然后，本地事件处理服务能够处理这个信息，以便通过（例如）格式化信息以遵循在事件注册表中发布的一种通用格式来创建事件消息。事件消息然后通过事件适配器子层发送到事件总线，事件适配器子层负责使事件消息适应事件总线支持的协议。示例：我们来研究一下车队管理场景中的 Delivery System，特别是作为事件提供者的车辆派遣子系统。我们假设车辆派遣子系统是一个在关系数据库中存储数据的业务应用程序。每当负责一个特定送货任务的司机或车辆在这个应用程序中发生更改，就应该发出一个名为 “Delivery Change” 的业务事件。事件实例化器被实现为存储送货数据的表上的一个触发器。每当这个表中的一个送货实例更新，就会触发这个触发器。这个触发器实现本地事件处理服务，它验证这个更新与负责这个送货任务的车辆或司机的变化是否相关。如果这个测试成功实施，触发器逻辑将收集所有必要的信息（Driver1 ID、Vehicle1 ID、Driver2 ID、Vehicle2 ID、Sender ID、Receiver ID）并在一个专门的送货更改事件表中创建这条 “Delivery Change” 事件消息的一个实例。事件适配器子层使用一个 JDBC 适配器实现，负责轮询这个表，并负责在事件总线层面上发起外部事件处理逻辑。业务视角在更高级的实现中，事件发送器层能够支持更高级的创建者端事件探测模式，并能够实现本地事件处理代理。可以在本地事件处理子层中考虑基础事件的过滤、聚合、补充甚至验证，以便通过事件总线发送一条事件消息，描述一个有价值的业务事件的发生的特征。示例：在公共健康警报场景中，让我考虑将 “Hospital” 作为事件提供者，“Potential Epidemic Outbreak” 事件作为它生成的事件。医院信息系统中报告了许多患者病例。其中，有些病例需要特别监控，因为它们与一种特定的感染有关。这样一种情况的发生是一个基础事件。要探测一个 Potential Epidemic Outbreak，需要在这家医院中匹配几个类似的基础事件，它们在一个有限的时期内影响许多患者。因此，事件实例化器和本地事件处理服务实现一个事件处理代理，负责：验证这些基础事件的起源和质量，将它们互相关联，根据这个事件处理网络的有关各方的预期生成一个 “Potential Epidemic Outbreak normalized” 事件。
事件处理阶段这个阶段在事件总线中发生。可能有不同的处理流，涉及事件总线的不同组件，具体取决于将要处理的事件的数量。这里描述了两种不同的行为，以便处理一个简单事件或处理多个事件。处理单个进入的事件一个可能的基础处理模式就是 “发布/订阅”。当一条事件消息在事件总线层面上被接收到后，它将被发布服务子层拦截，并分发到由事件总线管理员（Event Bus Administrator）配置的各种通道。这些通道在事件注册表中发布，以便对事件使用者或订阅服务组件可用。事件使用者访问事件注册表，以便获取与他们感兴趣的事件类型关联的通道的有关信息。事件使用者通过直接监听相关通道来接受事件消息。示例：在车队管理场景中，我们来研究一下 Delivery Change 事件，将 Delivery Management Dashboard 作为一个事件使用者。每当事件总线探测到一个 Delivery Change 事件，相关的事件消息将在一个特定的事件通道上可用。Delivery Management Dashboard 正在监听这个通道。收到一条新的事件消息时，Delivery Management Dashboard 使用它的本地事件处理器（参见 “事件使用阶段”）来处理该消息。也可以是这样一种情况：单个入站事件可能生成多个带有不同格式的出站事件，具体取决于它的负载和针对它表示的订阅请求。事件使用者可以使用订阅服务表示他们对特定事件类型的兴趣。他们还可以设置额外的参数来指定他们收到相关事件的通知的方式。这些参数可能是（部分列表）：将在通知中收到的事件消息的格式将用于接收这条消息的通道事件过滤标准当事件总线接收到一条事件消息时，发布服务子层针对这种事件类型处理每个单独的订阅请求。必要的事件处理服务（主要是过滤、补充和转换服务）被处理来调整这条事件消息。通知服务推动生成的事件消息通过请求的通道，到达事件使用者。示例：在公共健康警报场景中，我们将 “General Practitioner” 作为事件使用者，“Potential Epidemic Outbreak Alert” 事件是它发送的事件。General Practitioner 订阅健康警报事件，因为他希望在他的领域中每当出现一个 Potential Epidemic Outbreak 警报时他都能得到电子邮件通知，而且他想得到一些关于这种相关疾病的其他信息。事件总线订阅服务应该提供一些设施，允许他浏览可用警报列表，定位一个关于地理位置的过滤器，以便选择他可能感兴趣的其他数据，并选择他喜欢的交付通道。事件总线将使用这些参数来过滤进入的 Potential Epidemic Outbreak 警报事件，使用请求的额外信息补充它们，将其格式化为一封电子邮件，然后推动这封电子邮件穿过通知服务到达使用者。处理多个进入事件这种情况将考虑多个进入事件，这些进入事件可能跨多种类型，可能在一个指定的时期内从多个源发出，这里将其称为一个事件组。通过匹配来自这个事件组的多个事件，在事件总线内部、而不是在事件创建者层面探测一个有意义的业务场景。事件总线实现一个或多个负责执行这种探测的事件处理代理。事件总线管理员将设置一个或多个模式（可能使用订阅服务，或者事件信息管理服务）并将其存储在事件注册表中。这些模式可能包含多个维度，包括偶然性、事件、位置或其他维度。接收到一个事件时，事件查询服务可用于检查事件注册表，检查该事件是否属于一个与有效的模式匹配规则关联的事件组。如果是这样，事件处理服务子层将负责将这个规则应用到这个已接收事件。本例中的事件总线可能一直在等待一个这种类型的事件，因为它已经为这个事件组接收到至少一个事件；或者一个新的处理流可能会被启动，因为目前为止还没有为这个事件组接收到一个事件。这个模式匹配规则的处理将生成一个结果事件，它可能：直接在相关通道中发布通过相关通道处理并传输到感兴趣的订阅者传输到另一个负责另一个处理规则的 EPA，这个事件类型与该处理规则相关联
这可能是一个递归行为，链接起来的模式匹配流程组成了一个事件处理流。时间段通常是事件组的一个重要特征；在考虑事件总线中的事件处理服务的实现时，时间也是一个重要的因素。事件存储库可能在事件处理中扮演重要角色，特别是对于复杂事件处理。它持续跟踪在事件流中处理的事件，不管是进入的事件、生成的事件还是结果事件。
首先，这对实现监控非常有用。例如，要回答这样的关键问题：进入事件的哪个组合或事件处理代理的哪个序列导致了这个结果？其次，由于事件组可以在一个较长的时期内考虑，因此可能需要持久化相关事件。
示例：在车队管理场景中，我们研究一下 “Delivery Driver Exceeded Driving Time” 代理和一些关联事件：“Driver starts working” 和 “Driver ends working”。这个事件组的特征是这两种事件类型和一个超过 8 小时的时间段。每当在事件总线层面上接收到一个针对一个特定 Driver ID 的 “Driver starts working” 事件，一个 EPA 应该被启动，以便等待这个 Driver ID 的 “Driver ends working” 事件。如果这个事件比最初的事件延后了 8 个小时以上，一个结果事件 “Driver Exceeded Driving Time” 将被发出。在公共健康警报场景中，我们来研究一下 “Potential Epidemic Outbreak Alert” 事件和事件使用者 “Match Potential Epidemic Outbreak Alerts” 代理。这个事件组的特征是 Potential Epidemic Outbreak Alert 事件类型和一个两周的时间段。每当事件总线接收到一个这种类型的事件消息，该消息将被传输到一个实现以下代理模式匹配逻辑的 EPA：如果在不到两周的时间内从 10 个不同的源收到一个 Potential Epidemic Outbreak Alert，则应该发出一个 Pandemic Outbreak Alert。事件使用阶段这个阶段主要发生在与事件使用者关联的事件处理器层中。与事件发送阶段类似，这个层既可以扮演一个技术角色，也可以充当一个更面向业务的角色。技术视角在这个阶段，事件使用者从事件总线接收一条事件消息并处理该消息，处理过程依赖于它的本地事件处理器层。事件适配器子层负责接收事件消息并提供与事件总线支持的传输协议的接口。可能有一个事件消息的初步处理，这在本地事件处理子层实现。比如，这可能是事件消息负载的一个技术调整，以便遵循事件使用者特有的输入格式。事件编排（Event Orchestration）子层识别业务逻辑片段，这些业务逻辑用于实现与这条特定事件消息的接收关联的操作。事件编排子层启动这个逻辑的执行，使用这条事件消息的可选转换负载作为输入参数。示例：在车队管理场景中，我们来研究一下 Delivery Change 事件，Delivery Management Dashboard 作为它的事件使用者。Delivery Management Dashboard 实现为一个门户。本地事件处理器通过一个 WebSphere MQ 消息队列连接（本地事件适配器，与事件总线之间的接口）接收到一条新的 Delivery Change 事件消息。本地事件处理逻辑被实现为一个获取事件负载的 portlet，它处理事件负载，更新一些指示器，并修改显示给终端用户的图形。业务视角在更高级的实现中，事件处理器层能够充当多个基础事件消息的一个汇合点。这些基础事件消息在本地事件处理子层中进行匹配。这将生成一个结果事件，它与事件使用者的一个操作关联。这个结果事件然后传输到事件编排层，以便启动事件使用者中的相关业务逻辑。另一方面，单一事件消息的接收可能会生成多个本地处理，因为位于事件使用者端的有关各方可能会以不同的方式对它感兴趣。示例：在公共健康警报场景中，我们将 “Hospital” 当作事件使用者，“Pandemic Outbreak Alert” 事件是它使用的事件。当这样一个事件向 Hospital 发出通知时，由于这个事件引发了一个高度关键的情况，可能会同时对这个事件进行几种方式的本地处理。这个信息可能会通过一个新闻通道直接推送到医院的内联网门户可能会通过一条 SMS 消息召集一些关键的专业人士
这条事件消息可能会被发送到后勤应用程序，以便启动负责管理紧急健康情况的特定流程。将场景映射到概念模型在这个小节中，我们将回顾我们的事件处理场景，并展示如何将它们映射到这个概念架构的组件上。车队管理场景在前面的小节中定义了各种角色（事件创建者和事件使用者）、事件和事件处理代理之后，现在可以将这个车队管理场景映射到这个事件处理概念架构（见图 12）。事件创建者和事件使用者之间的链接很明显。所有代理（除了路由代理 A4）都被映射到事件总线中的事件处理组件。没有对这个概念模型的事件发送器和事件处理器部分的映射，原因是：Driver Report System 生成的两个事件 E1 和 E3 不需要任何特殊处理，可以原样被代理 A1 和 A2 处理，而 E5 可以被所有使用者原样使用。图 12. 车队管理场景中使用的概念架构组件在车队管理场景中，事件处理很重要，因为它允许及时地响应有关司机位置、驾驶时间和送货路径的所有不同信息。它还支持轻松更改有关允许的驾驶时间、送货方式更改等的规则。
公共健康警报场景定义了各种角色（事件创建者和事件使用者）、事件和事件处理代理之后，现在可以将这个公共健康警报场景映射到这个事件处理概念架构（见图 13）。事件创建者和事件使用者之间的链接很明显。事件处理代理和事件发送器之间有一些映射，主要处理被链接到事件总线中的特定组件。没有到这个概念模型的事件处理器部分的映射，因为根据本文描述的这个场景的特点，这种映射是不需要的。
图 13. 公共健康警报场景中使用的概念架构组件完成这个场景的描述后，我们考虑一下事件处理为何对这个公共健康警报示例很重要。由于这个场景与公共健康相关，时间是一个重要因素，事件历史、事件创建者和事件使用者的数量也很重要。理解这三个主要因素很重要，事件处理系统对它们进行了有效的定义：
事件创建者和事件使用者之间的松散耦合 —— 事件的起源不重要（只要事件使用者能够识别质量和来源）。一个非常重要的因素是：一旦探测到事件就立即启动事件处理，一旦识别一个流行病或大流行病爆发就立即提供通知。由于在事件使用者端事件处理系统不依赖业务处理，这支持一个高度灵活和动态的事件处理网络，这个网络能够向大量可能的事件使用者提供价值。
通信服务供应商场景图 14 展示了从通信服务供应商场景到这个事件处理概念架构的组件的映射。图 14. 通信服务供应商场景中使用的概念架构组件结束语本文介绍了业务事件处理的一个概念模型，这个模型由一个构建在事件处理网络上的概念架构构成。这个概念架构展示了如何准备和处理事件创建者生成的事件以供事件使用者使用。这个概念架构包含一个起中介作用的事件总线，它提供一些服务来根据需要过滤、补充、格式化、路由、聚合或分割事件。这个概念架构深入探索了创建者和使用者端可能需要的一些功能，比如一些简单的事件处理功能和事件适配器。这个概念架构的意图是识别实现任何事件处理可能需要的所有组件，但是对于任何特定的实现和场景，预计只需要其中一部分组件。本文介绍了几个场景，展示了如何使用事件驱动的处理来提供业务价值；我们还将这些场景映射到这个概念模型（事件处理网络和概念架构）来展示如何在几个不同的实践场景中应用这个概念模型。我们描述了每个场景，解释了事件处理对这些场景的重要性，列举了实现这些场景所需的创建者、使用者、事件和事件处理代理，展示了到这个概念架构的映射。随着业务事件处理提供的业务价值和机遇受到越来越广泛的认识，拥有一个概念模型和架构就变得更加重要。基于这个概念模型和架构，我们可以构建一些逻辑和物理架构，以便将其用于实现业务事件处理解决方案。
致谢本文作者谨向对此概念模型和本文撰写作出贡献的有关人士表示感谢，他们是：Christopher Ahrendt、Kyle Brown、Koteswara R Chejarla、Norman Cohen、John Dinger、Greg Flurry、Paul Giangarra、Kevin Hall、Robert Heuchert、Beth Hutchison、David H Janson、Jojo Joseph、Chung-Sheng Li、Rahul Narain、Peter Niblett、Dave Russell、Rob Sawyer、Boris Shulman、Michael Spicer 和 Bobby Woolf。
相关主题阅读 Gartner Report
“”（AV-20- 年）。关于
的 IBM 解决方案简述。阅读 IBM Redbook 出版物
，了解更多信息。“”（Etzion、O. Sharon 和 G. Sharon，IBM Systems Journal，Vol 7 No 42，2008 年） 出版了一个事件处理术语表，可从他们的公共网站的 Document Management 部分下载。本文使用的术语遵循这个术语表中规定的术语定义。 在 developerWorks 上的
获取提高您的技巧所需的资源。下载
或 ，并开始使用来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=SOA and web servicesArticleID=550830ArticleTitle=事件处理系统的概念模型publish-date=