《企业集成模式》读书笔记 - 第三章

本书英文全名为《Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions 》对应的中译版为《《企业集成模式——设计、构建及部署消息传递解决方案》》，出版于 2003 年。绝对称得上是老前辈了…

1. 概述

本章标题为"消息传递系统"，意在介绍一个完整的消息传递系统应该包含哪些关键组件，并且这些组件的作用又分别是什么。

2. 基本概念

消息传递系统在具体实现上虽然会因为厂商的不同而不同，但在基本概念方面，它们至少要满足以下几条：

1. 通道。应用与应用之间交换数据时使用的虚拟管道。
2. 消息。被交换的数据在消息传递系统中的统称。
3. 管道和过滤器。用来解决交互的双方数据格式不一致的情况。
4. 路由。解决消息从一个应用发往另外一个应用时的路径选择问题。
5. 端点。用于将应用接入到基于消息传递进行集成的架构体系中。

3. 逐一介绍

上一小节，我们对消息传递系统中的关键性概念进行了简要介绍，本小节将对其进行逐一完善。

3.1 通道（Channel）

1. 消息传递的方式和目的地都不是随机的，我们需要通过建立特定的消息通道来规范消息的投递。
2. 通道绝大多数情况下应该被预先设置，应该被推迟到运行时的情况极少。
3. 解耦性：实现了应用的解耦合，使他们不必知道彼此的位置。

3.2 消息（Message）

1. 由两部分组成，分别是消息头部和消息体，其中消息头部将被由消息传递系统进行消费，判断如何操作该消息；而消息体中放置的则是应用传递给其他应用的数据。
2. 消息本身必须是可序列化，因为集成涉及到进程间的调用，因此被作为消息传递的数据必须能够被序列/反序列化。

3.3 管道和过滤器（Pipeline And Filter）

1. 在解决集成的双方数据格式不一致的前提下保持彼此的松耦合。将转换的逻辑提取到专门的组件中，其他组件不需要进行任何修改。满足开闭原则，
2. 使用"管道和过滤器"提高了可测试性。对于加解密组件，我们将聚焦测试其唯一的加解密功能。
3. 另外一大优势是单个组件的可组合性，采取乐高积木的方式拼接出强大的功能。

3.4 路由（Route）

1. 将目的地的选择这项需求从单个组件中抽离到专门的消息路由器中，实现"单一职责"。
2. 不会修改消息的内容，只关心消息的目标。
3. 解耦性：相较于通过，"路由"甚至不要求在应用之间协商建立共同的消息通道。

3.5 转换（Transfer）

1. 负责处理应用的双方数据格式不一致的情况。
2. 转换有四个层次，从下到上(从底层到上层)分别是：
   a. 传输协议。例如请求者采取的是RPC调用，而响应者要求使用HTTP。
   b. 数据表示。例如对调用方发送的数据需要加密之后再发给服务方。
   c. 数据类型。数据类型的转换，例如将日期转化为字符串以让对方识别等等。
   d. 数据结构(应用层)。应用语义层面的转换（老实说看到这里笔者都有点乱了…）。
3. 解耦性：在"通道"和"路由"的解耦性基础上，"转换"消除了彼此数据格式不同上导致的耦合性。

3.6 端点（Endpoint）

1. 负责将应用和消息传递通道链接起来，它是消息传递系统的客户，而应用正是使用它来发送或接收消息。
2. 是一个特殊化的通道适配组件，要为应用定制开发。

4. 总结

本章作为详细介绍消息传递系统的总章，概要介绍了整个消息传递系统中涉及到的关键性组件，为之后的四，五，七，八，十章中针对对应组件的详细介绍打下基础。