(window.slotbydup=window.slotbydup || []).push({
id: '2014386',
container: s,
size: '234,60',
display: 'inlay-fix'
&&|&&1次下载&&|&&总100页&&|
您的计算机尚未安装Flash，点击安装&
阅读已结束，如需下载到电脑，请使用积分（）
下载：40积分
0人评价5页
0人评价5页
0人评价7页
0人评价2页
0人评价8页
所需积分：（友情提示：大部分文档均可免费预览！下载之前请务必先预览阅读，以免误下载造成积分浪费！）
（多个标签用逗号分隔）
文不对题，内容与标题介绍不符
广告内容或内容过于简单
文档乱码或无法正常显示
文档内容侵权
已存在相同文档
不属于经济管理类文档
源文档损坏或加密
若此文档涉嫌侵害了您的权利，请参照说明。
我要评价：
下载：40积分您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
提升媒体应对能力 抓实声誉风险管理.pdf 4页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：100 &&
提升媒体应对能力 抓实声誉风险管理
你可能关注的文档：
··········
··········
现代商业银行昆锄
商业银行作为高风险、高信用
行创新产品等，严重影响了相关商业
的风险。巴塞尔委员会在2009年1月
的金融企业，需要依靠信誉和公众
银行的声誉和整体形象，个别媒体的
就新资本协议征求意见稿中明确将
信心维持运转。商业银行作为经营
负面报道起到了推波助澜的作用。
声誉风险列为第二支柱，成为商业银
信用的企业，对声誉具有独特的依
笔者根据在商业银行二级分行
行的八大风险之一，并指出银行应将
赖性，需要在新闻媒体保持一个正
从事着媒体危机应对与声誉风险管
声誉风险纳入风险管理的流程中。
面的社会形象。客户将资金存进银
理的工作实践，深感商业银行的声
商业银行声誉风险是一种次生风
行换取一个没有 自身价值的凭证 ，
誉风险管理工作责任重大，需要全
险，声誉风险事件则指已被媒体获
靠的是对商业银行声誉的肯定和信
行上下共 同努力，切实提升媒体应
悉或报道的，可能或 已经对商业银
用的信赖 。所以说声誉是各家商业
对能力。特别是必须加强商业银行
行形象、声誉、品牌价值造成负面
银行的生命线，只有具备 良好的声
对一线媒体应对管理 ，商业银行各
影响或损害的事件。商业银行必须
誉和杰出的服务才能有忠实的客户
分支机构、各级领导 、全体员工都
清醒地认识到，银监会等上级机关
和优秀的人才，才能形成商业银行
必须高度重视，必须及时报告各类
关于声誉风险管理的规定，就是商
业务发展的良性循环。而商业银行
声誉风险，通过各层面紧密协作，
业银行各级机构开展媒体危机应对
一 旦遭遇媒体的负面报道进而导致
正确应对和化解客户 向媒体的投
和声誉风险防控工作的主要依据。
声誉危机、产生声誉风险，不仅会
诉，才能进一步防止媒体负面报道
必须切实提升商业银行全行上下声
直接损害商业银行的信誉，影响上
危机的发生，坚决维护好商业银行
誉风险管理工作的规范化 、系统
市商业银行在资本市场的表现，导
的正面社会形象。为此，深感必须
化 、科学化 ，进一步强化做好突发
致商业银行品牌价值损失，甚至会
从以下几个方面，下大力气 、化大
性媒体危机应对管理工作，提高全
危及商业银行的生存 。研究表 明，
功夫来抓好商业银行媒体危机应对
行对突发新闻事件的防控能力和处
声誉因素在某些时候甚至比财务业
与声誉风险防控管理。
置效率，防范声誉风险事件发生，
绩更能提升或挫伤一家商业银行的
不断提升商业银行的知名度和美誉
一 、 商业银行必须高度重视，
度，为商业银行整体发展创造 良好
随着社会经济的发展和金融改
学好学透声誉风险管理规定
的舆论环境。
革的推进，群众维权意识的增强，
何谓 “商业银行声誉风险”，
各界群众和客户向新闻媒体对商业
中国银行业监督管理委员会在 《商
二、商业银行应增强紧迫感，
银行金融服务的投诉逐年增多。主
业银行声誉风险管理指引》作的定
正视当前声誉风险管理中存在
正在加载中，请稍后...扫描或点击关注中金在线客服
使用财视扫码登陆
下次自动登录
其它账号登录：
||||||||||||||||||||||||
&&&&>> &正文
银行一线员工声誉风险管理应对三字诀
作者：佚名&&&
中金在线微博微信
扫描二维码
中金在线微信
　　互联网+背景下，银行声誉风险管理中最为突出的难点是自媒体舆情监管和一线员工声誉风险应对水平的提升。而在日常的声誉风险管理中，银行往往过度强调整体的应对策略，而忽略掉岗位人员以外，特别是一线基层员工的应对技巧，以往诸多声誉风险事件中，很多都是由于一线员工的不恰当应对使得风险升级，造成了更深一步的负面影响，如某行微博门等等。
　　那么，是否有一种较为简单、实用的应对指南，可以迅速提升一线员工的应对水平呢？笔者结合当下声誉风险环境的特色，以及银行业一线员工工作实际情况，模仿“三字经”的形式，将每个应对步骤提炼成朗朗上口的三字经，希望其朗朗上口、简单易记的特色，可以成为诸多银行一线员工应对声誉风险时的小指南。
　　其中，总体应对策略的9字方针的形成，受到了贝叶思信息咨询公司杨昌龙总监相关论述的启发，在此表示感谢。
　　一、一线员工声誉风险技能现状
　　尽管大部分银行都制定了声誉风险管理办法及相应的应急预案，但是往往除岗位人员例行公事学习领会外，绝大部分一线员工，特别是支行柜面人员、低柜、服务人员等都很难真正掌握。对于肩负各项指标任务的一线员工而言，不仅有诸多业务资格考试需要面对，行内的各类专项技能培训也种类繁多，在这样繁忙紧张的工作中，很难拿出时间、精力对业务技能以外的声誉风险应对进行学习，也就当然给予不了足够的重视。因此，各类声誉风险防控策略、技巧很难下沉到一线，更多停留在岗位人员层面。
　　同时，无论是银行内部的声誉风险管理办法还是应急预案，在语言文字描述上，与其他各项规章制度一样，难免有些繁文冗节，对于一线员工而言，过于教条化，且很多步骤不合实际。正如很多一线员工所言，就像天书一样，一时摸不清头脑，更谈不上遇事时照章办事了。
　　因此，破除原有办法、预案，为一线人员制定简易的，切实可行的指南，简单快速提升一线人员应对水平在当下是十分有必要的。
　　二、一线员工声誉风险应对指南详解
　　如果将声誉风险比作火灾，那么一线员工就是发现火灾的巡查人员和首批赶赴现场灭火的消防人员，总体应对上，就应该有一个简单明确的指导方针，我们将这一应对策略总结为9字方针：早发现，准应对，防扩散。
　　1、早发现
　　早发现阶段要点可以总结为9字口诀：早识别，早上报，早面对。
　　往往一线员工在遇到突发事件、声誉事件时，存在为难情绪，畏难情绪，这就导致了实际应对中，不敢与正确面对，或者一味回避、置之不理，简单瞒报，妄想舆情自生自灭，或者一味粗暴压制，变成恐吓客户，阻拦客户表达合力诉求的拦路虎。
　　遇到突发问题后，一线员工最重要的就是正确面对，尽早识别，如果在能力范围内，能够当面、尽早解决的，尽量换位思考为客户解决问题，换来回头客，赚取口碑，赢得口口相传的好评，收获更多客户。超出业务、权限范围，就应该及时上报，求助于总分行相关条线、部门，协调解决，疏导客户情绪，起到防患于未然的效果。
　　因此，这一阶段，突出一个“早”字。快速响应，积极面对是缓解声誉风险的首要任务。
　　2、准应对
　　准应对阶段要点为9字口诀：不乱说，防钓鱼，留证据。
　　如果突发上升为舆情，客户诉诸媒体，或者在自媒体微信、微博，网站论坛等发布信息，或者到网点强拉横幅，聚众闹事，厅堂喧闹等，就应该准确应对防范事件和舆情的进一步升级，力求将事态拉回到可控范围内。因此，这一阶段的要点是少而精。
　　少，即少说，少做，少盲目应对；精，既是精准应对，也是精明应对。对于客户的情绪把握，引导的时机等要拿捏好，同时，必要时，对于客户的不合理诉求，甚至是恶意敲诈、勒索等，务必留存好证据。具体而言，就是尽量将客户引导至有监控的环境进行沟通、商讨，对于形成的一些共识、结果，要形成书面文字，留存好法律证据，以备后患。
　　3、防扩散
　　防扩散阶段要点为12字口诀：统一口径，协同作战，灵活引导。
　　如果事态进一步扩散，声誉风险的主战场其实已经由一线网点、部门转移到总分行一级专业岗位人员及高层管理人员身上，这一阶段一线员工作为非专业人员，要做的就是谨言慎行，避免帮倒忙。
　　这并非言过其实。在一些外资企业对内的岗位人员守则中，会有一条国人看来不近人情的规定，那就是发生火灾时，非专业人员要做的是迅速撤离现场，违者将受到处罚。对于很多国人而言，这种情况下，一定要首当其冲，做好事，责无旁贷，但是从专业角度，非专业人员不仅不能正确处理火灾，而且还可能给消防人员后续灭火带来不必要的麻烦，更有可能造成无谓的牺牲，因此，撤离现场就是最好的帮忙。
　　对于声誉风险工作也一样，到了最后应对阶段，一切应该放心交由总分行处理应对，一线就是要统一声音、统一步调，按照部署，严格执行。微博上经常戏谑“不怕狼一样的对手，就怕猪一样的队友”，这个时候，一线员工切忌为敏感应对添乱。
　　三、一线员工声誉风险应对三字诀
　　综上，从易懂、易记、易行角度，形成简单、押韵的三字诀，作为一线应对指南。由于三字诀为笔者结合多年一线工作提炼而成，烦请转载时注明出处。
　　遇突发，莫慌乱，笑脸迎，耐心办。
　　看苗头，观动向，啥意图，得明辨。
　　不隐瞒，莫压制，别回避，面对面。
　　搞不定，要上报，寻部门，找条线。
　　不乱说，莫妄言，按步骤，启预案。
　　上门闹，忌急躁，监控下，把事谈。
　　理诉求，清权限，留证据，存档案。
　　拒采访，防钓鱼，统口径，齐防范。
　　自媒体，要重视，少评论，不乱转。
　　面舆情，防扩散，人人有，任在肩。
　　(作者单位：青岛银行)
责任编辑：cnfol001
好消息！还在为选择留学院校而苦恼吗？还在为复杂的移民申请流程而心烦吗？818出国网微信号汇聚最新的出国资讯，提供便捷的移民留学项目查询和免费权威的专家评估，为你的出国之路添能加油！
微信关注方法：1、扫描左侧二维码：2、搜索“818出国网”（chuguo818）关注818出国网微信。
我来说两句
24小时热门文章
栏目最新文章苹果/安卓/wp
积分 39656, 距离下一级还需 16239 积分
权限: 自定义头衔, 签名中使用图片, 隐身, 设置帖子权限, 设置回复可见, 签名中使用代码
道具: 彩虹炫, 涂鸦板, 雷达卡, 热点灯, 金钱卡, 显身卡, 匿名卡, 抢沙发, 提升卡, 沉默卡, 千斤顶, 变色卡, 置顶卡
购买后可立即获得
权限: 隐身
道具: 金钱卡, 彩虹炫, 雷达卡, 热点灯, 涂鸦板
危机处理的基本原则和基本对策_危机处理的程序和基本措施危机处理的基本原则
　　处理危机事件、实施危机管理时，绝对不能随心所欲，必须按照一定的原则，妥善地加以处理，用稳妥的方法赢得公众的谅解和信任，尽快恢复组织的信誉和形象。应当遵循的基本原则有下面几项：
　　一是积极性原则。
　　遇到危机的出现，就要有负责的积极的态度调查、了解、分析、判断、决策的工作当中去，寻求最佳的解决方案，争取专家的帮助和公众的支持与谅解，这是危机公关的起码态度。
　　二是主动性原则。
　　组织内部的人员就要挺身而出，勇于承担责任，寻找解决问题的契机，变被动为主动，使不利因素变为有利因素。　　三是及时性原则。
　　危机公关的目的在于尽最大可能地控制事态的恶化和蔓延，把因危机造成的损失减少到最低程度，事件发生后，公关人员要迅速做出反应，果断进行处理，赢得了时间就等于赢得了形象。　　四是冷静性原则。
　　要沉着、冷静、富于理性精神。更不能急躁，随意，信口开论。稳定而积极处理危机.应付自如。
　　五是真实性原则。
　　产生种种猜疑误解，甚至会流传出许多谣言。本着实事求是的态度，公布事实真相，让事实说话，才能防止流言蔓延，影响组织的形象。
　　六是责任性原则。
　　要勇于承担责任，做到不推卸，不埋怨，不寻找客观理由。这样才能赢得社会的谅解和好感。
　　七是善后性原则。
　　做好危机事件后的善后工作，包括对公众损失的补偿，对社会的歉意，对自身问题的检讨等等。
　　八是灵活性原则。
　　进行有针对性、灵活性的处理。由于危机多属于突发性的，不可能有既成的措施和手段。因此，根据实际情况，灵活处理很重要，也很关键。危机处理的基本对策
　　危机处理的对策包括总对策和具体对策：
　　总的对策：重视事实，迅速调查，妥善处理，做好善后工作，再造组织形象。
　　具体对策：根据不同的公众对象分别采取不同的对策。
　　第一， 对上级有关部门。及时请示汇报，及时报告事态的发展，求得上级部门的指导。对外回答敏感问题之前，须向上级部门请示报告，严格按照统一的口径对外发布信息。
　　第二， 对企业内部员工。迅速而准确地把事件的发生和将采取的对策告知员工，使大家齐心协力，共渡难关；　　第三， 对受害者。认真了解受损情况，实是求事地承担责任，并诚恳道歉。冷静地倾听受害者的意见，受害者要求给予重视。 给受害人以同情和安慰，避免出现为自我辩护的言行，保持与受害者的联系。
　　第四， 对新闻界。主动与新闻界取得联系，向新闻界提供事实真相和相关的信息，并表明自己的态度，并与新闻界取得谅解，争取新闻界的合作。公开宣布发布新闻的时间，并按照规定的时间发布新闻，在部分事实结果没有明朗之前，不信口开河，盲目加以评论。 充分利用新闻媒介与公众沟通，引导和控制舆论局势。 如果有关危机的新闻报道与事实不符，应及时予以指出并要求更正。但应保持冷静和理性的态度。及时对新闻界的合作表示感谢。危机处理的程序和基本措施
　　当危机不可避免地发生后，所要做的就是如何减少损失，挽回形象。危机处理的基本措施可从危机处理的四个过程来加以说明：　　第一，立即调查情况、制定计划以控制事态的发展。
　　在危机处理时，首先应组织有关人员，尤其是专家参与，成立危机处理小组，对危机的状况做一个全面的分析：危机产生的原因是什么?发展状况及趋势如何?受影响的公众有哪些?谁是危机的直接受害者、间接受害者和潜在受影响者?具体受影响的程度如何?他们可能希望通过什么方式予以解决?危机信息对外扩散的发布渠道和范围是怎样的?这些问题必须弄清楚，因为这将是企业采取补救措施的直接依据。在找到这些依据之后，就可以根据这些依据来制定相应的对策。时间和公开化仍是此阶段的要素，如果有必要，甚至可以每天向外界宣布调查的进展情况。　　第二，迅速反应，把握主动，积极沟通，有效管理信息的进与出。
　　危机的属性就是公开性，危机处理可以说就是危机沟通。在传播与沟通中，企业一定要掌握报道的主动权，也就是要“说真话，赶快说”。因为一旦外界通过其他渠道了解到某些事实真相，将会使组织陷于非常不利的局面。办法是由发言人以最短时间发表坦诚的声明，承诺将迅速对危机进行处理，并及时对外通报。及时安排准确的信息披露，以进行有效的舆论引导，避免媒体的炒作。例如，三菱汽车频发的事故引起舆论警觉后，又爆出该公司23年来蓄意隐瞒客户投诉的消息，结果三菱被迫在全球范围内召回近百万辆问题汽车。在蒙受巨大经济损失的同时，也失去了消费者的信任，而这种损失无法用金钱估算。
　　第三，当组织与公众的看法不—致，难以调解时，必须靠权威发表意见。
　　要善于借助公证性和权威性的机构来帮助解决危机。邀请第三方协助调查，以赢取公众信任。事实证明，在很多情况下，权威的介入将对危机处理起决定性作用。例如，雀巢公司的“奶粉风波”恶化后，成立了一个由10人组成的专门小组，监督该公司执行世界卫生组织规定的情况。这些人中有著名医学家、教授、公众领袖乃至国际政策专家。此举大大加强了公司在大众心中的可信性。　　第四，做好善后工作，尽快挽回声誉。
　　特别是出现重大责任事故，导致社会公众利益受损时，组织必须承担起责任，给予公众一定的精神补偿和物质补偿。在进行善后处理工作的过程中，必须做到一个“诚”字。例如，美国福特因为凡士通的问题轮胎名声大受影响。为挽回损失，公司耗资350万美元在全美200多家知名网站上刊登了一则告示：“有关凡士通轮胎一事，请点击福特的正式新闻主页。”主页上介绍了更换轮胎的地址、公司新闻公报以及联系方式。福特这则广告所传达的信息是：请相信我们的努力，一切问题都可以得到解决。调查显示，广告刊出后的头7天，点击数达到5000万次。虽然福特因轮胎事件声誉受损，但随后进行的大规模的广告活动至少证明它是一家负责任的企业。
支持楼主：、
购买后，论坛将把您花费的资金全部奖励给楼主，以表示您对TA发好贴的支持
载入中......
&nbsp&nbsp|
&nbsp&nbsp|
&nbsp&nbsp|
&nbsp&nbsp|
&nbsp&nbsp|
&nbsp&nbsp|
如有投资本站或合作意向，请联系（010-）；
邮箱：service@pinggu.org
投诉或不良信息处理：（010-）
论坛法律顾问：王进律师事件处理系统的概念模型
简介很多领域中的企业过去总是以一种事件驱动的方式经营，且必须每天处理不断增加的业务事件和交易。事件处理（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=