消息
消息
Spring 集成Message是数据的通用容器。
任何对象都可以作为有效负载提供，并且每个Message实例包含包含用户可扩展属性作为键值对的标头。
这Message接口
下面的清单显示了Message接口：
public interface Message<T> {
T getPayload();
MessageHeaders getHeaders();
}
这Messageinterface 是 API 的核心部分。
通过将数据封装在通用包装器中，消息传递系统可以在不了解数据类型的情况下传递数据。
当应用程序发展以支持新类型时，或者当类型本身被修改或扩展时，消息传递系统不会受到影响。
另一方面，当消息传递系统中的某些组件确实需要访问有关Message，此类元数据通常可以存储到消息标头中的元数据中并从中检索。
消息报头
正如 Spring 集成允许任何Object用作Message，它还支持任何Object类型作为标头值。
事实上，MessageHeaders类实现java.util.Map_ interface，如下面的类定义所示：
public final class MessageHeaders implements Map<String, Object>, Serializable {
...
}
即使MessageHeaders类实现Map，它实际上是只读实现。
任何尝试putMap 中的值会导致UnsupportedOperationException.
这同样适用于remove和clear.
由于消息可能会传递给多个使用者，因此Map无法修改。
同样，消息的 payloadObject不能set在初始创建之后。
但是，标头值本身（或有效负载 Object）的可变性是有意保留给框架用户决定的。 |
作为Map，可以通过调用get(..)替换为标头的名称。
或者，您也可以提供预期的Class作为附加参数。
更好的是，当检索预定义值之一时，可以使用方便的 getter。
以下示例显示了这三个选项中的每一个：
Object someValue = message.getHeaders().get("someKey");
CustomerId customerId = message.getHeaders().get("customerId", CustomerId.class);
Long timestamp = message.getHeaders().getTimestamp();
下表描述了预定义的消息标头：
| 标头名称 | 标头类型 | 用法 |
|---|---|---|
MessageHeaders.ID |
java.util.UUID |
此消息实例的标识符。 每次更改消息时都会更改。 |
MessageHeaders. TIMESTAMP |
java.lang.Long |
消息的创建时间。 每次更改消息时都会更改。 |
MessageHeaders. REPLY_CHANNEL |
java.lang.Object (String or MessageChannel) |
当未配置显式输出通道且没有 |
MessageHeaders. ERROR_CHANNEL |
java.lang.Object (String or MessageChannel) |
将错误发送到的通道。
如果值为 |
许多入站和出站适配器实现还提供或期望某些 Headers，您可以配置其他用户定义的 Headers。
例如，这些 Headers 的常量可以在存在此类 Headers 的那些模块中找到。AmqpHeaders,JmsHeaders等。
MessageHeaderAccessor应用程序接口
从 Spring Framework 4.0 和 Spring Integration 4.0 开始，核心消息传递抽象已移至spring-messaging模块和MessageHeaderAccessor引入了 API，以提供对消息传递实现的额外抽象。
所有（核心）特定于 Spring 集成的消息头常量现在都在IntegrationMessageHeaderAccessor类。
下表描述了预定义的消息标头：
| 标头名称 | 标头类型 | 用法 |
|---|---|---|
IntegrationMessageHeaderAccessor. CORRELATION_ID |
java.lang.Object |
用于关联两个或多个消息。 |
IntegrationMessageHeaderAccessor. SEQUENCE_NUMBER |
java.lang.Integer |
通常是一个序列号，其中包含一组带有 |
IntegrationMessageHeaderAccessor. SEQUENCE_SIZE |
java.lang.Integer |
一组相关消息中的消息数。 |
IntegrationMessageHeaderAccessor. EXPIRATION_DATE |
java.lang.Long |
指示消息何时过期。
不直接由框架使用，但可以使用标头扩充器进行设置，并在 |
IntegrationMessageHeaderAccessor. PRIORITY |
java.lang.Integer |
消息优先级 — 例如，在 |
IntegrationMessageHeaderAccessor. DUPLICATE_MESSAGE |
java.lang.Boolean |
如果消息被幂等接收方侦听器检测到为重复消息，则为 True。 请参阅 Idempotent Receiver Enterprise Integration Pattern。 |
IntegrationMessageHeaderAccessor. CLOSEABLE_RESOURCE |
java.io.Closeable |
如果邮件与 |
IntegrationMessageHeaderAccessor. DELIVERY_ATTEMPT |
java.lang. AtomicInteger |
如果消息驱动的通道适配器支持配置 |
IntegrationMessageHeaderAccessor. ACKNOWLEDGMENT_CALLBACK |
o.s.i.support. Acknowledgment Callback |
如果入站终端节点支持，则回调以接受、拒绝或重新排队消息。 请参阅 Deferred Acknowledgment Pollable Message Source 和 MQTT Manual Acks。 |
其中一些标头的便捷类型化 getter 在IntegrationMessageHeaderAccessor类，如下例所示：
IntegrationMessageHeaderAccessor accessor = new IntegrationMessageHeaderAccessor(message);
int sequenceNumber = accessor.getSequenceNumber();
Object correlationId = accessor.getCorrelationId();
...
下表描述了同样出现在IntegrationMessageHeaderAccessor但通常不被用户代码使用（也就是说，它们通常由 Spring Integration 的内部部分使用——为了完整起见，将它们包含在这里）：
| 标头名称 | 标头类型 | 用法 |
|---|---|---|
IntegrationMessageHeaderAccessor. SEQUENCE_DETAILS |
java.util. List<List<Object>> |
需要嵌套关联时使用的关联数据堆栈（例如 |
IntegrationMessageHeaderAccessor. ROUTING_SLIP |
java.util. Map<List<Object>, Integer> |
请参阅 Routing Slip。 |
消息 ID 生成
当消息通过应用程序转换时，每次更改（例如
by a transformer） 分配新的消息 ID。
消息 ID 是一个UUID.
从 Spring Integration 3.0 开始，用于 IS 生成的默认策略比以前的策略更高效java.util.UUID.randomUUID()实现。
它使用基于安全随机种子的简单随机数，而不是每次都创建一个安全的随机数。
可以通过声明一个 bean 来选择不同的 UUID 生成策略，该 bean 实现org.springframework.util.IdGenerator在应用程序上下文中。
类加载器中只能使用一种 UUID 生成策略。
这意味着，如果两个或多个应用程序上下文在同一个 classloader 中运行，它们将共享相同的策略。
如果其中一个上下文更改了策略，则所有上下文都会使用它。
如果同一类加载器中的两个或多个上下文声明了org.springframework.util.IdGenerator，它们都必须是同一类的实例。
否则，尝试替换自定义策略的上下文将无法初始化。
如果策略相同，但已参数化，则使用要初始化的第一个上下文中的策略。 |
除了 default 策略之外，还有两个额外的IdGenerators提供。org.springframework.util.JdkIdGenerator使用上一个UUID.randomUUID()机制。
您可以使用o.s.i.support.IdGenerators.SimpleIncrementingIdGenerator当 UUID 并不真正需要并且简单的递增值就足够时。
只读标头
这MessageHeaders.ID和MessageHeaders.TIMESTAMP是只读标头，无法覆盖。
从 4.3.2 版本开始，MessageBuilder提供readOnlyHeaders(String… readOnlyHeaders)用于自定义不应从上游复制的标头列表的 APIMessage.
只有MessageHeaders.ID和MessageHeaders.TIMESTAMP默认为只读。
全球spring.integration.readOnly.headers属性（参见 全局属性 ）进行自定义DefaultMessageBuilderFactory对于框架组件。
当您不想填充某些现成的标头（例如contentType由ObjectToJsonTransformer（请参阅 JSON 转换器）。
当您尝试使用MessageBuilder，则此类标头将被忽略，并且特定的INFOmessage 被发送到日志中。
从版本 5.0 开始，Messaging Gateway、报头扩充器、内容扩充器和报头过滤器不允许配置MessageHeaders.ID和MessageHeaders.TIMESTAMP标头名称DefaultMessageBuilderFactory，然后他们抛出BeanInitializationException.
标头传播
当消息生成终端节点（例如服务激活器）处理（和修改）消息时，入站标头通常会传播到出站消息。 一个例外是转换器，当完整的消息返回到框架时。 在这种情况下，用户代码负责整个出站消息。 当转换器仅返回有效负载时，入站标头将被传播。 此外，仅当出站邮件中尚不存在报头时，才会传播报头，从而允许您根据需要更改报头值。
从版本 4.3.10 开始，您可以配置消息处理程序（修改消息并生成输出）以抑制特定标头的传播。
要配置不想复制的标头，请调用setNotPropagatedHeaders()或addNotPropagatedHeaders()方法。MessageProducingMessageHandler抽象类。
您还可以通过设置readOnlyHeadersproperty 中META-INF/spring.integration.properties转换为以逗号分隔的标头列表。
从版本 5.0 开始，setNotPropagatedHeaders()在AbstractMessageProducingHandler应用简单模式 （xxx*,xxx,*xxx或xxx*yyy） 以允许筛选具有通用后缀或前缀的标头。
看PatternMatchUtilsJavadoc了解更多信息。
当其中一个模式为 （星号） 时，不会传播任何标头。
所有其他模式都将被忽略。
在这种情况下，服务激活器的行为方式与 transformer 相同，并且必须在*Message从 Service 方法返回。
这notPropagatedHeaders()选项中可用ConsumerEndpointSpec用于 Java DSL
它还可用于<service-activator>组件作为not-propagated-headers属性。
消息实现
该Messageinterface 是GenericMessage<T>，它提供了两个构造函数，如下面的清单所示：
new GenericMessage<T>(T payload);
new GenericMessage<T>(T payload, Map<String, Object> headers)
当Message，则会生成一个随机的唯一 ID。
接受Mapof headers 将提供的 headers 复制到新创建的Message.
还有一个方便的 implementationMessage旨在传达错误条件。
此实现采用Throwableobject 作为其有效负载，如下例所示：
ErrorMessage message = new ErrorMessage(someThrowable);
Throwable t = message.getPayload();
请注意，此实现利用了GenericMessage基类已参数化。
因此，如两个示例所示，在检索Message有效载荷Object.
这MessageBuilderHelper 类
您可能会注意到，Messageinterface 为其 payload 和 headers 定义检索方法，但不提供 setter。
这样做的原因是Message在初始创建后无法修改。
因此，当Message实例被发送到多个消费者（例如，
通过 publish-subscribe Channel），如果其中一个 Consumer 需要发送具有不同有效负载类型的回复，则必须创建一个新的Message.
因此，其他使用者不会受到这些更改的影响。
请记住，多个使用者可以访问相同的有效负载实例或标头值，并且此类实例本身是否不可变由您决定。
换句话说，用于Messageinstances 类似于 unmodifiableCollection和MessageHeadersmap 进一步说明了这一点。
即使MessageHeaders类实现java.util.Map，则调用put作（或 'remove' 或 'clear'）MessageHeaders实例会导致UnsupportedOperationException.
Spring 集成不需要将Map的创建和填充传递到GenericMessage构造函数中，而是提供了一种更方便的方式来构造Messages：MessageBuilder.
这MessageBuilder提供两种用于创建Message实例Message或使用有效负载Object.
从现有的Message、该Message复制到新的Message，如下例所示：
Message<String> message1 = MessageBuilder.withPayload("test")
.setHeader("foo", "bar")
.build();
Message<String> message2 = MessageBuilder.fromMessage(message1).build();
assertEquals("test", message2.getPayload());
assertEquals("bar", message2.getHeaders().get("foo"));
如果您需要创建一个Message替换为新的有效负载，但仍希望从现有的Message，你可以使用 'copy' 方法之一，如下例所示：
Message<String> message3 = MessageBuilder.withPayload("test3")
.copyHeaders(message1.getHeaders())
.build();
Message<String> message4 = MessageBuilder.withPayload("test4")
.setHeader("foo", 123)
.copyHeadersIfAbsent(message1.getHeaders())
.build();
assertEquals("bar", message3.getHeaders().get("foo"));
assertEquals(123, message4.getHeaders().get("foo"));
请注意，copyHeadersIfAbsent方法不会覆盖现有值。
此外，在前面的示例中，您可以看到如何使用setHeader.
最后，还有set可用于预定义标头的方法，以及用于设置任何标头 （MessageHeaders还为预定义的标头名称定义常量）。
您还可以使用MessageBuilder设置消息的优先级，如下例所示：
Message<Integer> importantMessage = MessageBuilder.withPayload(99)
.setPriority(5)
.build();
assertEquals(5, importantMessage.getHeaders().getPriority());
Message<Integer> lessImportantMessage = MessageBuilder.fromMessage(importantMessage)
.setHeaderIfAbsent(IntegrationMessageHeaderAccessor.PRIORITY, 2)
.build();
assertEquals(2, lessImportantMessage.getHeaders().getPriority());
这priorityheader 仅在使用PriorityChannel（如下一章所述）。
它被定义为java.lang.Integer.