OSGi 服务的消息总线

Posted

技术标签:

【中文标题】OSGi 服务的消息总线【英文标题】:Message bus for OSGi services 【发布时间】:2012-02-21 19:17:19 【问题描述】:

我正在进行一个项目,我们将迁移一个基于大量定制技术的主要软件系统,以基于 OSGi 服务。为此,我们可能需要某种与 OSGi 服务配合得很好的消息总线。

同步和异步传送 仅点对点 保证交付 - 最好通过文件持久化 从同一个客户端(异步模式)订购的严格消息,但必须来自不同的客户端 支持进程到进程和节点到节点 nice 但不是严格要求

开源解决方案将是首选,但不是必需的。

我查看了eventbus(如https://***.com/a/1953453/796559 中的建议),但似乎效果不佳。

那么问题是,哪些技术符合上述条件?

【问题讨论】:

【参考方案1】:

您不是在寻找 ESB 吗? ServiceMix 是:

灵活的开源集成容器,将 Apache ActiveMQ、Camel、CXF、ODE、Karaf 的特性和功能统一到一个强大的运行时平台中,您可以使用它来构建自己的集成解决方案。它提供了一个完全由 OSGi 提供支持的企业级 ESB。

【讨论】:

谢谢,这很快 :-) 我会尽快检查 ServiceMix。【参考方案2】:

看起来您在这里谈论的是 ESB。如果是这种情况,那么您可能已经看过wso2 ESB。它由apache synapse 提供支持。它使用 OSGi 作为模块化框架,因此您可以根据需要添加/删除功能。有一个来自 wso2 的完整的product stack,比如基于相同 OSGi 核心平台的消息代理、业务流程服务器 (ODE) 等。

免责声明:我为 wso2 工作。

【讨论】:

【参考方案3】:

托尼,

刚刚来自一个非常相似且成功的项目,请让我与您分享我的经验,以节省您一些时间并为您的公司节省一些钱。首先,ESB 在 8 年前被提出时是一个非常好的主意。而且,他们解决了一个重要问题:您如何以那些讨厌的编码人员能够理解的方式定义业务问题?目标是开发一个系统,允许业务人员创建一个软件解决方案,几乎不需要或不需要烦人的开发人员交互,这样可以更好地花在管理奖金上的钱。

为了回答这个问题,许多组织的优秀人员提出了 JBI、BPMN 和许多其他解决方案,让业务人员可以对他们想要“数字化”的业务流程进行建模。但实际上,它们都存在一个非常关键的缺陷:它们解决了业务问题,但没有解决集成问题。因此,除非由一些高价顾问完成,否则其中许多实施都是不成功的,即便如此,您的前景也很渺茫。

与此同时,一些非常聪明的人在 90 年代后期出版了一本名为“企业集成模式”的书,其中确定了 60 多种用于解决常见集成问题的设计模式。许多执行 ESB 工作的人意识到他们的问题不在于业务建模。相反,问题是如何集成他们现有的应用程序。为了帮助解决这个问题,Michael Strachan 和一些非常聪明的人开始了 Apache 软件基金会项目“Camel”。 Camel 是企业集成模式的严格实现,此外还有大量组件,旨在让您和我这样的人将东西连接在一起。

因此,如果您认为您的业务流程只是需要将数据从一个应用程序发送到另一个应用程序,并在两者之间进行适当的数据转换,那么 Camel 就是您的答案。现在,如果您想根据数据库中的一组可配置规则建立“路由”(您想要发送数据的一系列指定应用程序端点)怎么办?好吧,骆驼也能做到!有一个终点!无论如何,不​​要做传统的 ESB,它陈旧而破败。并且绝对做骆驼的事情。

如果这有帮助,请告诉我。

【讨论】:

感谢 cmets。我完全同意。我正在寻找一种非常低级的方式来帮助以通用方式跨更大的产品库连接服务……我不是在寻找任何类型的业务建模。所以......我会看看骆驼,看看它可能适合......【参考方案4】:

OSGi 规范定义了一个组件“Event Admin”,它是一个轻量级的发布-订阅事件子系统。 来自 RFC0157:

Event Admin 指定事件源向其发送事件的方法 事件监听器。事件源可以创建带有主题的事件,并且 属性并请求事件管理员将事件传递给事件 已宣布对特定活动主题感兴趣的听众和/或 属性值。事件源可以请求同步(和 无序)交付或异步(有序)交付。

与您的要求相比,它的得分如下:

同步和异步传送:检查 仅点对点:没有。发布订阅 保证交付 - 最好通过文件持久性: 从同一客户端订购的严格消息(异步模式):YES 支持进程到进程:if (process == OSGi service) -> Yes 支持节点到节点:还没有。的家伙 分布式 OSGi 一直在做这个,但我还没有看到 任何具体的东西。

我喜欢 Camel 的概念,但由于我的要求有限,最近决定使用(更轻的)Event Admin。就骆驼的动机向迈克 +1。我会研究一下,然后在决定之前比较选项。

【讨论】:

【参考方案5】:

iPOJO Event Admin Handlers 是访问@maasg 提到的事件管理服务的更好用方式。

【讨论】:

以上是关于OSGi 服务的消息总线的主要内容,如果未能解决你的问题,请参考以下文章

如何在服务总线队列触发功能中将服务总线消息移动到死信

马蜂窝消息总线——面向业务的消息服务设计

面向业务的微服务消息总线

Azure 服务总线:啥是“请求”和“消息”?

函数应用无法从 Azure 服务总线获取消息

消息总线 vs. 服务总线 vs. 事件中心 vs. 事件网格