当我在看EDA时候

知识准备

关键词解释：

iBPM：代表智能业务流程管理(Intelligent Business Process Management)
SOA：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
CEP:复杂事件处理 (CEP) 处理同时发生的不同事件，以确定这些事件对应的操作。事件通道中的事件可以有不同的事件类型，并且可以长期发生。可以根据内容、时间或位置来关联事件。因此，CEP 通常用于检测异常、风险，甚至业务机会，旨在利用相比传统报告解决方案更具现时性的信息的优势，最终在竞争中占据上风。
EDA：一个事件驱动框架（EDA）定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。这种事件传送方法在基于消息的系统里就是:储存（store）和转送（forward）。
ESP:在事件流处理 (ESP) 中，除了“相关”事件以外，“通常的”事件（如所有一般指令或 RFID 事件）也会发布到事件通道中。这对事件处理提出了更高的要求，同时也提供了更多评估选项。
SEP:在简单事件处理 (SEP) 中，只有“相关”事件才会被放入事件通道中进行处理。比如“XY 类别的汽车已售罄”或“冬季轮胎库存紧张”。这非常类似于基于消息的系统。处理逻辑评估事件类型和内容，然后相应地做出反应。
MDM:MDM 提供通用组件（或服务）以确保数据维护和分发的一致性。
FP
FRP
10.RP
11.ESB:Gartner 于 2002 年创造了术语“企业服务总线”，分析师 Roy Schulte 进一步引入这个术语来描述当时市场上的一类软件产品。10 年后，关于 EBS 到底是什么或者它应该提供什么依然没有达成共识。根据制造商和来源的不同，有很多不同的定义。其中，ESB 的定义包括：
“一种集成架构样式，支持提供者和服务用户之间通过由各种点对点连接构成的公共通信总线进行通信”
“企业用来集成应用程序环境中服务的基础架构。”
“一种架构模式，使用面向服务支持异构环境之间的互操作性。”

一、EDA

1.1 EDA定义

Gartner在2003年引入了一个新术语事件驱动架构（Event Driven Architecture，EDA), 主要用于描述一种基于事件的范例。EDA 是一种用于进行设计和实现应用和系统的方法—在这些应用和系统里, 事件所触发的消息可以在独立的、非耦合的组件和服务之间传递，这些模块彼此并不知晓对方。这些应用程序中的EDA极大地改进了企业或政府响应不同的、表面上毫无关联事件的能力。通过提供瞬时过滤、聚合和关联事件的能力，EDA可以快速地检测出事件并判断它的类型，从而帮助组织机构快速、恰当地响应和处理这些事件。通常事件可以采用发布/订阅机制。

1.2 事件驱动架构概述

一个事件驱动框架（EDA）定义了一个设计和实现一个应用系统的方法学，在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器发布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理把这个事件转送给相应的事件消费者。如果这个事件消费者是不可用的，事件管理者将保留这个事件，一段间隔之后再次转送该事件消费者。这种事件传送方法在基于消息的系统里就是:储存（store）和转送（forward）。

构建一个包含事件驱动构架的应用程序和系统，会使这些应用程序和系统响应更灵敏，因为事件驱动的系统更适合应用在不可预知的和异步的环境里。

事件驱动架构在具体实现中是指由一系列相关组件构成的应用，而组件之间通过事件机制完成一定的业务功能。由于在一个EDA系统中各个组件都只专注于处理输入的消息与发布输出的消息，因而EDA系统能够更有加效地对管道化（pipelined）的、由多软件模块链接而成的并发事件流（concurrent processing of events）进行处理。

1.3 EDA特点

EDA系统中各组件以异步方式响应事件，在本质上是可以并行的，因而在政府部门的电子政务应用中具有极大的优势。其具备以下特点:

◆ 并发执行

◆ 事件触发/数据触发/时间规则触发

◆ 实时/增量响应

◆ 分布式事件系统处理

上述特点能很好地满足政府部门应用需求，如跨部门的应急联动系统或联合监管协同服务等应用。

