wsql

应用集成与数据集成建设总体思路

应用集成与数据集成建设总体思路

建设背景

XXXX学院依托数字化校园项目为建设契机，着力于在现有校园信息化管理的基础上进一步发展并完善数字化校园精细化建设及管理。以“挖掘先进的管理理念，应用先进的计算机网络技术把高校现有的教学、科研、管理、生活、服务等有关的资源进行整合和集成，实现统一的用户管理、资源管理和权限控制，实现资源的有效配置和充分利用，实现校务管理和后勤服务过程的优化、协调，创造新的教育和工作模式，完成传统教育模式难以实现的目标”为特征的数字化校园建设成为了学校信息化建设的主要工作。数字化校园建设是一个系统工程，很多高校在建设中都遇到了困难，包括：由于缺乏统一规划，业务系统之间的功能重叠，关键数据归属和管理不明确，很难保证数据一致性；业务系统的技术平台繁多，互操作能力差，数据交换和功能调用困难，维护成本高，可靠性和安全性差；建设过程中存在各自为政的状况，分散实施和维护系统，难以实现统一认证和信息共享；用户体验差；业务系统整体开发周期长，开发效率低，难以应付学校业务需求的变化等等。

结合目前学校的建设情况和 xx公司的需求分析，学校针对信息化的迫切需求和所面临的问题，对数字化校园建设提出了新的要求：

优先建设信息化基础平台，提供数字化校园的核心功能，包括统一认证、数据存储与交换、安全管理等；
保证信息化基础平台的开放性与灵活性，能够与基于各类技术平台的业务系统交互数据和调用功能；
建设统一的校园信息门户，将教学、科研和管理相关的业务系统集成在一起，对用户提供服务；
保证信息化基础平台具有良好的可扩展能力，能够灵活地应对业务需求变化；
保证信息化基础平台的安全可靠，具有良好的身份验证、数据加密、行为审核、系统日志等功能。

　　为了满足这些数字化校园建设的新要求，我们需要一种新的体系结构，它既能有效地利用现有的IT 基础设施，又具有足够的灵活性和适应性，能与不断变化的业务流程和业务模型保持一致、并实现军校精细化管理的高标准高要求。

建设目标及原则

学校精细化管理是紧紧围绕以人为本的管理理念，以精心的态度，精心的过程，落实细节管理，实现学校管理效益最大化和最优化的一种现代管理思想，是建立在规范管理基础上，对学校规范管理的科学提升。其内涵应包含：一是“精”，即学校管理工作的重点要突出。学校工作开展的基础是要切合实际，要根据实际确定每个时期的工作重点，重点工作重点做，才能把握住方向，才能立竿见影出效益。二是“细”，即学校管理工作的覆盖环节要全。需要法治，也需要人治，但最重要的是法治，只有具备了一套完整而又详尽的规章制度，才能做到事事有章可循。“细”的另一方面含义是要“小”。从小处着眼，从小事抓起，才能真正落实精细化管理。三是“化”，即学校管理工作要制度化，学校制度内化为师生自觉遵守的行为规范。重点强调把制度落实要到位并内化为自觉行动。

高校精细化管理的实施须遵循以下主要原则：（1 ）数据化原则。强调用数据说话、用数据分析、用数据要求、用数据检验。（2 ）程序化原则。程序化管理，是把工作事项或任务，沿纵向细分为若干个前后相连的工作单元，将工作过程细化为工作流程，然后进行分析、简化、改进、整合和优化。（3 ）操作性原则。就是使制定的规则具有可操作性，而且要对实施过程要有措施进行监控。（4 ）标准化原则。就是要统一学校中各类管理活动的标准，这是做到规范化的核心内容和基本保证，也是实现操作性的前提条件。标准化体现着严格的组织纪律性，有利于克服管理的随意性和无序性，体现了“依法治校”管理的思想。

高校信息化现状及主要问题

高校信息化建设一般需经历系统集成、应用集成、信息集成、社会集成等四个阶段，到目前，各高校校园网基础设施建设已初具规模，大多数高校正处在第二或三阶段。但从整体上看，数字化校园服务体系并不完备，信息化应用水平不高，主要表现在：

信息孤岛现象比较严重。不同时期由不同人员分别建立研发的信息系统，没有遵循统一的数据标准，数据格式也不尽相同，造成了应用系统各自独立，无法相互有效访问数据和共享服务，形成了网络环境下的信息孤岛。
缺乏数字化校园建设的总体规划和统一部署，管理系统和信息资源分散，校内各部门信息化建设各自为政，资源浪费和重复建设现象普遍存在。
公共服务资源、信息资源匮乏，数字图书、网络教学平台、学科资源平台、决策服务系统等建设严重滞后。
我们认为上述问题和风险，也可以通过信息化建设过程中的精细化管理得以有效的解决和合理的规避

面向精细化管理的数字化校园建设总体思路

高校精细化管理的实施需要较高的信息化水平，随着高校信息化建设的深入，高校内部基本实现了各自业务系统的建设，如人事系统、教务系统、财务系统、科研管理系统等等，基本具备实行精细化管理的硬件条件。但数字化校园建设作为一项综合的系统工程，关系到学校工作的方方面面，对高校的管理工作也有着深远的改革和创新意义，所以，我们必须适应时代发展潮流，结合精细化管理的创新理念，科学规划、合理部署信息化建设工作。
（一）规划建设思路
主要是通过数字化校园的信息资源规划，加强顶层设计，建立高校的业务模型、功能模型、用户模型、权限模型、信息模型、数据模型和数据标准；采用统一系统架构，强化统一建设，将信息系统的三要素（数据、流程、技术）分离，实现业务与技术发展的无关性，达到良好的系统可扩展性；加强数据的规划、组织与管理，整合数据资源，构建集成数据环境；关注用户行为，了解用户需求，规划良好的用户环境，建立以人为本的用户环境。
首先是构建数字化校园数据中心，制定统一数据标准，规范接口技术，实现数据的共享，消除“信息孤岛”，这是高校推进信息化和精细化管理的基础；其次，通过分析精细化管理的内涵特点，科学规划数字化建设的项目，整合现有各个系统的服务功能和信息资源，合理分析有关信息，为学校科学决策服务；最后，以师生为本，充分挖掘和丰富各类网络信息资源、公共服务资源，不断将精细化管理落实到高校教学、科研、社会服务等三大主要功能中。
（二）通过信息化平台实现精细化管理

高校管理精细化必须是高校管理信息化。通过分析高校职能部门工作的内容和特点，将精细化管理的内容主要分为精细化预算管理、精细化流程管理、精细化成本管理、精细化时间管理、精细化质量管理、精细化组织管理等六项。学校信息化建设必须全面结合并有效实现上述管理目标，将精细化管理和信息化真正落到工作实处。
1 ．基于信息化的精细化预算管理

预算管理是提高效益和控制成本的主要手段，就高校而言，好的计划预算是成功的一半。通过事前调研、事中监督和事后评估对预算全程控制、全面管理，从而使部门的预算有依据、可操作、能动态调整，进而确保预算重点突出、统筹兼顾。以此，学校在数字化校园规划建设时，将财务系统信息、科研系统信息、人事系统系统信息、学生系统信息、教务系统信息等通过数据中心，进行数据信息有效地整序，按财务预决算办法，经科学综合的对学校上一年各部门、学院经费使用情况统计分析，以此来决策下一年合理的预算方案。有利于学校合理筹集资金、科学编排预算、合理使用经费、提高预算效率。
2 ．基于信息化的精细化流程管理
其目的在于梳理高校各级职能部门的工作思路，明确部门工作的步骤方法，辨别部门工作的关键节点。精细化流程管理要求各级职能部门具体业务的运作要有一个流程规范，通过流程规范控制好每一道流程，减少工作的失误，同时显著地提高工作效率和质量。学校规划建立一站式迎新系统和毕业离校系统，公文流转系统，一卡通系统等等。采用消息驱动机制，实现管理工作流程控制自动化，通过优化、简化流程，提供高效快捷服务。
3. 基于信息化的精细化成本管理

高校的精细化成本管理首先要建立部门完善的财务制度，要求核算部门与财务有关的行为，通过减少支出的中间环节，抓好节能降耗，采用先进技术和科学管理手段，压缩一般性支出，提高办公用品利用率和再利用率来全面降低组织成本。学校规划建立资产管理系统、设备招标和采购系统、大型实验设备及实验数据的共享。从而完善财务管理制度，优化资产配置，盘活存量，控制成本，提高资金使用效益。
4 ．基于信息化的精细化时间管理
精细化时间管理要求规划高校各能部门日常工作的顺序，合理地分配每一位成员的时间，在保障质量和效率的前提下实现时间的科学管理和最大利用。因此，精细化时间管理探究的是时间付出的边际效用最大化，要坚持以人为本的原则，将日常工作按重要性和紧迫性两个维度进行划分，按照“重要性高、紧迫性高”、“重要性低、紧迫性高”、“重要性高、紧迫性低”和“重要性低、紧迫性低”的顺序安排组织工作。高校在信息化建设规划时，可以建立协同办公系统、科研协作平台、网络视频会议系统等等。以此打通业务壁垒，提高工作效率。
5 ．基于信息化的精细化质量管理
工作质量和服务水平是衡量高校各职能部门工作的重要标准。所谓“细节决定成败”，高校应将精细化质量管理贯穿工作始终，这就要求建立一套质量管理和质量保障的规章制度，全员参与，全过程控制工作各环节的质量因素。人才培养质量关系到学校声誉和发展，信息化建设必须将教学质量监控系统、学生评教系统、科研管理系统等有机的整合起来，实现质量管理的精细化过程控制。
6 ．基于信息化的精细化组织管理
其目的是通过建立各级职能部门成员个人信息库，实现部门的人力资源科学管理。精细化组织管理除了解决人员招聘、培训、考核层面的操作问题。同时从组织管理的角度，通过个性化管理，保障高校各级职能部门的战略与执行，提升各级职能部门的核心能力。实现全过程管理。此外，利用信息化手段，充分共享全校数据，建立教职工数字档案系统、领导干部信息系统等，提供各维度的统计分析，及时为科学决策提供服务。

分项布局及技术考量
1. 整体架构设计

XXXX学院“数字化校园”建设的总体技术架构目标可以定义为：在“校园网络”的基础设施层、基础服务层上，以应用支撑层为基础架构，以应用系统层关键业务系统为核心，所有应用在“信息门户层”中集中展现，以“信息安全体系”和“运行维护体系”为保障。通过本项目建设，将构建一个面向服务、安全可靠、操作便捷、技术先进、规范统一、灵活可扩的数字化校园，为学校的教学、科研、管理提供全面的人性化服务。

统一信息门户平台：该系统建设位于数字化校园体系结构中的最上层，实现数字化校园各应用系统与用户的交互服务过程，给师生提供了一个访问信息化服务的统一入口，是数字化校园对内服务的窗口。

统一身份认证平台：统一身份认证平台提供统一管理多个应用系统的用户和身份认证功能，提高应用系统用户管理的水平，减少系统权限管理混乱、安全隐患难以发现的问题出现。通过使用该系统，用户不须记忆不同的密码和身份，为统一构建的业务系统提供一致的权限服务模型，通过统一信息门户平台实现单点登录，整体上避免重复投资。

共享数据平台：共享数据平台是对数字化校园中的各种结构化数据，包括数据库、数据集成、数据集市中的数据进行统一管理的平台。采用统一的数据交换平台集成全校异构数据。共享数据平台的建设将统一学校各业务系统的数据标准，整合各应用系统的共享数据信息，同时为上层综合应用提供一致准确的数据来源和积累。

业务构建平台：该平台为数字化校园管理信息系统建设提供构件化开发运行框架，是管理信息系统可持续发展的技术保障；使用独立的报表工具开发、维护各应用系统中的报表。

围绕三大中心统一规划建设学校各类应用系统，服务于管理、教学与科研。

校园管理中心：校园管理中心是以URP （大学资源规划）思想为核心，构建统一的管理信息系统和业务系统，整合全校各管理系统的数据与流程，为决策提供支持，这也是本期项目建设的重点。校园管理中心应用系统建设覆盖学校各业务部门主要管理职能的管理信息系统，涉及学校的人、财、物、文、事等多个方面，包括了高校各种管理信息系统，主要包括教务、学工、研究生、科研、人事、资产、财务、办公自动化等管理系统，简称URP 系统。

校园资源中心：校园资源中心是利用统一的资源集成与管理平台，将电子图书资源、论文期刊资源、互联网资源、课件多媒体资源等多种资源集成，实现数字资源的跨媒体统一检索，通过统一信息门户平台为用户提供访问数字资源的单一入口。校园资源中心的建设涵盖了数字资源制作、异构资源整合、信息发布、跨媒体检索、数字资源利用、信息安全管理等多个方面，对数字资源进行全生命周期管理。

校园服务中心：校园服务中心是以校园一卡通及网络基础服务系统为核心，对全校的学生消费、社区生活、校内服务整合和管理；逐步建设基于网络的各种社区应用，如网上交流平台、网上交易平台等。目前，服务中心的建设主要体现在校园一卡通系统和网上社区服务类应用建设。校园一卡通方案具有无需绑定厂商、用户和资金集中管理、应用丰富等优点，实现“一卡在手，走遍校园”，为广大师生员工的教学、科研和生活提供了方便、快捷的手段。网上社区服务类应用给师生提供丰富多彩的网上服务，如基本的服务应用包括邮件、论坛BBS 、网络存储、个人主页BLOG ；通讯服务如即时通讯、视频会议、IP 电话、网络电视、视频点播等，以及校园电子商务类应用。

三大体系建设：

数字校园保障体系包括信息标准体系：信息标准体系建设为各个系统定义统一的标准，包括信息标准、编码标准、接口标准、数据交换标准、管理规范、实施规范、维护规范等，是保障数字化校园系统规范、可靠运行的基础。

信息安全体系：随着技术的发展与普及、IT 技术的不断进步、我校数字化校园建设的深入，系统安全建设将更加迫切，所以包括网络接入安全、数据存储安全、应用访问安全、安全管理制度等各个层面的安全体系建设将贯穿数字化校园建设始终。

系统运维管理体系：包括系统监控、系统管理、项目管理、维护服务等，是保障数字化校园系统安全可靠运行的重要支撑体系。

综合以上三大体系和中心的建设思路我推荐采用灵活高效完整的 SOA 架构来进行整体设计。 SOA(Service-Oriented Architecture ，面向服务的架构) 是整合业务过程、支持IT 基础设施建设、提供标准化的组件服务的架构。这些组件可以重用和组合，以适应不断变化的业务需求。它是一组业务、流程、组织、管理和技术方法，是一种敏捷的系统架构。SOA 服务平台是由多个服务所构成的，这些服务用来表示在业务流程中可以被组合以及再组合成多个不同的解决方案和场景的元素，并且由业务需求所决定。这种对服务进行整合和再组合的能力为业务和IT 提供了更紧密的联系，同时也为处理新问题提供了灵活性。SOA 服务平台的作用是提供一个基础，从而可以更灵活地、更易组成地、更可复用地提供核心业务服务。

　　从架构师角度来看，在一个典型的SOA 中，每一层都具有自己的属性和关系集合。

必要的架构元素：为了实现自动的、自管理的SOA ，企业服务总线(Enterprise Service Bus, ESB) 是一个必要的架构元素。一个ESB 所提供的最本质的基础服务是传输、基于服务质量(Quality of Service, QoS) 的路由、中介和网关服务，能够与业务流程环境并行地设计和部署。

　　总线可以多种方式实现，如经典的消息传送MQ 、EAI(Enterprise Application Integration ，企业应用整合) 以及代理技术，或者使用特定平台组件如J2EE 系统中的服务整合总线。

　　ESB 使开发者们可以组件形式调用和使用业务功能，通过将它们当作满足基于Web 服务描述语言(WSDL) 的规范接口描述的服务，而不需要理会API 或协议。

　　实现： SOA 软件模型的实现必须首先通过平台无关标准来实现中立性，互操作的基本标准包括XML 和XSD 、HTTP 、SOAP 、WSDL ，以及正在发展中的WS-Policy 、WS-Resource ，WS-Security 等。当然SOA 也能够在特定软件平台上实现，包括J2EE 环境、Microsoft 的.NET 、大型机或现有的基于消息的操作系统，甚至基于C/C++ 的环境。所以SOA 架构中可以集成提供接口的各类软件平台上的应用。

　　安全性： SOA 架构作为企业级的体系结构，安全性是必须要考虑的。它采用WS-Security 、WS-Trust 、WS-Federation 等多个规范保证安全性。

　　优势：从长远来看，通过复用的“构件”和SOA 的灵活性，实施SOA 可以节省资金、时间和精力；通过灵活的解决方案和更短的部署时间，避免IT 实施的失败；通过IT 与业务服务的紧密结合，使IT 投入更合理等等。特别是基于SOA 的解决方案是与Web 服务相结合的，它打破了软件程序和供应商之间的私有化障碍，主流软件解决方案供应商都承诺使用这个开放标准，以规范各自的硬件和软件，使信息和数据得到共享。

　　重构：数字化校园体系系结构中主要包括网络基础环境、基础硬件和软件环境、校园门户、各类业务系统以及作业系统集成接口等。在SOA 架构中，由于使用了标准的开放的接口规范，基于ESB 的业务系统集成，对各厂商解决方案具有良好的兼容性，并可通过面向流程的业务整合对SOA 架构进行拓展。采用SOA 架构技术，对传统的数字化校园体系结构进行重构。

