级别： 中级 Matt Haynos (mph@us.ibm.com), 产品经理, WebSphere Extended Deployment, IBM
2007 年 7 月 05 日 IBM® WebSphere® Extended Deployment （Extended Deployment）是面向应用服务器的基础设施软件，它能够优化并降低基础设施的成本、划分资源优先级以供最重要的应用程序使用，并能够改善可用性。它通过虚拟化和智能工作负载管理实现这些功能。但是
WebSphere Extended Deployment 还包括了另外一些功能：通过 ObjectGrid 有效管理超大规模数据组织中的大量数据，以及运行除 OLTP 之外的其他类型的应用程序。在本文中，我们将详细介绍 WebSphere Extended Deployment 的 ObjectGrid 和 Java™ 批处理编程支持。
简介
应用服务器继续成为企业 IT 领域中一个重要部分。随着应用服务器的成熟，它们的数目也在不断增长。随之而来的难题是如何对其进行有效的管理和使用。添加服务器通常是为了运行受限制的应用程序，虽然服务器可能仍然具有处理能力，但全部用于其他低优先级或低利用率的应用程序。
您可能会添加不同类型的应用服务器 — 例如，添加开源应用服务器，或者通过购买获得新的应用服务器 — 这样情况就会变得更加糟糕。结果可能会导致较低的利用率，丢失业务机会，并且整个基础设施的效率也很低。这些糟糕的结果，以及对于良好管理和服务质量的需求，再加上需要能够提高应用程序性能来处理日渐增长的数据量，您很可能会发现自己需要新型的应用程序基础设施功能。
IBM WebSphere Extended Deployment 并不是一个应用服务器，但却其表现出现的特征类似应用服务器。这种软件能够完善应用服务器和执行环境，提供高品质服务、能够处理日益增长的数据量的基础设施，并提供除联机事务处理（OLTP）以外的应用程序模式。
在上一篇文章（请参看 参考资料）中，我们曾经提到过 WebSphere Extended Deployment 是一个集成的网格平台。其中包括 3 个组件：Operations Optimization、Data Grid 和 Compute Grid。在 V6.1 版本中，它不但可以与
WebSphere Application Server 一起使用，而且可以与 BEA WebLogic、WebSphere Community Edition、JBoss 和 Apache Tomcat 一起使用。这对 WebSphere Extended Deployment 来说是一个重要的方向 — 很多人都认为 WebSphere Extended Deployment 只适用于
WebSphere Application Server。
Operations Optimization 可以为任务和应用程序制定优先级，并通过虚拟化和智能工作负载管理来提高应用程序基础设施的利用率。它包含了一些集成的健康状况和操作管理功能。其名称就暗示了它所能实现的功能。Data Grid 可以帮助处理大量数据（多达 TB 级）— 在开发应用程序时，Data Grid 会负责处理其他东西（可伸缩性，性能以及高可用性）。Compute Grid 可以简化在现有应用程序基础设施之上对除 OLTP 之外的应用程序的开发和运行。这些应用程序之一 — Java 批处理任务 — 在大型机环境中会特别有用。我们将讨论越来越常见的使用 Java 完成的批处理编程，以及它所提供的优点。
本文的重点是深入介绍 WebSphere Extended Deployment 的 Data Grid 和 Compute Grid 组件。具体来说，我们将详细介绍 Data Grid 的 ObjectGrid 组件，并着重介绍 Compute Grid 中对于 Java 批处理任务的支持。我们将着重介绍 Data Grid 和 Compute Grid 所提供的优点和基础设施，并从较高层次上简要介绍编程模型。在后续文章中，我们将提供一个编程模型的详细例子，包括给出一些示例代码。
ObjectGrid：高级数据基础设施支持
数据量正在以指数形式持续增长。在很多情况中，数据量已经超过了应用程序和底层基础设施的处理能力。通常这都会导致速度变慢，或者应用程序性能不一致。传统的 “可扩充” 基础设施非常昂贵，通常只能暂时减轻性能问题。我们需要的是一种完全不同的方法。ObjectGrid 代表了一种日益流行的基础设施技术，可以处理数据量急剧增长的问题。
ObjectGrid 是一种非常灵活的基础设施，用于高性能、可扩充、数据密集型应用程序（请参看图 1）。它可以以非常灵活的方式使用，从非常简单的缓存到超大规模的数据网格，后者中的数据被条带化地分布到成百上千的数据服务器上进行管理。在前一篇文章中，我们提供了这些配置的一个样例。ObjectGrid 被设计用来支持广泛的使用场景。
图 1. ObjectGrid：支持灵活的数据基础设施
诸如 ObjectGrid 之类的超大规模数据基础设施代表了数据管理中的一个有趣趋势：它颠覆了传统的 “应用程序优先” 的理念。传统上，应用程序是最基本的也是最重要的，而数据访问和管理则是次要的。这种情况正在发生变化。现在，由于数据量增长带来的挑战如此尖锐，首要的问题是确保能够获得一个健壮且可伸缩的基础设施来处理数据。然后就可以围绕它来构建应用程序。
另外，当信息分散到很多分布式服务器提供的内存中时，传统的持久存储（例如数据库）也就出现问题了。当然，信息的持久存储总是需要的，但是由于信息通常会使用复制技术冗余保存在数据网格的多个位置，因此只要一组有代表性的服务器正在运行，信息就总是可以访问的。这种方法的一个问题是 —— 也是需要永久存储信息的原因 —— 它无法很好地处理整个数据网格的灾难性故障。
ObjectGrid 基础设施和服务质量
您可以使用 ObjectGrid 作为一个简单的缓存，或者在一个分层缓存环境中使用，其中数据的一个子集可以在一个非常巨大的数据缓存中访问，可能会使用一小组服务器。但是我们将着重介绍更大、更加分布也更加有用的 ObjectGrid 配置。下面让我们来看一下 ObjectGrid 所提供的基础设施特性，以及良好的服务质量。
从基础设施的观点来说，ObjectGrid 包含了一组宿主数据的服务器。通常，这些数据都被称为 mapsets，并且通常都假设这些数据是保存在内存中的。有时由于大小问题无法将所有必需的数据都保存到内存中，因此通常需要指定一些删除规则，说明何时应该将数据从内存缓存中移除，以及彻底删除或者写入永久存储中。
ObjectGrid 可以在任何 J2SE 兼容的容器中运行，它是一个轻量级的程序，只占用很少的内存（20MB）。通常它都嵌入到容器之中，例如 WebSphere Application Server 或 JBoss，由于它只需要 J2SE，因此可以在很多宿主 Java 的环境和应用服务器上运行。
mapset 有一个相关的数据布局或模式。ObjectGrid 数据网格可以管理多个 mapset。在 ObjectGrid V6.1 中，mapset 可以动态进行修改。这就意味着可以向模式中添加新字段，正在执行的应用程序可以继续运行，不过显然它们直到进行修改之后才能察觉到新的字段。这一点尤其重要，因为有时停止一个使用数据网格的应用程序是非常困难的，甚至是不可能的。
另外，对宿主在一台服务器上某个分区中数据的所有更新都可以实现传统的完整性。另外，可以通过传统语义创建复本。ObjectGrid 可以支持单阶段提交事务协议，这样可以确保实现高级的性能和可伸缩性。
可用性
ObjectGrid 支持 mpaset 的异步和同步复制。数据的复制和对复本的管理是 ObjectGrid 支持高可用和弹性的重要功能。另外，数据服务器是以自主（self-sufficient）的形式工作的；在启动时，它们会与一个目录服务联系一次，以便获得引导信息。因此 ObjectGrid 架构天生就是有弹性的。下面，我们将介绍如何在配置文件中指定复制。
性能
ObjectGrid 持续平衡和优化可用服务器之间的数据分布，从而确保实现最优的性能。数据位于内存中，因此您可以同时定位应用程序来实现非常高的应用程序性能。
可伸缩性
随着数据量的增加，可以通过简单地向数据网格中添加其他服务器来实现可伸缩性。在添加新服务器后，ObjectGrid 将使用这个新服务器，它将数据移动到新服务器上并优化数据在数据网格中所有服务器上的布局。这就意味着随着数据量的增加，应用程序的响应时间能够保持一致，通常并不是这样。
ObjectGrid 配置文件
图 2 给出了 ObjectGrid 应用程序配置文件的一个可视化表示。这个应用程序配置文件告诉 ObjectGrid 如何管理应用程序，以及如何根据基于配置自动执行所有操作。
从基础设施的观点来看，ObjectGrid 真正酷的地方在于它可以自动管理我们提到的服务质量。您可以关注应用程序方面的考虑，而 ObjectGrid 负责处理基础设施方面的问题。在需要很多规划和努力来处理并管理可伸缩的、有弹性的数据架构时，这一点非常重要。您可以认为 ObjectGrid 就是为基础设施提供了类似于 google 的功能（例如，支持映射/还原）。
图 2. ObjectGrid 应用程序配置文件
ObjectGrid 的应用程序编程
那么，ObjectGrid 应用程序看起来究竟是什么样子呢？图 3 给出了打包 ObjectGrid 应用程序的可视化表示。
图 3. ObjectGrid 应用程序剖析
ObjectGrid 支持两种编程风格：可以使用传统的 JCache type Map API，在 V6.1 版本中可以使用
EntityManager API。EntityManager API 更新一些，与低级的 Map API 相比，它在内存数据管理方面具有概念更简单的编程模型。
Map API 基于 Java Map 接口，进行扩展后允许将操作分组到事务块中。它还允许将一组关键字与给定的关键字建立关联。
清单 1. 映射关键字
sess.begin();
mapA.insert(“Kevin”, someValue);
mapA.update(“Perry”, someOtherValue);
List i = new ArrayList();
i.add(“Raj”);
i.add(“Ken”);
List l = mapA.getAll(i);
Sess.commit();
|
EntityManager API 允许使用元数据对对象图进行注释，并从数据网格中读取这个对象图形，或者将这个对象图形写入数据网格中。图中的每个实体/对象都对应一个映射，ObjectGrid 会自动维护这个关系并检测这些对象的变化。您可以指定将图形保存在数据网格中，或者从数据网格中检索该图形。这比 Map API 更加抽象，也更容易使用。
Compute Grid
现在，让我们把注意力转回到 Compute Grid 上来。Compute Grid 是 WebSphere Extended Deployment 中用来开发、执行和管理异步应用程序类型的包。此处的 “异步” 意指非在线的，通常是指批处理 程序。但是批处理这个术语还暗含着其他一些意思，因此就将它们称为异步。
传统来说，应用服务器基础设施专门用于 OLTP 任务负载。Compute Grid 的设计目的就是为了扩展除 OLTP 之外的可以开发和运行的应用程序类型，并使编程模型变得非常容易使用。Compute Grid 可以支持 3 种应用程序模式：Java 批处理任务、计算密集型和本地执行的任务。Java 批处理任务是本文重点介绍的内容，尤其是它在使用 z/OS® （用于批处理应用程序的重要平台）的大型机环境中的使用。
Compute Grid 一个重要的方面不仅在于提供的应用程序模式，而且还在于它所提供的其他基础设施功能。异步应用程序具有与 OLTP 应用程序截然不同的特性，需要使用不同的方法进行运行和管理。例如，尽管较长的响应时间在 OLTP 环境中可能是一个问题，但是异步应用程序大部分都是长时间运行的。因此工作负载管理功能需要能够理解这一点。
计算网格应用程序模式
Java 批处理任务
Java 批处理应用程序模式允许使用 Java 和简单易用的 POJO（Plain Old Java Object）编程模型来开发传统的记录处理批处理应用程序。与 ObjectGrid 类似，这里您不需要关心基础设施问题，而可以集中精力进行应用程序的开发。您并不需要担心检查点、管理日志文件等问题。
服务包括：
-
检查点
— 能够以选定的间隔重新进行批处理任务
-
结果处理
— 能够使用任何 JEE（Java Enterprise Edition）工具截获步骤及任务返回代码，并进行处理
-
批处理数据流管理
— 能够处理从文件、数据库或其他输入/输出数据源中读取和放置数据
Java 作为一种批处理编程语言具有很多有用的优点。在大型机（z/OS）环境中尤其有用。首先，通过对单一语言、OLTP 和批处理编程使用的开发环境进行标准化实现较高的效率。这要比支持单一语言以及跨越传统上完全不同概念的相关工具简单很多。
与此相关的是，也是一种非常有趣的趋势，组织现在可以为 OLTP 和批处理环境编写单独的代码库。传统上来说，这是完全不同的概念。但是使用一种语言（Java 语言）就可以逐渐将这两个环境统一起来。统一 就是指单独的代码库，有时在服务上下文中使用，有时在异步上下文中使用。当然，在这样做时也有一些考虑 —— 例如架构和性能 —— 但是在这两种环境中使用 Java 都将有利于两种环境的统一。
另外，我们已经见过一些例子，希望使用 Java 作为他们批处理开发语言的客户（大部分关于 z/OS）将架构元素（例如消息队列）组合起来实现他们的目标。通常，这些方法都非常麻烦，而且效率低下。Compute Grid 中的 Java 批处理支持为开发和执行 Java 批处理程序提供了完整的基础设施框架，并具有集成的服务质量。在很多情况中，从成本和性能的观点来考虑，这样做都更加有效。
在图 4 中，我们看到了对开发人员在创建 Java 批处理应用程序时所编写的步骤（或方法）的高级表示。此处主要的方法是 processJobStep()，您可以看到这种编程方法虽然简单却功能强大。另外，打包和部署也使用了标准的的 Java 和 JEE 应用。
图 4. Java 批处理编程框架
计算密集型应用程序
计算密集型应用程序模式用于分治式（divide-and-conquer）的高性能应用程序，例如我们在金融服务（投资分析、投资优化或风险缓释）或药品开发（成分分析）中看到的那些应用程序。随着多核架构的出现，以及并行处理的日益流行，这种类型的应用程序越来越普遍。
本地执行
本地执行实际上并不是一种应用程序模式，也没有与之相关的编程模型。相反，它是一种用来为作业指定可执行程序的组成部分的方法。因此它是一种在您的应用程序基础设施上运行非 Java（实际上可以是任何可执行文件）程序的简单方法。
Compute Grid 基础设施
Compute Grid 基础设施有两个关键元素。第一个元素是作业的概念。要使用 Compute Grid 执行一个应用程序，必须对作业进行描述。这是通过称为 xJCL 的作业控制语言实现的。然后将作业提交给 Compute Grid 基础设施的第二个元素：作业调度器。
xJCL
xJCL 是 Compute Grid 的作业控制语言（JCL）。xJCL 所采用的格式是 XML。它与 z/OS JCL 非常类似，名字由此而来。在 xJCL 中，需要指定最小的作业类型（例如 Java 批处理作业）和作业步骤。在每个作业步骤中，都可以设置 XML 变量来指定诸如可执行程序名、可设置的环境变量以及传递给可执行程序的参数之类的东西。我们不会详细介绍 xJCL 的语法，不过图 5 将通过一个 xJCL 代码片断进行介绍。
清单 2. xJCL 作业控制语言
<?xml …>
<job name="Batch">
<env-entries>
<env-var name="PATH" value="…"/>
<env-var name="CLASSPATH" value="…"/>
</env-entries>
<exec executable="java">
<arg line="tryit"/>
</exec>
</job-step>
</job>
|
作业调度器
Compute Grid 作业调度器负责提交 xJCL 指定的作业，然后执行。它与
WebSphere Extended Deployment 的 OLTP 工作负载管理和服务策略结合使用，从而优化跨共享基础设施工作的 OLTP 和 Compute Grid。服务器可以并行执行 OLTP 和 Compute Grid 工作负载。
有些人可能希望使用其他调度器来替换 WebSphere Extended Deployment 的作业调度器。如果您早已经有一种调度解决方案，例如 Tivoli® Workload Scheduler 或 Platform Computing LSF，就会出现这种情况。这些调度器可以提交、监视并控制 Compute Grid 作业，并将它们集成到企业或更加全局的工作负载调度中。另外，有一些工具可以使用传统的集群技术让 Compute Grid 作业调度器实现高可用性。
作业类和分类规则
由于异步应用程序特有的性质，它们与在线应用程序截然不同。其中之一就是资源消耗。由于异步应用程序的运行时间通常比在线事务长，并且没有交互操作，因此需要提供一些控制来确保作业不会消耗比正常情况下更多的资源。
因此， Compute Grid 包含了两个元素 — 作业类和分类规则 — 它们为管理 Compute Grid 作业提供了重要的功能。作业类提供了对资源消耗的管理控制，可以通过调度器配置进行定义。作业类是一些指定的策略，控制以下内容：
- 最大执行时间
- 每个端点并行执行的最大作业数
- 最大作业日志大小
- 作业日志保持
- 执行记录保持
- 某个作业的作业类是通过 xJCL 中的
class= 关键字进行分配的
从这些策略中您可以看到 WebSphere Extended Deployment Compute Grid 所提供的管理控制类型。
分类规则为服务策略的分配提供了管理规则。它们也可以通过调度器配置进行定义，并表示为一个按照指定顺序进行评价后的有序规则列表，其中第一个匹配项就可以分配服务策略。规则是由以下内容构成的一个布尔表达式：
- 作业名
- 作业类
- 提交者标识、组
- 作业类型（例如批处理作业）
- 时间、日期
- 平台（例如 z/OS）
z/OS 增强
上面我们提到了大型机批处理环境使用的 Java 批处理工具。Compute Grid 还提供了一些特定的增强来更好地集成 z/OS 工作负载管理。Compute Grid 利用并集成了本地 z/OS 工作负载管理（WLM）来增强作业的执行和管理：
-
SMF 统计批处理作业的记录
— SMF 120（JEE）记录对作业的调整，包括作业 ID、用户和 CPU 时间
-
用于批作业调度的动态服务
— 利用 z/OS WLM 启动新服务来根据需要执行批处理作业
-
服务策略分类和委托
— 通过将事务类从调度器传递给 z/OS 应用服务器实现作业对 z/OS WLM 的注册，使用 Compute Grid 作业分类来选择 z/OS 服务类
结束语
在本文中，我们详细介绍了 WebSphere Extended Deployment 所支持的应用程序模式，及其有关的基础设施功能。我们着重介绍了 WebSphere Extended Deployment 的 ObjectGrid 以及对 Java 批处理作业的支持。在后续文章中，我们将进一步介绍相关的编程模型，并给出一些代码示例。
参考资料 学习
获得产品和技术
-
请下载 IBM 产品评估版，开始使用来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
-
使用 IBM 试用版软件 改进您的下一个开发项目，可以从 developerWorks 下载或从 DVD 获得。
讨论
关于作者  | 
| | Matt Haynos 是 IBM WebSphere Extended Deployment 的产品经理。此前，他一直在 IBM 的网格计算小组中工作，当初他加入该小组时，网格技术还刚刚起步；他在该小组中负责多项工作，包括与构建 IBM 网格计算业务相关的广泛计划。他在 IBM 的应用程序开发、程序指导和业务开发领域拥有多个技术和管理职位。他拥有罗彻斯特大学的计算机科学/应用数学和认知科学的学士学位，以及佛蒙特大学的计算机科学硕士学位。他与妻子和两个儿子居住在美国康涅狄格州。 |
对本文的评价
| 
