Events 应用程序集成的消息驱动与事件驱动方法

我想知道，当我们提到SOA或中间件时，通常在应用程序和企业集成的情况下，消息驱动环境和事件驱动环境之间是否有明确的区别。我知道用户界面类似于事件驱动模型，我们的系统在其中拦截用户的操作

此外，很明显，消息传递支持基于发布/订阅、同步或异步通信、事务等的系统

但是在中间件/soa/应用程序集成上下文中有区别吗？（架构级别）。我试图查阅维基百科（，和）等资料，但我仍然有些困惑。开发人员什么时候应该选择一种解决方案而不是另一种

是否有一种方法比另一种方法更有意义的例子或案例？或者有什么全面的资源和指南来实施每一项

非常感谢您的见解。

对于“是否有明确的区别”的简短回答是“否”

这些术语并不完全可互换，但暗示了相同的基本体系结构——特别是您将触发事件或消息

您参考的第一篇文章是关于低级管道的，即代表您传输消息的MOM或pub sub“总线”。事件驱动体系结构是在该框架之上构建的

---

“事件驱动”一词虽然也适用于GUI代码，但实际上并不处于同一抽象级别。在这种情况下，与沿着消息/事件驱动的路线构建整个企业相比，这是一种很小的模式。

事件驱动的体系结构可以在有消息或无消息的情况下实现。消息传递是以可靠、有保证的方式将生产者引发的事件传递给消费者的一种方式。特别是当生产者和消费者真正解耦，可能托管在不同的服务器/虚拟机/环境中，并且无法直接访问任何共享内存时

但是在特定情况下-当事件的使用者是在同一应用程序本身中注册的函数/回调时，或者当使用者需要同步执行时，则可以在不发送消息的情况下实现事件订阅。

正如本文中所说，为了理解事件驱动的设计，与其看它呈现什么，我们必须观察它隐藏了什么，这只是编程的基础；“调用堆栈”

在事件驱动设计中，方法调用的定义就在窗口之外。不再有呼叫者和被呼叫者。这是对通话顺序和顺序的告别。系统不需要知道事情发生的顺序。因此,， 共享内存空间是调用堆栈的先决条件，它变得不必要了

然而，在调用堆栈环境中，调用方不仅必须知道接下来会发生什么，还必须能够将功能与方法名关联起来

默认情况下，面向消息的应用程序会删除共享内存。发布服务器和订阅服务器不需要共享内存空间。另一方面，所有其他特性（即顺序、方法名称耦合等）都不是必需的

---

如果消息传递是为了符合事件驱动体系结构的公理而设计的，则可以认为它们是相同的。如果我们使用事件驱动的方法，我们通常希望在发布事件的事件组件中发送源对象。因此，在subscriber中，我们不仅可以获得数据，还可以知道是谁发布了此事件。例如，在移动开发中，我们收到的视图可以是按钮、图像或一些自定义视图。根据这个视图的类型，我们可以在订阅服务器中使用不同的逻辑。在这种情况下，我们甚至可以添加一些后处理，修改源组件-例如，将动画添加到这些源视图中

当我们使用消息驱动的方法时，我们只想发布包含一些数据的消息。这与发布此消息的订户无关，我们只想接收数据并以某种方式进行处理。

以下是Jonas Bonér对这个问题的观点。第三段：

不同之处在于消息是定向的，而事件不是-消息有一个明确的可寻址收件人，而事件只是发生在其他人（0-N）观察它时

---

事件驱动体系结构和消息驱动体系结构是两种不同的东西，它们解决了两个不同的问题

事件驱动体系结构的重点是如何触发系统运行。在EDA上下文中被认为是事件的大多数触发器是通过键盘和鼠标以外的方式生成的事件。这是一个EDA，如果它让我们明确地考虑事件生成器、事件通道和事件处理引擎的话

键盘和鼠标显然是事件生成器，但这些事件的处理已经由各种框架或运行时处理，作为架构师，我们不需要担心。还有一些特定于特定领域的事件是架构师应该考虑的。示例–供应链管理事件–挑选、包装、发货、分销、零售商、销售等。从工业物联网类型应用的技术角度来看，事件包括–RFID读取、生物计量读取、传感器数据、条形码扫描、，系统生成的事件是需要明确注意的事件，因为这些事件驱动系统的功能

---

消息驱动体系结构的重点是通过使用标准的面向消息的中间件将消息从系统的一个模块传递到另一个模块来集成分布式系统。

这个问题很久以前就被提出了。我认为一个更现代、更明确的回答是：

消息是发送到特定目的地的数据项。