大多数资源问题你必须要把批处理集成到现代设计方式中在Java/多平台上处理把些处理转移到Unix平台以降低成本计算

        对于某些用户来说把批处理集成到现代设计思路方法逻辑结论意味着所有处理都将成为可处理

        Sudarsan说如果我遇到个SUBMIT我要立即得到答案但是他坚持认为这种事情不会很快实现他解释说你不能同时处理许多请求这是你要严格调度原因

        Sudarsan并不认为在线交易处理(OLTP)将取代批处理然而他发现选择竞争优势企业(或者仅仅为了生存企业)需要把批处理和实时/在线处理结合起来

        在把批处理和实时处理集成在起的后企业通过维护较少系统和通过进行技能整合实现了成本优势使用批处理和OLTP系统人员可以使用种开放和灵活架构处理系统能够分布到各个地方因此批处理会更经常地、少量地、在更多地方和OLTP起使用

Java员不知道批处理

        Sudarsan承认在谈到有关企业批处理系统时候有个令人担心原因他承认人们确实害怕接触老式系统15或者20年前编写这些系统代码人正在退休新员没有这些方面技能包括批处理以及如何把批处理和当前系统和商业环境集成在起技能

        他解释说客户没有财力为Java应用和批处理工作维护两个代码库这两个代码库需要使用相同逻辑但是却不能使用

        每周7天每天24小时处理需求意味着使用老思路方法批处理应用必须要更换此外你不能让切东西都是OLTP当前硬件和软件Software不允许这样做Sudarsan知道这些限制他曾设法创建个实时解决方案

        Sudarsan说我也是这些情况受害者你在这种情况下可以提出个雄心勃勃架构我们设法让整个事情都是实时但是当我们经过测试并且升级到生产阶段时切都崩溃了然而他发现批处理和OLTP集成是有用和必要

SOA实现了批处理/OLTP集成

        Sudarsan整理总结了在个现代化努力中实现集成对SOA需求市场研究公司Gartner在研究报告中引述他话说:

        “...在线处理中使用商业功能和在批处理中使用商业功能是相同因此机构应该考虑自己IT现代化战略并且考虑把SOA当作个标准化应用集成机制”

        Sudarsan现在使用服务组合以便在SOA环境中使用批处理

        他说个批处理环境可作为个轻型包装物用于现有OLTP应用基础设施因此你处理编排使批处理成为个商务处理步骤--另种老式集成思路方法你不再需要从早上8点至晚上8点做OLTP工作并且从晚上8点至早上8点进行批处理工作相反你每天24小时都可以做批处理工作

        在概念上你要把基于SOA批处理工作量管理分为 3个部分:批处理客户、批处理调度和工作量资源管理器这个客户需要规划、调度、执行、监视和管理批处理工作服务批处理调度进行计划、优化、启动和编排无人管理执行工作或者工作网络这个批处理调度提供坚实和管理批处理工作服务然后工作量资源管理在全部可用资源中分配应用工作量以满足工作政策和服务水平协议要求

        这种批处理执行环境可以是计算机集群、计算机网格和分布式环境或者好老式大型计算机

共同缺陷

        Sudarsan说那些努力要把批处理引进到21世纪IT组织经常犯同样般来说这样组织研制支持基础设施和安全系统复杂应用他们过度使用第 3方库向这个问题扔许多钱

        Java应用开发人员对这个过程控制得太多了尽管他们般都缺少有关批处理系统知识同时这个平台技术支持人员缺少能够证明自己技能

在编码前详细介绍说明商务逻辑

        Sudarsan在把批处理升级到SOA环境时候采取了种吸取教训思路方法他最佳做法列表开始就是避免许多IT部门采取“预备!开火!瞄准!”做法

        如果你仅做项批量应用“代码翻译”例如要不费劲地从COBOL翻译到Java这种事情可能是代价昂贵和不可行此外你将制作出不可读、不能维护和不充分代码如果你要了解批处理工作不依赖平台模式是什么样你必须要了解商业逻辑和商业流程

        Sudarsan主张使用手工处理和工具创建这些商务逻辑/流程制品他说这样做是要保证捕捉当前实施和满足未来需求自动设计流程不会做这个事情

速度胜过携带性

        Sudarsan接下来说为了提高效率你需要把处理功能尽可能地安排在这个系统附近这对于Java员来说是很难接受这些员接受教育就是便携性超过切

        但是,即使Java用于目标批处理平台那也不是实施每个组件规定或者Java工作

        例如你应该把分类放在操作系统层面你还可以从Java启动这个分类分区也不应该用Java完成操作系统互动也是如此(具体操作系统登录、审计和监视)你也许在OLTP系统中用Java做这个事情但是在批处理过程中数据(文件、数据库)数量的大无法使用Java

        如果批处理工作流不寻常地轻你应该仅选择种更便携式实施但是Sudarsan说整个纯数据处理或者ETL(提取/转换/装载)式处理最好在数据层完成而不要在对象层完成

瞄准有效数据访问

        批处理性能问题可能拖整个系统后腿Sudarsan说避免出现这个问题关键是有高效率数据访问他提供了9个可以利用领域以便在设计数据中心模型时候保证快速访问:

·还存

·把只读数据和更新数据分开

·全球文件系统

·数据分区、移动

·复制

·大量数据访问和次单个记录

·并发性/争论/致性

·数据联合/转换/虚拟化

·规定数据内容宣布思路方法和对个工作需要

把数据放在应用层附近

        最后据Sudarsan说你把数据放在应用层附近能够极大地提高数据吞吐量

        如果你应用层和数据层互动很麻烦性能就会下降如果你把数据放在应用层以外区别子系统你也会造成性能下降这样做将导致管理费用问题这些问题是由网络负载、翻译、串行化等引起

做移植工作 4个步骤

        你当前实施可能使用几种独特批处理功能如果是这样话你每个功能需要采取 4个步骤:

·询问在用Java实施时作为个单独批处理功能是否需要个特殊步骤也许它能够合并也许它需要分开每项实施应该需要总时间十分的

·找出批处理组建--数据流、逻辑、检查点和相关工作控制参数这应该用你30%时间

·编写不依赖于批处理容器逻辑商业逻辑提供批处理应用能够个应用编程接口(API)这应该占你20%时间

·测试(单位、性能和升级性)和调谐这应该占你40%时间

        Sudarsan称只要你有人力资源能够实施这种可升级开发模式这个过程能够让你并行开发多个工作

        Sudarsan最后介绍了IBM用于J2EE批处理编程模型它关键功能包括异步执行、处理架构、面向记录和容器管理设计、个真正批处理编程模型和使用XML工作控制语言他最后介绍了他如何设计在大型计算机上执行现有批处理应用Java wrapper

        他对于Java员基本观点是:只要他们熟悉每周7天每天24小时批处理特殊需求以及这些需求如何能够满足OLTP需求他们就能够开发很好批处理系统