从目前情况来看，EDA系统还只是处理简单事件的系统，对于复杂事件的处理还有待进一步的研究。但是，EDA仍然能作为SOA系统的一个有效补充，弥补SOA系统的一些不足，如实时响应度不够。

1.4 事件驱动架构优势

事件驱动设计和开发所提供的优势如下所示:

◆ EDA提高了对不断变化的业务需求的响应，最大限度地减少了对现有业务应用的影响，也常消除了对新打包应用的需要。如果采用特有的粗颗粒服务模型可以基于业务目标快速确定可控的业务变更，并直接、迅速、有效地实施变更以达到业务敏捷性和完整性。

◆ 可以更容易开发和维护大规模分布式应用程序和不可预知的服务或异步服务;

◆ 可以很容易，低成本地集成、再集成、再配置新的和已存在的应用程序和服务。

◆ 促进远程组件和服务的再使用，拥有一个更灵敏、没有Bug的开发环境。

从时间维度来看EDA的优势:

◆ 短期利益:更容易定制，因为设计对动态处理有更好的响应;

◆ 长期利益:系统和组织的状态变得更精准，对实时变化的响应接近于同步。

1.5 EDA和SOA之间的关系：

SOA和EDA是平等和互补的。所以，我不认同那些努力传播SOA的同学们所说的“EDA只是SOA的一个子集”的论断。一个更广泛的事件驱动架构概念，不仅是超越事件驱动SOA的，还应该包括实时信息流和分析，以及复杂事件处理。

当EDA认为事件是系统中最重要的组成时，你最好注意那些组件或者服务，以及组件之间的‘通道’”

与Request/Response系统不同的是，要求请求者必须明确发送请求信息，而事件驱动架构提供一个机制去动态响应事件。在一个EDA系统里，事件产生者发布事件，事件消费者接受事件。

业务系统可以从SOA和EDA中受益匪浅，因为事件发生时EDA系统能触发事件消费者，SOA服务可以快速地从相同的消费者中访问、查询。系统要求有最高的响应性，当事件被触发时这个系统必须能快速决定必须的动作。到事件结束，事件应该被发布和消费，而且事件要穿越SOA所有的边界，包括整个体系结构和物理层。

系统要有最高的响应性，当事件触发时这个系统必须能快速决定必须的动作。到事件结束，事件应该被发布和消费，而且事件要穿越SOA所有的边界，包括整个体系结构和物理层。

1.6 ESB连接EDA和SOA

企业服务总线(Enterprise Service Bus，ESB)在异类平台和环境间建立联系，充当允许不同应用程序进程之间进行通信的中间层。部署到企业服务总线的服务可以由使用者或事件触发。它同时支持同步方式和异步方式，可促进一个或多个参与者之间的交互。因此 ESB 可提供 SOA 和 EDA 范例的所有功能。“ESB提供了消息的传输，格式的转换等关键功能，为服务的请求者和服务提供者之间架设了沟通的桥梁，是企业应用基础架构的粘合剂。” 甲骨文公司大中华区高级技术经理黄建勇说。

企业服务总线可连接各个异类节点并作为中介传递其间的所有通信和交互，这些节点可分散在面向服务的体系结构(同步一对一方法)和事件驱动的体系结构(异步多对多方法)中。ESB 是目前处理集成挑战的最有效方法，是可提供最大业务灵活性和不同应用程序间的高效连接技术解决方案。

EDA应用在很多ESB（企业服务总线）产品中，比如FiornaoESB中间件产品支持同步、异步和请求响应事件，事件处理和传输实用不同的技术例如JMS，HTTP，电子邮件和基于XML的RPC等。比如“政府网上监察系统”通过对被监察对象（系统）数据的实时采集，通过EDA技术的事件触发，事件过滤，实现对违规、违法、越权行政、超时限行政等问题进行通知和督办等。

1.7 EDA应用方向