方案平台的多种选择：目前可应用的SOA 解决方案很多，软件厂商IBM 、BEA 、Oracle 、微软、金蝶、开源社区等都有自己的SOA 解决方案。

从技术研究的开源产品层面来看：目前基于OSOA(Open Service Oriented Architecture) 制定SCA(Service Component Architecture ，服务构件架构) 和SDO(Service Data Objects ，服务数据对象) 的开源产品，主要有Apache Tuscany 、EclipseSTP(SOATools Platform) 、PECL SOAfor PHP 、CodeCauldron Newton 等。这些开源产品已能提供企业级系统架构的诸多特性，尤其以Apache 下的Tuscany 和Eclipse 旗下的STP 最为引人注目。

建设内容：在重构中，我们进行如下内容的建设：

　　1. 应用ESB 对数字化校园中各类业务系统的服务进行集成，并对服务消息进行基于QoS 服务质量的路由；

　　2. 应用业务流程建模对服务进行流程管理，搭建符合业务需求的作业流程；

　　3. 建立数据中心平台，提供数字化校园数据存储、数据交换、访问控制和数据分析等功能；

　　4. 建立统一认证平台，集中管理数字化校园中各类用户信息与权限信息；

　　5. 建立信息门户平台，依靠由业务流程建模和ESB 搭建的业务流程对数字化校园用户提供一致的访问界面；

　　6. 通过构建数字化校园信息标准体系，规范校园范围内的数据交换标准和服务抽象标准；

　　7. 通过数字化校园安全保障体系保证数字化校园整体的安全。

　　递进式实施：数字化校园建设本身就是一个长期的过程，基于SOA 架构的数字化校园体系结构的实施也是如此。

　　策略：我们对基于SOA 架构的大型应用平台的实施采取了一个有效的递进式策略：

　　1. 考察采用该架构的类似案例；

　　2. 对可能应用到的技术进行验证；

　　3. 搭建基础设施和进行小范围的试点；

　　4. 试点成功后逐步扩大到整个系统领域。

　　过程

　　结合数字化校园的特点，基于SOA 架构的数字化校园体系结构的具体实施过程应该有以下7 个步骤：

　　1. 业务需求分析与抽象，并调研已有业务系统的情况；

　　2. 建立数据中心，实现数据集中存储与共享；

　　3. 建立统一认证服务，实现用户单点登录；

　　4. 建设校园信息门户，为用户提供信息访问服务；

　　5. 搭建数字化校园ESB 总线和BPM(Business Process Management ，业务流程管理软件) ，集成校园网基础服务系统，对SOA 架构进行试点；

　　6. 业务服务规划与抽象，为现有业务系统开发集成到ESB 总线的服务接口；

　　7. 基于ESB 总线、BPM 与数据中心环境建设新的业务系统，搭建高层信息决策与分析系统。

　　下一步工作：测试基于CAS 的统一认证服务，首先在校园网相关业务系统中实现单点登录，下一步将数据中心建设和信息门户建设作为主要工作，并逐步搭建数字化校园的ESB 总线和BPM ，进行基于SOA 架构的应用试点。

　　数字化校园建设是管理与技术相结合的，是服务于高校教学、科研与管理的要求的。基于SOA 架构的数字化校园建设需要与学校管理相结合，识别与定义业务服务，并且进行有效的组织，逐步采用递进式的建设策略，根据实际情况和技术发展来做出相应的调整。

1. 应用集成规范

具体规范参见 xx公司为 XXXX学院编写的《应用集成规范分册》。

建设信息整合必须要遵守的原则

全方位集成原则，信息整合系统既是“数据中心”也是“业务中心”，信息整合要具有界面集成、数据集成、应用迁移、业务集成等能力。

全面集成原则，既要支持逻辑集成，也要支持物理集成。
开放性原则，信息整合平台不能成为第N+1 个系统。
标准化原则，基于IEC61970 国际标准。
规范化原则，规范各个应用系统数据。
统一原则，实现代码统一，信息模型统一。
平台化原则，采用标准的平台，保证可靠性和标准性和开放性。
流程化原则，业务基于流程引擎实现流程重组和可定制。

达梦提供的信息整合解决方案，完全满足上面的原则。通过EAI 技术实现的集成业务、共享业务的功能，对于重要的业务系统实现单点登录、应用集成和流程集成，为企业构建业务处理中心。提供集成数据、集成业务、决策数据等信息的查询、展示应用。利用企业门户技术（EIP ）集成各个应用系统中已有的数据信息查询功能，加上信息分析中心的分析结果查询功能，形成整个企业的信息展现中心，满足企业所有人员的信息查询与共享需求。由EIP 门户平台提供员工统一的访问入口(Portal) ，集成多种业务系统的用户界面，建立一个跨应用，跨设备的，集成的互动用户界面。下图给出了系统的总体架构，总体架构分为多层实现：适配器接口层、数据集成层、应用/ 流程集成层、决策分析层、综合应用层、信息门户层、访问接入层、安全保障体系和二次开发与维护体系。

其中在SOA 设计中的几个重点层面说明如下：

应用/ 流程集成层：本层通过基于BEPL 的流程平台实现对流程的建模、调度、监控实现新流程的开发以及流程集成的支持；同时支持基于SOA 方式的应用及适配器的集成。

数据集成层：本层实现完整的数据集成功能，包括：数据整合、数据集中、数据交换。数据集成主要通过ETL 工具软件、基于EII 的数据交换技术实现。经过ETL 抽取后的数据存储在中心数据库中，中心数据库选择国际领先的大型商用数据库实现，是EAI/EIP 所有数据展现、分析功能的核心。

适配器接口层：本层提供应用系统接入EAI/EIP 系统的接口支持。接口分为几种不同的形式：

基于SOA 的应用系统的适配器
基于Web Service 实现的共享数据接口
EAI/EIP 平台软件提供的标准适配器
基于IEC61970/CIS 的实时系统适配器
数据库访问接口

安全保障体系：统一的安全保障体系包括认证、授权、审计、角色映射、信用映射等模块，这些服务嵌入在应用基础架构中，提供了EAI/EIP 应用和Web Services 的安全性，这种面向服务的安全框架可以将所需的安全请求提交给上面的各种安全服务来处理。

二次开发与维护体系：提供EAI/EIP 系统的二次开发及运行维护的支持。二次开发包括：EAI/EIP 开发工具、系统访问借口、标准适配器模板等。= 运行维护包括：EAI/EIP 平台监控、系统监视、管理、运行日志等工具。

基础支持环境：包括：基本J2EE 运行环境、数据库、Web 服务等方面。支撑环境提供给EAI/EIP 的信息门户采用的产品与及应用集成采用的产品统一的技术架构支持、统一的开发支持、统一的应用部署支持、统一的运维管理支持。

技术路线

- 以J2EE 为主体，.Net 为辅助的混合架构
- 基于“IEC61970/CIS” 和“实时数据库镜像”的实时集成
- 以IEC61970/CIM 为基础的信息模型
- 基于ETL 的数据整合、数据集中和基于EAI 的数据交换
- 基于BPM 的流程集成
- 基于SOA 的应用集成
- 基于EIP 的页面集成和应用框架
- 基于BI 的数据分析
- 基于“报表中心”的灵活报表分析
- 基于PKI 认证中心的安全认证

系统特点

平台化水平高，采用国际上标准平台技术；
全面的信息整合方案，提供数据整合、应用整合、企业门户等全方位的整合方案；
开放性好，灵活方面，可以针对业务系统的变化，重新定制信息整合平台；
标准化水平高，以IEC61970 中的CIM 模型为基础实现了标准信息模型；
数据整合手段全面，既有基于中间件的逻辑集成能力，又有物理集成能力；
数据规范化能力强，能有效处理：代码不一致、数据不规范等电力数据整合的特殊问题；
在数据整合、应用整合和门户平台之上，有丰富的应用功能，能实现报表中心、管理中心、OLAP 及智能决策等功能；

1. 数据集成规范

具体规范参见 xx公司为 XXXX学院编写的《数据集成规范分册》。

从技术角度来看本项目中涉及到的数据集成所引用的资源主要包括两类，一类是数据库层面的上的可靠性、高可用性、高性能的设计要求中所贯彻的数据库设计、规划、实施、部署中的硬件网络存储技术，另一类是数据使用和数据共享数据集成同步的Web 服务“stack" 系列技术规范，他们是一个整体的技术体系，包括UDDI 、SOAP 、WSDL 、XML 等。针对 XXXX学院目前已有的异构开发环境的（J2EE/.NET 、 Win32 ）的系统、应用、商务流程以及数据源构成的应用环境。应用环境的通信状况是混乱的，只有很少的接口文档，并且维护代价也非常的昂贵。而数字化校园所需的新建的其他若干系统增加系统综合的复杂性。我们的考虑如下：

我们以企业的例子来打比方：当企业向B2B 电子商务协作方向迁移时，他们首先要做的是审视他们内部的系统、应用以及商务流程。一些商务流程会横跨多个内部应用，在企业能够有效的和外部网络连接之前，这些应用必须能够实时动态的进行通讯。

Figure 1. 点对点的B2B 应用互联

随着诸如企业资源规划(ERP) 、客户关系管理(CRM) 、供应链管理(SCM) 以及企业门户(Enterprise Portal) 等多种商业应用的引入，激增了企业信息系统的应用分割。早期这些系统被设计成自包含的"�/ 盒" 系统，只有很少或者更本没有方法来访问它内部的数据和商务流程。虽然现在许多这些应用都提供了更好的访问他们的内部数据和商业逻辑的方法，可是把这些系统和企业里其他系统集成仍是一个巨大的挑战。

Figure 1 的每一个节点都包含它自己的数据，而这些数据可能会在节点之间共享。共享这些数据代表性的方法是通过数据传输方法，包括一批数据处理以及数据输入输出服务来完成。之所以采用这种方法是因为一个节点的数据对其他节点来说不是实时存在的，而后者也不能在处理时分析和做决定。

什么是企业应用集成?

不断增长的客户和商业伙伴对实时信息的期望的持续增加，为了满足这种期望的需要，企业被迫连接他们的那些异构的系统来增加产出、提高效率以及，最终的，使顾客满意。为使一个组织内部IT 系统互相通信，导致了企业应用集成(EAI) 的发展。EAI 通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等。EAI 解决方案的起源可以追溯到那些提供双向的解决方案以完成在企业内部的ERP 、CRM 、SCM 、数据库、数据集成以及其他重要的内部系统之间无缝地共享和交换数据的需要。

Figure 2. B2B 企业应用集成
§

EAI 不是一个能彻底解决最终问题的方案，他更可以说是正在建立一个灵活的、标准化的企业应用底层架构，可以允许新的基于IT 的应用和商业处理能够更容易和更有效的被部署。新的底层架构允许企业中的应用能够实时的，无缝的互相通信。

EAI 的类型

EAI 解决方案可以呈现许多种形式并以多种级别出现。EAI 合适的级别依赖于许多因素，包括公司的大小、公司的行业类别、公司应用的集成度或是项目的复杂度以及预算等等。

这里列出了EAI 的中间件解决方案的4 个类型：

用户界面集成
数据集成
商务流程集成
函数/ 方法集成

当我们看到这些解决方案的类型，要注意的是我们在讨论解决方案的样式而不是具体实现。

用户界面集成( 界面重组)

界面重组是一个面向用户的整合，他将原先系统的终端窗口和PC 的图形界面使用一个标准的界面( 有代表性的例子是使用浏览器) 来替换。一般的，应用程序终端窗口的功能可以一对一地映射到一个基于浏览器的图形用户界面。新的表示层需要与现存的遗留系统的商业逻辑或者一些封装的应用如ERP 、CRM 以及SCM 等进行集成。

企业门户应用(Enterprise Portal) 也可以被看成是一个复杂的界面重组的解决方案。一个企业门户合并了多个企业应用，同时表现为一个可定制的基于浏览器的界面。在这个类型的EAI 中，企业门户框架和中间件解决方案是一样的。

数据集成

数据集成发生在企业内的数据库和数据源级别。通过从一个数据源将数据移植到另外一个数据源来完成数据集成。数据集成是现有EAI 解决方案中最普遍的一个形式。然而，数据集成的一个最大的问题是商业逻辑常常只存在于主系统中，无法在数据库层次去响应商业流程的处理，因此这限制了实时处理的能力。

此外还有一些数据复制和中间件工具来推动在数据源之间的数据传输，一些是以实时方式工作的，一些是以批处理方式工作的。

下面列出了一些数据集成的方法：

批传输
数据合并
数据复制
析取、转换、装载解决方案(ETL Solution)

Figure 3. ETL Solution

ETL 解决方案( 如上图所示) ，是基于ETL 引擎的，从不同的应用程序析取、转换、过滤和装载数据到数据集成和( 或) 数据市集。现在ETL 已经是企业实现数据集成的一个非常有效的途径。

商务流程集成

虽然数据集成已经证明是EAI 的一个流行的形式，然而，从安全性、数据完整性、商务流程角度来看，数据集成仍然存在着很多问题。组织内大量的数据是被商业逻辑所访问和维持的。商业逻辑应用并加强了必须的商业规则、商务流程和安全性，而这些对于下层数据都是必需的。

商务流程集成产生于跨越了多个应用的商务流程层。通常通过使用一些高层的中间件来表现商务流程集成的特征。这类中间件产品的代表是消息中介，消息中介使用一个总线模式或者是HUB 模式来对消息处理标准化并控制信息流。下面的图示在一个较高的层次说明了一个开放的商务流程的组成：

Figure 4. 基于开放式商务流程的集成

函数/ 方法集成

函数和方法集成包括直接的和严格的，在网络环境中的跨平台应用程序之间的应用到应用(A2A) 的集成。它涵盖了普通的代码(COBOL,C++,Java) 撰写、应用程序接口(APIs) 、远端过程调用(RPCs) 、分布式中间件如TP 监控、分布式对象、公共对象访问中介(CORBA) 、Java 远端方法调用(RMI) 、面向消息的中间件以及Web 服务等等各种软件技术。

Figure 5. 函数/ 方法的集成
§

面向函数和方法的集成一般来说是处于同步模式的，即基于客户( 请求程序) 和服务器( 响应程序) 之间的请求响应交互机制。

Web 服务

Web 服务提供了一个分布式的计算技术，用于在Internet 或者intranet 上通过使用标准的XML 协议和信息格式来展现商业应用服务。使用标准的XML 协议使得Web 服务平台、语言和发布者能够互相独立，这是EAI 解决方案的一个理想的候选者。

通过开放的Internet 标准：Web 服务描述语言(WSDL ，用于服务描述) ，统一描述、发现和集成规范(UDDI ，用于服务的发布和集成) ，简单对象访问协议(SOAP ，用于服务调用) 和Web 服务流语言(WSFL ，用来定义工作流，这尚不是一个W3C 标准) ，Web 服务消除了现存解决方案( 如CORBA 和DCOM) 中的互用性问题。

EAI 和Web 服务

Web 服务不是EAI 或者是EAI 的一部分，更甚者，Web 服务是另外一个技术，Web 服务能够使EAI 成为真正可能的、便捷实施的，同时又引人注目的解决方案。Web 服务能彻底地改变传统的EAI 中点对点的集成处理方式。

使用Web 服务，通过松散的应用集成，一个企业可以仅仅实现EAI 的一个子集，即能取得实效。与之相反，EAI 要实现一个全盘的方案，来紧密的集成和联系支持公司业务的所有的系统和应用。在公司内部不同的业务系统和技术单体中可能需要花费数年的持续的努力，高投资以及为之配备的充实的资源。

Web 服务，以这样一种松散的服务捆绑集合形式( 也可以说是一个特别得解决方案) ，能够快速、低代价地开发、发布、发现和动态绑定应用。就当代Web 服务的技术发展水平来看，Web 服务可以实现应用程序之间的函数或方法级的集成。他们不是自然的基于事务的，同时仅提供了基本的" 请求/ 响应" 功能。然而，在下一代的Web 服务中，在功能上和技术上都会更先进，将会提供用户接口封装和安全性，他们将能够包装一个应用程序并且把他嵌入到其他的应用程序中去。

现有的主要关注于应用集成的EAI 解决方案将不得不因此而改变。在将来，包装好的应用程序将使用如XML 、SOAP 、WSDL 和UDDI 技术来把他们的函数或方法作为Web 服务的界面来显示。因此，EAI 解决方案将不得不提供一个对服务集成的广泛的支持，而不仅仅是应用集成。

传统EAI 解决方案和Web 服务之间的显著的不同

下面是传统的EAI 解决方案和Web 服务之间的一些基本的不同点：

( 注意：有一些不同点所描述的Web 服务的特点可能并非是Web 服务目前有的特性，而是考虑了Web 服务被提议的未来的改进)

简单性：毫无疑问，相比于典型的EAI 解决方案( 也许包括分布式技术如DCOM 和CORBA) ，Web 服务更便于设计、开发、维护和使用。既然开发和使用Web 服务的平台框架已经准备好了，创建跨越多个应用程序的商务流程处理将变得相对简单。

