引言
WebSphere® Business Integration Server Foundation Version 5.1（以前为 WebSphere Application Server Enterprise）中的调度程序服务能够使 J2EE 操作具有高性能、高可用性、持久性和事务调度等特征。
调度程序包含以下两个组件：
调度程序资源
调度程序 API。
调度程序资源表示为一个调度程序实例，它在 WebSphere Application Server Java™ Naming and Directory Interface（JNDI）中可用。每个调度程序资源都有一些管理它的行为的独特特性；例如，在哪个数据库中存储持久性调度。调度程序资源是使用标准 WebSphere Application Server 管理控制台或 AdminControl 脚本对象配置的。
调度程序 API 是一个 Java 接口，可以用于创建和管理任务。该 API 可以通过任何的 J2EE 服务器应用程序（Enterprise Java Beans 和 servlets）访问。
调度程序能够执行两种类型的任务：
调用无状态会话 Enterprise Java Bean（EJB）。
发送 Java Message Service（JMS）消息。
调度程序将数据存储在 WebSphere Application Server 支持的任何数据库中，并使用 WebSphere Application Server 事务管理器。因此所有的调度程序操作都是事务性和持久性的；每个任务都能保证一次运行成功。如果有一个任务因为某种原因执行失败，那么整个操作都会回滚。
调度程序可以使应用程序开发人员在任务的生命周期内创建自己的无状态会话 EJB 以便接收事件通知，允许使用自定义日志实体或工作流应用程序插件。无状态会话 EJB 也可以用于提供普通日历。开发人员可以使用提供的日历 bean，也可以为他们现有的业务日历创建一个日历 bean。
WebSphere Business Integration Server Foundation V5.1 Information Center 中介绍了调度程序服务，其中描述了基本的安装和配置过程、简化的编程示例，并引用了调度程序 API JavaDoc。
规划
调度程序是 WebSphere Business Integration Server Foundation 产品的一部分，在运行调度程序活动时都需要用到调度程序。调度程序服务如果要访问资源，要求先配置好调度程序资源和 J2EE 应用程序。每个资源都是以大致相同的方式配置为 DataSource 或 JMS Queue，可以在多个配置域（服务器、节点或单元）中创建。您可以创建多个调度程序配置资源，并通过一个或多个 J2EE 应用程序访问每个调度程序资源。
用户角色
调度程序服务需要有几个用户角色来规划、开发、管理和操作该调度服务：
Administrator：
在其组织的基础设施下对调度程序的运用进行构架。包括创建恰当的调度程序配置资源、调优每个调度程序实例、为应用程序分配资源以及解决问题。
Developer：
创建与调度程序服务 API 相交互的 J2EE 应用程序，包括管理应用程序（控制台应用程序）和接收事件的应用程序（调度程序需要与之交互的应用程序）。
Operator：
监控调度程序以查看是否有错误，并运用 Developer 编写的应用程序来响应错误环境。
资源配置
每个调度程序配置资源都有一些参数来为资源管理调度程序引擎的运转方式，以及如何在 JNDI 中定位资源。如果使用管理控制台配置调度程序资源，那么屏幕就会像图 1 那样：
图 1. 调度程序配置面板
如果两个调度程序资源在不同级的作用域中使用同一个 JNDI 名称进行配置，那么最小粒度级的作用域优先。
图 2. AccountReport 调度程序配置面板
每个调度程序配置资源都具有以下参数（图 2 也列出了这些参数）：
轮询守护程序
调度程序资源会为每个提供调度程序服务的服务器分配一个轮询守护线程。因此，如果调度程序资源是在节点级作用域中配置的话，在该节点中的每个服务器都会分配到一个在其上运行的轮询守护程序。
轮询守护程序负责从数据库加载任务。守护程序使用在调度程序配置资源中设置的 Poll Interval 来确定数据库轮询时需要等待的时间。如果这个值为 60，那么 对于所有在此周期内设置的待执行的任务而言，该守护每 60 秒钟会试着加载一下任务。
图 3. 间隔 60 秒的轮询守护
Poll Interval 设置确定重复的执行任务的最小周期，同时也确定一次装入内存的任务数。因此，创建一个 24 小时的大轮询间隔并不是最佳的选择，即使你一天只运行一次重复的任务。每个任务会装入内存从而消耗资源。创建一个 1 秒钟的小轮询间隔可能看起来是恰当的选择，然而，这样会生成其他的数据库争夺。最好的做法是选择 5 秒至 3600 秒（1 小时）之间的值，视您的任务需要的最小重复间隔而定。
Work Manager
用于调度程序配置资源的 Work Manager 设置提供给调度程序固定数目的线程，以便在其上分配工作，同时也提供给它一个用于确定如何将 J2EE 上下文信息分配到线程中的策略。
图 4. 缺省的 WorkManager 配置面板
应用到调度程序中的 WorkManager 参数如下所示：
WorkManager 可以在多个调度程序之间共享，并可用于非调度程序目的。如果您想为多个应用程序和服务建立单个的线程轮询和警报轮询的话，这将是很有用的。请记住，虽然 WorkManager 可以在单元和节点作用域上配置，但是线程轮询和警报轮询是在每个活动服务器上复制的。图 5 阐述了不同的服务器如何具有不同的 WorkManager 实例，却具有相同数目的可用线程和警报。
图 5. 共享的节点级 WorkManager
WorkManager 服务
WorkManager 具有几个服务上下文，在 Scheduled 任务执行时可以复制到其上。只有当服务是在用于创建和执行任务的应用服务器上安装和启用时才会复制服务，这些服务中的每一个都是这样的。所有的 WorkManager 服务上下文都只应用到 BeanTaskInfo 任务中。
高可用性
可以通过创建副本调度程序资源或者在集群中创建一个资源这样来配置调度程序服务，使之具有高可用性。WebSphere Application Server Enterprise Version 5.0.2 和 WebSphere Business Integration Server Foundation Version 5.1 中的调度程序利用租用权的概念来使独立的轮询守护程序之间的冲突最小化。许多的调度程序引擎共同竞争租用权，赢得租用权的调度程序就会运行任务。如果某一调度程序没有得到租用权，那么轮询守护程序就不会试着去加载和运行任何任务了。
在调度器间共享的租用权会使用同样的 JNDI 名称和数据库表。因此在集群级上配置的调度程序资源就会自动地利用租用权了。
租用权是利用每个调度程序的 WorkManager 的独立警报线程获得的。尝试获取租用权的时间会略小于 Poll Interval（Poll Interval 的 64％）。在轮询间隔的 80％ 的时间内租用权本身就会过期。因此，如果轮询间隔是 100 秒，每隔 80 秒租用权就会过期。每隔 64 秒（80 * .8）租用权警报就会试着去更新或获得一个租用权。如果调度程序变为不可用，那么调度程序不可用的最大时间为 ((PI * .8) + (PI * .64))，相当于 80 秒（租用权的期限）加上 64 秒（备份调度器获得该租用权的时间），即总共为 144 秒。
调度程序在 Version 5.0.2 之后的版本运用不同的算法来设置租用权时间，这种算法设置的时间独立于轮询间隔。这就可以使客户使用一个更大的轮询间隔，而不牺牲可用性。在 5.0.2 以后的版本中，租用权每隔 60 秒过期，并且每隔 40 秒由所有的守护程序更新或获得。因此，调度器变为不可用的最大时间为 100 秒，与轮询间隔无关。
关于租用权
Version 5.0.2 之前的版本不能够使用租用权。如果添加多余的调度程序，可用性就会增加，然而争夺也会增加。如果不想牺牲性能，您就不能够增加超过一个的冗余调度程序。每个任务都会在每个服务器上加载并运行，但只有一个会运行成功。检测到冲突时就会简单地终止所有其他的副本任务。
如果您正在使用的调度程序所用的数据库是利用 Version 5.0 或 5.0.1 版本的调度程序所提供的数据描述语言（Data Definition Language，DDL）文件创建的，那么您就不会有 Lease Manager。要想激活 WebSphere Application Server Enterprise Version 5.0.2 或 WebSphere Business Integration Server Foundation Version 5.1 中的 Lease Manager，只需要简单地创建调度程序所提供的 DDL 文件中提到的新的 Lease Manager 表即可。通过重新运行创建这些表的 DDL 就可创建新的表，不会影响到现有的数据（关于如何创建这些表的细节请参见参考资料）。一旦创建这些表之后，调度程序就会自动启动，使用租用权来管理多余的调度程序连接。
在图 6 中，调度程序资源在同一个单元中的三个不同的服务器上存有副本。每个调度程序（JNDI 名称为 sched/Main）引用同样的 JDBC DataSource 和 Wor
