我们正在使用Apache Camel实现一个Web服务，该服务有很多（20-50）＆＃34;直接：＆＃34;调用Java方法的路由。每种方法基本上都有一条路径，无论是业务规则处理还是DAO访问方法。所有路由都使用from("direct:").to("direct")，但从不使用任何其他组件。
虽然这似乎可以将系统与标准的Controller-＆gt; bo-＆gt; dao图层分离，但它会增加不必要的Camel路线簿记。
更好的选择只是为Business Objects和Dao层定义Java接口，为任何其他服务（系统外部，如file://或http://）提供额外的接口请求将是Business Objects或Controllers中的依赖项。此附加接口的实现将使用Apache Camel与这些外部服务进行通信。
作为旁注，我正在思考如何说服现任同事看到我的观点。
思想？
tldr; Apache Camel是否应该在只有1或2个应用程序的地方使用？
答案 0 :(得分：1)
我使用的应用程序中有20个系统涉及各种复杂性，协议和模式。我知道涉及50多个系统的其他地方。唯一的限制是你的设计，性能等。
Apache Camel是一个中间件框架。从本质上讲，您的业务逻辑不应该知道数据是如何获得的，也不应该知道应该交付的内容，而应该知道应该提供的内容。骆驼应该照顾好其余部分。
顺便问一下，您的中间件是否与外部世界无关？为什么只使用direct而不使用其他组件？
您还可以使用bean集成隐藏中间件。这会让你更加脱钩。见这里：http://camel.apache.org/bean-integration.html
这实际上取决于你想要完成什么以及你的要求是什么。
答案 1 :(得分：0)
嗯，对于您的特定用例，我会说您可能会更好地使用常规Java实现，而Camel被用作系统与外部世界之间的粘合剂。就像Souciance explains in his answer一样，当你必须与多个系统集成时，Camel真的很闪耀，所以你至少应该保留它以便与外部世界进行通信。
但是，已经使用Camel实现了系统内部，我不得不说，用纯Java替换它需要付出更多的努力，特别是因为当前的实现给出了您可以使系统更加健壮，例如通过使用高性能MQ替代direct路由，这将有助于您的系统更好地抵抗故障，并在以后更容易解耦，而不是提到在你的DAO对象周围有路由可以在系统负载增加时更容易实现数据库更新的批处理。