开放标准：不像有所有权的EAI 解决方案，Web 服务是基于开放标准诸如UDDI 、SOAP 、HTTP 的。这个可能是导致Web 服务被广泛接受的最重要的因素。事实上基于现存的开放标准消除了企业潜在地为了支持新出现的Web 技术的投资的需要。

灵活性：既然EAI 解决方案需要点对点集成，一端的改变必须告知另外一端，这自然使集成变得非常的生硬，同时也是浪费开发人员的时间的。基于Web 服务的集成是非常灵活的，因为他是建立在发布服务的应用程序和使用服务的应用程序之间的松散耦合。

便宜：EAI 解决方案，诸如消息中介，其实施是非常昂贵的。而Web 服务的实施则会变得便宜而快速。

范围：EAI 解决方案，诸如消息中介，把应用程序作为一个单个的实体来集成。然而Web 服务允许企业把大的应用划分为小的独立的逻辑实体并且包装他们。举例来说，企业可以为一个ERP 应用的不同的商业组件进行包装。如订单管理、接受购买订单、订单情况、订单确认、帐户接受、帐户支付等等。

高效性：已在前面几点提到的，Web 服务允许应用程序划分为一些小的逻辑组件，因为在小粒度基础上集成应用程序，集成将变得更容易。这也使Web 服务的EAI 解决方案比传统的EAI 解决方案更有效率。

动态：Web 服务通过提供动态的服务接口来实施一个动态的集成。然而传统的EAI 解决方案都是静态处理的。

用Web 服务的EAI 示例

下面的Figure 6 显示了在一个在企业内使用Web 服务的例子。在这个例子中，在应用服务器中运行的企业门户从多个内部应用集成信息，并提供一个跨越这些应用的业务处理的入口点。企业门户应用通过内部应用程序使用私有UDDI 注册中心(Private UDDI Registry) 来获得可提供的Web 服务的技术信息，并且在企业内部Intranet 上调用这些服务。一些经常被调用的Web 服务的绑定信息将被企业门户应用缓存，这样得以避免花费在动态绑定上的资源和时间。在这个例子里面，Web 服务把企业门户和CRM 、ERP 应用程序松散的集成在一起。

Figure 6. 使用Web 服务进行WAI 的示例
§

流程步骤如下：

在登录企业门户之后，用户发出请求信息；
支持企业门户框架的应用程序通过浏览私有UDDI 注册中心获得关于CRM 和ERP 应用的Web 服务的技术；
Web 服务的位置和WSDL 绑定信息被穿送给应用服务器；
应用程序调用CRM 应用发布的Web 服务得到个人的信息，如名字、身份证号码、地址以及用户的Email 。这个通讯过程是基于SOAP 交互的；
应用程序调用ERP 应用发布的Web 服务获得银行帐号信息，诸如银行帐号号码，结余和用户交易历史记录。这个通讯过程也是基于SOAP 交互的；
信息被格式化后，被发给起初的调用用户。

从哪里开始

企业在内部应用程序中使用Web 服务来实施应用集成的项目，应当从函数、应用程序接口(API) ，或者远端过程调用(RPC) 级别开始这一进程。这个将使企业内使用和实施Web 服务的IT 技术人员熟悉Web 服务技术，当企业将来使用Web 服务进行外部集成(B2B 集成) 项目时，将会有助于项目的有效进行。在Intranet 内控制、管理、寻找、执行和维护Web 服务相对来说也比通过企业防火墙在Internet 上使用Web 服务更为容易。进一步来说，它将帮助企业来比较和鉴别，使用标准化和相对便宜的Web 服务解决方案相对于昂贵的传统的EAI 解决方案到底是不是对提高企业的产出率更有帮助。

然而，要求企业抛弃现存的EAI 底层架构并且盲目的转向开发基于Web 服务的解决方案来替代它是不太现实的。企业不会停止使用提供完整事务服务的EAI 中间件框架。在使用Web 服务的场所，不是替代( 现在还不是) ，而是应该使用Web 服务来支撑现存的下层结构。

经过一段时间，Web 服务将逐渐的由一个EAI 解决方案进化为一个B2Bi(B2B Intergration) 解决方案。

结论

通过一个被Web 标准支持的方法而不是一个有私有知识产权的系统，Web 服务提供一个中立的平台来集成应用程序，从而被用于集成不同的应用系统。依靠Web 服务，企业能够实时地访问不同部门、不同应用、不同平台和不同系统的信息，这已是Web 服务被接受的最重要和最有力的因素之一。在企业" 冒险" 在B2B 中使用Web 服务实施应用集成之前，企业应当首先在他们内部的非面向事务的一般商业流程集成中使用Web 服务。

1. 实时数据集成

对于设计企业应用程序来说，面向服务的体系结构 (SOA) 提供了像可重用组件和独立于平台的通信等优点。当考虑 SOA 的时候，必须将数据集成作为一项基本要素。大量遗留数据来自于每天的日常事务，并且必须将其作为新应用程序的组成部分来进行维护。如果将 SOA 和数据集成技术结合在一起，那么通过可重用性、与其他企业应用程序之间增加的通信，以及 Web 服务的使用，都将使您从中受益。DataStage 是一款 IBM 旗舰产品，它为实时数据集成 (RTI) 提供了一整套解决方案，可以将 RTI 作为 Web 服务来进行处理。您将使用 DataStage 开发示例 RTI 作业，将其作为 Web 服务进行发布，并使用 Java™ 客户端调用这个 Web 服务。

实时数据集成和 WebSphere DataStage 的简介

RTI 是 IBM WebSphere DataStage （以下简称为 DataStage ）中的一个组件，它允许您创建可共享的标准服务，包括 Web 服务。您可以调用这些代表 DataStage 作业的数据集成功能的服务，而无需全面地了解数据集成逻辑。将 DataStage 作业作为可共享的服务进行部署，这将为您带来很多的优点，其中包括：

提供对不同数据源（内部的和外部的）的单点标准访问。
实时地重用来自 DataStage 作业的逻辑。
通过为每个应用程序提供统一的服务，可以更快地部署应用程序，这将极大地减少冗余代码。

图 1 显示了 RTI 的体系结构。

图 1. RTI 的体系结构
§

本部分说明了如何将 RTI 作业作为 Web 服务进行部署。让我们将这个过程分为下面几个部分进行介绍：

RTI 作业拓扑的简介
使用 DataStage 一步一步地开发一个示例数据集成组件
将数据集成组件作为 Web 服务进行发布
开发一个 Java 客户端，以调用您所发布的 Web 服务

RTI 作业拓扑

RTI 服务器支持以下三种作业拓扑：

拓扑一：批处理作业
拓扑二：包含 RTI 输出组件的批处理作业
拓扑三：完全与 RTI 兼容的作业

拓扑一：批处理作业

拓扑一使用新的或者现有的、作为 RTI 服务公开的批处理作业。（请注意，这种拓扑不包含任何 RTI 组件，如 RTI 输入组件或者 RTI 输出组件，在下面的部分中将对它们进行说明。）基于批处理作业的 RTI 服务可以接受作业参数作为输入参数。这种类型的服务不返回任何输出。当您配置部署时，可以为作业参数设置相应的值。图 2 显示了这种拓扑的一个示例。

图 2. 批处理作业
§

拓扑二：包含 RTI 输出组件的批处理作业

拓扑一和拓扑二之间唯一的区别在于，拓扑二包含 RTI 输出组件。RTI 输出组件是作业的退出点，并且作为服务响应，它将为客户端应用程序返回一行或者多行内容。RTI 输出组件支持一个输入链。它的表定义可以映射为 RTI 服务的输出参数。请参见图 3 中关于这种拓扑结构的示例。

图 3. 包含 RTI 输出组件的批处理作业
§

拓扑三：完全与 RTI 兼容的作业

在拓扑三中，作业可以同时使用 RTI 输入组件和 RTI 输出组件。RTI 输入组件是作业的入口点，在服务请求期间接受一行或者多行内容。RTI 输入组件支持一个输出链。它的表定义可以映射为 RTI 服务的输入参数，如 Web 服务操作的输入参数。符合拓扑三的作业始终是开启的。在您将这个作业作为 Web 服务进行了部署之后，您将发现该作业的一个实例正在 DataStage Director 中运行。图 4 显示了这种拓扑的一个示例。

图 4. 完全与 RTI 兼容的作业
§

开发一个示例 RTI 作业

现在，让我们来创建一个示例 RTI 作业，以便从数据库表中提取位置信息。您使用的参数是 employeeid ，将该参数组织为数组，这样您就可以同时传递多个参数。然后，该作业返回输入参数所指定的雇员的位置信息。这个 RTI 作业使用名为 RFIDLOCATION （请参见表 1 中该表的定义）的表，该表存储在一个名为 GBPMDB 的 IBM DB2® 数据库中。在表 2 和表 3 中分别显示了 RTI 输入组件和 RTI 输出组件的表定义。请注意，表 1 中包括了表 2 和 3 中所有的列。因此，当您使用 DataStage Designer 导入表定义的时候，您可以由表 1 中的表定义得到表 2 和 3 的表定义。

表 1. 表 RFIDLOCATION 的表定义

列名	主键	类型	长度	可否为空
RFIDRecordLocationID	是	Integer	10	不能为空
EmployeeID	否	Varchar	60	不能为空
LocationID	否	Integer	10	不能为空
RecordTime	否	Timestamp	26	不能为空

表 2. RTI 输入组件的表定义

列名	主键	类型	长度	可否为空
EmployeeID	否	Varchar	60	不能为空

表 3. RTI 输出组件 LocationInfo 的表定义

列名	主键	类型	长度	可否为空
EmployeeID	否	Varchar	60	不能为空
LocationID	否	Integer	10	不能为空
RecordTime	否	Timestamp	26	不能为空

使用 DataStage Designer 导入表定义

在 DataStage Designer 的存储库中，右键单击 Table Definitions ，然后选择 Import > Plug-in Meta Data Definitions 。
在 Name 栏中选择 DSDB2 ，并单击 OK 。
在下一个窗口（请参见图 5 ）中，从下拉列表中选择服务器的名称（在这个示例中，选择 GBPMDB ）。该服务器的名称即为您创建的数据库的名称，该数据库中包含您希望导入的表。
键入用户名 db2inst1 和密码 passw0rd ，以连接到服务器。
选择 Tables 复选框，并单击 Next 以继续。
图 5. 选择数据库
§
现在，从 Select Table(s) 列表中选择 RFIDLOCATION 表，然后单击 Import ，以导入 RFIDLOCATION 表的表定义。

您现在应该可以在 DataStage Designer 存储库中的 DSDB2 子类别中看到您刚刚导入的表定义，如图 6 所示。

图 6. 表定义
§

创建一个并行作业

现在，在 DataStage Designer 中创建一个新的并行作业（请参见图 10 中这个作业的布局）。这个作业中包含一个 DB2/API UDB 组件、一个 RTI 输入组件、一个 RTI 输出组件和一个连接组件，它们通过链接组件连接在一起。
图 7. 作业布局
§
将新的作业保存为 sampleRTI 。

配置该作业的属性

在 DataStage Designer 中单击 Job Properties 图标，以打开 Job Properties 窗口（请参见图 8 ）。
在 General 选项卡中，选择 Allow Multiple Instance 和 RTI Service Enabled 。
单击 OK ，然后保存该配置。
图 8. 作业属性的配置
§

配置 DB2/UDB 组件

双击 DB2/UDB API 组件的 RFIDLOCATION ，以打开如图 9 所示的窗口。
图 9. 配置数据库连接信息
§
在这个窗口中，指定服务器的名称（即您希望连接到的数据库的名称），在这个示例中，使用 GBPMDB 。
输入用户 ID db2inst1 和密码 passw0rd 。保留其他的配置作为缺省配置。
单击位于该窗口顶部的 Output 选项卡。
在 Output 页面的 General 选项卡（请参见图 10 ）中的 Table names 字段中输入 RFIDLOCATION ，并从 Query type 下拉列表中选择 Generated SQL query 。
保留剩余的缺省设置，并单击 Columns 选项卡。
图 10. 配置表信息
§
在 Columns 选项卡中，单击 Load 按钮，以加载表定义。这时将弹出一个窗口，显示您在存储库中选择的表定义。
在 DSDB2 子类别中选择 RTILOCATION ，然后单击 OK 。
现在来选择列（如图 11 所示），然后单击 OK 。
图 11. 选择列

您将看到如图 12 所示的结果。单击 OK ，并保存该作业。
图 12. 导入结果
§ 配置 RTI 输入组件 Employeeid
双击 RTI 输入组件 Employeeid ，并在 Outout 页面中选择 Columns 选项卡。
将在这里加载表定义。（为 Employeeid RTI 输入组件加载表定义的步骤与在配置 DB2/UDB 组件 § 部分中所描述的步骤是一样的。）
在加载了表定义之后，单击 OK ，并保存该作业。

配置 RTI 输出组件 LocationInfo

双击 RTI 输入组件 LocationInfo ，并转到 Input 页面中的 Columns 选项卡。
加载表定义。（为 Employeeid RTI 输入组件加载表定义的步骤与在配置 DB2/UDB 组件 § 部分中所描述的步骤是一样的。）
在加载了表定义之后，单击 OK ，并保存该作业。

配置连接组件 JoinByEmployeeid

双击 JoinByEmployeeid ，以便对它进行设置。
转到 Stage 页面中的 Properties 选项卡，然后选择 EMPLOYEEID 将其作为连接键，并选择 Inner 作为连接类型，如图 13 所示。
图 13. 配置连接组件
§
现在，转到 Output 选项卡。您可以看到，DataStage 已经在源和目标之间生成了一个映射关系。保留这些缺省设置，并单击 OK 。

编译该作业

单击 DataStage Designer 中的 Compile 图标。这时将打开 Compile Job 窗口，同时显示一条 Job successfully compiled 的消息，假定在整个过程期间没有出现任何错误的话。现在，该作业已做好了部署的准备。

将 RTI 作业 sampleRTI 作为 Web 服务进行部署

本部分剩下的部分描述了如何使用 RTI 控制台将 RTI 作业作为 Web 服务进行部署。

在 Current Task 窗格中，打开 RTI 控制台，并单击 Register an RTI Server 。这个操作将打开 RTI Server Wizard ，如图 14 所示。
在 RTI Server Name 字段中，输入 RTI 服务器的计算机名称。端口号可能不同，这取决于您的 RTI 服务器运行时所处的应用服务器。例如，如果该应用服务器是 IBM WebSphere Application Server ，那么端口号是 9080 。
保留所有其他字段的缺省设置，并单击 Finish 。
图 14. 设置 RTI 服务器
§
您刚注册的 RTI 服务器现在作为一个图标出现在右边的窗格中。双击该图标。
在 Current Tasks 窗格中，单击 Register a DataStage Machine 以打开 DataStage Machine Registration Wizard （请参见图 15 ）。
在 Machine name 字段中，输入运行 DataStage 服务器或者 DataStage TX 主机的计算机名称。
对于 DataStage 服务器计算机，在 User 和 Password 字段中输入您的有效凭证。RTI Agent 的缺省侦听端口是 2000 。如果您的 DataStage 管理员更改了这个端口，那么请进行下面的操作：

1. 选择 User-defined port 按钮。
2. 输入新的端口号。
3. 单击 Finish 。

图 15. 设置 DataStage 计算机
§
在 Current Tasks 窗格中，单击 Add a New Service to the RTI Server 以打开 RTI Service Wizard 。
在 Service name 字段中，输入新服务的名称，然后单击 Finish 。
您刚创建的服务现在作为一个图标出现在右边的窗格中。双击这个 sampleRTI 图标。
在 Current Tasks 窗格中，单击 Add Support for Service Bindings 以便打开 Add Support for Service Bindings Wizard 。
在右边的窗格列表中选择 Soap over HTTP ，然后单击 Next 。
在 Additional binding-specific description 字段中，可以输入一个绑定的描述，将它添加到 Web 服务描述语言（WSDL ）中。
从 Style 列表中，为 SOAP 消息选择一个编码类型。您的选择取决于客户端应用程序所能接受的类型。
单击 Finish 。这个绑定图标出现在 Results 窗格中。
在 Current Tasks 窗格中，选择 Add an Operation 以打开 New Operation Wizard ，如图 16 所示。您将看到注册的 DataStage Server 的列表和表示为节点的 DataStage TX 计算机。
选择作业 sampleRTI ，即您刚创建的作业，然后单击 Next 。
图 16. 选择 RTI 作业
§
在 Operation Name 字段中，如果需要的话可以更改这个名称。其缺省值是作业或者映射的名称。
在 Queue Size 字段中，使用服务请求来指定操作队列的大小。如果队列大小超出了指定值，那么将拒绝请求。缺省值为三个请求。
在 Wait delay 字段中，指定最大的等待时间，以毫秒为单位。如果等待时间超出了指定的最大时间，则拒绝请求。缺省值是 100 毫秒。
单击 Next 。
下拉 Options 列表并选择 Array （请参见图 17 ）。对于那些接受或需要在单个请求中包含多行内容的任务，应该将它们的输入参数组织为数组。在这个示例中，您作为 Web 服务部署的作业可以在单个请求中接受多行内容，因此您必须从 Options 列表中选择 Array 。

图 17. 创建新的操作
§

