简介

我一直在与几个客户一起努力开发一个名为 Spring Batch 的新产品。其目标是在企业环境中提供支持批量处理的工具和应用程序。Spring Batch 是 Spring 产品组合 的一部分，并在 Spring 2.1 发布列车中进行了首次发布。

构建一些原型代码的最初动力实际上来自多个 Interface21 客户。这提供了一些有用的额外细节以及对实现的一些约束，以便它可以应用于客户提出的现实世界问题。我希望本文能够激发更多兴趣并提供关于总体方法的反馈。

Rod Johnson 将与来自 Accenture 的合作伙伴一起在 JavaOne 上介绍 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 工具相关联，从而带来高度可扩展架构的优势，其中传输和分发策略的选择可以尽可能延迟到最后。原则上，相同的应用程序代码可用于处理少量数据的独立工具，以及大规模的企业级批量处理引擎。