親愛的 Spring 社群：

我們很高興宣布 Spring Integration 4.1 Release Candidate (RC1) 版本已推出。請使用 Milestone Repository 搭配 Maven 或 Gradle，或下載 發布歸檔 來試用看看。

此版本包含許多新功能和改進，以及一些錯誤修正。GA 版本預計於 11 月初發布。

首先，感謝所有針對 4.1 Milestone 1 提供意見回饋並提交報告 (錯誤或新功能) 的人。 特別感謝那些透過 Pull Requests 提供貢獻的人。 以下是自 milestone 以來的主要變更摘要

Web Sockets 支援

此功能已在 4.1 Milestone 1 中引入，但已解決了一些問題，並且我們現在提供了一些範例，以更好地了解如何在 Spring Integration 應用程式中使用 Web Sockets：Basic 和 STOMP Chat。

JDK8 Optional<?> 一致的處理

如果您正在使用 Java 8，您將能夠使用 Optional<?> 容器作為服務方法參數。 例如

public void optionals(@Payload("@myConvert.conv(payload)") Optional<Bar> payload,
        @Header(value="foo") Optional<String> header)

在這種情況下，如果 @myConvert.conv(payload) 傳回 null，則 payload 變數將包含一個 Optional.empty()。 header 變數也是如此 - 如果請求 Message<?> 中沒有 foo header。 這可以用作 @Header 註解上 required 屬性的替代方案。

Routing Slip 模式

現在支援 Routing Slip 模式。 我們引入了 RoutingSlipRouteStrategy，而不是簡單的 static list of channel names，它根據請求 Message<?> 和 reply object 提供動態運行時路由。 也支援 SpEL

<header-enricher input-channel="input" output-channel="process">
	<routing-slip value="channel1; request.headers[myRoutingSlipChannel];
	                        routingSlipRoutingStrategy;"/>
</header-enricher>

在複雜的、動態的情況下，當難以配置多個路由器來確定訊息流程時，此模式非常有用。 透過此增強功能，當訊息到達沒有 output-channel 的端點時，將查詢 routing slip 以確定將訊息傳送到哪個下一個頻道。 當 routing slip 用盡時，正常的 replyChannel 處理將恢復。

Idempotent Receiver 模式

在此版本中，我們已將 Idempotent Receiver 實作為一流的功能。 以前，使用者必須透過在 <filter/> 中使用自訂的 MessageSelector 來實作此模式。 框架現在支援將此功能作為一個 Advice 元件，可以將其應用於任何 consuming endpoint

<idempotent-receiver endpoint="endpoint1, foo*"
				     metadata-store="store"
					 discard-channel="duplicates"
					 key-expression="payload.invoiceNumber"/>

這會建立一個 AOP IdempotentReceiverInterceptor，它會應用於 MessageHandler#handleMessage 在 id 與提供的 endpoint 模式之一相符的端點中。

如果省略了 discard-channel，則重複的訊息仍然會傳送到 message handler，但它將包含一個 duplicateMessage header，允許使用者程式碼採取進一步的動作。

對於 JavaConfig，提供了 @IdempotentReceiver 註解，但是也必須配置 IdempotentReceiverInterceptor @Bean

@Bean
public IdempotentReceiverInterceptor idempotentReceiverInterceptor() {
   return new IdempotentReceiverInterceptor(new MetadataStoreSelector(m ->
                                                    m.getPayload().toString()));
}

@Bean
@ServiceActivator(inputChannel = "input", outputChannel = "output")
@IdempotentReceiver("idempotentReceiverInterceptor")
public MessageHandler myService() {
	....
}

有關更多資訊，請閱讀 IdempotentReceiverInterceptor JavaDocs。

Scatter-Gather 模式

現在提供了 Scatter-Gather Enterprise Integration Pattern

<!--Auction scenario-->
<scatter-gather input-channel="inputAuction" output-channel="output"
                scatter-channel="auctionChannel">
	<gatherer release-strategy-expression="^[payload gt 5] != null or size() == 3"/>
</scatter-gather>

<!--Distribution scenario-->
<scatter-gather input-channel="inputDistribution" output-channel="output"
                gather-channel="gatherChannel">
	<scatterer apply-sequence="true">
		<recipient channel="distribution1Channel"/>
		<recipient channel="distribution2Channel"/>
		<recipient channel="distribution3Channel"/>
	</scatterer>
	<gatherer release-strategy-expression="^[payload gt 5] != null or size() == 3"/>
</scatter-gather>

它是一個複合端點，結合了 publish-subscribe 邏輯和一個 aggregation 函數。 當然，之前可以使用現有的 publish-subscribe-channel 或 recipient-list-router 以及 aggregator 元件將其實作為整合流程，但是此新功能為諸如 best quote 之類的場景提供了更簡潔的實作。

Redis Queue Gateways

已將一對基於 Redis List 的 request-reply (inbound 和 outbound) gateway 元件添加到 Redis 模組

<int-redis:queue-outbound-gateway request-channel="sendChannel" queue="foo"/>

<int-redis:queue-inbound-gateway request-channel="requestChannel" queue="foo"/>

Reactor 的 PersistentQueue

已更改 QueueChannel 以允許注入任何 Queue<?> 實作。 這樣做是為了允許在 [Reactor] (http://reactor.github.io/reactor/) 專案中使用 Chronicle-Queue 實作

@Bean QueueChannel queueChannel() {
   return new QueueChannel(new PersistentQueueSpec<Message<?>>()
                           		.codec(new JavaSerializationCodec<>())
                           		.basePath("/usr/queuePath")
                           		.get());
}

跳過輪詢

在使用輪詢端點時，有時需要「跳過」輪詢，可能是因為某些下游條件可能導致失敗，或者說，任務執行器池沒有可用的執行緒。 此版本新增了 PollSkipAdvice，可以將其插入 poller 的 advice 鏈中，跳過邏輯基於使用者提供的程式碼。

注意事項

1. Spring Integration 4.1 需要 Spring Framework 4.1
2. 雖然現在需要 JDK8 才能建置 Spring Integration，但該框架在運行時仍然與 Java 6 相容。
3. 我們期望在本週稍後宣布 Spring Integration Java DSL 發布候選版本的可用性。

結論

請參閱此版本的 發布說明 和 專案頁面 以取得更多資訊。 有關 4.1 版本中「新增功能」的完整列表，請參閱參考文件。 從早期版本升級的使用者應查閱各種 migration guides。

與往常一樣，我們非常歡迎貢獻。