事件驱动架构(EDA)是分布式应用程序的普遍架构形式，非常典型的是:分布式应用程序都被设计成为模块化的、封装的、可共享事件服务的组件。能够通过应用程序、适配器以及无入侵性的代理操作来创建这些服务。

由于EDA的特点，在金融贸易、能源贸易、电信以及欺诈检测这些行业中，一直都在采用事件驱动架构(EDA)技术。近期在我国政府的电子政务建设中

利用EDA分布式处理架构的优势构建共享交换平台，实现跨部门、跨平台、跨应用系统的政务信息资源的共享与交换，并对政府应急系统和跨委办局之间的业务协同办公提供支撑和保障。

EDA

Martin Fowler

二、响应式编程和响应式系统（EP&&ERP）

响应式技术目前成功的标志之一是“响应式reactive”成为了一个热词，并且跟一些不同的事物与人联系在了一起——常常伴随着像“流streaming”、“轻量级lightweight”和“实时real-time”这样的词。

2.1 FRP

FRP定义

2.2 响应式编程Reactive programming，

不要把它跟函数响应式编程混淆了，它是异步编程下的一个子集，也是一种范式，在这种范式下，由新信息的有效性availability推动逻辑的前进，而不是让一条执行线程a thread-of-execution去推动控制流control flow。

响应式编程一般是事件驱动event-driven，相比之下，响应式系统则是消息驱动message-driven的

响应式编程的基本好处是：提高多核和多 CPU 硬件的计算资源利用率；根据阿姆达尔定律以及引申的 Günther 的通用可伸缩性定律Günther’s Universal Scalability Law 脚注3 ，通过减少序列化点serialization points来提高性能。

另一个好处是开发者生产效率，传统的编程范式都尽力想提供一个简单直接的可持续的方法来处理异步非阻塞式计算和 I/O。在响应式编程中，因活动(active)组件之间通常不需要明确的协作，从而也就解决了其中大部分的挑战。

响应式编程真正的发光点在于组件的创建跟工作流的组合。为了在异步执行上取得最大的优势，把反压back-pressure加进来是很重要，这样能避免过度使用，或者确切地说，避免无限度的消耗资源。

2.4 事件驱动 && 消息驱动

响应式编程——专注于短时间的数据流链条上的计算——因此倾向于事件驱动，而响应式系统——关注于通过分布式系统的通信和协作所得到的弹性和韧性——则是消息驱动的脚注4 （或者称之为消息式messaging 的）。

一个拥有长期存活的可寻址long-lived addressable组件的消息驱动系统跟一个事件驱动的数据流驱动模型的不同在于，消息具有固定的导向，而事件则没有。消息会有明确的（一个）去向，而事件则只是一段等着被观察observe的信息。另外，消息式messaging更适用于异步，因为消息的发送与接收和发送者和接收者是分离的。

一条消息就是一则被送往一个明确目的地的数据。一个事件则是达到某个给定状态的组件发出的一个信号。在一个消息驱动系统中，可寻址到的接收者等待消息的到来然后响应它，否则保持休眠状态。在一个事件驱动系统中，通知的监听者被绑定到消息源上，这样当消息被发出时它就会被调用。这意味着一个事件驱动系统专注于可寻址的事件源而消息驱动系统专注于可寻址的接收者。

2.5 响应式系统

响应式系统的基石是消息传递message-passing，消息传递为两个组件之间创建一条暂时的边界，使得它们能够在时间上分离——实现并发性——和空间space ——实现分布式distribution与移动性mobility。这种分离是两个组件完全隔离isolation以及实现弹性resilience和韧性elasticity基础的必需条件。

2.6 响应式系统&&响应式编程

响应式编程是一种管理内部逻辑internal logic和数据流转换dataflow transformation的好技术，在本地的组件中，做为一种优化代码清晰度、性能以及资源利用率的方法。响应式系统，是一组架构上的原则，旨在强调分布式信息交流并为我们提供一种处理分布式系统弹性与韧性的工具。

