我正在进行一个项目，我们将把一个基于大量定制技术的主要软件系统迁移到基于 OSGi 服务。为此，我们可能需要某种与 OSGi 服务配合良好的消息总线。
- 同步和异步交付
- 仅点对点
- 保证交付 - 最好通过文件进行持久化
- 严格的消息从同一客户端（异步模式）订购，但必须从不同的客户端
- 支持进程到进程和节点到节点 不错，但不严格要求
开源解决方案将是首选，但不是必需的。
我查看了 eventbus （如 https://stackoverflow.com/a/1953453/796559），但这似乎效果不佳。
那么问题来了，哪些技术符合上述呢？
I'm in the middle of a project where we will migrate a major software system based on a larger set of custom made technologies to be based on OSGi services. For this we will likely need a some sort of message bus that plays nice with OSGi services.
- Sync and ASync delivery
- Point-to-point only
- Guaranteed delivery - preferable with persistence via files
- Strict message ordered from the same client (Async mode), but necessarily from different clients
- Support for process-to-process and node-to-node nice but not strictly required
Open source solutions will be preferred, but not required.
I have looked at eventbus (as recommended in https://stackoverflow.com/a/1953453/796559), but that does not seem to work well.
So the question is, which technologies match the above?
发布评论
评论（5）
托尼，
我刚刚完成了一个非常相似且成功的项目，请让我与您分享我的经验，以节省您的时间和您的公司的资金。首先也是最重要的一点，ESB 在 8 年前被提出时确实是一个好主意。而且，他们解决了一个重要问题：如何以那些讨厌的程序员能够理解的方式定义业务问题？我们的目标是开发一个系统，允许业务人员创建一个软件解决方案，而几乎不需要或不需要烦人的开发人员交互，这会吸收更好地用于管理奖金的资金。
为了回答这个问题，许多组织的优秀人员提出了 JBI、BPMN 和许多其他解决方案，使业务人员可以对他们想要“数字化”的业务流程进行建模。但实际上，它们都在非常关键的层面上存在缺陷：它们解决了业务问题，但没有解决集成问题。因此，除非由一些高价顾问来完成，否则许多实施都是不成功的，即使这样，您的前景也很粗略。
与此同时，90 年代末一些非常聪明的人出版了一本名为“企业集成模式”的书，其中确定了 60 多种用于解决常见集成问题的设计模式。许多执行 ESB 工作的人意识到他们的问题不在于业务建模。相反，问题是如何集成现有的应用程序。为了帮助解决这个问题，Michael Strachan 和一些非常聪明的人启动了 Apache 软件基金会项目“Camel”。 Camel 是企业集成模式的严格实现，此外还有大量旨在允许像你我这样的人将东西连接在一起的组件。
因此，如果您认为您的业务流程只是需要将数据从一个应用程序发送到另一个应用程序，并在两者之间进行适当的数据转换，那么 Camel 就是您的答案。现在，如果您想将“路由”（您想要发送数据的一系列指定的应用程序端点）建立在数据库中一组可配置规则的基础上，该怎么办？嗯，骆驼也能做到！有一个终点！不管怎样，不要使用传统的 ESB，它已经过时而且已经失效了。绝对做骆驼的事。
如果这有帮助，请告诉我。
Tonny,
Having just come from a very similar, and successful project, please let me share my experience with you to save you some time and your company some money. First and foremost, ESB's were a really good idea 8 years ago when they were proposed. And, they solved an important problem: how do you define a business problem in a way that those pesky coders will understand? The goal was to develop a system that would allow a business person to create a software solution with little or no pesky developer interaction needed that would suck up money better spent on management bonuses.
To answer this the good folks at many organizations came up with JBI, BPMN and a host of other solutions that let business folks model the business processes they wanted to "digitize". But really, they were all flawed at a very critical level: they addressed business issues, but not integration issues. As such, many of these implementations were unsuccessful unless done by some high-priced consultant, and even then your prospects were sketchy.
At the same time, some really smart folks in the very late 90's published a book called "Enterprise Integration Patterns" which identified over 60 design patterns used to solve common integration problems. Many of the folks performing ESB stuff realized that their problem wasn't one of business modelling. Rather the problem was how to integrate thier existing applications. To help solve this Michael Strachan and some really smart guys started the Apache Software Foundation Project "Camel". Camel is a strict implementation of Enterprise Integration Patterns in addition to a huge number of components designed to allow folks like you and I to hook stuff together.
So, if you think of your business process as simply a need to send data from one application to another to another, with the appropriate data transformations between, then Camel is your answer. Now, what if you want to base the "route" (a specified series of application endpoints you want to send data thorugh) off of a set of configurable rules in a database? Well, Camel can do that too! There's an endpoint for that! Anyhow, dont' do the traditional ESB, its old and busted. And Absolutely do the camel thing.
Please let me know if this helps.
OSGi 规范定义了一个组件“Event Admin”，它是一个轻量级的发布-订阅事件子系统。
来自 RFC0157：
与您的要求相比，其得分如下：
分布式OSGi一直致力于这方面的工作，但我还没有看到
任何具体的东西。
我喜欢 Camel 的概念，但最近决定选择（更轻的）事件管理，因为我的要求有限。为迈克的骆驼动机+1。我会先研究一下，然后比较各种选择，然后再做出决定。
The OSGi specification defines a component "Event Admin" which is a lightweight pub-sub event subsystem.
From the RFC0157:
Compared to your requirements, it would score as follows:
Distributed OSGi have been working on this, but I've not seen
anything concrete.
I like the concept of Camel, but recently decided to go for the (lighter) Event Admin as my requirements are limited. +1 to Mike on the Camel motivation. I'd look into it and then compare options before deciding.
您不是在寻找 ESB 吗？ ServiceMix 是：
Aren't you looking for an ESB? ServiceMix is a:
iPOJO 事件管理处理程序 是一种更好用的访问@maasg 提到的事件管理服务。
iPOJO Event Admin Handlers are a nicer-to-use way to access the Event Admin service mentioned by @maasg.
看起来你在这里谈论的是 ESB。如果是这种情况，那么您可能需要查看 wso2 ESB。它由 apache synapse 提供支持。它使用OSGi作为模块化框架，以便您可以根据需要添加/删除功能。 wso2 有一个完整的产品堆栈，例如消息代理、业务流程服务器 (ODE) 等，基于相同的技术OSGi 核心平台。
免责声明：我为 wso2 工作。
looks like you are talking about an ESB here. If its the case, then you might have look at wso2 ESB. It is powered by apache synapse. it uses OSGi as the modular framework, so that you can add/remove features according to your requirement. There is a whole product stack from wso2 like message brokers, Business process servers (ODE), etc based on the same OSGi core platform.
disclaimer : I work for wso2.