介绍

我一直在与几位客户努力开发一款名为 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 工具存在联系，从而带来非常可扩展的架构优势，其中传输和分发策略的选择可以尽可能晚地做出。原则上，相同的应用程序代码可以用于处理少量数据的独立工具，以及大规模的企业级批量处理引擎。