第 2 章 路由构建的基本原则

在 Apache Camel 中，pipelining 是在路由定义中连接节点的主要模式。管道概念可能对 UNIX 操作系统的用户最熟悉，在其中加入操作系统命令。例如，ls | more 是命令的一个示例，这些命令可将目录列表 ls 传送到 page-scrolling 实用程序，更多。管道的基本概念是，一个命令的输出 会附带到下一个命令 的输入 中。路由的自然相似之处在于，从一个处理器的 Out 消息转到下一个处理器的 In 消息。

路由中的每个节点（除初始端点外）是一个 处理器，它从 org.apache.camel.Processor 接口继承。换句话说，处理器构成了 DSL 路由的基本构建块。例如，DSL 命令，如 filter （）、delayer （）、 setBody （）、 设置Header （） 和 to （） 所有代表处理器。当考虑处理器如何整合路由以构建路由时，必须区分两种不同的处理方法。

第一种方法是处理器只修改交换的 In 消息，如 图 2.1 “处理器修改 In 消息” 所示。交换的 Out 消息在此例中保持 null。

图 2.1. 处理器修改 In 消息

以下路由显示了一个 setHeader （） 命令，它通过添加（或修改） BillingSystem 标题来修改当前的 In 消息：

from("activemq:orderQueue")
    .setHeader("BillingSystem", xpath("/order/billingSystem"))
    .to("activemq:billingQueue");

第二种方法是处理器创建 Out 消息来代表处理的结果，如 图 2.2 “处理器创建内存不足消息” 所示。

图 2.2. 处理器创建内存不足消息

以下路由显示了一个 转换（） 命令，它会创建一个 Out 消息，其消息正文包含字符串 DummyBody ：

from("activemq:orderQueue")
    .transform(constant("DummyBody"))
    .to("activemq:billingQueue");

其中 constant ("DummyBody") 表示恒定表达式。您不能直接传递字符串 DummyBody，因为要 转换（） 参数必须是表达式类型。

图 2.3 “InOnly Exchange 的 Pipeline 示例” 显示用于 InOnly 交换的处理器管道示例。处理器 A 通过修改 In 消息来运作，而处理器 B 和 C 创建 Out 消息。路由构建器将处理器链接在一起，如下所示。特别是，处理器 B 和 C 以 管道 的形式链接：即，处理器 B 的 Out 消息会在将交换馈送到处理器 C 之前移到 In 消息，然后将处理器 C 的 Out 消息放到制作者端点之前。因此，处理器的输出和输入被加入到持续管道中，如 图 2.3 “InOnly Exchange 的 Pipeline 示例” 所示。

图 2.3. InOnly Exchange 的 Pipeline 示例

默认情况下，Apache Camel 使用管道模式，因此您无需使用任何特殊语法在路由中创建管道。例如，以下路由从 userdataQueue 队列中提取消息，通过 Velocity 模板传送消息（以文本格式生成客户地址），然后将生成的文本地址发送到队列，即 envelopeAddresses ：

from("activemq:userdataQueue")
    .to(ExchangePattern.InOut, "velocity:file:AdressTemplate.vm")
    .to("activemq:envelopeAddresses");

其中 Velocity 端点 velocity: file:AddressTemplate.vm 指定 Velocity 模板文件的位置，该文件在文件系统中。to （） 命令将交换模式更改为 InOut，然后将交换模式发送到 Velocity 端点，然后将它 重新变为仅限。有关 Velocity 端点的详细信息，请参阅 Apache Camel 组件参考指南 中的 Velocity。

图 2.4 “InOut Exchanges 的管道示例” 显示 InOut Exchanges 的处理器管道示例，您通常用于支持远程过程调用(RPC)语义。处理器 A、B 和 C 以管道的形式链接，每个处理器的输出发送到下一个输入。producer 端点生成的最终 Out 消息将将所有方式发回到消费者端点，在其中提供回复原始请求。

图 2.4. InOut Exchanges 的管道示例

请注意，为了支持 InOut Exchange 模式，必须在 路由中最后一个节点（无论是生产端点或其他类型的处理器）创建 Out 信息。否则，任何连接到消费者端点的客户端都会挂起并等待回复消息。您应该注意，并非所有制作者端点都创建 Out 消息。

通过处理传入的 HTTP 请求，请考虑以下处理付款请求的路由：

from("jetty:http://localhost:8080/foo")
    .to("cxf:bean:addAccountDetails")
    .to("cxf:bean:getCreditRating")
    .to("cxf:bean:processTransaction");

如果传入的付款请求通过 Web 服务管道、cxf:bean:addAccountDetails、cxf:bean:getCreditRating、cxf:bean:processTransaction 对其进行处理。最终的 Web 服务 processTransaction 会生成通过 JETTY 端点发回的响应(Out 消息)。

当管道只由一系列端点组成时，也可以使用以下替代语法：

from("jetty:http://localhost:8080/foo")
    .pipeline("cxf:bean:addAccountDetails", "cxf:bean:getCreditRating", "cxf:bean:processTransaction");

In optional Out 交换的管道基本与 图 2.4 “InOut Exchanges 的管道示例” 中的管道相同。InOut 和 In optionalOut 的区别在于，In optional Out Exchange 模式的一个交换被允许将 null Out 消息作为回复。也就是说，如果是 In OptionalOut 交换，则会将 nullOut 消息复制到管道中下一节点的 In 消息。相反，如果是 In Out 交换，则会丢弃 nullOut 消息，并且当前节点中的原始 In 消息将被复制到下一节点的 In 消息中。