对于“拿来主义”我举手赞成
集成服务是SQL Server 2005中面向高性能数据集成的功能组成，它有一个配套的数据流机制和控制流机制，并且可以为数据分析服务提供必要的ETL支持。集成服务类似以往的DTS，采用包（Package）方式来执行一个个具有数据流支持的数据任务。除此之外，集成服务还有很完善的图形化管理工具和丰富的应用开发接口(API)。SQL Server 2005单独把集成这一部分独立成独立的服务，充分表明微软对其作为数据平台而不是单纯数据库产品的定位。在放弃了以往DTS之后，微软用.Net重写了集成服务，并把它分成了面向流程处理的Integration Service run-time engine和面向数据转换的Integration Service data flow engine，同时由于重新开发的缘故，保证.Net开发人员可以不通过互操作访问集成服务，可以说为未来SQL Server集成功能的发展提前“脱胎换骨”。
集成服务的系统架构
图1：集成服务的总体架构
总体上讲，集成服务由四个部分组成，如下说明。
Integration Services service：主要用来监控所有包的执行，并管理包的存储。
Integration Services object model：通过提供一组API来支持命令行工具、图形化工具和用户二次开发。
Integration Services runtime and the run-time executables：具体完成包的执行过程。
Data Flow task：提供了内存的缓冲结构用于保存从源数据源到目的数据源的中间结果，根据包的配置对提取的源数据进行清洗和修改，并控制整个包设计的数据文件和数据库访问。
相对DTS的跨越式进步
笔者相信很多读者在初次进入集成服务界面的时候，会觉得与DTS似曾相识而且很多功能特性基本上雷同，但是笔者要说明的是这都是UI上的共同点，本质上集成服务已经有了跨越式的发展。回顾以往DTS的功能，其实对于数据的加工功能非常有限，仅仅提供简单的转换支持，但是在集成服务中不仅可以完成数据转换，还可以进行数据清理(Cleaning)和聚合（Aggregating），此外还提供了笔者一直期待的合并（Merging）和复制（Copying）（相信这两个也是很多读者期待已久的功能）。另外，相对于以往简单的ActiveX脚本，新的集成服务支持读者通过.Net代码来完成转换，这大大增强了数据转换的控制能力。更为重要的是可以把整个数据包作为对象来调用，这样对于解决应用中繁杂的数据提取、转换和存储工作有很大帮助，可以充分法发挥.Net Assembly与包两种执行载体的优势。
增强了的“包”处理
与DTS类似，SQL Server 2005中的集成服务的包也是由数据源连接、控制流、数据流、时间处理、包参数和配置组成的，新的集成服务中既可以用图形设计器或.Net语言开发包，包是Integration Service提取、执行和保存的单元。一个最基本的包是由一个控制流和数据流组成，而且可以通过一个包模版生成，所有的开发工作可以在Visual Studio 2005或者SQL Server Business Intelligent Development Studio中完成。
图2：集成到Visual Studio 2005的SSIS开发环境
其中，控制流元素主要描述的了包中Task的布局，每个Task之间的优先次序和它们如何与数据源连接关联并执行的，为了方便逻辑上可以把一组相关的Task共同保存在一个Container中，可以把它们们作为一个集合进行各种配置。控制流的逻辑示意结构如下：
图3：控制流的逻辑示意结构
与控制流不同，数据流对象主要描述的是数据在点与点之间的转换。这里转换的都是数据，每个点都是一个逻辑的数据点（内存中逻辑的或者是介质上物理的）。SQL Server 2005中支持大量的数据源类型，同时借助.Net的扩展机制完全可以采用类似扩展ADO.Net Data Provider类似的办法扩展数据源。数据流的逻辑示意结构如下：
图4：数据流的逻辑示意结构
这里笔者建议主要集中在SQL Server平台上开发的朋友，可以现在就开始利用面向对象的继承特性，结合微软提供的Enterprise Library或者是一些Application Block开发通用的企业集成服务包摸版，通过继承和多态在未来的开发中快速建立应用。
同样是由于SQL Server 2005集成了CLR，而且SSIS已经用.Net重写了整个集成服务，因此通过集成服务的对象模型，开发人员可以从各个侧面对其进行扩展，主要包括：
（1）Task
（2） Connection Manager
（3） Log Provider
（4）Enumerator
（5）Data Flow Component
（6）Event Handling
更加丰富的事务控制能力
对于商业逻辑而言，事务性始终是必不可少的内容，与以往DTS上简单的事务不同，SQL Server 2005的集成服务可以在包(Package)、容器(Container)、任务（Task）三个层次配置操作过程的事务性，不过与COM+中DTC事务选项不同的是集成服务中缺少了RequireNew类型的事务关联选项，仅仅提供Required、Supported和NotSupported三个交易关联选项。
Required：代表若父容器已经启动了一个事务，那么当前单元就把自己加入（Enlist）进去，否则就重新发起一个事务。
Supported：则持无所谓的态度，如果父容器有了，就把自己Enlist进去，否则也不会主动发起一个事务。
NotSupported：则是持反叛的态度，不管父容器是否有事务，反正他自己的内容就是不在事务控制下完成。
对于事务执行情况的监控可以采用WMI或者SQL Server 2005集成服务的Log Provider机制完成。不过笔者因为以往一直在用COM+开发，因此更习惯于用Component Service的DTC浏览器察或者是Performance Monitor查看DTC的执行情况。
图5：用COM+的DTC浏览器察看分布式事务执行情况
数据你好，请Report给我看
SQL Server 2005中的报表服务笔者认为已经具有了一个企业报表环境的特质，这个版本中不仅提供了对于关系数据库的支持，而且对分析服务的多维数据也提供了支持。面向用户可以用HTML、PDF、TXT、Excel等多种格式导出报表，而且通过扩展机制几乎可以涵盖所有的数据源类型、所有的文本呈现类型和所有的报表方式。
通过报表服务可以可视化的完成报表设计过程的交互工作，并且可以在Web上完成绝大多数的报表管理工作。在本次的版本中，还增加了对于多维数据的Drill down，并且可以在运行时进行对于报表内容的筛选。
报表服务的整体架构
图7：报表服务的整体架构
上图是报表服务的整体架构，这其中，报表服务特别强调了扩展机制，主要包括如下4个方面。
Authentication extension：通过认证的扩展机制，可以从很多方面把来自企业的各种认证机制进行集成，包括传统应用中的“账号/口令”认证，Windows平台的基于活动目录的认证，不同信任域或者异构平台的证书认证，甚至于通过Speech SDK开发的声音认证、通过生物技术认证等等。
Rendering extension：通过扩展该机制，可以把报表内容通过更多的介质方式保存，例如可以面向企业用户提供电子邮件的支持。
Delivery extension：提供扩展该机制可以提供更多样的分发方式。
Data Processing extension：扩展该机制可以把更多的数据源，尤其是非关系数据库或者是不具有二维表格结构的数据加入到报表引擎中。
叩开业务人员自主开发Ad Hoc报表的大门
以往的报表工具更多面对的是开发技术人员，即使是非常简单的报表都要经开发人员之手再呈现给用户，但是报表服务提供了Report Model的机制，通过该机制可以把技术上的数据源信息以业务人员友好的方式，让他们在自己熟悉的Office环境中完成一些简单实用报表的DIY工作。同一个Report Model在不同的群体眼中有两个不同的角色：
对于业务人员，Report Model就是一个可以用来加工各种报表的平台，里面有他们所熟悉的业务语言描述的各种数据资源。Report Model向业务人员屏蔽了数据源连接、访问认证、表达式、原始数据内容筛选、执行参数等很多技术细节。
对于Report Model设计的技术人员而言，他们面对的是一堆数据对象实体、关系和属性。
笔者认为，如果您从事的是行业性开发或者是面向固定的大型企业应用开发，那么储备Report Model开发积累一方面可以让您快速的适应新的应用，另一方面可以简化很多技术性处理工作，最主要的是如果培训和宣传到位，它可以把业务人员的主动性也调动起来，这对于节省IT日常维护成本也有直接的利益。
通过扩展机制建立“企业报表环境”
随着信息技术的广泛应用，在许多政府和企业内部常常存在数个，甚至数十个信息系统。基于成本和运行维护费用的考虑，许多信息系统都在做不同方式的集中，无论是服务器整合、数据库整合、统一存储结构、单点登录和认证、应用系统间基于中间件和Web Service的互联等等。从整体的角度来看，都是根据技术功能进行合并。反观报表作为非常通用的业务功能和技术手段，其中不少表单在本政府序列或本行业的很多信息系统中无论数据内容还是数据格式都是一致的，但是在各个信息系统实施的时候，由于开发平台、开发工具、报表工具的变化，又往往被反复的设计、开发、部署，这往往造成成本、人力、时间的浪费。
同时，为了满足业务需求的变化，报表又往往是信息系统中修改较为频繁的部分：
对于报表的内容条目、格式的变更数量往往和界面的变更数量持平，对于新增的业务项目，报表的变更数量还可能数倍于对原始数据维护界面的变更数量。
从获取方式上，某个业务刚上线时可能只需要本地打印、Web访问；随着该业务逐步融为基本业务流程后，又常常会出现邮件报表的要求；伴随移动设备的普及，提供精简的移动报表的需求也常常会被提出；随着政府内部和企业内部各个信息系统间、各政府信息系统之间、各企业信息系统间互联的要求不断深化，来自不同信息系统间的归并报表也将会逐步浮出水面。
作为某个政府序列或一个企业而言，报表往往是其非常重要的信息资产，如果在每个信息系统内部都作针对本系统或本企业人员的报表访问控制，还是存在一个重复建设的问题。
报表的集中存储管理（存储、备份、恢复等）如果分散到不同的信息系统中，设备、存储管理人员也难免往往会出现重复投资的情况。
报表内容修改的不一致性，例如业务变更时，对报表内容和数据布局的修改往往需要在多个信息系统中重复修改。
那么SQL Server 2005的报表服务器是从整个技术流程上为您进行这种企业报表集成提供可能：
图8：报表服务扩展机制的过程化支持
17
文章来源于领测软件测试网 https://www.ltesting.net/
