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


摘要

Apache Camel 提供多个处理器和组件,您可以在路由中链接在一起。本章介绍了使用提供的构建块构建路由原则,以此说明基本情况。

2.1. Pipeline 处理

概述

在 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. 处理器创建内存不足消息

processor 创建 out 信息

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

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

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

InOnly Exchanges 的管道

图 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

InOut 交换的管道

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

图 2.4. InOut Exchanges 的管道示例

InOut 交换的管道示例

请注意,为了支持 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:addAccountDetailscxf:bean:getCreditRatingcxf:bean:processTransaction 对其进行处理。最终的 Web 服务 processTransaction 会生成通过 JETTY 端点发回的响应(Out 消息)。

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

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

In optionalOut 交换的管道

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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.