介紹

我一直在與幾位客戶努力開發一款名為 Spring Batch 的新產品。其目標是提供工具和應用程式，以支援企業環境中的批次處理。Spring Batch 是 Spring Portfolio 的一部分，其初始版本將在 Spring 2.1 釋出列車中釋出。

構建一些原型程式碼的最初動力實際上是來自 Interface21 的多個客戶。這提供了一些有用的額外細節以及對實現的約束，以便能夠應用於客戶提出的實際問題。我希望本文能夠激發更多的興趣，並就總體方法提供反饋。

Rod Johnson 將在 JavaOne 上與 Accenture 的合作伙伴一起介紹 Spring Batch。如果您有幸參加，您將看到一些產品背後的細節和思考。在這裡，我將展示一些在演示中不會涵蓋的 Spring Batch 基礎設施層面的細節。

一旦我弄清楚如何將所有工件（網站、JIRA、持續整合等）整合在一起，原始碼就會在 Subversion 中釋出。我還計劃再寫幾篇博文，更詳細地介紹產品的設計方式。有一個郵件列表供有興趣的人跟隨我們邁向 1.0 版本釋出的過程。要訂閱該列表，請訪問列表資訊頁面。

Spring Batch 基礎設施

首個版本提供了一些低階工具來支援產品的其他部分。我們稱之為 Spring Batch 基礎設施。

基礎設施的目標之一是為批次處理的最佳化提供一種宣告式或半宣告式的方法。這包括將操作批次處理的能力，以及在出現異常時重試某項工作。這兩種需求都帶有事務的色彩，並且類似的概念（傳播、同步）可能具有相關性。它們也都適用於 Spring 中常見的模板程式設計模型，例如：TransactionTemplate, JdbcTemplate, JmsTemplate.

框架中的核心介面是BatchOperations還是BatchCallback，以及主要的實現是BatchOperations是BatchTemplate。示例用法

BatchTemplate template = new BatchTemplate();

template.setCompletionPolicy(new FixedChunkSizeCompletionPolicy(20));

template.iterate(new BatchCallback() {

    public boolean doInIteration(BatchContext context) {
        // Do stuff in batch...
        return true; // Return false signals that data are exhausted
    }

});

回撥會重複執行，直到完成策略確定批處理結束，在本例中是 20 次操作後。在實際操作中，這會使用正常的 Spring 事務管理框架包裝在事務中。

Spring Batch 基礎設施還提供了一個用於業務操作自動重試的 API。這獨立於批次支援，但通常會與其結合使用。在這種情況下，核心介面是RetryOperations還是RetryCallback，以及主要的實現是RetryOperations是RetryTemplate.

示例用法

RetryTemplate template = new RetryTemplate();

template.setRetryPolicy(new TimeoutRetryPolicy(30000L));

Object result = template.execute(new RetryCallback() {

    public Object doWithRetry(RetryContext context) {
        // Do stuff that might fail, e.g. webservice operation
        return result;
    }

});

最佳化事務性管道處理

產品釋出後，基礎設施可以立即用於簡化批次最佳化和自動重試。該框架面向應用程式開發人員，無需瞭解框架的任何細節——有一些應用程式開發人員介面可用於方便地構建資料處理管道，除此之外，我們的目標是儘可能支援 POJO 程式設計模型。這類似於 Spring Core 在事務管理和 DAO 實現方面的做法。

Spring Batch 容器層

Spring Batch 的設計願景是，基礎設施可用於實現我們稱之為 Spring Batch 容器層的一類面向流程的批次應用程式。將要釋出的第一個容器是批次處理應用程式，它在其實現中使用基礎設施。這個所謂的“簡單批處理執行容器”將提供強大的功能，用於批次生命週期的可追溯性和管理。一個關鍵目標是，批次程序的管理（定位作業及其輸入和結果，啟動、排程、重新啟動）對於非開發人員來說應儘可能簡單，例如具有一定業務支援的應用程式支援團隊。有人告訴我這是褻瀆神靈，但我喜歡將其視為“ETL”（提取、轉換、載入）工具。至少從字面上看，容器所做的事情就是 ETL，即使它不符合某些人對傳統 ETL 的看法。Spring 程式設計模型非常適合此類問題——編寫知道如何定位和處理單個數據項的 POJO，然後讓框架處理其餘的工作。

請繼續關注有關容器層、領域概念、通用語言和設計細節的更多博文。

未來方向

除了簡單的容器，我們還希望提供一個擴充套件，該擴充套件可以接收輸入源，將其劃分為子範圍，並同時處理這些子範圍。這的一種常見應用是將併發處理置於遠端代理（例如 EJB 或 Web 服務）之後。所有併發子程序都可以單獨標識自己，顯示統計資訊，並在出現錯誤後從最後一個已知良好記錄重新啟動。它們還可以將其可報告的詳細資訊彙總到父程序，以便操作員能夠對並行作業進行單一檢視。與簡單容器一樣，可以使用實現為邏輯工作單元的相同業務邏輯。區別僅在於配置——Spring 程式設計模型在這裡再次發揮了最佳作用。

Matt Welsh 的工作表明，SEDA 比更嚴格的處理架構具有巨大的優勢，而訊息容器開箱即用地提供了很大的彈性。因此，我們希望提供一個更偏向 SEDA 的容器或容器支援，同時支援更傳統的方法。這裡可能與 Mule 和/或其他 ESB 工具存在聯絡，從而帶來非常可擴充套件的架構優勢，其中傳輸和分發策略的選擇可以儘可能晚地做出。原則上，相同的應用程式程式碼可以用於處理少量資料的獨立工具，以及大規模的企業級批次處理引擎。