den*_*chr 52 integration messaging soa events middleware
我想知道当我们引用SOA或中间件时,以及通常在应用程序和企业集成的情况下,消息驱动和事件驱动的环境之间是否有明显的区别.我知道用户界面类似于事件驱动模型,我们的系统拦截用户的操作.
此外,很明显消息传递支持基于发布/订阅,同步或异步通信,事务等的系统.
但是中间件/ soa /应用程序集成上下文有区别吗？(架构级别).我正在尝试咨询维基百科这样的来源(这里和这里),但我仍然有些困惑.开发人员何时应该选择一种解决方案？
是否存在一种方法或案例,其中一种方法比另一种更有意义？或者是否有任何全面的资源和指南来实施每一个？
非常感谢任何见解.
joh*_*van 52
以下是关于JonasBonér提出的问题的Typesafe/Reactive观点.从这篇博文的第三段开始:
不同之处在于消息是定向的,事件不是 - 消息具有明确的可寻址接收者,而事件恰好发生在其他人(0-N)上以观察它.
Mat*_*ois 27
很久以前就问过这个问题.我认为,一个更加现代化和明确的回应是给定的反应宣言的消息驱动的(相对于事件驱动):
消息是发送到特定目标的数据项.事件是组件在达到给定状态时发出的信号.在消息驱动的系统中,可寻址的接收者等待消息的到达并对它们作出反应,否则处于休眠状态.在事件驱动的系统中,通知侦听器附加到事件源,以便在发出事件时调用它们.这意味着事件驱动系统侧重于可寻址事件源,而消息驱动系统则侧重于可寻址收件人.消息可以包含编码事件作为其有效负载.
sdg*_*sdg 20
对"有明显区别"的简短回答是"否".
这些术语不是可以互换的,但暗示了相同的基本架构 - 特别是您将触发事件或消息.
您引用的第一篇文章是关于代表您传输消息的低级管道,MOM或pub-sub"总线".事件驱动的体系结构是您在该框架之上构建的.
事件驱动这个术语虽然也适用于GUI代码,但并不是真正处于同一抽象层次.在这种情况下,与沿着消息/事件驱动的行构建整个企业相比,它是一种小型模式.
小智 7
事件驱动的体系结构可以使用或不使用消息传递来实现 消息传递是以可靠,有保证的方式将生产者提出的事件传达给消费者的一种方式.特别是当生产者和消费者真正脱钩并且可能托管在不同的服务器/ VM /环境上并且不能直接访问任何共享内存时.
但是在特定情况下 - 当事件的使用者是在同一应用程序本身内注册的函数/回调时,或者当需要同步执行消费者时,可以在没有消息传递的情况下实现事件订阅.
假设您正在为电子商务网站构建付款服务。下订单后，订单服务将要求您的付款服务授权客户的信用卡。仅当信用卡被授权后，订购服务才会将订单发送到仓库进行包装和运输。
您需要与订购服务团队合作，以了解如何将信用卡授权请求从他们的服务发送到您的服务。有两种选择。
事件驱动方法的优点是其他服务也可以订阅各种事件。例如，可能有一个RevenueReporting服务可以订阅AuthorizationAccepted事件并为Finance团队创建报告。
事件驱动方法的缺点是整个系统变得有点难以理解。例如，假设订单服务团队根据您信用卡被拒的原因（没有资金，帐户关闭，帐单地址错误等）要求您用不同的事件替换AuthorizationDeclined事件。如果您停止发布AuthorizationDeclined事件，是否会中断其他服务？如果您有许多事件和服务，则可能很难跟踪。