响应式编程是一个非常有用的实现技术，可以用在响应式架构当中。但是记住这只能帮助管理一部分：异步且非阻塞执行下的数据流管理——通常只在单个结点或服务中。当有多个结点时，就需要开始认真地考虑像数据一致性data consistency、跨结点沟通cross-node communication、协调coordination、版本控制versioning、编制orchestration、错误管理failure management、关注与责任concerns and responsibilities分离等等的东西——也即是：系统架构。

三、CEP

3.1 关键概念

事件指在业务里发生的事情，包括业务活动、流程状态、网络或IT条件，或者其他任何东西。很多事件只要能够识别出来就可以进行处理，通常会伴随着发送警报。当无法可靠处理单个事件而必须在上下文里分析时，就会使用CEP。几乎所有场景里，CEP分析都要求事件能够实时关联，并且要求带有准确时间戳的一定格式。

CEP应用大致分为两大类：事件关联和根本原因分析。通常来说，事件关联用来识别不是单个事件，而是多个事件组合起来触发的条件.

比如“如果你打喷嚏并且发烧了，那么你感冒了。”根本原因分析用来解释一系列事件—通常是错误—的底层原因，确保补救措施并不仅仅针对症状，而是能够真正解决问题。

所有CEP都应该是实时的，或者和事件同时发生，但是，当然这里的同时发生意味着很多种情况。CEP处理的关系越复杂，就越难保证实时性。

3.2 从事件驱动编程（Event-driven Programming)开始

如果你写过GUI程序，对事件处理一定不陌生。事实上，事件驱动编程已经成为一种设计模式。大多数的GUI库都会采用这一模式。

简单的说，事件驱动模式包括三个参与者：事件产生者，事件分发器和事件处理器。

事件产生者（Events Generator）决定是否需要产生事件。比如，GUI上的每个组件都是一个事件产生者，可以根据用户操作产生鼠标事件或者键盘事件。
事件分发器（Events Dispatcher）收集所有事件产生者发出的事件放入事件队列(Events Queue)，并根据事件的类型将事件分发给已经注册的事件处理器。事件分发器通常由GUI框架实现。
事件处理器（Events Handler)根据接收到的事件进行处理，需要GUI框架的使用者自行编写。

事件驱动编程的核心价值在于：程序的执行流程不是预先定义好的，而是由程序的使用者决定的。这将极大增强程序的交互性。

就好像DVD与RPG游戏的区别：前者的剧情是设定好的，你只能进行开始、暂停、快进、回退等有限的交互；后者可以决定主角的行为从而影响故事的结局。

3.3 事件驱动业务（Event-driven Business)

代码的世界不可能是现实世界的完整镜像，但一定是对现实世界的某种抽象，这种抽象能够简化代码世界中对问题的分析和处理。同时，这种抽象还可以反向映射到现实世界，为我们解决现实问题提供思路。

现代企业生存的外部环境处于剧烈的变化之中，“敏捷企业”已经成为生存之道，而事件驱动业务是敏捷企业的一个基本要求。

事件驱动业务（Event-driven Business)，是在连续的业务过程中进行决策的一种业务管理方式，即根据不同时点上出现的一系列事件触发相关的任务，并调度可用的资源执行任务。如果说事件驱动编程能够为软件带来更灵活的交互性和强大的功能，那么企业中的事件驱动业务能够大幅度提高业务的效率和灵活性。

事件驱动业务依托于比较成熟的信息化建设。各个业务应用系统在产生连续不断的数据流的同时，根据定义好的条件产生一些业务事件，按照策略对这些业务事件进行分析处理，触发新的业务事件或者业务流程，即实现了业务的事件驱动。

从上面的描述可以看出，事件驱动业务要求能够快速（毫秒级）、不间断的处理连续、海量的数据，具备灵活的规则或策略设置，从而具备迅速识别、捕获、响应实时业务数据的能力。而传统的企业IT架构通常采用：

