1. Spring Batch2的新的特性
Spring Batch2.0有六個主要的主題：
Ø Java 5
Ø 非順序的步驟
Ø 基於塊的處理
Ø 元數據擴展
Ø 伸縮性
Ø 可配置
1.1. Java 5
Spring Batch的1.x版本基於Java 1.4，這樣限制了框架使用1.5的一些新的特性，比如：泛型和參數化類型。整個框架都做了調整來適應新的特性。所心，1.4已經不再支持了。開發者使用的大多數接口已經泛型化。例如，ItemReader接口在1.x中，如下面所示：
就像你所看到的那樣，read方法返回了一個Object。2.0中，如下所示：
可以看到，2.0已經支持泛型，參見read函數的返回值，你也可以看到，mark和reset已經被移除，這是因爲處理流程上的改變，這會在後面提到，很多其它的函數也像這樣進行了更改。
1.2. 基於塊的處理
以前，默認的處理規則就是基於項的處理。
在基於項的處理中，ItemReader返回了一個對象，然後交給了ItemWriter，當數量達到了commit interval規定的值的時候，進行階段性的提交。例如，如果commit interval設置成５，ItemReader和ItemWriter每個都被調用５次，下面就是一個代碼的結構：
ItemReader和ItemWriter都被完全綁定起來：
由於處理的範圍是一個item，支持回滾的場景就需要額外的方法，這就是mark，reset，flush和clear。如果成功讀寫了兩條數據，而第三條在寫的時候出現了錯誤，事務就需要回滾，在這種情況下，writer的clear方法就會被執行，表示它應當清空自己的buffer，然後ItemReader的reset方法就會被調用，表示它應當回到上一個mark方法被調用的點。
在2.0裏面，策略被改成了基於塊的結構：
使用上面相同的例子，如果commit interval是５的話，read就會被執行５次，但write只會被執行一次。這些數據項會被放進一個list裏面，然後被同時寫出，下面是一個能夠簡單說明問題的例子：
這個修改不僅讓處理和伸縮更加簡單，而且也讓ItemReader和ItemWriter更加的清晰。
就像你所看到的，接口不再有mark，reset，flush和clear方法，這讓開發者感覺readers和writers的創建更加的直接。對於ItemReader接口，只會向前走。如果需要回滾的話，框架會自動爲開發者緩存數據項。ItemWriter是如此的簡單，由於它一次拿到了個塊的數據，不再是一次一個，在把控制權交還給step之前，可以輸出任何資源。
1.2.1. 項處理器
以前，Steps僅僅只有兩個依賴，ItemReader和ItemWriter。
上面的基礎配置確實是十分的健壯，但是，有很多的情形，item需要在交給writer之前進行轉換。在1.x中，這需要用組合模式進行實現。
這的確起作用，但是這需要在reader、writer和step之間增加新的一層。更重要的是，ItemWriter需要作爲一個ItemStream在Step中進行單獨地註冊。因爲這個原因，ItemTransfomer改名爲ItemProcessor，而且移到了和ItemReader及ItemWriter的同一層。
1.3. 配置擴展
2.0以前，唯一的配置Spring Batch的方法就是像SpringBean一樣的配置方式。但是在2.0，有了新的名字空間。例如，在1.1裏面，像下面這樣配置一個任務。
在2.0裏面，等效的配置如下：
1.4. 元數據訪問提升
JobRepository接口，實現在基本的使用Job元數據進行CRUD操作，而且，這在查詢的時候也會很有幫助。因爲這個原因，JobExplorer和JobOperator才被定義出來。
1.5. 非序列的步執行
在step的配置方面，2.0也有了很大的提升，而不在僅僅是一條線的往下走。
現在是可以選擇的：
使用新的名字空間，可選擇的step變得十分的容易。
1.6. 擴展性
Spring Batch1.x期望作爲一個單獨的vm，也許是多線程模型，但是很多的多進程併發的特性被編譯進去。基於Spring Batch服務特性的目標，很多項目實現了一個可伸縮的解決方案，來保證進程只會在一個有順序的情況下發生。在2.0裏面，這些顯得現的更加的透明，有兩種可伸縮的方案，remote chunking和partitioning。
1.7. Remote Chunking
Remote Chunking是一種把一個step的工作進行分解的技術，而且不需要任何額外的對數據結構的瞭解。一個輸入源可以被動態的拆分，一個進程進行讀，任務的處理被分發到遠端的工作線程。遠端實現了一個監聽模式，響應一個請求，處理數據，發送一個異步的回覆，請求和回覆的傳送必須被分發者和一個單獨的消費者保持起來。這種特性使得任何JMS的實現都變得可讀。由於Spring Batch是在Spring Integration的頂層構建的Remote Chunking，因此對於消息中間件來說，它是不可知的。
1.8. Partitioning
對於輸入的數據的結構有一些瞭解的話，Partitioning（分發）也是一個可以嘗試的途經。像一系列的主鍵，或者一個要處理的文件的名字。這個模型的優點就是，每個處理程序，就像一個單獨的Job，它們不需要實現任何特殊的新的模式，這讓它們很容易配置和測試。原則上來講，Partitioning比Remote Chunking有更好的伸縮性，因爲這沒有在一個地方進行文件讀操作的瓶頸。
在Spring Batch2裏面，Partitioning需要兩個接口的支持：PartitionHandler和StepExecutionSplitter，PartitionHandler知道執行的結構，它必須發送請求到遠端的steps，收集執行結果。PartitionHandler是一個SPI，Spring Batch提供了一個可在本地運行的實現，通過一個TaskExecutor。這十分有用，如果這是一個IO十分頻繁的操作的話，由於在這些情況下遠程執行只增加了複雜度，卻沒有性能上的提升。其它的實現可能是和運行時的結構進行綁定。
