能否使用消息代理将PDF、MS Word文档内容以XML形式流传输？

你描述的技术链路是可实现的，核心逻辑如下：

• ActiveMQ本身不内置Word、PDF文本提取能力，你需要额外开发一个轻量的处理服务：该服务作为ActiveMQ的消费者，监听存储了文档二进制流/文件路径的指定队列，收到消息后调用Apache Tika完成文档文本内容提取。
• 提取得到的纯文本内容可以封装为结构化消息后直接写入Apache Kafka的指定Topic，下游流处理服务消费Kafka消息即可将内容传入Apache OpenNLP完成实体识别、文本分类等处理任务。
• 该方案的优势是用ActiveMQ实现了上传端和处理端的异步解耦，可应对文档上传峰值场景，避免下游处理链路被突发流量打垮。

如果你不想引入ActiveMQ，也可以根据你的技术栈选择以下方案：

• Kafka Connect方案：如果你的技术栈已经以Kafka为核心，可直接使用Kafka Connect的文件源连接器，监听指定的文件存储目录（本地目录、MinIO、对象存储桶均可），检测到新增Word、PDF文件后自动调用内嵌的Tika提取文本，直接写入Kafka Topic，全程不需要额外引入消息队列组件，链路更短。
• RabbitMQ方案：如果你需要更灵活的消息路由能力（比如按文档类型、文件大小分发到不同的处理队列），可以用RabbitMQ替代ActiveMQ，其延迟更低，消费确认机制更灵活，更适合小批量高频的文档上传场景。
• 流计算引擎直连方案：如果所有文档都统一存储在分布式文件系统或对象存储中，可直接用Flink/Spark Streaming的文件监听功能，定时扫描新增文档，提取文本后直接处理并喂给OpenNLP，适合近线+离线混合的处理场景，不需要额外引入消息中间件。

• 所有方案都推荐使用Apache Tika作为统一的文档文本提取工具，它已经封装了POI、PDFBox等底层组件，兼容绝大多数版本的Word、PDF格式，不需要单独处理版本适配、格式兼容问题。
• 超过100M的大文档建议先做分片传输，避免单个消息体超过MQ、Kafka的单消息大小限制，提取文本完成后再做内容合并。

内容的提问来源于stack exchange，提问作者user2315860