在业务应用系统中处理业务操作
遵循固定的业务流程（Business Process）处理跨系统事务，并且这些流程很少变化基于数据仓库进行海量数据的存储及事后分析
这种IT架构远远达不到事件驱动业务的要求。

事件驱动业务能够应用的业务领域很多，凡是需要快速处理连续性数据、需要能够灵活制定策略的业务，都可以采用事件驱动的业务模式。如证券行业常见的风险分析预警（事前及事中风控）、投资决策（程序化交易）、经纪人绩效计算等。

3.2.1 业务事件处理的几个层次

其实在传统的IT架构中，我们已经实现了业务事件的处理。比如在传统的业务应用系统中，我们通常将业务数据存储在数据库中，通过应用系统的操作界面由人工发现和处理业务事件。

这样的处理方式存在两个不足，一是速度慢，二是对于复杂的情况只靠人脑难以处理。于是有了两个技术方向：

消息队列（MQ）对于速度慢的解决办法是用机器代替人工，为了在多个系统之间传递消息，发展出了消息队列（MQ）的技术
商业智能（BI）为了应对复杂性，通过数据仓库将数据整合到一起，并用专门的工具在数据模型的基础上进行分析
但是上述两个方向是正交的：MQ不适合处理复杂性，而BI主要适应于对结构化的历史数据的分析，无法处理“现在”的情况。

3.4 CEP：鱼与熊掌可以兼得

CEP（Complex Event Processing）的出现解决了上述两个方面的问题，在实时性和复杂性方面都得到了很好的解决。

3.4.1 处理数据流

不管是单独的应用系统，还是数据仓库，都是先将数据存储到数据库/数据仓库，然后再处理或查询。而CEP与MQ类似的将数据看作是数据流 。在连续数据的快速移动过程中进行分析处理。这样的方式不需要很大的数据加载，完全可以在内存中进行，从而能够快速产生结果。

3.4.2 处理复杂性

业务事件可能很复杂，在各种不同的数据流中源源不断产生各种类型的事件。需要对这些业务事件进行复杂的计算，如过滤、关联、聚合等，同时还需要考虑这些也是事件出现的时间序列。最终才能产生有意义的事件，或触发业务流程。同时，这些计算的规则可能还会经常变化。

这一类的问题通常通过基于规则的推理机（即规则引擎）来实现。

综上所述，CEP在逻辑上应该包括：

事件发生器通过应用系统、文件系统、数据库、互联网、人工、以及传感器产生事件
事件处理器模式的匹配、验证和改进，路由，转换以及编排
事件消费者与事件发生器类似，也可以是应用系统、文件系统、数据库、互联网、人工界面等

3.5 CEP的三个基本模型及其特性，以及CEP的限制

CEP的最简单方案是触发或者阈值激活处理。该模型里，事件要么直接导致一些操作的发生，要么是当事件达到某个阈值时会执行某个操作。CEP能够在从源到目的地的事件流里引入事件处理，比如在线事务处理，因为生成的延时很小。虽然触发或阈值CEP能够通过单个类型事件实现，但是也可以使用多个不同权重的不同事件来提供对条件更为深入的理解。

第二种模型是上下文模型，该模型假定一个事件或者事件集在某个特定的上下文里才有意义，因此需要维护这个上下文。可以通过模式匹配来完成，意味着查找满足某个模式的特定事件集，或者当事件改变某个显式上下文或状态时通过状态事件处理，随后在上下文理解事件。后一种方案很广泛地用于网络管理，这里上下文示例可能包括初始化，激活或者错误。

对于更为复杂的CEP，可以使用级联分析模型，这里的事件流包括使用某个CEP模型处理的一种或者多种类型的事件。它们并不是直接采取操作加以处理，而是生成其他事件或者事件上下文，随后注入CEP的其他阶段，直到能够最终决定采取什么操作。

综上所述,需要关注的点是：

触发或者阈值激活处理
上下文模型
级联分析模型

四、iBPM

