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就是您的答案。现在，如果您希望将“路由”（您想要发送数据的指定系列的应用程序端点）基于数据库中的一组可配置规则，该怎么办？好吧，骆驼也可以这样做！有一个端点！无论如何，不​​要做传统的ESB，它的旧和破坏。绝对做骆驼的事情。

如果有帮助，请告诉我。

Answer 2

OSGi规范定义了一个组件“Event Admin”，它是一个轻量级的pub-sub事件子系统。 来自RFC0157：

  

事件管理员指定事件源向其发送事件的方法   事件听众。事件源可以创建具有主题和的事件   属性和请求事件管理员将事件传递给事件   已宣布对特定事件主题感兴趣的听众和/或   财产价值。事件源可以请求同步（和   无序的交付或异步（和订购）交付。

与您的要求相比，它会得分如下：

• 同步和同步传送：检查
• 仅限点对点：否。发布 - 订阅
• 保证交付 - 最好通过文件持久化：否
• 从同一客户端订购的严格邮件（异步模式）：是
• 支持流程到流程： if（process == OSGi service） - ＆gt;是的
• 支持节点到节点：尚未。的家伙们 分布式OSGi一直致力于此，但我没有看到 什么具体的。

我喜欢Camel的概念，但最近决定选择（较轻的）Event Admin，因为我的要求有限。迈克尔对卡尔的动机+1。我会调查它然后在决定之前比较选项。

Answer 3

您不是在寻找ESB吗？ ServiceMix是：

  

灵活的开源集成容器，可将Apache ActiveMQ，Camel，CXF，ODE，Karaf的功能统一为强大功能您可以使用运行时平台构建自己的集成解决方案。它提供了由OSGi独家提供的完整的企业级ESB。

Answer 4

iPOJO Event Admin Handlers是一种更好用的方式来访问@maasg提到的Event Admin服务。

Answer 5

看起来你在这里谈论ESB。如果是这样，那么你可能会看wso2 ESB。它由apache synapse提供支持。它使用OSGi作为模块化框架，以便您可以根据需要添加/删除功能。来自wso2的整个product stack类似于基于相同OSGi核心平台的消息代理，业务流程服务器（ODE）等。

免责声明：我为wso2工作。