大多数企业IT运营主要依赖批处理操作。这种依赖在你升级到SOA的时候也不会消失，尽管SOA仅意味着向许多人提供在线交易处理。IBM软件实验室服务部门主管IT设计师Sridhar Sudarsan遇到过这些问题。他曾指导过一些全球客户的企业架构解决方案。这些客户包括在金融、公共部门和汽车行业的一些大企业。
对于Sudarsan的客户来说，在这些客户转移到SOA的同时，批处理问题仍是一个大问号。
Sudarsan在J2EE平台上与其他人共同创建了IBM的批处理编程模型，在批处理现代化工作方面花了许多时间。他还演示了诸如“在SOA中的批处理最佳做法：转变状况”等主题。
批处理和实时处理
在批处理能够一夜之间简单地运行的时候，这个架构是简单的。它由工作申请、调度(使用一个调度程序和一个分配程序)和执行等组成。你有大量的数据流，使用某种类型的检查点机制反复进行处理。
现代批处理必须要发生，同时每一件都将或多或少地发生。因此，你必须要处理批处理窗口缩小的问题以及伴随的需要调度和优化IT资源的问题。你必须要把批处理集成到现代设计方式中，在Java/多平台上处理，把一些处理转移到Unix平台以降低成本计算。
对于某些用户来说，把批处理集成到现代设计方法的逻辑结论意味着所有的处理都将成为可处理的。
Sudarsan说，如果我遇到一个SUBMIT，我要立即得到答案。但是，他坚持认为这种事情不会很快实现。他解释说，你不能同时处理许多请求。这是你要严格的调度的原因。
Sudarsan并不认为在线交易处理(OLTP)将取代批处理。然而，他发现选择竞争优势的企业(或者仅仅为了生存的企业)需要把批处理与实时/在线处理结合起来。
在把批处理与实时处理集成在一起之后，企业通过维护较少的系统和通过进行技能的整合实现了成本优势。使用批处理和OLTP系统的人员可以使用一种开放的和灵活的架构。处理系统能够分布到各个地方。因此，批处理会更经常地、少量地、在更多的地方与OLTP一起使用。
Java程序员不知道批处理
Sudarsan承认，在谈到有关企业批处理系统的时候有一个令人担心的因素。他承认，人们确实害怕接触老式的系统。15或者20年前编写这些系统代码的人正在退休。新的程序员没有这些方面的技能，包括批处理以及如何把批处理与当前的系统和商业环境集成在一起的技能。
他解释说，客户没有财力为Java应用程序和批处理工作维护两个代码库。这两个代码库需要使用相同的逻辑，但是却不能使用。
每周7天每天24小时的处理需求意味着使用老方法的批处理应用程序必须要更换。此外，你不能让一切东西都是OLTP的，因为当前的硬件和软件不允许这样做。Sudarsan知道这些限制，因为他曾设法创建一个实时解决方案。
Sudarsan说，我也是这些情况的受害者。你在这种情况下可以提出一个雄心勃勃的架构。我们设法让整个事情都是实时的。但是，当我们经过测试并且升级到生产阶段时，一切都崩溃了。然而，他发现批处理与OLTP的集成是有用和必要的。
SOA实现了批处理/OLTP集成
Sudarsan总结了在一个现代化的努力中实现集成对SOA的需求。市场研究公司Gartner在研究报告中引述他的话说：
“...在线处理中使用的商业功能与在批处理中使用的商业功能是相同的。因此，机构应该考虑自己的IT现代化战略并且考虑把SOA当作一个标准化的应用程序集成机制。”
Sudarsan现在使用服务组合以便在SOA环境中使用批处理。
他说，一个批处理环境可作为一个轻型的包装物用于现有的OLTP应用程序基础设施。因此，你的处理编排使批处理成为一个商务处理步骤--另一种老式的集成方法。你不再需要从早上8点至晚上8点做OLTP工作并且从晚上8点至早上8点进行批处理工作。相反，你每天24小时都可以做批处理工作。
在概念上，你要把基于SOA的批处理工作量管理分为三个部分：批处理客户、批处理调度程序和工作量资源管理器。这个客户需要规划、调度、执行、监视和管理批处理工作的服务。批处理调度程序进行计划、优化、启动和编排无人管理的执行工作或者工作网络。这个批处理调度程序提供坚实和管理批处理工作的服务。然后，工作量资源管理在全部可用的资源中分配应用程序工作量以满足工作政策和服务水平协议的要求。
这种批处理执行环境可以是计算机集群、计算机网格和分布式环境，或者好的老式大型计算机。
共同的缺陷
Sudarsan说，那些努力要把批处理引进到21世纪的IT组织经常犯同样的错误。一般来说，这样的组织研制支持基础设施和安全系统的复杂的应用程序。他们过度使用第三方的库，向这个问题扔许多钱。
Java应用程序开发人员对这个过程控制得太多了，尽管他们一般都缺少有关批处理系统的知识。同时，这个平台的技术支持人员缺少能够证明自己的技能。
在编码前详细说明商务逻辑
Sudarsan在把批处理升级到SOA环境的时候采取了一种吸取教训的方法。他的最佳做法列表一开始就是避免许多IT部门采取的“预备!开火!瞄准!”的做法。
如果你仅做一项批量应用程序的“代码翻译”，例如要不费劲地从COBOL翻译到Java，这种事情可能是代价昂贵和不可行的。此外，你将制作出不可读的、不能维护的和不充分的代码。如果你要了解批处理工作的不依赖平台的模式是什么样的，你必须要了解商业逻辑和商业流程。
Sudarsan主张使用手工处理和工具创建这些商务逻辑/流程制品。他说。这样做是要保证捕捉当前的实施和满足未来的需求。自动的设计流程不会做这个事情。
速度胜过携带性
Sudarsan接下来说，为了提高效率，你需要把处理功能尽可能地安排在这个系统附近。这对于Java程序员来说是很难接受的，因为这些程序员接受的教育就是便携性超过一切。
但是,即使Java用于目标批处理平台，那也不是实施每一个组件的规定或者Java工作。
例如，你应该把分类放在操作系统的层面。你还可以从Java启动这个分类。分区也不应该用Java完成，操作系统互动也是如此(具体操作系统的登录、审计和监视)。你也许在OLTP系统中的用Java做这个事情。但是，在批处理过程中，数据(文件、数据库)的数量之大无法使用Java。
如果批处理的工作流不寻常地轻，你应该仅选择一种更便携式的实施。但是，Sudarsan说，整个纯数据处理或者ETL(提取/转换/装载)式的处理最好在数据层完成，而不要在对象层完成。
瞄准有效的数据访问
批处理性能问题可能拖整个系统的后腿。Sudarsan说，避免出现这个问题的关键是有高效率的数据访问。他提供了9个可以利用的领域以便在设计数据中心模型的时候保证快速访问：
·还存
·把只读数据与更新数据分开
·全球文件系统
·数据分区、移动
·复制
·大量数据访问与一次的单个记录
·并发性/争论/一致性
·数据联合/转换/虚拟化
·规定数据内容的宣布方法和对一个工作的需要
把数据放在应用层附近
最后，据Sudarsan说，你把数据放在应用层附近能够极大地提高数据的吞吐量。
如果你的应用层和数据层互动很麻烦，性能就会下降。如果你把数据放在应用层以外的不同的子系统，你也会造成性能下降。这样做将导致管理费用问题。这些问题是由网络负载、翻译、串行化等引起的。
做移植工作的四个步骤
你当前的实施可能使用几种独特的批处理功能。如果是这样的话，你每个功能需要采取四个步骤：
·询问在用Java实施时作为一个单独的批处理功能是否需要一个特殊的步骤。也许它能够合并，也许它需要分开。每一项实施应该需要总时间的十分之一。
·找出批处理的组建--数据流、逻辑、检查点和相关的工作控制参数。这应该用你的30%的时间。
·编写不依赖于批处理容器逻辑的商业逻辑，提供批处理应用程序能够调用的一个应用程序编程接口(API)。这应该占你20%的时间。
·测试(单位、性能和升级性)和调谐。这应该占你40%的时间。
Sudarsan称，只要你有人力资源能够实施这种可升级的开发模式，这个过程能够让你并行开发多个工作。
Sudarsan最后介绍了IBM用于J2EE的批处理编程模型。它的关键的功能包括异步执行、处理架构、面向记录和容器管理的设计、一个真正的批处理编程模型和使用XML工作控制语言。他最后介绍了他如何设计在大型计算机上执行现有的批处理应用程序的Java wrapper。
他对于Java程序员的基本观点是：只要他们熟悉每周7天每天24小时批处理的特殊需求以及这些需求如何能够满足OLTP的需求，他们就能够开发很好的批处理系统。
【发表评论0条】
