金税三期的一些思考.doc

金税三期的一些思考.doc 对“金税三期”软件架构及实现的一些思考 2011-01-06 11:07:05| 来源:中国税务网 | 作者:罗会波 内容提要:本文从信息化建设的一般规律及税务信息化在整个电子政务中的位置论述了“金税三期”的建设是税务信息化自身发展的必然要求。通过分析“金税三期”的关键需求，指出了SOA及BPM是当前架构和实现“金税三期”的最佳选择。同时，说明了用SOA建设“金税三期”工程时应防止的两种极端做法，相应地提出了使用SOA架构“金税三期”所应采取的策略应该是扬弃的策略，既不能全盘否定原有系统，也不能抱残守缺。并结合纳税人增值税发票限额查询的事例及典型的SOA架构由点到面对原来不同系统中的数据共享、服务抽象、服务组合及SOA治理等做了具体说明。同时结合征管系统及公文处理中涉及到的业务流程说明在实现时，采用BPM取代定制的流程管理及老式工作流系统的优越性。最后，对防止供应商的技术绑定及“金税三期”面向未来的问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 提出了建议和看法。 关键词:“金税三期” 架构实现 SOA BPM 一、税务信息系统的现状及新的需求 事物的发展总是遵循一定的客观规律，信息化建设也不例外。美国管理信息系统专家诺兰(Richard Nolan)的信息系统进化阶段模型(即诺兰模型)就较好地描述了信息化发展的一般规律。该模型将信息化的进化划分为六个阶段，它们分别是:初始阶段、传播阶段、控制阶段、集成阶段、数据管理阶段和成熟阶段。那么，我们正在建设的"金税三期"工程处在该模型的什么阶段呢,对比税务信息化建设当前的实际情况和模型，不难发现我们正处在模型的第四阶段，并力争向第五阶段过渡的过程中。 第四阶段名为集成阶段。因为在第三阶段通常会产生许多独立的实体，比如各种应用软件系统等。而创建这些实体时受到当时的条件限制，往往都是基于局部的、战术上的考虑而非整体的、战略上的考虑。这样就会造成数据冗余存储，及对新的需求的反应迟钝。前不久刚好碰到这样一个典型例子。上级要求统计一下一般纳税人专用发票开票限额的数据。这本身是一个极简单的需求，结果却出人意料的大费其神。该数据最完整版本在增值税防伪税控系统中，但该系统没有提供统计查询的功能。只能一户一户地查询。该数据的另一个版本在Ctais2.0系统中的防伪税控核定情况查询中的最大发票金额字段中。在Ctais2.0中虽然可以进行统计查询，但问题是Ctais2.0中只有其上线后走相应的文书的企业才有该数据，而在以前的Ctais1.1时就已经核定的企业的数据就没有出现在Ctais2.0的系统中。因此，想直接统计数据肯定不准。而上级要求的统计时间规定得很紧，想提交修改程序的需求显然不现实，最后只能在增值税防伪税控系统中一户一户地查询。这种工作效率与没有信息化时的情况有什么 实质上的区别吗,我看区别不大。对那些户数上千的城区分局来说工作量也是显而已见的。像这样重复存储的信息还有很多，比较典型的如纳税人注册方面的信息和税务机关的人员信息，它们广泛地分布在各种应用系统中。而各个应用系统的使用用户和维护人员往往不同，因此，按照当前这种情况，要保证在各个系统中的这些数据的一致性和准确性几乎是不可能的。这也是在模型的第四阶段为什么诺兰会说:“这时，组织从管理计算机转向管理信息资源，这是一个质的飞跃。从第一阶段到第三阶段，通常产生了很多独立的实体。在第四阶段，组织开始使用数据库和远程通信技术，努力整合现有的信息系统。”的原因。由此可见，集成是信息化发展到这一阶段的内在要求，也是建设“金税三期”工程的首要原因。 在集成阶段基本就绪后，数据的一致性和准确性都将会有大步的提高。这就为迈向模型的第五阶段即所谓的数据管理阶段打下坚实的基础。信息时代也被称为知识经济时代，这里的知识就是指的数据中包含的知识。众所周知的啤酒与尿布的故事就是知识经济的最好例证。当税务信息系统中积累起大量的准确的数据的时候。其蕴含的知识将是全社会的财富，也是真正实现信息化税收的基础。它只等待人们去挖掘，去利用。比如在税务系统内，对上层可以提供决策所需要的宏观信息;对基层可以提供纳税评估等方面的信息，在这方面基层有许多鲜活的实例。比如，有些纳税人长期零申报，在其申报表等文件上看不出有什么破绽，税务人员往往通过企业的水、电等的耗费情况，与其他类似的企业的数据的对比从而估算出其真实的生产经营情况，最终评估出企业的应纳税额。这难道不是与啤酒与尿布的故事有异曲同工之妙吗,“金税三期”也准备在这方面做一些探索。 上面是从税务信息化自身发展的纵的方向来看“金税三期”所处的历史阶段。下面，将税务信息化建设放在整个电子政务的背景上，横向看看“金税三期”所处的位置。早在94年金税一期工程就已经正式上马了，可见，金税工程是最早开建的金字头的政务信息化工程之一;金税工程的发展在电子政务中也是非常迅速的，从当初的金税一期工程仅仅只是增值税交叉稽核系统和增值税防伪税控系统。其中，增值税交叉稽核系统还是一个主要采用企业提供增值税专用发票，由税务机关组织手工录入的方式进行数据采集的比较原始的系统。经由金税二期及综合征管软件及其它系统的开发和应用，现在金税工程的内涵得到了极大地丰富，外延也几乎覆盖了所有处理涉税事务及税务系统内部管理的信息系统。成为整个电子政务中举足轻重的一个重要组成部分。正是金税工程所处的这种地位，不可避免地会对它提出新的需求:一是对内部各个系统的资源整合，使其由大变强;二是与外部(纳税人、其它政府部门及银行等)系统的交互将由现在的以零星的局部的数据交换为主，变成日常的全面的业务协同。三是要提高系统随需而变的响应速度。信息化发展之初，信息系统提供给人们的高速度的映像是非常深刻地。如:在信息化系统完全没有的时候，稽查部门去发票管理部门查几张怀疑有问题的发票存根联时，发票管理部门的人员往往翻箱倒柜折腾半天才 能办妥。有信息化后，只要鼠标轻点，很快就会给出结果。但随着系统逐渐变大，系统中各个部分的依赖关系也逐渐变得复杂起来，系统对需求变化的灵敏度也在开始下降，好比数学上的麦比乌斯圈一样，沿着圈走，不知不觉就走到了出发点的反面。近年来，随着金融危机的爆发，国际经济局势动荡不定，为了应对这种局面政策也必定是灵活多变的。另一方面我国幅员辽阔，各地的经济形势也很不相同。这些都迫切地要求政务信息系统是能够灵敏地随需而变的。 为了集成现有的系统，以及增加系统对需求的反应的灵敏度。人们曾做出过不懈的努力。其中比较有代表性的技术就是EAI(企业应用集成)，它试图通过将应用程序集成起来达到联通各个信息孤岛的目的。实践证明，该技术有一些严重的缺陷，主要的就有如下几点:其一，各个应用间的通信 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 往往是私有协议，这样造成了各个应用是紧密耦合的;其二，当集成一个新系统时，可能就要针对该系统的特性开发新的私有协议，这就大大的增加了集成的工作量;其三，该技术采用的是点对点的集成，当应用程序很少时，这种方法还是显得比较有效的。但是当要集成的应用数量变大时，应用间的依赖关系将会爆炸性地增长，立即会失去控制。但是人们的努力并没有白费，正是为了克服以往的一些集成方法及技术的不足，一种新的方法日渐成熟，它就是SOA(面向服务的体系结构)及BPM(业务流程管理)。 二、使用SOA及BPM来架构和实现“金税三期” SOA是一种设计方式，它为机构提供关于创建和使用业务服务的各个方面的指导。是迄今为止集成IT系统最有效的方式。使用SOA来整合时，一个不能回避的问题就是如何处理新老系统关系的问题。IT界在这个问题上存在着两种有代表性的观点:一种是原来各种应用系统都必须按照SOA的方式进行完全的重新设计;另一种则认为现有系统都是经过实践检验的成熟系统，只要将它们进行适当的包装，然后组合在一起就行了。前一种观点类似于历史虚无主义，IT实践证明，该观点是站不住脚的，在经济上也是不合算的，纵然老系统有这样或那样的缺陷，但其中不乏有经过实践多年检验的、反复修正的好的部分。这些都是税务系统化建设中积累起来的宝贵财富。不能将洗澡水和婴儿同时倒掉。因此，这种观点显然是不可取的;而后一种观点则是抱残守缺，固步自封。同样也无法达到IT系统集成所真正要达到的目的。打一个通俗的比方，如果我们要求集成后的系统是一艘航母，而采用曹操的方式将战船组合起来，是永远不可能打造成一艘真正意义上的航母的。因此，这种观点也不是很靠谱的。那么正确的方式只能是采取扬弃的方式，去粗取精，去伪存真。该重新做的部分必须重新做，值得保留的部分则尽量保留。 首先，从“金税三期”的架构上讲。前面说过，金税工程的内涵与外延都发生了很大的变化。比如金税二期及以前的金税工程基本上就是指增值税防伪税控系统。该系统的诞生是由它所处的特定的历史条件所决定的。当时伴随着增值税的改革，许多人想钻增值税的漏洞，比如假增值税发票方面的违法犯罪现象频出。当时亟待有一个 这方面的IT系统来堵住这些漏洞;因此，早期的金税系统应运而生。另一方面，由于当时还没有建成一个统一的综合征管系统，早期的金税系统是作为一个独立的系统而存在的。但是随着综合征管软件Ctais的上线运行，不难发现早期的金税工程中所涉及的数据比如纳税人登记信息，及功能如发票管理、报税等在两个系统中重叠。这种重叠现象至少会带来如下几方面的负面影响:一是数据来源不唯一，对新的需求反应迟钝，如我们前面介绍过的查询一般人增值税发票限额的例子;二是增加纳税人及基层税务机关的工作量，因为大量重复的工作要在两个系统中重复进行;三是由于各个系统一般分别由不同的人员维护，因此，系统中的业务数据的修改往往不可能同步，从而造成业务数据口径的不一致，这就给税收的征管工作带来了麻烦，也为数据分析和决策支持等埋下隐患。要消除这些负面影响，只有在"金税三期"架构时就统筹考虑到如何将金税二期系统与综合征管系统融合在一起。还是以查增值税发票限额为例，分别从数据和功能两个方面来加以说明。 在数据方面:数据的来源必须唯一，同样性质的数据只应该在整个系统中只保存一个版本，而不是在不同的子系统中保存多个版本。比如征管和防伪税控系统都要用到纳税人的注册信息，该信息只能是在纳税人注册功能模块提供的数据，防伪税控用到该数据时不应该再人为地重复录入或者从数据库中倒入。而征管系统在发售发票等业务要用到发票限额，也只能由防伪税控功能所批准认定的数据，而不应该手工重复采集或从数据库中再倒入该数据。只有这样才能满足“金税三期”所要求的“数据一次采集，多处复用”的需求，也不会产生数据口径不一致的问题，提高数据的准确性。像该例中不同系统共享数据的情况还很多，特别典型的是纳税人注册信息及税务系统内部的人员(包含其角色及权限)信息，往往会被多个系统共享。可能会形成访问瓶颈，即使这样，也只能是通过集群(Cluster)等负载平衡技术来加以解决。这样就会在很大程度上解决数据共享及联通信息孤岛的问题。 在功能方面:采用SOA方式来架构系统，比较彻底地颠覆了传统应用开发中从每个具体的应用程序要解决的局部的战术问题的思考方式。而是强调从业务的战略全局上思考问题。因此，在技术上我们经常会看到在SOA文献中提到流程都是端到端(End-to-End)流程。之所以现在能达到这样的境界，我想是与现实的需求的驱动以及已有的软硬件平台的逐步发展成熟分不开的。如果把IT基础设施(这里形象地把它称着机器吧)放在一端，将业务放在另一端。不难发现，随着时间的推移，在应用程序开发领域，人们的关注点离业务越来越近，而离机器越来越远。笔者90年代在一家通讯设备公司工作时接触到一个电话机上用的CPU，它的功能就是用来控制电话拨号等简单功能，业务上没有什么值得过多关注的地方。但它的累加器的位数只有四位二进制位。也就是说用它来处理一个字节都要分成两段来处理。那时人的关注点不得不离机器很近。现在恰好相反，业务越来越复杂而且灵活多变。而机器却有了长足的进步，无论是硬件还是基础软件都已经打下了一个坚实的基础。人们自然将关注的焦点 放到业务方面来了。SOA就是将业务需求的功能抽象为业务服务(Business Services)。然后，再通过业务服务注册表(Service Registry)模式、企业服务总线模式(ESB)、服务编制(Orchestrate)及服务编排(Choreography)模式等将这些业务服务组织起来以满足业务需求。为了对SOA架构有一个全面的认识，下面引用《Understanding SOA with Web Services》的一个典型的架构如图1所示。 从图1可以看出，图的上部接近业务而下部接近机器。我们现在的关注点是在应用层(Application Layer)以上的地方。先看应用程序层，该层的应用程序大多为了特定的战术目标，分别用不同的开发语言，运行在各种不同的平台上。这些应用程序可以说是鸡犬之声相闻老死不相往来，这些应用程序被形象地称为筒仓(Silos)。不是它们之间不想往来，只是要在这些应用中共享信息，实在是太困难。 SOA采取在应用层加上一个服务层(Services Layer)的方法。这里的服务是根据业务的需要从已有的应用中抽象出来的或者是新开发的。这些服务的接口是有明确定义的，技术上称为良定的(Well Defined)，而服务实现则可以有多种方式，这就使得服务是松耦合的。为了打通程序筒仓之间的联系，SOA提供了Web服务平台，该平台允许以一种与下层应用及技术平台无关的方式来定义和使用业务服务。基本的原理说白了很简单，比方，我们把一个个程序筒仓看成是一个个国家的人。它们都说自己国家的语言。显然，不同的语言无法交流。但这些人同时也都还能说英语(或对其进行英语 培训 焊锡培训资料ppt免费下载焊接培训教程 ppt 下载特设培训下载班长管理培训下载培训时间表下载 )。当我们把这些人组织成一个团队来工作时，就都用英语来交流。Web服务平台就是起类似的作用。相当于英语的就是XML语言。如Web服务定义在。wsdl文件中，通信协议采用SOAP等。这里无论是。wsdl文件，还是SOAP的定义文件都是用的XML语言。具体到查增值税发票限额的例子:当防伪税控要用到纳税人注册 信息时就向征管系统请求纳税人注册信息的服务;反过来，当征管系统要用到发票限额时则请求防伪税控的发票限额服务。当用户要查询纳税人的发票限额时，可以将征管系统和防伪税控提供的服务进行组合，用新形成的组合服务来满足这种需求。 从上面的介绍可以看出:SOA是以服务为中心的，而服务又是跨应用的，有些甚至是跨组织机构的。如何管理好这样一些服务就提到议事日程上来了，这就出现了所谓的SOA治理。SOA治理是一个贯穿于SOA整个生命周期的活动。比如:从架构时就应规划好哪些服务可以对纳税人开放;哪些服务可以对业务伙伴(银行、国库及其他政府部门等)开放;哪些服务要对税务机关内部开放以及如何确保这些服务的端到端的安全等。 其次，从“金税三期”的实现来看。无论是征管系统，还是行政管理系统都有大量的业务流程。它们的位置在图1中的业务流程层(Business Process Layer)。从设计的角度讲，这些业务流程中的大部分都是经过实践检验的可以保留的。但它们的具体实现因为限于当时的技术条件，有些流程逻辑是与业务逻辑混杂在一起的，典型的做法是在业务数据库表中设置状态字段，在程序代码中根据状态字段的值决定接下来做流程的哪一步;稍微高级一点是采用了工作流平台，但这种早期的工作流平台是与特定的技术(如J2EE或。NET)紧密耦合的。显然，在实现“金税三期”时，必须使流程逻辑与业务逻辑分离。用BPM就能轻易地做到这一点。BPM的应用对行政管理中的公文处理还有特别重要的意义。因为公文处理主要涉及到的是各种复杂的流程，而业务数据相对来说很简单，这样就可以轻易地将公文处理部分从原来的平台迁移到与征管系统统一的平台上来，这样不仅可以节约在平台软件上的开销，也降低了维护的难度。 使用BMP还会带来其他一些好处:从设计时看，首先，现在一些典型的中间件供应商如Oracle所提供的BPM都有可视化的建模工具。便于真正熟悉业务流程的流程开发人员自己建模。这也符合我们前面提到的使人们关注的焦点放在业务上，以保证最终的系统最大可能的符合业务需求。在软件开发领域有一张非常流行的卡通图，如图2所示: 图2形象地反映了一个需求是如何被“以讹传讹”，最终被搞得面目全非的过程。BPM提供的相应的工具，就是试图从一开始就减小这种风险;其次，流程逻辑与业务逻辑分离后，也便于它们各自的快速更改，有利于流程再造，从而提高应对业务变化的敏捷性;最后，BPM是基于SOA的，使得跨应用、跨组织机构的流程得以实现，增强与外界的业务协同。 从运行时看，BPM的应用带来的另一好处是它很容易与业务规则(Business Rules)协作，这在很大程度上可以不依赖编程而使系统的业务流程达到根据业务规则变化而变化的需求，这极大地增加了业务的敏捷性。因为无需编程就无需重新部署，甚至不需要重启服务器。这一特点在我国的税务信息化系统中显得尤为有用。许多政策在不同的地区或不同的时间采用不同的数量控制，比如起征点等。采用BPM与业务规则配合的方式，既可以保持整个软件架构的相对统一，又在很大程度上可以让具体的业务流程随地区或时间的变化而变化。此外，BPM的用户界面通过采用JSF及AJAX等技术可以获得良好的用户体验。 当然，“金税三期”实现时对软件可能被绑定到特定的供应商也要有足够的认识。以Bea和Sun公司近年来接连被Oracle公司收购为标志，中间件供应商也有大集中的趋势。这应该引起注意，因此，在实现时尽可能采用公开 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 的技术，而尽可能少地使用特定供应商所独有的技术。如有可能可以借鉴戏剧中的A、B角做法。生产环境选用一家公司的产品。最好另外准备一套替用品，该替用品选用另一家公司的产品。其实，看公司的宣传材料，不难发现它们都是在宣扬自己的长处，而贬低竞争者的产品。实际上，主要竞争对手的产品在一些基本功能上往往是难分轩轾的。 最后，无论是在系统架构还是实现阶段，都要考虑到向未来过渡的问题。比如，向云计算过渡等。云计算包含三个层次:即软件即服务;平台即服务及基础架构即服务。可见其核心仍然是服务。只要现在真正做好服务的抽象、实现及治理工作，待到将来云计算技术标准发展成熟时，再向其过渡，应该会是很自然的。使得今天“金税三期”的投资真正成为明天仍然有用的资产，而不是鸡肋。果真如此，“金税三期” 将成为税务信息化发展史上新的里程碑。 参考文献: [1](美)Eric Newcomer，Greg Lomow，Understanding SOA with Web Servic es[M].美国:Addison Wesley Professional，2004 [2]罗会波，JSF第一步——JSF+Spring+Hibernate+AJAX编程实践[M].北京:清华大学出版社，2007 [3]毛新生，金戈，黄若波，易立，李珉，任静安，SOA原理。方法。实践[M].北京:电子工业出版社，2007 [4](美)Jeff Davies，Ashish Krishna，David Schorow，SOA权威 指南 验证指南下载验证指南下载验证指南下载星度指南下载审查指南PDF :通过BEA AquaLogic Service Bus实现[M].倪志刚，王铭孜，黄兆勤译。北京:电子工业出版社，2008 [5](美)Virginia Beecher，Deanna Bradshaw，Tulika Das，Vimmika Dinesh，Anirban Ghosh，Mark Kennedy，Alex Prazma，Richard Smith，Deborah Steiner，Oracle, Fusion Middleware Developer's Guide for Oracle SOA Suite 11g Release 1[Z]Oracle，2010 [6](美)Carolina Arce Terceros，Steven Leslie，Oracle, Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Manag ement 11g Release 1[Z]Oracle，2010 [7]邵荣，换一个角度看软件开发[N].计算机世界报，2008-01-07，(第01期，B14-B15) 作者单位: 湖北省当阳市国家税务局