2009-09-02 100 views
27

我在看的ESB集成到现有的Java/Maven的基于Web的产品。具体来说,我在看ServiceMix和Mule。该产品将连接到几种不同的服务,包括电子邮件,Quartz,通过HTTP,SMS和IM的RESTful Web服务。我只是快速浏览了文档,这两个选项似乎相当重量级且相当复杂。这似乎是什么时候使用ESB的教科书示例,但我不想花大量时间学习一个或另一个系统。正在整合一个值得学习曲线的ESB(ServiceMix/Mule)吗?

就像我说的,我已经有了一个由Maven构建的web应用程序,并且希望集成其中一个系统会相当简单,即使只是发送电子邮件这样简单的东西,但它看起来像添加任何一个都会拉入在罐子方面占世界的一半,并且很难嵌入到现有产品中。

是值得一试的其中一个选项来拉?有没有一种简单的方法将它们整合到现有的应用程序中,而不必完全重构它?有其他更轻的选项吗?我应该考虑哪些方面会使他们的使用值得?

+2

什么是ESB购买你除了更复杂?你为什么认为你需要它?有多少服务是“几个”,您认为您必须拥有多少服务才能使ESB成为必需? – duffymo 2009-09-02 00:43:39

+1

我预计在我们达到生产时,将拥有低至两位数的外部服务。他们会有所不同,但他们中的许多人将服务于类似的目的。例如,通过电子邮件,即时通讯或短信通知,其中唯一的区别是媒介。 – Tim 2009-09-02 15:56:54

+4

超过一年后的跟进。最终交出了骆​​驼的骡子。我们对骆驼很满意。令人惊讶的充满活力的社区,轻量级,现在有一本书来补充一般良好的文档。我会说,从骆驼开始,除非有一些明显的原因,你需要一个完整的ESB。 – Tim 2011-01-05 14:53:13

回答

13

Mule在插入XML服务方面非常简单,他们有很多视频示例,我发现这些示例非常有用。

ESB应该是未来,正如你所说 - 你的确看起来像是一个教科书中使用它的例子。

我会尽力回答您的问题:

是值得一试的其中一个选项来拉? 我认为这是你需要问自己一个问题 - 什么是你想达到什么目的?如果你想让它更容易实现,那么通过纯代码或ESB可能需要相同的时间才能完成所有设置。如果你想把它当作学习练习,那可能是值得的。

有没有一种简单的方法将它们整合到现有的应用程序中,而无需完全重构? 简短回答没有。您需要重新设计才能与大多数第三方库/框架集成。

还有没有其他的,重量更轻的选择吗? 骡真的很简单。您可能可以使用MQ来执行HTTP,SMS和IM。可能是ActiveMQ或RabbitMQ。

我应该考虑哪些方面让他们的使用值得? 是,ESB产品是专为企业,其中新业务往往添加和配置是可能改变。全部使用XML使得这一改变变得更容易一些。所以,如果你只是建立一个一次性的软件,它可能不是正确的路。但是,如果您稍后添加更多内容并不断连接不同的服务,它可能是最佳路线。

+1

我能够让Mule和这个项目一起工作,而且没有太多麻烦,尽管它看起来似乎可以吸引大多数可以想象的jar。当我最终得到正确的咒语时,对我的代码的影响非常小,这很好,但文档对于将Mule集成到现有的web应用程序并不是很好。我仍然不知道这是否值得,但我现在有办法确定这一点。谢谢。 – Tim 2009-09-07 13:08:31

4

骡子项目的创始人罗斯梅森在这个主题上写了一篇很好的文章,To ESB or Not to ESB。我建议看看它。此外,您可能想看看Mule iBeans如果你正在建设这是一个Web应用程序,只想做一些简单的集成和不感兴趣的调解它提供了一个更简单的模型。

+0

https://blogs.mulesoft.com/dev/mule-dev/to-esb-or-not-to-esb/(新链接) – 2017-06-15 00:30:26

12

您可能还想看看Apache Camel框架,它对于您提到的所有集成需求都非常强大,并且不会受到完整的ESB的惩罚。

+2

有趣的是,你应该提及,因为我现在正在评估骆驼作为潜在的选择而不是骡子,因为它似乎更轻。我还没有做出任何决定,但它似乎确实可以给我我需要的东西而没有太多的开销。 – Tim 2009-11-12 01:15:12

1

我建议不要浪费宝贵的时间与MULE。我迄今为止的经历并不好。 我不会将它用于任何关键系统。它远离成熟的产品。 除此之外,RESTful服务绝对承诺很多简单并具有实际使用情况。

1

我想说,如果您有两个以上的应用程序或数据库需要彼此交谈并且他们使用多种通信协议,那么投资是值得的。或者,如果你预计未来这种情况将是真实的。听起来像你的要求当然适合这个。

另一种表明使用ESB或至少一条消息总线的情况是您期望或需要一个或多个应用程序独立于其他应用程序进化的地方。例如,一个正在积极发展中,其他则没有。 ESB可以将稳定的系统与活跃开发的系统中的更改隔离开来,无需始终更新所有内容。

ESB的真正威力在于,应用程序可以委派有关如何沟通的所有决策以及与ESB进行通信的人员,并让该组件对这些方面负全部责任。所有其他组件都彼此隔离,无需担心彼此,从而大大减少了依赖关系组合的问题。

在学习曲线,我发现骡子ESB是相当直截了当地拿起肯定将是努力学习所有需要的API来说话的,你是想多业务低得多的学习曲线方面连接到。