在类似ApacheCamel的ESB上，什么机制实际上是沿着从端点到端点的路径"行进"(拉/推)消息？

骆驼RouteBuilder只是组成了Endpoints和Routes的图形，并知道在它访问某个Endpoint之后要将消息传递给哪个目的地/下一个Endpoint或Endpoints自己知道它处理的消息的下一个目的地是哪个。

不管怎样，我都很困惑：

• 如果是RouteBuilder知道消息在系统中的"流动"，那么这个RouteBuilder需要知道何时发送到Endpoint A的业务逻辑，它应该传递Endpoint B对Endpoint C旁边的消息，但是在所有camel示例中，我都看到这个业务逻辑不存在；并且
• 似乎将这种"流"业务逻辑放入Endpoints中会将它们结合在一起，并破坏SOA/ESB/EIP等的一些基本原则。

在这个框架下，我相信camel正在构建一个纯图形，其中每个节点都是camel端点/处理器，每个边缘都是两个端点(源和目标)之间的路径。当您调用RouteBuilder的API时，这个图正是它所构建的。当你去一条骆驼路线的start()时，图形很可能被验证并转换成一系列需要执行的Runnable，并且可能使用某种自定义Executor或线程管理来处理这些Runnables。

因此，Runnable的执行(到达时处理消息的处理器)由这个自定义Executor处理。这是一种"沿消息行进"的机制，尽管任务排队的顺序是由RouteBuilder组成的图形的总体结构驱动的。

我建议先看一下这个质量保证书阿帕奇骆驼到底是什么？…以及它所指的链接，关于ApacheCamel的更多背景。

业务逻辑可以是任何类型的逻辑，例如JavaBean(POJO)。camel允许您以一种松散耦合的方式访问业务逻辑。例如，请参见这些链接

• http://camel.apache.org/service-activator.html
• http://camel.apache.org/bean-integration.html
• http://camel.apache.org/bean.html
• http://camel.apache.org/bean-binding.html
• http://camel.apache.org/hidden-middleware.html
• http://camel.apache.org/spring-remoting.html