簡介

我一直與幾位客戶努力開發一個名為 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，該 POJO 知道如何定位和處理單個資料項目，並讓框架完成佈線工作。

請關注此空間，以獲取有關容器層、網域概念、通用語言和設計細節的更多部落格。

未來方向

除了簡單容器之外，我們還希望提供一個擴充功能，該擴充功能可以採用輸入來源，將其劃分為子範圍，並同時處理這些子範圍。 一個常見的應用程式是將並行處理置於遠端代理之後，例如 EJB 或 Web 服務。 所有並行子進程都能夠單獨識別自己，顯示統計資訊，並在出錯後從上次已知的良好記錄重新啟動。 它們還能夠將其可報告的詳細資訊匯總到父進程，以便運算符可以單一檢視並行作業。 以邏輯工作單元實作的相同業務邏輯可以在簡單容器中使用。 唯一的區別在於配置 - Spring 程式設計模型再次發揮了最佳作用。

Matt Welsh 的工作表明，SEDA 比更嚴格的處理架構具有巨大的優勢，並且消息傳遞容器為我們提供了許多現成的彈性。 因此，我們希望提供一個更具 SEDA 風格的容器或容器支援，以及支援更傳統的方法。 這可能與 Mule 和/或其他 ESB 工具相關聯，從而帶來高度可擴展架構的好處，在這種架構中，可以盡可能晚地做出傳輸和分配策略的選擇。 原則上，相同的應用程式程式碼可以用於處理少量資料的獨立工具，以及大規模的企業級大量處理引擎。