iBPM 代表智能业务流程管理(Intelligent Business Process Management)。Gartner 认为iBPM在 BPM 的基础上增强了复杂事件处理(CEP)、智能机器人和云服务的能力，并在案例管理以及流程协调能力上更为卓越。

Gartner的Jim Sinur最早提出了“iBPM”的概念。实际上，当业务流程管理系统（BPMS）与其他智能工具融合, iBPM便应运而生。这些智能工具包括机器学习、云服务、移动社交、复杂事件处理(CEP)、物联网集成、业务活动监控（BAM)。

把事件技术跟操作联系在一起，让分析结果跟应用集成及有用的商业活动关联，这些对于业务流程管理（BPM）的实践者来说是重要的。

4.1 特点

iBPM有以下一些特点：

更智能的自动化

更智能的路由，由流程机器人自动完成流程工作；

更智能的移动工作

云服务，支持任何地方的流程工作；

更智能实时的分析能力

复杂事件处理（CEP）能力；

4.2 iBPM与BPM的区别

BPM是以规范标准的方式对业务流程进行建模以及执行的一组工具，而iBPM 是BPM的智能提升。从流程发现、设计、建模、执行、监控以及分析优化的流程全生命周期的各个阶段，融合了人工智能、复杂事件处理、云服务和移动技术。

4.3 iBPM 特点

根据Pega System，iBPM中的智能（i）体现在以下几个方面：

动态案例管理：

iBPM支持传统的预设计划和结构化的BPM流程，也支持创建关联知识工作者的动态流程案例。这些动态流程案例反映出融合社交、协作、响应式的新型工作模式，包括异常处理。动态案例可以由多层级的任务组成，也可以响应或触发事务。

社交iBPM：

iBPM在流程生命周期的各阶段融入社交工具。最重要的是，iBPM提供了社交网络在规则协作下的应用场景。

移动iBPM：iBPM允许组织通过移动设备无缝启动和完成端到端的自动化流程工作。流程状态、流程工作和通过移动流程合作的即时性使得全新的移动工作成为可能。
云iBPM：

通过云端的iBPM平台，可以安全建立企业应用程序，也就是iBPM平台即服务（PaaS）；而最终BPM解决方案构建和部署后，iBPM成为可以在云上执行或运行的服务:iBPM软件即服务（SaaS）；

iBPM中的业务规则：

业务规则实现业务决策逻辑和业务策略，这些规则驱动iBPM的解决方案。业务规则有许多类别和类型，如决策树、决策表、约束和表达式。业务规则的重点是使业务逻辑尽可能接近业务，而不必担心执行时间、执行方法或执行顺序。业务规则是声明式的，可以使用预测建模技术来检测业务模式，然后在iBPM的场景中调用或操作已发现的规则；

iBPM用于实时决策的分析和自适应：

行业中最重要的趋势之一是数据科学的出现，特别是大数据分析。预测分析可以通过解开隐藏在大量数字信息中的规律，为组织带来实实在在的好处。 iBPM通过预测和自适应（自学习）分析，使得探寻某些决策具有可操作性。在iBPM中，可执行模型中用以挖掘的数据来源和类型多种多样，涵盖社交网络、事务数据和数据仓库。iBPM运用预测和自适应数据分析模型，在各种动态案例交互中提供更智能化的执行方案。

BPM解决方案是动态的、社会化的、移动的、规则驱动和适应性的。这些解决方案可以不断地分析、学习和适应外部事件，以及三方成员和参与者的行为。 iBPM为适应性企业提供了平台、解决方案、最佳实践、方法和管理方式。

iBPM的研究和技术使得“适应性企业”在商业环境中脱颖而出。通过智能业务流程管理，自适应的企业不断将其经营目标的政策和业务流程完全透明，使得业务流程管理的能见度更高、控制力更强。在未来的商业环境中，适应性企业在应对变化时变得更灵活和主动。毕竟，商业中唯一不变的就是改变！

五、MDM

5.1 MDM 的作用

