使用 Camel 的最合适架构答案

【问题标题】：Best suitable architecture using Camel使用 Camel 的最合适架构
【发布时间】：2014-06-13 09:39:03
【问题描述】：

我们正在为我们公司的应用程序定义一个架构，因此该架构必须负责与其他应用程序/系统的集成。我们首先想到的是将所有集成集中在一个 ESB (Mule) 中，它将以独立模式运行。然而出现了新的需求，问题是每个应用程序都必须管理自己的集成（尚未定义，但它们不应该很复杂）。

现在我们正在评估使用 Apache Camel 或 Mule，但在嵌入式场景中。与一些伙伴讨论它，我们不太清楚哪种方式是建立这个架构的最佳（或更合适）的方式。在我看来，作为每个应用程序的责任，我会将 Camel 直接集成到我的应用程序中（作为一个库）；但他们说在单独的项目中部署 Camel 是一个更好的选择。

这些是我所看到的场景：

我嵌入了 Camel 的应用程序。例如，如果我的应用程序必须调用 Web 服务，我只需对其进行编码并发送它（From(...).to(...) 等）
我的应用程序和另一个嵌入了 Camel 的应用程序。如果我的应用程序必须调用 Web 服务，并且我想通过 Camel 管理所有集成，我想我有要调用骆驼项目（通过 JMS，或调用它公开的接口），请在该项目中定义一个路由，该路由表示：当我从 X 读取时（即时调用接口）调用此 WS。我的意思是，当我认为不需要它时，它会增加更多的复杂性。

可能我误解了 Camel 的真正工作原理，所以我很高兴听到我的错误；）

【问题讨论】：

我在下面给出了答案。我尽量保持简短，但是如果您需要更多信息，请告诉我。
我能知道为什么决定每个应用程序都应该管理自己的转换吗？在我看来，使用集中式解决方案会更好，除非有特定原因会迫使您尝试实施第二种解决方案。
当然，集中式解决方案是更好的选择，但这是我们所在的组织做出的决定（我的意思是，我的公司为该组织开发应用程序）。

标签： java architecture apache-camel eai

【解决方案1】：

Camel 的最佳架构？这取决于您的需求。您似乎有几个需要相互集成的应用程序。因此，对于需要与另一个应用程序集成的每个应用程序，都会有一条集成路线。

让我们稍微扩展一下。

假设我们有两个应用程序，一个客户管理应用程序和一个订单管理应用程序。这两者必须相互整合。从概念上讲，您需要创建和维护的应用程序有两条路线。

对于这种让应用程序相互集成的简单集成，在应用程序本身（嵌入式模式）中使用骆驼/骡子是有意义的。集成量很小。

由于这两个应用程序现在通过集成路由本身紧密耦合，因此客户应用程序中的更改可能会导致订单应用程序中的更改。然而，由于系统很小，所以工作量很小。

但是，如果涉及更多系统，这种方法将成为维护的噩梦。让我们稍微提高一下复杂性。

让我们来看四个系统。需要相互集成的客户、订单、会计和运输系统。只需再添加两个系统进行集成，您的路线总数就会达到 12 条。我们将系统数量增加了一倍，但我们将路线数量增加了 6 倍。也就是说，可能出错的数量增加了 600%。

使用 ESB 将大大简化此设计。希望你能多理解一点。

注意： 使用骆驼从应用程序中调用 Web 服务是矫枉过正的。而是使用更适合此操作的 Apache CXF 执行此操作。

【讨论】：

@Namphibian- 解释很好，图表也很好。你能推荐我用来绘制这些图表的应用程序吗？它是开源的吗？
@naveenraj 我使用 MS 的 visio 制作此图。如需开源替代方案，请查找 dia。它会做同样的事情。
感谢@Namphibian 的解释。我同意如果有更多的集成，ESB 将简化设计。但是在我的场景中，我们不能为所有应用程序部署一个跨中间件：每个应用程序都应该处理它的集成。所以我想知道哪种策略更适合：在我的应用程序中使用 Camel 嵌入，或者为每个应用程序部署另一个仅使用 Camel 进行路由的应用程序等。调用 WS 的示例只是应用程序可能具有的集成示例之一，但不会是唯一的。
如果您只需要 Web 服务，那么将 cxf 嵌入到您的应用程序中似乎是最有意义的。如果只有极少数情况下您需要更多奇特的传输，那么您也许可以使用骆驼将它们提取到单独的服务器，以在这些协议和您的应用程序提供的服务之间架起桥梁。
@user1093643 在你的情况下，我会尽可能使用 ESB 路由，并且只在应用程序之间进行集成作为例外。