这个 RTI 作业在单个请求中返回多行内容，因此在 Options 列表中再次选择 Array 。
单击 Next 。
您现在应该处于 New Operation Wizard - Messages Summary 窗口中，如图 18 所示。在 Service Request 和 Response Messages 字段中，检查该操作的输入和输出参数，然后单击 Finish 。
图 18. 检查输入和输出参数
§

现在，您可以设置运行时参数。

在 Minimum 字段中，输入可以在任何给定时间运行的并发作业实例的最小数目。
在 Maximum 字段中，输入可以在任何给定的时间运行的并发作业和映射实例的最大数目。其缺省值为 5 ，最大值的缺省值是 500 。
保留其他字段的缺省设置，并单击 Next 。
在下一个窗口中，如果需要的话，替换缺省用户凭证，然后单击 Finish 。
当 Opertion Created 窗口弹出时，单击 OK 。
右键单击位于右边的窗格中的绑定图标，并选择 Activate ，如图 19 所示。
图 19. 激活该绑定
§
双击您创建的操作。在右边的窗格中，您将发现您刚附加到该操作的作业。
在 Global Tasks 列表中，单击 Browse the RTI Registry 以打开 RTI Registry Web 页面。您将在列表中发现您刚刚注册的 RTI 服务 sampleRTI （请参见图 20 ）。
图 20. RTI 服务列表
§
单击 sampleRTI 显示它的注册信息。
要在 Web 浏览器中显示该服务的 WSDL ，单击 WSDL 链接。通过这个 WSDL 文件，您可以调用所开发的这个 RTI 作业。

开发一个 Java 客户端，以便调用这个 Web 服务

这个部分说明了如何使用 Java 客户端调用您刚刚部署的 Web 服务，而您的主要任务是开发这个 Java 客户端。在开始之前，您需要准备好下面的环境：

Eclipse IDE 版本 3.0 或更高版本 — 您可以使用 Eclipse 开发该 Java 项目；准备一个 Eclipse IDE ，这样您可以很容易地遵循本部分中所介绍的步骤。
JDK 1.4 或者 1.5 — 这是开发 Java 项目的基本要求。
Apache Axis — 您使用 Axis 从 Web 服务生成本地 Java 存根，这使得可以很容易地调用 Web 服务。

现在，您可以开始开发您的 Java 客户端了。

创建一个 Java 项目，并将其命名为 TestRTIJob 。
右键单击该项目，并选择 Properties 。打开一个如图 21 所示的窗口。
单击 Libraries 选项卡，如图 21 所示，添加 Axis .jar 文件。
图 21. 添加 .jar 文件
§
从 Eclipse IDE 中选择 Run > Run 以打开一个如图 22 所示的窗口。
图 22. 生成 Java 存根
§
在这个窗口中的左侧创建一个新的 Java 应用程序实例，然后单击右边的 Search 按钮。
从打开的 Choose Main Type 窗口中，选择 WSDL2Java 类。Axis 提供了这个类，以便由 WSDL 文件生成本地 Java 存根。
单击 OK 。
复制您刚发布到 Program arguments 字段的 Web 服务的 WSDL 文件的 URL ，如图 23 所示。
图 23. 复制 WSDL 文件的 URL§

单击 Run 。当完成该程序时，您将注意到在您的项目中生成了一些存根类，如图 24 所示。这些类可以帮助您调用该 Web 服务。
图 24. 生成的 Java 存根类
§
现在，您需要创建一个名为 TestRTIJob 的类，以便通过刚生成的存根类来调用 Web 服务。清单 1 中提供了这个类的源代码。

清单 1. 调用 Web 服务

package com.ascential.rti.sample;

import java.rmi.RemoteException;

import javax.xml.rpc.ServiceException;