MDM 的作用是组织如何处理公司实施其业务流程所需的主数据。

主数据管理 — 主数据管理 (MDM) 是旨在确保主数据质量的管理活动。其目的是保证主数据对象适用于公司所有增值流程。MDM 包括所有必要的操作和控制流程，这些流程包含质量保证定义，并保证对主数据对象实施维护和管理。此外，MDM 还提供 IT 组件来映射这个过程。因此，MDM 起着支撑作用，并以隐含的方式从两个方向帮助提高附加值。首先是数据质量管理不断提高主数据的数据质量，从而提升信息的价值；其次是主数据对象对所有核心流程的适用性，从而通过优化的核心流程提高附加值。

主数据对象 — 主数据对象是正式的基本业务对象，在公司内的增值流程中使用。主数据对象描述结构（蓝图）和质量要求（如结构中的验证、允许值）。它们与用户交互，通常将参考数据（值列表）理解为公司的实际主数据。一个典型的例子是标准化的值列表，如 ISO 国家/地区代码和 ISO 货币代码。主数据使用这些列表作为分组、分层和分类的基础。在本文中，主数据不是唯一的参考列表，但都是正式的基本业务对象。

5.2 MDM 系统架构

作为业务转型，MDM 追求的目标是在公司范围内实施主数据管理。要在合理的运营成本下实现这个目标，IT 必须支持这个过程。一方面，这适用于 MDM 本身的手动支持流程，另一方面适用于数据处理和分发的自动化流程。

为此，有必要建立一个清晰的、包括系统相互依赖关系的系统架构。MDM 的系统架构描述目前的形势和计划的目标架构。以下结果对 MDM 发展规划非常有意义：

针对 MDM 发展规划的 IT 总体规划，以基础架构为重点

包含数据模型和数据存储的主数据规划
跨公司信息流（价值和商品的流动）概述
运营流程（影响 MDM 发展规划和支持 MDM 所需的 IT 应用程序系统）的流程规划
设计领域包括包含必要的 MDM 特定系统的应用程序架构、对 IT 组件的支持、主数据物流的集成架构和基础系统架构。检查应用程序系统和候选 MDM 以确保它们提供相应的功能，同时用相应的标准对其进行评估。应用程序和集成组件基于与基础设施架构相互独立的基础架构平台。信息架构对 MDM 有着特殊意义。除了跨公司信息流（价值和商品的流动）以外，信息架构还描述了主数据对象、关联及其属性。

六、ESB

6.1 定义

ESB 是一个中间件解决方案，使用面向服务的模型来促进和支持异构环境之间的互操作性。没有规范准确定义了什么是 ESB 或者它应该提供什么功能。虽然 ESB 主要与“调节”和“集成”这类概念相关，但它还适合作为一个平台以类似于应用服务器的方式提供服务。ESB 代表被称作“集成”和“应用服务器”的产品类别的整合。

image

6.2 关键特性

ESB 的一个关键特性是服务虚拟化。本文提出的 ESB 蓝图提供了各种功能的有序排列，构成了评估 ESB 产品的基础。

6.3 要点

企业服务总线应被视为一个架构样式或模式，而不是一款产品。
ESB 没有定义或规范，因此也没有标准。
ESB 可帮助实现系统间的松散耦合。
ESB 上的服务是无状态的。长期运行的流程不属于 ESB，但是在使用 BPEL 和 BPMN 之类语言的 BPM 系统中受支持。
“误用”ESB 来执行批处理时应小心谨慎，因为可能会对性能产生负面影响

更多详情

关系说明

1. ESP && CSP && CEP

ESP 与 CSP 之间的区别到底是什么？ESP 是流的处理，其中事件流是按时间顺序排列的事件序列，如股票行情自动收录器。而 CEP 工作在称为“事件云”的“云”上。事件云是来自 IT 系统不同部分的多个事件生成活动的结果。事件云可能包含多个流。因此，流是云的一个特殊实例。

