osgi - OSGi 服务的消息总线

Question

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

同步和异步传送

仅点对点

保证交付 - 最好通过文件持久化

从同一客户端(异步模式)订购的严格消息，但必须来自不同的客户端

对进程到进程和节点到节点的支持很好，但不是严格要求的

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

我看过 eventbus (如 https://stackoverflow.com/a/1953453/796559 中推荐的那样)，但这似乎效果不佳。

那么问题来了，哪些技术符合上述要求？

Answer 1

托尼，

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

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

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

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

请让我知道这可不可以帮你。