public class TestRTIJob {

public static void main(String[] args){

SampleLocator locator = new SampleLocator();

SampleDOCLIT service = null;

try {

service = locator.getsampleSoap();

String name = service.RTIJob("001");

System.out.println("The name is: " + name);

} catch (ServiceException e) {

e.printStackTrace();

} catch (RemoteException e) {

e.printStackTrace();

}

运行这个类。Java 控制台打印出了用户的位置信息。

到这里为止，您完成了全部的工作! 您已经完成了从开发一个 RTI 作业，到作为 Web 服务发布它，以便从 Java 客户端调用该服务的全部过程。

结束语

IBM WebSphere DataStage 提供一种便利的方法，用于将 DataStage 作业作为 Web 服务进行部署。在本部分中，您了解了 RTI 以及其所有的特性，然后您开发了一个示例 RTI 作业，并将其发布为一个 Web 服务。最后，您使用 Java 客户端调用了这个 Web 服务。希望您能够更加熟悉 DataStage 以及它如何无缝地与 SOA 进行结合。

1. 集成开发实施的重难点分析

首先，合理的开发流程是ETL 实施的必要前提。数据集成项目往往是面向多个系统、海量数据的庞然大物，面对各种各样纷杂的头绪一套系统、科学、行之有效的开发流程必不可少。

其次数据源分析将是一项非常重要的基础性工作，整个分析工作任务琐碎、繁杂，工作量巨大，是数据集成系统建设中最为耗时费力的工作之一。数据源分析既需要分析者具备丰富的业务经验、数据库设计经验，也需要分析者有细致、耐心和执著的工作精神，更需要恰当、高效的工作方法。

另外ETL 开发的质量检核将是系统运行维护的重要保证。测试是否完整可靠将直接决定数据集成中数据的可用性，文档是否真实全面也将是影响数据集成的后续开发的重要因素

ETL 的开发是数据集成实施成功的关键，本部分将就如何实现ETL 流程开发与实施中的质量保证做一下探讨，主要从开发流程、数据源分析、质量保证等几方面进行阐述。

ETL 开发流程

从上面的开发流程图中，我们对ETL 的整个开发过程有了清楚的认识。实施的过程中要包括业务需求分析、数据源分析、ETL 规则确定、ETL 概要设计、ETL 详细设计、ETL 编码、单元测试、数据质量测试、ETL 流程测试、ETL 性能优化等步骤。在实施过程中ETL 规则评审与数据质量的评审都是基于数据源分析的正确性，也是数据集成实施成功与否的关键，如数据源分析的不正确，整个项目实施的结果将是“中看不看用”。测试将是开发流程中的另一瓶颈，保证着是否能把真实有用的源系统数据转入到数据集成中来。

数据源分析

从开发的流程中，数据源分析将输出《数据源分析报告》、《ETL 抽取规则》、《脏数据处理规则》等正式文档及一些中间结果，这几份文档的质量是决定后续实施是否顺利、是否需要返工的基础。数据源分析工作主要是提取源系统符合业务需求的数据项并对源系统数据质量进行，下面我们将分几方面进行讨论。

数据质量衡量分类

高质量的数据是指那些符合业务需求的数据。对源系统数据的衡量分类隐含着制定数据集成数据标准的工作，而且在此基础上需保证所取数据的真实性、可用性。衡量数据质量可在以下几个方面进行，并在需要采集的数据源中进行评估，分析数据源的质量，得出相应的ETL 规则：

数据质量特征	描述
正确性	数据值必须与数据域一致
准确性	一个数据值与设定为准确的值之间的一致程度由业务专家审查决定是否没有错误
完全性	一致性——维护数据使不同系统的数据没有差异和相互矛盾一组数据满足一组约束条件的程度
完整性	不同系统的相关数据之间联接是正确的
唯一性	决定数据记录（和关键数据值）不被重复定义和使用的能力
有效性	数据质量完全满足分类标准规定的可接受要求该条件用于在编辑时确定数据值是否可以接受，是否可以产生需要的结果
时效性	单个或多个数据项目能够在要求时间内提供的程度特定数值更新的程度

5 级测试方法

对数据源进行质量评估可以采取5 级测试法。从0 级直至4 级，每级的测试将针对不同的关注点分析源系统数据，最终达到检核保证抽取数据质量的目的。

级别	描述
0 级－值域分析	值域分析为将为每个数据元素确定真实的数据域值
1 级－完全性和有效性评估	数据质量评估方法论的完全性和有效性评估部分关注在数据环境中的单个数据元素的数据内容
2 级－结构的整体性评估	这一部分的评估将关注源系统数据结构和源系统中数据记录之间的关系。需要在本阶段评估的关键要点是：主键、外键和基数的关系规则
3 级－业务规则合规性评估	业务规则合规性评估将在数据转换完成后进行，其将分析建立在多个数据元素间逻辑关系的质量
4 级－转换规则合规性评估	转换规则合规性评估将在数据集成环境中进行，以确保数据从ODS 转移到数据集成的数据转换符合业务的要求

数据质量评估反馈和报告

数据源经过数据质量评估后将产生大量测试数据，为了有效利用这些数据，需要对其进行整理并以报告的形式反馈给有关人员。报告是根据数据质量评估的结果制作和发布的，其目的是收集数据存在的质量问题, 提出数据质量的提升方案以及解决数据质量问题的方法。完整的报告应包括：

- 评估的数据元素清单
- 数据元素的衡量标准
- 数据元素的评估结果

数据质量评估报告将按照分成两个部分：一是根据级别0 －2 评估结果，二是在数据装载至ODS 后进行的级别1 －4 评估。数据质量小组将持续跟踪这些问题的状态并提出相应的解决方法。

弥补工作的可选方案

在评估的过程中，一旦在测试中发生数据质量问题，必须采取相应的行动。根据 xx公司开发经验以及目前国内项目实施的现状，一般采取以下所列的方法：

改善方法	方法描述
源系统纠正	在大多数情况下，解决原有数据质量问题最彻底的方式是在源头将其纠正（比如在源数据系统中）。这通常是最为行之有效的解决方案，因为不需要在数据集成项目中增加额外的工作。同时通过这种方式来解决问题，还可以使本项目以外的其它项目在以后整合原有数据时获得很大的方便。但是因为针对源系统缺陷进行的问题纠正工作通常需要投入很多的成本、时间和人员，同时某些重要的源系统（如核心帐务系统）是不允许轻易修改的，某些数据也无法通过修改源系统进行补充，所以某些数据的质量无法通过源系统的修改得到明显改善
数据补充系统	如果数据质量评估显示原有数据元素不能达到信息数据集成的要求，并且无法在源头加以解决，项目的ETL 流程小组将收到警示，以便于其适当改变业务操作来获取数据。另外，从历史角度来看，如果急需的电子数据无法达到数据集成建设的要求，应评估采用手工方式将纸质记录转换成电子数据的可行性，并与数据补充小组紧密合作，以确保相关问题通过建立的数据补充系统加以处理
数据清洗（通过 ETL 流程）	数据清洗使数据集成项目中改善数据质量的最常用的方法，数据清洗将主要解决与源数据变动较为相关的、并可在ETL 流程中加以解决的数据质量问题。但是由于这项工作的技术要求较高，技术人员对源系统和目标数据集成都要非常熟悉，进行这部分工作的难度很大。如果源系统的低质量的数据很多，清洗的工作量同样很大，往往投入很大而收益甚微，从而引起项目的风险

质量保证

为了更好的保证项目的实施质量，ETL 文档与测试是不可少的，应重视文档与测试工作。

ETL 测试

对数据集成项目，ETL 测试主要从如下几个方面进行考虑：测试策略、文档核实、测试类型、测试方法、测试工作、可交付件等。

测试策略：根据项目的实际情况选择测试是贯穿整个开发过程还是在全部开发工作完成以后进行，并确定测试的顺序，此任务需在项目的开始阶段就进行考虑。
文档核实：核实制定测试计划时所需的文档，并标明了各文档的可用性
测试类型

数据准确性测试
业务周期测试
容量测试
集成测试
性能评测
安全性和访问控制测试
故障、转移和恢复测试

测试方法

用例测试

抽样测试

测试工具

测试管理

缺陷跟踪

可交付工件

测试用例

测试记录

缺陷报告

ETL 文档

文档编制必须由全体参与人员共同编制审核，写出业务人员和技术人员都能看懂的技术文档。文档的概念应该是广义的，不仅包括传统意义上的书面文字资料，还应包括系统测试运行中记录的电子日志等。作为ETL 实施中质量实施的保证的一部分，建议至少包括以下文档：

《ETL 方案书》
《ETL 需求分析报告》
《ETL 开发计划》
《数据源分析报告》
《ETL 业务规则书》
《脏数据处理规则书》
《编码规范书》
《ETL 概要设计说明书》
《ETL 详细设计说明书》
ETL 测试计划
测试报告书

1. 集成环境的工具使用及对比

将 WebSphere® DataStage 与 WebSphere Federation Server 相结合，为移动和转换数据提供一种有效而灵活的架构。在传统数据整合市场中，很多供应商要么将他们的产品定位为 Extract-Transform-Load (ETL) 工具，要么定位为 Extract-Load-Transform (ELT) 工具，甚至还将其产品定位为 Transform-Extract-Load (TEL) 工具。很自然地，每个供应商都吹捧他们采用的方法功能多么强大，同时也强调竞争对手采用的方法固有的弱点。

那么，哪种方法是最好的？实际上，所有方法都有其优缺点，大多数公司很可能会发现需要将这些技术组合起来使用。因此，对于 ETL 、ELT 和 TEL 这道字母汤而言，真正的关键在于灵活性，并且能够支持最适合所处理工作的技术。仅仅因为现有的工具不能充分支持一个过程，而将本来适合 ETL 架构的数据流建模到 ELT 架构中，这是导致灾难性后果的一个原因。

WebSphere DataStage 数据整合工具天生就具有很好的灵活性，可以为 ETL 、ELT 和 TEL 拓扑提供固有支持。本部分展示如何通过组合 WebSphere DataStage 和 WebSphere Federation Server ，有效地支持 Transform-Extract-Transform-Load (T-ETL) 数据整合拓扑，以扩展上述字母汤。在 T-ETL 拓扑中，WebSphere DataStage 和 WebSphere Federation Server 相互补充，相对于单独使用 WebSphere DataStage ，这种组合可以显著提高性能，节省 CPU 周期。在这个场景中，WebSphere Federation Server 可以在输入源附近预先进行处理，从而减少提供给提取阶段的数据，并减少 WebSphere DataStage 需要执行的转换。之所以能获得这样的优点，是因为 T-ETL 架构恰好能充分发挥这两种产品的长处；WebSphere Federation Server 的长处在于基于成本的优化器，以及异构环境中集合处理的效率，而 WebSphere DataStage 的优点在于强大的并行转换和数据流引擎。

在更详细地描述 T-ETL 架构之前，本部分接下来的小节将简要地对 WebSphere Federation Server 作一个介绍。随后的用例场景小节详细描述能突出 T-ETL 的优点的 4 种不同用例。接着，本部分总结有望从这种架构中获益的 WebSphere DataStage 作业的一些特征。

WebSphere Federation Server

WebSphere Federation Server 支持业界新兴的 Enterprise Information Integration (EII) 概念。这种技术使应用程序能够访问和集成不同的数据和内容源，无论这些信息位于何处，它们看上去就像是一个资源，但同时又能保持源系统的自治和完整性。

联邦的底层原理是，对于用户而言，他们使用的所有数据看上去是在一个数据源中。通过呈现这个单独的源镜像，联邦技术使数据请求者不必直面与访问不同位置的数据相关的所有复杂性，包括连接、语义、格式和访问方法。中间件使用户或代表用户的应用程序可以透明地访问信息，而不必关心其物理实现。因此，WebSphere Federation Server 非常适合作为常见分析和报告工具、开发环境门户和其它标准 IT 基础设施组件的幕后工具。

通过 WebSphere Federation Server ，可以在一条 SQL 语句中将分布式请求发送到多个数据源。例如，可以在一条 SQL 语句中连接一个 DB2 表、一个 Oracle 表和一个 XML 标记文件中的数据。当应用程序向联邦系统提交一个查询时，联邦服务器识别相关数据源，并生成一个用于获得被请求数据的查询执行计划。查询执行计划通常将原始查询拆分成多个片段，这些片段表示委派到各个数据源的作业，同时还提供联邦服务器要执行的其它处理，包括进一步的过滤、聚合或合并数据。即使某些被请求的信息来自具有很少或不具有查询处理能力的数据源，例如简单的文本部分件，联邦服务器将进一步处理从数据源收到的数据，这种能力使应用程序可以充分利用查询语言的威力。除了管理联邦以外，联邦服务器还是一个功能完整的关系数据库，具有存储和管理本地数据的能力。

总而言之，WebSphere Federation Server 的功能包括：

整合来自本地表和远程数据源的数据，就好像这些数据是本地存储在联邦数据库中。
更新关系数据源中的数据，就好像数据存储在联邦数据库中一样。
将分布式请求发送到数据源进行处理，利用数据源的处理能力和特有的优化能力。
在联邦服务器上处理一部分分布式请求，弥补 SQL 在数据源上的限制。

实现 EII 的联邦方法已经可以与更传统的数据整合方法相媲美。整合的数据存储通常用于提取、转换、装载（ETL ）或复制数据，是当今信息集成的标准选择，已经成为高可用性的能够快速获取、集成访问相关信息的最佳方法。通过创建单个物理拷贝，企业可以满足性能或可用性需求，交付时间点一致的快照，并为语义一致性提供完善的转换。

联邦可以帮助 IT 部门快速地开发原型和改进转换，访问最新的数据，交付有附加价值的、内容丰富的信息，例如不能复制的文档和图像，并提供对不能整合的数据（例如由于兼容性原因）的访问，从而有效地对业务做出响应。在当今快节奏的环境中，通过将数据整合与联邦相结合，企业可以获得更大的灵活性，可以更快地作出反应。

使用 WebSphere DataStage 和 WebSphere Federation Server 的 T-ETL 架构

本部分着重描述组合使用 WebSphere DataStage 和 WebSphere Federation Server 执行数据整合的优点。这种组合使 WebSphere Federation Server 成为 WebSphere DataStage 的数据预处理器，在从一个或多个数据源提取数据之际，或在此之前，实际上就在执行初始的转换。在数据进入 WebSphere DataStage 之前，T-ETL 架构使用联邦来连接、聚合和过滤数据，并由 WebSphere DataStage 使用其并行引擎执行更复杂的转换和目标的维护。图 1 说明了这种架构：

图 1. 使用 WebSphere Federation Server 和 WebSphere DataStage 的 T-ETL 架构
§

该架构充分利用这两种产品各自的优点，形成了一种灵活、高效的数据整合解决方案。WebSphere Federation Server 的优点在于连接能力和 SQL 处理能力，而 WebSphere DataStage 的优点在于并行数据流和强大的转换逻辑。WebSphere Federation Server 的基于成本的优化器还允许 T- ETL 架构动态地对数据量和数据模式的变化作出反应，而不需要修改作业。

T-ETL 不是一个新概念，在提取数据时，很多 ETL 作业可能已经采用了某种形式的转换 —— 例如过滤和聚合数据，或者执行位于同一个源数据库中的两个源表之间的连接。但是，源对象必须在同一个数据源的约束严重地限制了 T-ETL 解决方案的适用范围。WebSphere Federation Server 消除了这一限制，并将初始的转换阶段的范围扩展到 WebSphere Federation Server 所支持的异构数据源。例如，当源数据是一个 Oracle 表、一个 Teradata 表和一个平面文件时，WebSphere Federation Server 允许实现 T-ETL 。除了扩展原有转换阶段的范围外，联邦还可以提高各阶段的效率，因为其核心是在有效过滤和连接数据集方面有 30 多年投资的关系数据库引擎。

突出 T-ETL 优点的用例

以下四个用例场景是为突出使用 WebSphere DataStage 和 WebSphere Federation Server 整合数据的潜在优点而设计的。在每个案例中，首先给出使用 WebSphere DataStage 作业的数据整合场景，进而展示如何将 WebSphere Federation Server 与 WebSphere DataStage 相结合，以减少执行时间和资源消耗。并且还展示如何修改原始的 WebSphere DataStage 作业，以利用 WebSphere Federation Server 的功能。本节的最后总结能从这种优化中受益的 WebSphere DataStage 作业应有的特点。

图 2 显示了用于测试这些用例场景的配置。

图 2. 用于用例场景的配置
§

取决于作业的配置，数据可能源自很多不同的 UNIX 系统。同样，目标也可能在一个或多个 UNIX 系统上。DB2 UDB API WebSphere DataStage stage 用于访问 DB2 源、目标和 WebSphere Federation Server 。所有源和目标数据库都是非分区数据库。IBM Information Server （包括 WebSphere DataStage Enterprise Edition V8.0 和 WebSphere Federation Server V9.0 ）安装在一台双 CPU 的 Windows Server 2003 机器上。在这四个用例场景中，每个作业都被设计为并行作业，以便充分利用 WebSphere DataStage 的并行处理能力。由于 WebSphere DataStage 服务器上有 2 个 CPU ，因此使用的并行度为 2 。

这些用例引用一家虚构的零件交付公司的一些表。取决于具体的场景，这些表在物理上位于一个或多个源系统：

CUSTOMER 表，每个不同的客户键对应一行。每行包含客户的姓名、负债数、属于哪个市场等信息。
ORDERS 表，每个不同的订单键对应一行。每行包含下订单的客户键、订单的总价值、下订单的日期、描述订单优先次序的代码。通常，数据库中的有些客户有数个订单，而有些客户没有订单，或者很久都没有下订单。
LINEITEM 表，一个订单中的每样商品对应一行。每行包含它所属订单的订单键。通常，一个订单会包含数行内容。每行内容引用一个特定的零件键，并包括所定购的数量，零件的发货日期，以及使用的发货方式。
STOCK 表，将零件键与供应商键相链接，跟踪每家供应商手头上的零件数量。

案例 1 ：多个异构源

ProjectedBalance 作业根据 CUSTOMER 表中最近记录的客户负债数，以及最近 30 天客户下的订单的价值（记录在 ORDERS 表中）总和，计算客户的当前负债数。然后，该作业列出客户和计划负债数，按客户负债情况从多到少排序。如今，在很多企业中，客户信息与交易订单信息通常位于不同的数据库中。

考虑下面的 WebSphere DataStage 作业，该作业实现 ProjectedBalance 计算：

图 3. ProjectedBalance WebSphere DataStage 作业
§

图 3 中的 ProjectedBalance 作业从 ORDERS 表中获取上个月的订单，并为每个客户键计算订单总价值。然后，将该信息与 CUSTOMER 表连接，以提取客户姓名、地址和当前负债数。将客户的当前负债与客户在上个月下的订单的总价值相加，算出计划负债。最后，将这些记录（大约有 70,000 条）插入到 ProjectedBalance 表中，或者在将它们输出到平面文件之前对它们进行排序（以确保负债最多的客户排在报告的前面）。

图 3 中的 WebSphere DataStage 作业使用一个典型的 ETL 过程，以一种结构化的方式获取所需的结果。但是，在这个案例（以及其它类似的案例）中，通过将 WebSphere Federation Server 和 WebSphere DataStage 相结合，并对作业作细微的修改，就可以更高效地获得相同的结果。通过使用 WebSphere Federation Server 作为 WebSphere DataStage 的数据预处理器，将 WebSphere DataStage 作业的某些功能交给联邦数据库引擎处理，可以显著地减少作业的执行时间和占用的 CPU 时间。

考虑下面这个等效的 ProjectedBalance DataStage 作业：

图 4. 使用联邦的 ProjectedBalance WebSphere DataStage 作业
§

图 4 中的作业可以与图 3 中原始的 ProjectedBalance 作业获得相同的结果，但是 CUSTOMER 与 ORDERS 之间的连接，以及总订单价值的聚合，已经被放入单个阶段（Join_CustOrds ）中，并且下推到 WebSphere Federation Server 处理，而在那里处理起来更高效。作业中的其它阶段保持不变。

为了将连接下推到 WebSphere Federation Server ，Orders 、AggOrdersByCustomer 、 Customer 和 Join_CustOrds 阶段被重新写成执行等效功能的 SQL 。为便于编写和理解，可以使用 SQL Common Table Expressions (CTE) 来逐个处理各阶段并分解 SQL 。例如，图 5 中显示的 SQL 被使用 CTE 分成 4 个便于管理的块 —— 每个块完全等价于 WebSphere DataStage 阶段中它所替代的块。实际上，Customer 和 Orders CTE 使用的 SQL 与原始作业的 CUSTOMER 和 ORDERS stage 中使用的 SQL 相同。以这种方式使用 CTE 可以大大简化用 SQL 表达 WebSphere DataStage stage 的过程，因为它允许开发人员分别考虑每个阶段，逐个地进行转换。

图 5. ProjectedBalance 作业被下推到 WebSphere Federation Server 的 SQL
§

当图 4 中的 ProjectedBalance 作业执行时，Join_CustOrds 阶段连接到联邦数据库，该阶段中的 SQL 被传递到 WebSphere Federation Server 。WebSphere Federation Server 使用它的基于成本的优化器确定连接数据的最高效的方法。大部分节省下来的执行时间和 CPU 时间要归功于最佳执行计划的选择，以及功能完整的 DB2 关系数据库引擎对数据集的有效的处理。联邦数据库处理完 Join_CustOrds 阶段中的 SQL 之后，WebSphere DataStage 使用获得的数据，作业的处理继续进行。第二个显著的性能优点是，WebSphere Federation Server 执行的初始连接 “ 减少” 了；也就是说，它输出的数据远远少于从源数据读取的数据。这意味着当与 WebSphere Federation Server 结合使用时，WebSphere DataStage 读取的数据（70,663 行）要少于在原先的实现中所读取的数据（240 万 + 77,636 行）。

昵称
由于使用 WebSphere Federation Server 连接 Oracle 和 DB2 数据，图 5 中的 SIMON.CUSTOMER 和 SIMON.ORDERS 实际上是引用联邦数据库中定义的昵称。而这些昵称又指向数据源中的表。

在数据到达 WebSphere DataStage 之前，使用 WebSphere Federation Server 对数据执行某种预处理，在这样做的过程中，就已经有效地采用了 T- ETL 方法；这说明了 WebSphere DataStage 和 WebSphere Federation Server 这对组合的灵活性。

图 3 中显示的原始 ProjectedBalance 作业的执行时间为 204 秒。而图 4 中显示的 T-ETL 作业的执行时间只有 127 秒 —— 总体执行时间缩短了 38% 之多。WebSphere DataStage 和 WebSphere Federation Server 机器使用的 CPU 资源同样有所减少，并且数据源上的 CPU 消耗并没有显著增加。因此，在这个案例中，当将 WebSphere DataStage 与 WebSphere Federation Server 结合使用时，与单独使用 WebSphere DataStage 相比，作业的执行时间和 CPU 消耗减少了 38% 。

案例 2 ：一个典型的 ELT 场景

OrderPriority 作业生成由 'Building' 市场的客户所下的未完成订单的列表。该列表根据订单中未完成内容的未付款收益和下订单的日期排序。图 6 显示了 OrderPriority 作业的 WebSphere DataStage 实现。

图 6. WebSphere DataStage OrderPriority 作业
§

OrderPriority 作业首先提取 'Building' 市场客户的客户键，然后从 ORDERS 表中提取关于他们所下的订单的信息。然后，从 LINEITEM 表中提取关于订单中尚未发货的各行项目的信息。接着通过 LineitemRevenue stage 计算每个未发货的行项目的收益，将它们相加求和，确定每个订单的未付款收益。然后对订单进行排序，首先按未付款收益排序，然后按订单日期排序。最后，将这些数据（大约 45,000 条记录）插入到 ORDERPRIORITY 表中。

图 6 中显示的 OrderPriority 作业也可以使用 ELT 方法取得所需的结果。这种机制首先从源系统提取 DB2 LINEITEM 和 ORDERS 数据以及 Oracle CUSTOMER 数据，然后将它们装载到保存目标表的 SQL Server 数据库中。在将数据装载到 SQL Server 数据库之后，可以使用 SQL 执行转换和装载结果表。但是，在使用 ELT 方法时，该作业会将大大超过所需的数据装载到 SQL Server 数据库中 —— 而它实际上只需装载 WebSphere DataStage 作业从源提取的等量的数据。将数据装载到目标数据库之后，还会失去源数据库上可能提供的索引或其它优化。因此，这样的查询很可能会消耗超过实际需要的资源。

图 7 显示了使用 WebSphere Federation Server 实现 T-ETL 方法的 OrderPriority 作业：

图 7. 使用 WebSphere DataStage 和 WebSphere Federation Server 的 OrderPriority 作业
§

原先的 OrderPriority 作业中 CUSTOMER 、ORDERS 和 LINEITEM 之间的三方连接现在被下推到 WebSphere Federation Server 中执行。同样，这里使用 CTE 将原始作业的 stage 转换成 SQL 。图 8 中显示了 SQL ：

图 8. OrderPriority 作业被下推到 WebSphere Federation Server 的 SQL
§

用于 Customer 、Orders 和 Lineitem CTE 的 SQL 与原始 OrderPriority 作业中的 SQL 相同。作业中的所有其它 stage 保持不变。

如果没有 WebSphere Federation Server ，就无法在一条 SQL 语句中处理 CUSTOMER 、ORDERS 和 LINEITEM 之间的三方连接，因为数据在两个异构的源中。大多数其它 ETL 产品都只能将连接下推到单个同构的数据源（或目标），正是由于这个原因，这些产品采用 ELT 策略 —— 在执行 SQL 处理之前，从多个源提取数据，然后将数据装载到一个目标。WebSphere DataStage 与 WebSphere Federation Server 的灵活组合使 ETL 开发人员可以选择最适当的方式来达到他们的数据整合目的 —— 而不必限于一种特定的 ETL 方法。

WebSphere Federation Server 用于连接 T-ETL OrderPriority 作业中的 Customer 、Orders 和 Lineitem 表的连接顺序不同于 WebSphere DataStage 开发人员在原始作业中使用的顺序。WebSphere Federation Server 决定将 Orders 首先与 Lineitem 连接，然后将该连接下推到远程 DB2 服务器，在那里它可以更高效地执行。在将 Orders 和 Lineitem 之间的连接下推到 DB2 服务器之后，从数据源提取的数据量就减少了。原始 OrderPriority 作业与 T-ETL 版本的 OrderPriority 作业在连接策略上的变化是 T-ETL 版本的作业更为有效的原因之一。

§ WebSphere Federation Server 基于成本的优化器
当该作业执行时， WebSphere Federation Server 根据已有的关于表的统计信息决定如何访问数据。通过将选择最佳访问计划（以及连接策略）的责任交给 WebSphere Federated Server ， WebSphere DataStage 开发人员在连接两个或多个数据集时，就不必自己确定最佳策略。

原始 OrderPriority WebSphere DataStage 作业执行时间为 70 分 45 秒（4,246 秒）。而使用 WebSphere Federation Server 作为数据预处理器的 T-ETL 版本的作业则仅执行了 12 分 11 秒（731 秒），执行时间节省了大约 83% 。

在提取数据并将数据发送到 WebSphere DataStage 时，让 WebSphere Federation Server 执行连接和转换通常可以使源数据库上提供的索引和其它优化得到充分的利用，而在原始方法中这是不可能的。 WebSphere Federation Server 使用它的基于成本的优化器决定执行多源查询的最有效的方式。这意味着下推相同数据源上的表之间的连接，在适用的情况下自动使用探测类型查找，在查询执行时，根据已有的索引和统计信息使用最有效的连接技术。如果 WebSphere Federation Server 执行的这些早期的连接和转换也减少了（即输出的数据少于读取的数据），那么就可以减少提供给 WebSphere DataStage 作进一步转换的数据。因此，当采用组合实现时，WebSphere DataStage 需要处理的数据大大减少了，总体性能随之上升。例如，在 OrderPriority 作业中，WebSphere DataStage 从 OrderDetails stage 读取 119,642 行，这正是 WebSphere Federation Server 执行的连接输出。而在不使用 WebSphere Federation Server 的原始 OrderPriority 实现中，WebSphere DataStage 需要从 DB2 和 Oracle 源中读取超过 5200 万行数据。

案例 3 ：源和目标是相同的数据库

ShipPriority 作业分析以某些发货方式发货的订单的优先顺序。该作业计算在最近 6 个月的时间里，一般或高优先级订单中通过邮寄或海运发货的行项目的数量，并将这些数量按订单优先级排序。该作业演示了源和目标是相同数据库、且作业中执行的转换非常简单这样一个很典型的场景。图 9 显示了用于 ShipPriority 作业的 WebSphere DataStage 作业。

图 9. ShipPriority WebSphere DataStage 作业
§

一开始，从 LINEITEM 表中提取规定时期内通过邮寄或海运发货的行项目所对应的订单号。然后在 ORDERS 表中查找这些订单键，确定行项目所属订单的优先级。该作业使用很小的 Lookup stage （GetOrderInfo ）来探测 ORDERS 。提取到与每个符合条件的行项目相关联的订单的优先级之后，计算行项目的数量，并按订单优先级和行项目的发货方式列出这些数字。最后，将这些数据插入到 ORDERS 和 LINEITEM 源表所在的同一个 Oracle 数据库中的 SHIP_PRIORITY 表中。该作业的输出是紧急或一般订单中通过邮寄或海运发货的行项目的数量，如下所示：

L_SHIPMODE URGENT_COUNT NORMAL_COUNT

---------- ------------ ------------

MAIL 2079 3159

SHIP 2150 3171

这种类型的作业有一个特点，即源和目标在相同的数据库中，且执行的转换并不复杂，这种作业非常适合重新将作业编写成一条可以完全在数据库引擎中执行的 SQL 语句。

图 10 中显示的 ShipPriority DataStage 作业演示了那样的重写，原始作业的所有逻辑都被整合到一个 DB2 stage （ShippingPriority ）中，并以 SQL 表达。ShippingPriority stage 实际上连接到 WebSphere Federation Server ，后者使用昵称来与 Oracle 会话。

图 10. 使用 WebSphere DataStage 和 WebSphere Federation Server 的 ShipPriority 作业
§

§ RowGenerator stage
之所以要包括图 10 中的 DummyRowGenerator stage ，是因为一个 WebSphere DataStage 作业必须包含多于一个 stage 才能执行。这个例子中使用 RowGenerator stage 生成一个值（这个值后面将被丢弃）。

在这个例子中，WebSphere Federation Server 执行作业所需的所有处理。由于源和目标在相同的数据库中，所以这个例子并不是一定需要使用联邦。可以将 SQL 直接传递到 Oracle 数据库。但是，以这种方式继续使用 WebSphere Federation Server 可以使 WebSphere DataStage 开发人员获得一致性，并且容易修改源和目标，而不必改变 WebSphere DataStage 作业。在这个例子中，与直接和 Oracle 交互相比，WebSphere Federation Server 的开销更小，因为它只需提取 ShippingPriority stage 中的 INSERT..SELECT 语句，然后直接将其传递给 Oracle 。

图 11 显示了 ShippingPriority stage 中使用的 SQL ：

图 11. ShipPriority 作业被下推到 WebSphere Federation Server 的 SQL
§

同样，SQL 被使用 CTE 拆分成易于理解的几个小块；每个小块代表原始的 WebSphere DataStage 作业的一个特定的 stage 。以上显示的 LineItem 和 OrdersLookup CTE 使用原始 WebSphere DataStage 所使用的相同的 SQL 从源表提取信息。

当新版本的 ShipPriority 作业执行时，WebSphere DataStage 连接到联邦数据库，并发出 INSERT..SELECT 语句。如图 11 所示。联邦数据库提取 SQL 语句，将它转换成有效的 Oracle 语法，并传递到 Oracle 数据库上进行处理。Oracle 数据库执行查询，并在返回前将行插入到 SHIP_PRIORITY 表中。

在将作业重写成 SQL 的过程中，就有效地将作业从典型的 ETL 作业转换成所有处理都在数据库引擎中进行的作业。虽然这是达到目标的一种有效的方式，但是这种方法只能用于源和目标在相同数据库中，且转换可以用 SQL 表达的那些作业。

在测试系统上，原始的 ShipPriority 作业执行了 68 秒。而重写的使用 WebSphere DataStage 和 WebSphere Federation Server 的作业则仅仅执行了 6 秒，总执行时间缩短了超过 91% 。此外，对于重写后的作业，承载 WebSphere DataStage 和 WebSphere Federation Server 的机器上的 CPU 的消耗也大大降低，Oracle 数据源上的总体 CPU 消耗减少了大约 47% 。Oracle 服务器上 CPU 消耗的减少是因为新的作业能够更好地利用 Oracle 数据库中的优化来执行查询。在其它情况中，将处理下推到数据库可能会导致数据库服务器上消耗更多的资源；如果资源有限，或者共享这台机器的其它工作负载的响应时间很关键，那么这样做并不理想。

§ 将 SQL 直接下推到 Oracle
使用 WebSphere DataStage 将 INSERT..SELECT 直接下推到 Oracle 的一个类似的 ShipPriority 作业的执行时间也是 6 秒。这说明在这个案例中， WebSphere Federation Server 影响很小，其效果与直接在源数据库执行 INSERT..SELECT 相同。

当整个作业都可以下推并在一个数据库中执行的时候，继续使用 WebSphere DataStage 将使 ETL 开发人员可以使用相同工具解决所有数据整合需求。此外，WebSphere DataStage 作业的元数据存储在 IBM Information Server 元数据储存库中，因此可以共享该信息，还可以利用 IBM Information Server 套件中的其它功能。由于发现、清洁、整合和数据访问过程都使用相同版本的元数据，因此可以立即估计对任何信息的更改，或任何处理对企业信息集成过程中任何其它组件的影响。

就像本部分中描述的作业一样，作业几乎肯定依赖于其它作业，而不大可能独立地执行。WebSphere DataStage 的作业定序器是一种图形化工具，程序员可以通过它来指定要运行的一系列作业，以及带循环和流控制的异常处理。根据序列中的作业成功还是失败，序列可以包含表示不同动作的控制信息。通过将 ShipPriority 作业设计在 WebSphere DataStage 中，就可以利用作业定序器 —— 例如，在成功完成一个一年两次的订单整合作业之后，就触发 ShipPriority 作业。

在这些案例中，通过继续使用 WebSphere Federation Server ，ETL 开发人员可以获得单个的、一致的数据镜像 —— 无论数据位于何处（关系数据源还是非关系数据源），以及可用于访问任何数据的单个的 SQL 方言。因此，开发人员可以重用为将处理下推到 Oracle 数据库中而编写的相同 SQL ，在 DB2 on Z/OS 数据库（例如）执行相同的过程。WebSphere Federation Server 使用昵称引用数据源对象，这也增加了 WebSphere DataStage 作业的灵活性。

考虑一家从 Oracle 迁移到 Microsoft SQL Server 的企业，其 IT 部门有一组 WebSphere DataStage 作业，这些作业将处理下推到一个 Oracle 数据库。为了迁移这些作业，ETL 开发人员必须逐一修改每个作业，用 SQL Server stage 替换作业中的 Oracle stage ，然后将 Oracle SQL 转换成 Microsoft SQL Server 方言。然后，必须对新的作业进行测试，确保与原始作业一致。如果已经使用了 WebSphere Federation Server 部署原始作业，那么迁移时只需撤销 Oracle 昵称，并创建相应的 SQL Server 昵称 —— WebSphere DataStage 作业本身不必更改。由于作业本身不必更改，实际上减少了测试工作。

案例 4 ：数据集市填充场景

StockCheck 作业报告在下一季度公司的供应商很可能没有足够库存的零件。这种预测是根据之前三个月零件销售增长 5% 的假设以及关于每个供应商当前库存的信息作出的。对于存在上述有危险的零件的每个地区，该作业生成一个列表，其中包括那个地区提供这些零件的供应商的名称和预计短缺的数量。

图 12 显示了实现 StockCheck 的 WebSphere DataStage 作业。

图 12. StockCheck WebSphere DataStage 作业
§

取决于供应商所在的地区，StockCheck 作业的输出被传递到 5 个不同的目标，或者，如果供应商所在地区不存在危险零件，则生成一个否认文件。每个目标代表一个数据集市，每个数据集市在物理上位于一个特定区域中。StockCheck 是一个相当典型的数据集市填充作业，它使用 ETL 逻辑将数据从一个数据集成转移和转换到更小的一些数据集市。

该作业使用 LINEITEM (Oracle) 表计算上一季度销售的每种零件的数量。接着使用 STOCK (DB2) 表提取零件的供应商键和当前库存水平。然后，该作业计算出每种部件 5% 的销售增长，并将这个值与供应商手头上的当前库存进行比较。接下来，对于供应商很可能没有足够库存的那些零件，提取其供应商信息，例如姓名和地址。供应商信息是由一个外部实用程序通过 GetSuppliers stage 获得的。最后一步是按地区划分供应商，并将一条记录插入到适当的数据集市中 —— 以报告那个地区的库存情况，并采取适当的动作。

StockCheck 作业的复杂性意味着将它转换成 ELT 模式是件非常艰巨的作业。不管是使用外部应用程序获取供应商名称和地址的 GetSuppliers stage ，还是根据供应商所在地区将记录分发到不同目标数据库的 SelectRegion Switch stage ，都难于用 SQL 表达。

但是，将 StockCheck 转换成 T-ETL 模式则相当简单，只需转换作业中的一小部分，即 LINEITEM 与 STOCK 之间的连接。如图 13 所示。

图 13. 使用 WebSphere DataStage 和 WebSphere Federation Server 的 StockCheck 作业
§

在上述作业中，LINEITEM 与 STOCK 之间的两方连接被整合到 PartsSoldLastPeriod stage 中，并且被使用 CTE 转换成 SQL ，每个 CTE 表示原始 StockCheck 作业中的一个 stage 。用于访问 LINEITEM 和 STOCK 表的 CTE 与原始 stage 中的 SQL 是完全匹配的。图 14 显示了完整的 SQL ：

图 14. StockCheck 作业被下推到 WebSphere Federation Server 的 SQL
§

在这个 T-ETL 例子中，需要由 WebSphere Federation Server 来执行初始的转换，因为 LINEITEM 和 STOCK 表在不同的数据源上。将原始 WebSphere DataStage 作业中包含的所有功能都下推到目标或联邦层效果不佳，因为大部分处理被最适当地表达为 WebSphere DataStage 中的并行数据流（并得到最有效的处理）。执行那样复杂的一组转换的 SQL 十分笨拙，难于维护。这种解决方案的优点在于 WebSphere DataStage 的灵活性和并行处理引擎，以及联邦层对来自同构或异构源的数据进行有效的预处理能力 —— 提供一个简单的 SQL 接口。

原始 StockCheck WebSphere DataStage 作业执行时间为 682 秒，而 T-ETL 版本的作业的执行时间为 124 秒。消耗的时间大约缩短了 82% 。

识别可从 T-ETL 中获益的作业

前面描述的 4 个用例都是能从采用 T-ETL 方法移动和转换数据中受益的典型数据整合场景。凡是具有能在数据流早期减少输入数据的作业（例如连接、合并、过滤和聚合）的数据整合场景，几乎都能从 T-ETL 处理中受益。尽可能使用 WebSphere Federation Server 来执行减少工作集的操作通常更为有效，因为这种处理是在关系数据库引擎中执行的，而且可以利用源数据库上的优化（例如索引和物化视图）。同样不容忽视的是，通过早期减少输入数据，可以减少 WebSphere DataStage 读取的数据量。因此，组合使用 WebSphere Federation Server 和 WebSphere DataStage 的作业的执行时间和资源消耗很可能都少于单独使用 WebSphere DataStage 的作业。

§ 读取数据的约束
本部分描述的 4 个作业都将大量时间花在从数据源读取数据上。

最能从 T-ETL 方法中受益的整合场景是那些从源系统获取数据所花的时间在整个作业的执行时间中占较大比例的场景。也就是说，作业受到读取数据到 WebSphere DataStage 中的约束。可以使用 WebSphere DataStage V8 的 Job Performance Analysis 特性来识别符合上述条件的候选作业。图 15 显示了 Job Performance Analysis 针对 ProjectedBalance 作业的示例输出，并清楚地表明，作业的大部分时间花在读 CUSTOMER 表上。

图 15. Job Performance Analysis 工具的示例输出
§

在数据流中，输入数据集显著减小的地方通常代表着联邦与 WebSphere DataStage 之间最有益的临界点。可以根据对数据的认识识别这种临界点，或者，如果作业已经存在，则可以使用 WebSphere DataStage 的性能统计信息来识别。图 16 显示了 StockCheck 例子中前几个阶段的性能统计信息：

图 16. StockCheck 作业的临界点
§

§ “ 减” 操作符
本部分中描述的 4 个作业都包含减少工作数据集且能用 SQL 表达的阶段（早期在作业中定义）。

对于这个特定的作业，读统计信息的行数清楚地表明临界点就在 JoinOnPart 和 Calc5PctIncrease 两阶段之间。这是因为，在这个地方，来自两个输入源的工作数据集从 11.2M 和 900K 记录剧减至 1M 记录。还可以将后续阶段包括在下推到 WebSphere Federation Server 的 SQL 中（在这个例子中，对于 Calc5PctIncrease 和 GetLowStock stage 都可以这样做）。如果将数据集缩减最多之处的临界点之前的其它阶段也包括进去，可能会进一步提高性能。但是，这里性能提高得不大显著，而且很大程度上要取决于可用的资源和 WebSphere DataStage 引擎中定义的并行度。

将数据流的这一部分放在 WebSphere Federation Server 中执行有两个好处：

WebSphere DataStage 一开始要获取的数据集缩减了。由于需要处理的输入数据更少，WebSphere DataStage 执行的随后的处理得以加快。
由于 WebSphere Federation Server 可以利用很多优化技术，开始的 stage 中的工作在 WebSphere Federation Server 中执行通常比在 WebSphere DataStage 中执行得更快，从而导致整个作业的执行时间和资源消耗为之减少。

在每个案例中，将 ETL 作业转换成 T-ETL 作业的工作是通过将 WebSphere DataStage 作业的一部分重写成 SQL 来完成的。因此，被下推到 WebSphere Federation Server 的阶段必须能够用 SQL 语法表达。SQL 被包括在一个 DB2 stage 中，并传递给 WebSphere Federation Server 进行处理。使用 CTE 将原始作业的各个阶段重写成 SQL ，这提供了一种便于理解的方法，这种方法只要求基本的 SQL 编程技能。

T-ETL 作业中的 SQL 引用联邦数据库中预定义的昵称，而不是实际的源表。当然，昵称又引用源表。昵称的创建非常简单，只需一步，不同的作业可以使用相同的昵称来引用同一个远程对象。

WebSphere Federation Server 使用它的基于成本的优化器，确定检索和处理数据的最佳路径。这样一来，WebSphere DataStage 开发人员在组合两个或多个数据集时，就不必自行确定最佳连接策略。如果选择了错误的连接技术或链接顺序，其对性能的影响是数量级的。当使用 WebSphere DataStage 连接和合并数据时，就要由开发人员根据对数据的认识来确定最佳策略。

但是，数据是动态的，一种策略可能在作业开发时适用，在作业部署时又变得无效。由于联邦优化器是在运行时根据表示输入表的昵称的当前统计信息来确定计划的，因此可以在作业执行时针对数据量和分布的变化作出反应，并选择最佳计划。WebSphere Federated Server 优化器选择好最佳访问策略之后，就按该策略执行。如果可能的话，一些操作会被下推到数据源远程地执行，以利用那里的一些优化功能（例如索引）。不能下推的操作则在联邦数据库中执行，由于联邦数据库是功能完整的关系数据库，因此可以非常有效地处理这些基于集合的操作。

自然，这个过程也适用于从单个数据源提取数据的作业。通过将某些 stage 下推到数据源，减少输入到 WebSphere DataStage 的数据量，可以提高总体效率。

作为数据整合工具，WebSphere DataStage 的优点在于它的灵活性 —— 它可以支持很多不同的整合场景和 ETL 风格，包括 ETL 、ELT 和 TEL （在单个数据源上）。将 WebSphere DataStage 与 WebSphere Federation Server 相结合，为整合场景开辟了一个全新的整合领域，即 T- ETL ，它可以用于同构或异构数据源上的数据整合。

在 T-ETL 场景中，将 WebSphere DataStage 与 WebSphere Federation Server 组合使用的优点是，这种解决方案可以充分发挥这两种产品的长处： WebSphere Federation Server 的长处在于基于集合的处理方面的效率和异构环境中基于成本的优化，而 WebSphere DataStage 的长处在于灵活而强大的并行转换引擎和数据流建模。使用 WebSphere Federation Server 以基于集合的方式对数据进行预处理，减少数据，然后将数据传送到 WebSphere DataStage 上，在高度可伸缩的、并行的引擎中作进一步的处理，两种产品相辅相成，大大提高了整个作业的效率。

本部分找出最能从 T-ETL 策略中受益的数据整合场景，并通过实例进行验证。本部分找出的上述数据整合场景的四大特征为：

当单独使用 WebSphere DataStage 来实现时，从数据源取数据集所花费的时间在作业的总体执行时间中占较大比例。
在 WebSphere DataStage 作业的早期阶段中，输入数据要经过一些操作的处理（过滤、聚合或连接），这些操作会缩小数据的规模。换句话说，某个早期阶段的输出数据流应该少于输入数据流。
在早期要读取来自一个或多个输入数据源的数据的 “ 减” 操作（过滤、聚合或连接）当中，至少有一个操作可以表达为 WebSphere Federation Server 昵称上的一个 SQL 查询。
源数据库是非分区的。如果一个源系统是非分区的，那么 WebSphere DataStage 首先会连续地读数据，然后将数据分区，以便利用并行。通过将作业中把数据读到 WebSphere DataStage 中的那部分替换为能减少输入数据集的基于集合的处理机制，可以提高作业的效率。

通过使用联邦优化器，T-ETL 解决方案还使 WebSphere DataStage 开发人员不必将注意力放在为连接和合并各个阶段选择最佳连接方法和正确的链接顺序上 —— 这种决定对作业运行时的影响是数量级的。联邦优化器还使 T-ETL 解决方案更具有可适应性，因为当作业中数据特征发生变化时，最佳连接策略和链接顺序也可能随之变化。而优化器会考虑这些变化，并且在作业执行时选择最佳访问计划。

本部分演示了这样一点：通过将作业中的工作明确地划分到 WebSphere DataStage 和 WebSphere Federation Server 上，可以节省相当多的执行时间。表 1 总结了以上描述的 4 个用例场景。

表 1. 对 4 个用例场景的总结

作业名称	最初执行时间（秒）	使用 T-ETL 时的执行时间（秒）	提高的百分比
ProjectedBalance	204	127	38%
ShipPriority	68	6	91%
OrderPriority	4246	731	83%
StockCheck	682	124	82%

在这些用例中，执行时间至少减少了 38% ，这已经是一个很大的提高了，对于一个企业而言，这可以节省相当可观的成本。当然，和所有性能研究相同，当采用 WebSphere Federation Server 与 WebSphere DataStage 相结合的 T-ETL 方法时，所节省的执行时间不是固定不变的。但是，如果使用以上定义的 4 个特征来识别符合条件的作业，那么可以更有把握地说，采用 T-ETL 方法的作业可以减少较多的执行时间。

1. SOA 开发规划

SOA 是一种分布式的软件模型。SOA 的主要组件包括服务、动态发现和消息。

服务是能够通过网络访问的可调用例程。服务公开了一个接口契约，它定义了服务的行为以及接受和返回的消息。术语服务常与术语提供者互换使用，后者专门用于表示提供服务的实体。
接口通常在公共注册中心或者目录中发布，并在那里按照所提供的不同服务进行分类，就像电话簿黄页中列出的企业和电话号码一样。客户（服务消费者）能够根据不同的分类特征通过动态查询服务来查找特定的服务。这个过程被称为服务的动态发现。
服务消费者或者客户通过消息来消费服务。因为接口契约是独立于平台和语言的，消息通常用符合 XML 模式的 XML 文档来构造。

下面的图 1 § 说明了 SOA 中的不同角色。

§
Web 服务作为 SOA

Web 服务建立在开放标准和独立于平台的协议的基础之上。Web 服务通过 HTTP 使用 SOAP （一种基于 XML 的协议），以便在服务提供者和消费者之间进行通信。服务通过 WSDL （Web Service Definition Language ）定义的接口来公开，WSDL 的语义用 XML 定义。UDDI 是一种语言无关的协议，用于和注册中心进行交互以及查找服务。所有这些特性都使得 Web 服务成为开发 SOA 应用程序的优秀选择。

使用 J2EE 1.5 平台开发 SOA/Web 服务框架

1.5 版的 J2EE 平台通过新的 JAX-RPC 1.1 API 提供了完整的 Web 服务支持，这种 API 支持基于 servlet 和企业 bean 的服务端点。JAX-RPC 1.1 基于 WSDL 和 SOAP 协议提供了与 Web 服务的互操作性。J2EE 1.5 平台也支持 Web Services for J2EE 规范(JSR 921) ，后者定义了 Web 服务的部署需求并利用了 JAX-RPC 编程模型。除了几种 Web 服务 API 之外，J2EE 1.5 平台还声称支持 WS-I Basic Profile 1.0 。WS-I Basic Profile 标准让 Web 服务克服了不同编程语言、操作系统和供应商平台之间的障碍，从而使多种应用程序之间能够交互这意味着除了平台独立性和完整的 Web 服务支持之外，J2EE 1.5 还提供了跨平台的 Web 服务互操作性。

在 J2EE 1.5 下，Web 服务客户可以通过两种方式访问 J2EE 应用程序。客户可以访问用 JAX-RPC API 创建的 Web 服务；在幕后 JAX-RPC 使用 servlet 来实现 Web 服务。Web 服务客户也可以通过 bean 的服务端点接口访问无状态会话 bean 。Web 服务客户不能访问其他类型的企业 beans 。第二种选择——公开无状态 EJB 组件作为 Web 服务——有很多优势：

利用现有的业务逻辑和流程：在许多企业中，现有的业务逻辑可能已经使用 EJB 组件编写，通过 Web 服务公开它可能是实现从外界访问这些服务的最佳选择。 EJB 端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。
并发支持：作为无状态会话 bean 实现的 EJB 服务端点不必担心多线程访问，因为 EJB 容器必须串行化对无状态会话 bean 任何特定实例的请求。
对服务的安全访问：企业 beans 允许在部署描述符中声明不同方法级别的安全特性。方法级别角色被映射到实际的主体域（ principal domain ）。使用 EJB 组件作为 Web 服务端点，把这种方法级别的安全性也带给了 Web 服务客户。
事务问题： EJB 服务端点在部署描述符规定的事务上下文中运行。容器处理事务，因此 bean 开发人员不需要编写事务处理代码。
可伸缩性：几乎所有 EJB 容器都提供了对无状态会话 bean 群集的支持。因此当负载增加时，可以向群集中增加机器， Web 服务请求可以定向到这些不同的服务器。通过把 Web 服务模型化为 EJB 端点，可以使服务具有可伸缩性，并增强了可靠性。
池与资源管理： EJB 容器提供了无状态会话 bean 池。这改进了资源利用和内存管理。通过把 Web 服务模型化为 EJB 端点，这种特性很容易扩展，使 Web 服务能够有效地响应多个客户请求。

记住所有这些优点，下一节将展示如何在体系结构中将无状态 EJB 组件公开为 Web 服务。

设计 SOA/Web 服务框架

比方说有一家公司，它的各种系统（比如支付、财务和发票系统）需要彼此交互。此外，其中一些应用程序还需要对外界公开，以便不同的业务合作伙伴与它们进行交互。您还需要为各种应用程序（如输入发票的各种数据输入操作或者查看支付的状态）设计基于 Web 的解决方案。最佳选择就是设计一种松散耦合的基于服务的系统。这些服务应该得到开放标准的支持，这样任何业务合作伙伴都可以调用它们。

这些方面的考虑将使您转向 Web 服务 /SOA 框架，通过无状态 EJB 组件把各种服务和业务流程公开为 Web 服务。下面的图 2 § 说明了企业内部应用的 SOA 框架。

§
下面列出了 SOA 框架中进行交互的各种组件。这是一种典型的 MVC 2 框架。

客户（Client ）：用户通过 Web 浏览器与不同的应用程序交互，浏览器作为应用程序的客户。比如，出纳部门的用户可能要输入帐单细节并把信息提交给应用程序。可以使用 JSP 页面和 XHTML 来呈现客户页面。
应用程序控制器（Application controller ）：应用程序控制器是您的主控制器 servlet 。它负责初始化、委派请求和响应请求处理程序。
请求处理程序（Request processor ）：这是一个 Java 类，通过调用相应的请求执行程序完成要求的处理，对请求进行预处理。这种调用采用命令模式。
请求执行程序（Request handlers ）：请求执行程序完成具体请求的活动，比如与服务交互，向不同的企业信息系统（enterprise information systems ，EIS ）增加或检索信息。请求执行程序依靠业务定位程序发现相应的服务，然后通过这些服务访问需要的 EIS 信息。
业务定位程序（Business locators ）：这些程序负责隐藏查找服务的复杂性，并提供缓存逻辑。业务定位程序可以采用多种形式，比如 Web 服务定位程序、EJB 组件定位程序或者 JMS 定位程序。
会话 Facades （Session Facades ）：通过聚合来自多个系统或服务的方法，简化复杂对象的视图。会话 facades 是 EJB Web 服务方法的包装器。
EJB Web 服务（EJB Web services ）：根据 EJB 1.4 规范，Web 服务端点可以模型化为无状态的会话 bean 。如前所述，这种技术有许多优势。
数据访问接口（Data access interfaces ）：使用不同的技术（比如 EJB-CMP 、JDO 、DAO ）和不同的持久性技术访问 EIS ，所使用的访问技术取决于接口需求以及获取、插入或更新的数据量。这一层负责与 EIS 进行交互，并以相应的 EJB Web 服务方法所期望的格式把数据返回给这些方法。
MQSeries/JCA/CCF ：现有的基于主机的服务可以公开为 Web 服务，从而向外界展示它们。Web 服务客户使用基于 HTTP 的 SOAP 协议与 EJB Web 服务交互。EJB 方法通过 JMS 协议向 MQSeries 队列发送请求。（使用 MQSeries 是与基于主机的应用程序交互的一种方式。）主机端的 MQSeries 服务器触发相应的基于 COBOL 的程序，后者为与后台系统（比如 IMS DC ）进行交互提供必要的逻辑。然后这些程序把响应返回到队列中，应用程序逻辑检索这些响应并返回给 EJB 方法。SOAP 消息可以通过不同协议进行传输，比如 HTTP 、HTTPS 和 JMS ，但为了统一起见，本例子只使用 HTTP 和 HTTPS 。

这些组件提供了企业内部应用程序面向服务体系结构的基础。接下来讨论把服务向外界公开。

向外界公开服务

如果准备向外部用户公开服务，您需要某种安全约束来保证只有授权的用户才能访问服务。一种方法是提供另外的 Web 服务层，过滤掉禁用的 Web 服务请求，并提供登录和安全约束。这种过滤方式还应提供一种工具，向每一客户只公开授权给该用户的服务子集。

图 3 § 说明了企业外部应用的面向服务体系结构。它向外界公开了细粒度的服务。

§
以下是这种体系结构的基本功能单元：

外部客户（External clients ）：可以包括基于 Web 的客户、移动客户或者使用 .NET 环境、Perl 或其他编程语言编写的客户。所有这些客户都为不同的服务发送请求。只要遵循 WS-I Profiles 就不会出现互操作性的问题。
企业防火墙（Corporate firewall ）：根据其安全策略，这家公司在 intranet 和 Internet 之间架起了防火墙，对收到的分组信息进行限制。
Web 服务网关（Web Services Gateway ）：本例中，我选择使用 WebSphere Application Server 5.0 中的 Web Services Gateway 产品作为公开外部服务的网关。（关于该产品的更多信息，请参阅参考资料 § 。） Web Services Gateway 是一种中间件产品，在调用 Web 服务时提供了 Internet 和 intranet 之间的中间框架。使用 Web Services Gateway ，开发人员和 IT 经理可以安全地对外公开 Web 服务，防火墙之外的客户也能调用这些服务。它包括一个服务管理模型（部署、取消部署，等等）和过滤器（对流经网关的请求和响应起作用的自定义代码）。它只处理收到的 SOAP/HTTP 请求，通过网关的请求可能发送给 Java 类、EJB 组件或者 SOAP 服务器（该服务器甚至还可能是另一个网关）。它可以为单个的 Web 服务方法提供保护（基本授权），也可以保护整个网关。使用 Web Services Gateway ，来自客户的请求可以被转换成服务所要求的任何消息协议。例如，客户的请求可能是 HTTP 上的 SOAP ，但在内部可以使用 JMS 协议上的 SOAP ，Web Service Gateway 能够提供从一个协议到另一个协议的转换。
EJB 服务（EJB services ）：EJB 服务没有任何变化。过程的其他部分和图 2 § 所示体系结构提供的基于 intranet 的服务类似

§ 使用 EJB 组件实现粗粒度的服务

迄今所见到的过程都是向客户公开细粒度的 Web 服务。只要每个业务服务作为单个业务过程执行，这种设置就能很好地工作。但是假设客户要进行在线资金转移，这种情况下提供单一的、粗粒度的接口显然更加合理，让用户提供所有必要的信息，包括传输的金额、发出和接收的银行信息，等等。此外，这类情形中验证必须在执行任何业务逻辑之前完成。在设计 Web 服务方法时必须考虑到这些问题，还要记住除了网络调用之外还有解析与规划 XML 请求和响应的开销。

考虑到这些因素，可以把 Session Facades 模型化为 EJB Web 服务端点。Session Facades 可以在把请求委派给相应的 Web 服务方法之前首先验证请求。这样，您就可以向 Web 服务客户提供粗粒度的服务。

下面的图 4 § 说明了企业外部应用的面向服务体系结构的下一次迭代过程。这个版本的体系结构向外界公开粗粒度的服务。

§
这里，主要的实现仍然和图 3 § 中所示的相同。唯一的区别在于已经公开了 Session Facades 作为 Web 服务端点。EJB Web 服务可以模型化为本地接口而不是远程接口。使用会话 facades 和方法级安全性，可以限制要执行的服务。使用 Web Service Gateway 也能为 Web 服务客户施加安全措施。根据需要，可以实现粗粒度服务和细粒度服务的某种结合，通过调整 Web 服务网关中间件来向外部客户公开两种服务。（关于使用 Session Facades 与企业 Web 服务的更多信息，请参阅参考资料 § 。）

采用 WSDL 文件形式的 Web 服务接口可以发布到商业注册中心，从而使客户能够动态查找这些接口。如果交易伙伴已经知道这些服务，也不一定要进入商业注册中心，但是全球服务需要公共注册中心，以便客户能够查找可用的服务。例如，各个航空公司可以把它们的机票价格服务放在注册中心，普通客户可以发现所有这类服务，并查找航空公司所提供的最低票价。

1. 面对异构开发环境下的多系统的横联集成思路

真正的集成难题 - 接口多样性

同样考虑 n （n-1 ）集成问题。任何组织都会碰到某些类型的集成问题；或许是因为一次公司的合并、一个新的商业联盟或者仅仅是需要互连现有的系统。如果 n 个应用程序系统必须直接互连，那么将会产生 n(n-1) 个连接或接口。在图2 § 中，每个箭头表示一个接口。

§
因此，如果另一个应用程序系统 A （第 n+1 个）必须集成进来，将需要产生、文档化、测试和维护 2n 个新的接口。虽然在上图中，5 个应用程序组成的集合需要20 个直接接口，但是添加第6 个应用程序将需要10 个新接口！而更糟的是，必须修改每个已有的应用程序中的代码以包括进新的接口，因而将发生大量的测试费用。您可以立即为 n 个应用程序找到产生最小接口数目（n ）的最优解决方案，只为每个附加的系统添加一个新的接口，但是，通过直接连接是做不到的。

在过去的40 多年来，软件开发的实践经历了几个不同的编程模型。而进行的每一次转变在某种程度上都是为了处理更高级别的软件复杂性，并且使得可以通过部件、组件或服务来装配应用程序。近来，Java 技术促成了平台中立的编程，而 XML 促成了自描述，因而也促成了平台中立的数据。现在，Web 服务通过允许应用程序以对象模型中立的方式实现互连，从而克服了另一个障碍。使用简单的基于 XML 的消息传递 Scheme ，Java 应用程序能够调用基于 DCOM 、遵循 CORBA 甚至是 COBOL 的应用程序。在新加坡的一台大型机上的 CICS 或 IMS 事务能够被一台在慕尼黑的 Domino 服务器上运行的 Lotus 脚本驱动的基于 COM 的应用程序调用。最好的情况是，调用程序很有可能根本不知道该事务在哪里运行、它是由哪种语言编写的以及消息的传输路径。只需提出服务请求，然后就会得到答案。

与其任何一个前身相比，Web 服务更有可能成为提供提供有效的、可靠的和可扩展的机器到机器交互的标准，这是几个技术和文化上必须具备的先决条件适时结合的产物。这些先决条件包括：

无处不在的、开放标准的、低成本的网络基础架构和技术。它有助于一个分布式环境的形成，这个环境更有利于采用 Web 服务，而不是 CORBA 和 DCE
在一个以网络为中心的领域内达到的接受程度和技术成熟水平。它要求互操作性以实现关键的业务目标（比如，分布式协作）
一致同意基于 Internet 的开放标准和相关技术是实现低成本互操作性的最好方法。
基于网络的技术（比如 TCP/IP ）、工具集（IDE 、UML 等等）、平台（比如 J2EE 平台）和相关的方法（比如 OO 、服务等等）的成熟水平。它们提供了简化松散耦合的、可互操作的、机器到机器的交互（一种比 CORBA 用户体验到的高级得多的状态）所需的基础架构。

面向服务的体系结构允许设计这样的软件系统，它通过发布的可发现的接口为其他的应用程序提供服务，而其中的服务可以通过网络进行调用。当您用 Web 服务技术来实现面向服务的体系结构时，您是在一个更强大、更灵活的编程模型中创建一种新的构建应用程序的方式，从而降低开发成本、持有成本以及实现风险。SOA 既是体系结构模型，又是编程模型，是一种考虑构建软件的方式。

然而，还有更重要的机会刚刚出现。其中第一个就是网格计算，网格计算不仅是使用拥有大量 MIPS 的应用程序来进行计算的解决方案，而且还将提供一个框架，通过此框架可以动态地定位、重定位、平衡和管理大量的服务，这样，无论系统上的负载如何，总可以保证安全地获取所需的应用程序。而这又明显地需要按需计算的概念（on-demand computing ），按需计算可能是在任何配置下实现的，从简单的服务器集群到有1024 个节点的 SP2 网络。用户需要解决问题和适当的用于解决问题的计算资源——不多也不少——并且为实际使用的资源付费。

这些新功能的有效使用将需要重新构造许多现有的应用程序。现有的单一应用程序能够在这些环境中运行，但没有以最优的方式来使用可用的资源。这个问题和先前讨论过的问题一起可以产生如下结论：必须作出根本的改变——迁移到面向服务的体系结构。

面向服务的体系结构的需求

根据上面讨论的问题，可以很明显地看出，应该开发一种体系结构来满足所有的需求，这些需求包括：

首要的一点就是利用现有的资产。现有系统很少可以抛弃，它们通常都包含对于企业很有价值的东西。从战略上讲，目标是构造一个新的体系结构来创造所有想要的价值，但是，从战术上讲，必须集成现有系统，以便随着时间的推移，可以在可管理、渐进式项目中分化或取代它们。
支持所有必需的集成类型或“样式”。这包括：

- 用户交互——能够提供单一的、交互式的用户体验
- 应用程序连接性——通信层构成了所有体系结构的基础
- 流程集成——编排应用程序和服务
- 信息集成——联合和移动企业数据
- 依集成需求而构建——构建和部署新的应用程序和服务。

允许渐进式实现和资产迁移——这将支持开发这种体系结构的一个最关键的方面：获得更大的投资回报率（ROI ）的能力。数不清的集成项目由于它们的复杂性、成本和不切实际的实现进度安排而失败。
包括一个以标准的组件框架为基础构建的开发环境，促进更好地重用模块和系统，允许将遗留资产转移到这个框架中，并且考虑到新技术的及时实现。
允许实现新的计算模型；特别是，新的基于 Portal 的客户端模型、网格计算和按需计算（on-demand computing ）。

面向服务的体系结构——不只是 Web 服务

Web 服务的出现产生了根本的改变，因为很多 Web 服务项目的成功显示这种技术事实上确实存在，借此您可以实现真正的面向服务的体系结构。它使您又往回走了一步，不仅分析您的应用程序的体系结构，而且还要分析您正设法解决的基本业务问题。从业务的角度来看，它不再是一个技术问题，而是要开发一种应用程序体系结构和框架，可以在其中定义业务问题，还可以以一致的可重复的方式来实现解决方案。

不过，首先必须理解 Web 服务并不等同于面向服务的体系结构。Web 服务是包括 XML ，SOAP ，WSDL 和 UDDI 在内的技术的集合，它使您能够针对特定的消息传递和应用程序集成问题构建编程解决方案。随着时间的推移，您有理由相信这些技术将逐渐成熟并最终为更好、更有效、更健壮的技术所取代，但是，就目前的情况而言，它们可以发挥作用。至少，它们是 SOAs 能够最终实现这种观念的证明。那么，面向服务的体系结构实际上是由什么组成的呢？

SOA 只不过是一种体系结构。它不是任何诸如 Web 服务这样的特定技术的集合；而是超越它们的，在理想的情况下，是完全独立于它们的。在业务环境中，SOA 的纯粹的体系结构定义可能会是这样的“一种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，可以以定义好的顺序调用这些服务来形成业务流程”。请注意这里的表述：

所有功能都定义为服务。这仅仅包括业务功能、由底层功能组成的业务事务和系统服务功能。这将会产生粒度问题，后面我们将对此进行讨论。
所有的服务都是独立的。它们就像“黑匣子”一样运行：外部组件既不知道也不关心它们如何执行它们的功能，而仅仅关心它们是否返回期望的结果。
在其最一般的意义上来说，接口是可调用的；也就是说，在体系结构的层面上，它们究竟是本地的（在本系统内）还是远程的（在直接系统外）、是用什么互连 Scheme 或协议来调用或需要什么样的基础架构组件来连接，都是无关紧要的。服务可能是在相同的应用程序中，也可能是在公司内部网内完全不同的系统上的不对称多处理器的不同地址空间中，还有可能是在用于 B2B 配置的合作伙伴的系统上的应用程序中。

在所有这些表述中，接口是最关键的，同时也是调用应用程序关注的焦点。它定义了必需的参数和结果的类型；因而，它定义了服务的类型，而不是实现服务的技术。系统的责任是实现和管理服务的调用，而不是调用应用程序。这使得可以认识到两个关键的特征：其一，服务是真正独立的；其二，它们是可以管理的。管理包括许多功能，其中有：

安全性——请求的授权、加密和解密（在需要时）、确认等等
部署——出于性能、可用性冗余或其他方面的原因，允许服务在网络内重新部署（移动）
日志——用于审核、测量等等
动态重新路由——用于故障排除（fail over ）或负载平衡
维护——管理服务的新版本

§ 服务的性质

什么是服务？如前所述，在一个典型的业务环境里，服务意味着业务函数、业务事务和系统服务。业务函数可能是 getStockQuote 、getCustomerAddress 或 checkCreditRating 。业务事务可能是 commitInventory 、sellCoveredOption 或 scheduleDelivery 。系统服务可能是 logMessageIn 、getTimeStamp 或 openFile 。请注意各种类型服务之间的区别。从应用程序的角度来看，业务函数实际上是原子的非系统函数。业务事务很像是调用应用程序的简单函数，但是它们可能是作为自己的事务的上下文所包含的复合函数来实现的。它们可能包括多个底层函数，这些底层函数对调用者来说是透明的。系统函数是能够从诸如 Windows 或者 Linux 这样的特定平台中抽象出来的广义函数。应用程序框架可能提供像 openFile 这样的广义函数来有效地虚拟化数据源，从而可以在不考虑真实数据源的类型和位置的情况下使用这类函数。

这看起来像人为地规定服务之间的区别；您可以从应用程序的角度断言，所有的服务都是原子的，而与它是业务服务还是系统服务无关。做出这样的区别仅仅是为了引入粒度这个重要的概念。将业务程序分解成服务不仅仅是一个抽象的过程；它具有非常真实的现实含义。根据定义，服务可能是低级（细粒度的）函数，也可能是复杂的高级（粗粒度的）函数，并且在性能、灵活性、可维护性和可重用性方面都有很现实的折衷选择。定义服务的过程通常是在更大的作用域（应用程序框架的作用域）内完成的。这才是必须做的实际工作：也就是开发基于组件的应用程序框架，其中，服务定义为一组可重用的组件，而这些组件又可以用来构建新的应用程序或集成现有的软件资产。

现在，可以获得很多这样的框架；在 IBM ，一些像 EWA 、JADE 和 Struts （来自 Jakarta ）的这样的框架正用在客户集成场景中。以 EWA （读作“Eva” ）为例（它来自 IBM Software Group Advanced Technology Solutions 组），在一个较高的层次上，框架看起来如图 1 § 所示。在这个框架中，配置定义了一个应用程序，描述了该应用程序的组件以及它们调用的顺序和方法。以源中立的方式接收输入并将其传送到应用程序。因此，举例来说，用现有的 ATM 访问将因特网连接添加到一个银行应用程序，对应用程序逻辑来说是透明的。前端设备和协议处理程序使其成为可能。核心提供系统级服务，而特定用途的使得能够连接后端企业应用程序，这样它们就可以保持原来的状态，或者在一段时间以后进行迁移。虽然 EWA 是完全遵循 J2EE ，但是它可以连接到外部基于 DCOM 或 CORBA 组件的系统。

现在，EWA 包括超过 1500 个的常规和特定用途的组件，从而大大地减少了编写新的应用程序所需的代码数量。本系列的另一篇文章将详细地研究应用程序框架以及用户在开发这样一个应用程序框架的过程中需要什么。

解决前面的问题

现在，让我们回到讨论第一个集成场景，寻找一个将所需的接口数量减到最少的 Scheme ，如图 2 § 所示。

这张图看起来可能过于简化，但是现在可以很清楚地看出，在像 EWA 这样的框架中，这张图是一个起点。现在，添加属于体系结构概念范围的服务总线（Service Bus ）（在图 3 § 中用深色的中线表示）和服务或流管理器来连接服务和提供服务请求的路径。流管理器处理定义好的执行序列或服务流，它们将按照适当的顺序调用所需的服务来产生最后的结果。业务流程执行语言（Business Process Execution Language ，BPEL ）就是这种将流程定义为一组服务调用的技术的例子。

在这里，您需要确定如何调用服务，因而您将添加应用程序配置。接着，虚拟化输入和输出。最后，提供到后端流程的连接，以便使它们可以按“仅此状态”运行，并且还可以在将来进行迁移。现在，这个高层次的图至少在结构上是完整的了，如图 4 § 所示。

这张图与 EWA 框图有一些类同之处是毫不奇怪的；在最高的层次上，任何健壮的应用程序框架都必须提供这些功能。然而，从现在起，真正的工作开始了——构建 1500 个组件来丰富这个骨架。这就是为什么很多 IT 架构师选择在一个现有的框架中进行实现的原因；把现有的应用程序分解成用于框架的组件就够了，而不必重新开发所有其他已知将要用到的通用用途组件和系统组件。无论您如何使用它，您都可以使用现有的技术和框架来实现该体系结构，所以您绕了一整圈，现在又回到了开始的地方，在这里，流程首先分析必须解决的业务问题。如果您敢肯定您的体系结构事实上是可实现的，您现在就可以这样做。

体系结构中的集成需求

集成已限定为通过基于组件的服务进行的应用程序的集成，但是集成这个主题比这要宽泛得多。在估计一个体系结构的需求时，必须考虑一些集成的类型或“方式”。您必须考虑如下几方面：

应用程序集成
终端用户界面集成
应用程序连接
流程集成
信息集成
构建集成开发模型。

终端用户界面集成涉及如何集成特定用户访问的全部应用程序和服务来提供可用、高效、一致的界面。它是一个正在发展的主题，而新的发展在近期将主要取决于 Portal 服务器使用方面的进展。虽然 Portlet 已经可以通过 Web 服务调用本地服务组件，但是新技术（比如用户远程 Portlet 的 Web 服务）将使内容和应用程序提供者能够创建交互式服务，这些服务在因特网上可以通过 Portal 即插即用，从而为很多新的集成提供了可能。

应用程序连接是一种集成方式，它涉及体系结构必须支持的所有类型的连接。在一个层次上，这意味着数据的同步和异步通信、路由、转换和高速分布、以及网关和协议转换器等等。而在另一个层次上，它还与输入和输出或源（sources ）和汇（sinks ）的虚拟化有关，正如您在 EWA 的通道（Channel ）和协议转换程序（Protocol Handlers ）中所看到的。这里的问题在于数据移入、移出以及在实现体系结构的框架中移动的方式。

流程集成涉及开发映射到业务流程和为业务流程提供解决方案的计算流程、将应用程序集成到流程以及集成一些流程与其他一些流程。虽然第一项需求可能看起来似乎无关紧要，不过就是体系结构提供一个模拟基本业务问题的环境，但是，如果在这一层中不进行充分的分析，体系结构的任何实现注定都将失败，不管它采用的技术是多么的巧妙。将应用程序集成到流程可能包括企业中的应用程序，也可能涉及调用远程系统中的应用程序或服务，而这些远程系统多半属于业务合作伙伴。同样地，流程层集成可能涉及整个流程的集成而不仅仅是来自外部源的单个服务，比如供应链管理或金融服务这样横跨多个机构的流程。为了满足这样的应用程序和流程的集成需求，可以使用像 BPEL4WS 这样的技术，而应用程序框架也可以使用程序配置 Scheme （比如在 EWA 中看到的）。实际上，可以在底层使用 BPEL4WS 来构造一个高层配置 Scheme ，然后通过一个引擎来驱动，这个引擎不仅提供流管理，而且还提供其他功能。然而，在构建这一切之前，您应该首先了解体系结构方面的需求，然后，再构建合适的基础架构。

信息集成是一个流程，其作用在于为所有需要它的应用程序提供对企业中全部数据的一致访问，而不管这些应用程序是以什么形式需要它，也不受数据的格式、来源或位置的限制。在实现时，这项需求可能包括适配器和转换引擎，不过它通常要比这复杂。而关键的概念往往是数据的虚拟化，这可能包括数据总线（Data Bus ）的开发，企业中的所有应用程序都通过标准服务或接口从数据总线中请求数据。因此，不管数据是来自电子数据表、本地文件、SQL 或 DL/I 数据库，还是来自内存中的数据存储，都可以将数据提供给应用程序。永久存储中的数据格式可能还不为应用程序所知。应用程序更不知道管理数据的操作系统，因而访问 AIX 或 Linux 系统中的本地文件的方式与这些文件放在 Windows 、OS/2 、ZOS 或其他系统中时访问它们的方式相同。同样地，数据的位置也是透明的；由于它是由共同的服务提供的，所以是由访问服务而不是由应用程序来负责查询数据（无论是本地的还是远程的），然后按照请求的格式提供数据。

应用程序开发环境的最后一项需求是，必须考虑可能在企业中实现的集成的所有方式和层次，并且为它们的开发和部署做好准备。要想真正做到健壮，开发环境必须包括（和执行）一种方法来明确地规定如何设计和构建服务和组件，以便促进重用、消除冗余和简化测试、部署和维护。

上面列出的所有集成方式在任何企业中都有一定程度的体现，尽管在某些情况下它们可能是简化的，或者没有明确地进行定义；因而，在着手设计新的体系结构框架时，您必须全面的考虑它们。特定的 IT 环境可能只有很少的数据源类型，因此，消息集成可能会很简单。同样地，应用程序连接的作用域可能也很有限。虽然如此，如果希望框架能够随着企业的成长和变化成功地继续得以保持，则框架中的集成功能仍然必须由服务提供，而不是由特定的应用程序来完成。

部署面向服务的体系结构的好处

面向服务的体系结构可以基于现有的系统投资来发展，而不需要彻底重新创建系统。如果组织将开发力量集中在创建服务、利用现有的技术、结合基于组件的方法来开发软件上，将获得如下几方面好处：

利用现有资产—— 这是首要的需求。通过使用适当的 SOA 框架并使其可用于整个企业，可以将业务服务构造成现有组件的集合。使用这种新的服务只需要知道它的接口和名称。服务的内部细节以及在组成服务的组件之间传送的数据的复杂性都对外界隐藏了。这种组件的匿名性使组织能够利用现有的投资，从而可以通过合并构建在不同的机器上、运行在不同的操作系统中、用不同的编程语言开发的组件来创建服务。遗留系统可以通过 Web 服务接口来封装和访问。
商品化基础架构—— 在所有不同的企业应用程序之间，基础架构的开发和部署将变得更加一致。现有的组件、新开发的组件和从厂商购买的组件可以合并在一个定义良好的 SOA 框架内。这样的组件集合将被作为服务部署在现有的基础构架中，从而使得可以更多地将基础架构作为一种商品化元素来加以考虑
更快的产品上市速度—— 组织的 Web 服务库将成为采用 SOA 框架的组织的核心资产。使用这些 Web 服务库来构建和部署服务将显著地加快产品的上市速度，因为对现有服务和组件的新的创造性重用缩短了设计、开发、测试和部署产品的时间。
减少成本—— 随着业务需求的发展和新的需求的引入，通过采用 SOA 框架和服务库，为现有的和新的应用程序增强和创建新的服务的成本大大地减少了。同样，开发团队的学习难读也降低了，因为他们可能已经熟悉了现有的组件。
降低风险—— 重用现有的组件降低了在增强或创建新的业务服务的过程中带来的风险。如前所述，这也减少了维护和管理支持服务的基础架构的风险。
持续改进业务过程—— SOA 允许清晰地表示流程流，这些流程流通过在特定业务服务中使用的组件的顺序来标识。这给商业用户提供了监视业务操作的理想环境。业务建模反映在业务服务中。流程操纵是以一定的模式重组部件（构成业务服务的组件）来实现的。这将进一步允许更改流程流，而同时监视产生的结果，因此促进了持续改进。
以流程为中心的体系结构—— 现有的体系结构模型和实践往往是以程序为中心的。应用程序是为了程序员的便利而开发的。通常，流程信息在组件之间传播。应用程序很像一个黑匣子，没有粒度可用于外部。重用需要复制代码、合并共享库或继承对象。在以流程为中心的体系结构中，应用程序是为过程开发的。流程可以分解成一系列的步骤，每一个步骤表示一个业务服务。实际上，每个过程服务或组件功能都相当于一个子应用程序。将这些子应用程序链接在一起可以创建能够满足业务需求的流程流。这种粒度允许利用和重用整个组织中的子应用程序。

建议技术配置及产品

一）SOA 架构设计方法及应用集成产品

JBI 架构
1. 基于JBI 架构的ServiceMix 服务总线
SCA 架构
1. CXF(Celtix/Xfire ）服务总线
2. Apache Tuscany 服务总线
3. Oracle BEA Aqulogic 产品
4. IBM WebSphere Intergration Developer 产品
5. IBM WebSphere ESB Server 产品
6. IBM WebSphere Process Server 产品
SDO 架构
1. Apache Synapse 服务总线
2. Mule 服务总线
3. Apache ActiveMQ
4. IBM WebSphere MQ
5. IBM WebSphere Message Broker

数据集成产品

WebSphere DataStage 现更名为 InfoSphere DataStage
WebSphere Information Integration
WebSphere Federation Server
Oracle GoldenGate
Oracle Data Integrator

选型原则：

以上产品均能符合项目建设的目标，在未来的项目需求点对点应答中各产品的表现有所不同，各有优劣，须结合项目的实际规划方案和开发实施情况来进行深入的比较和推敲，xx公司对于以上产品均熟悉，达梦平台符合并满足以上的规范化实现平台的部署。
考虑总体拥有成本，其中包括license 成本、开发维护成本、用户使用管理成本、升级成本。
考虑可靠性和可用性及性能，在应用层面、数据库层面进行测试后再进行对比分析，因此集成前有必要对数据库、存储子系统、网络性能、VLAN/SAN/DMZ 等性能敏感区域进行全面调试后再比较、否则影响以上产品的实际表现。xx公司能够提供以上服务。
服务实施周期及质量控制、由于未来的新系统存在上线时间的不一致性，因此，务必考量以上方案涉及产品的容错性及迭代实施的时间成本和难度、包括以上各个产品部署的时候与应用子系统的安全性设计、数据交互、以及数据本身的存储、备份策略及方式，建议使用IBM TSM 软件进行全面的备份，备份需要考虑的备份对象和备份和恢复性能，对象包括操作系统（windows 、Linux 、unix ），邮件服务器(domino 、exchange) 、数据库服务器(oracle 、sqlserver 、sybase 、informix 、db2) 以及备份介质（硬盘、磁盘阵列、磁带库）。
实施和开发服务任重道远、项目管理不可忽视。
附件为IBM Rational 建议的SOA 设计及总体思路建议书、包含了IBM 公司SOA 产品及使用场景环境一览。

应用集成与数据集成建设总体思路

建设背景

建设目标及原则

高校信息化现状及主要问题

面向精细化管理的数字化校园建设总体思路

分项布局及技术考量

整体架构设计

应用集成规范

数据集成规范

实时数据集成

集成 开发实施的重难点分析

集成环境的工具 使用及对比

SOA 开发规划

面对 异构开发环境下的多系统的横联集成思路

建议技术配置及产品

你可能感兴趣的:(数据)

集成开发实施的重难点分析

集成环境的工具使用及对比

面对异构开发环境下的多系统的横联集成思路