在流内使用时间顺序有自己的优点：处理速度快，因为只有少数几个事件需要保存在缓冲区中。但是，依赖关系在云中非常重要：发生了哪些依赖事件？或者通常更精彩的是：或许没有发生哪些事件？

很明显，事件流处理侧重于高速处理，而 CEP 的重点是从事件云提取信息。在实践中，由于 ESP 和 CEP 之间的差别变得模糊，所以更强大的 CEP 占据了主导地位。

2. SOA && EDA

SOA 标识符是服务的松散耦合、客户端在提供者与使用者之间发起的 1:1 通信以及同步响应行为。EDA 的标识符是分离的交互、n:m 通信、事件驱动的操作和异步操作。我们认为没有必要确定一端或另一端。SOA 为 EDA 提供了非常坚实的基础，应用程序可以同时采用这两种风格。在以下情况下，组件应使用 SOA 调用服务：

确切知道要调用哪个服务
服务将只调用一次
期待得到关于服务完成的应答
期待应答
在以下情况下，组件应使用 EDA 发布事件：

在某些情况下，通知所有相关接收方
不知道事件的相关接收方
不知道接收方如何对该事件做出反应
不同接收方对同一事件有不同反应
涉及从发送方到接收方的单向通信

从这方面来说，“2 + 2 > 4”，因为这两种架构风格的组合大于各部分之和。SOA 在执行预定义的流程和逻辑时使用“请求-应答”通信模式（可能是异步方式，请求与响应之间的时间间隔比较长）。相比之下，ED 应用程序使用典型的“发布者/订阅者”模式，在某些情况下可处理大量事件，旨在创建更少的新“可操作”事件。SOA 与 EDA 是相辅相成的：结合使用可以创建按需提供的高商业价值应用程序

2.1 多事件航班

经常乘飞机旅行的人都非常熟悉一个令人不快的问题“我的行李在哪里?”在值机柜台，旅客与行李分离。飞行结束时，旅客需要经过一系列流程才能取回行李，包括：

办票柜台
安检
行李处理
舱门操作
航班操作
机场运作控制 (BAM) 仪表盘
客户服务

最好的临时结果是飞机按时起飞，乘客和行李都在飞机上。然而，我们很多人都知道，可能会发生许多导致事情变得复杂的事件。行李可能在会在办理登记手续与登机之间丢失。乘客可能因安检处排队导致误机。行李可能包含禁带物品，需要搜查。航班可能取消，乘客可能改飞其他地方。乘客办理登记手续后可能决定改签航班。也可能发生其他复杂情况。

在这种情况下，SOA、EDA 或两者的组合

在做决定之前，需要考虑的是：所描述的场景并不是单个“登机服务”或流程。而是一系列相互影响的服务/流程。交互非常复杂，取决于多个边界条件，因此这是一个典型的“感知与响应”场景，或者说是在必要时启动 SOA 服务的 EDA 技术。试图将这种场景统一在一个可执行的流程中势必会陷入一片混乱。

1. 办票:乘客办理登记手续、检查行李
2. 安检:乘客进入/离开安检区
3. 行李处理:在安检站扫描行李、行李装入集装箱
4. 舱门操作:舱门打开、登机、最后登机、关闭
5. 航班操作:登机口、装载集装箱、出发、起飞
6. 客户服务:新航班复查行李

3. SOA 和 MDM

SOA 的一个重要优点是 IT 组件的松散耦合。这有利于组件重用，并且组件可以更轻松、更灵活地支持新功能或新流程 。

MDM 应基于面向服务的概念，并提供通用组件（或服务）以实现数据维护和主数据检索的一致性。在这里，SOA 架构理念再次与 MDM 不谋而合。这一论断支持了两个不同的观点：

MDM 业务服务 — 用于维护和验证主数据的可重用业务逻辑
MDM 信息服务 — 业务流程中使用的可重用信息

4. ESB && EDA && SOA

ESB连接EDA和SOA

5.iBPM && BPM && CEP