图为本文作者
从某种程度上讲，能够自上而下地推进涵盖“部、省、市、县、乡”等五个层次的纵向综合业务系统，本身就是SOA的一种体现，只不过此时SOA的设计仅仅是面向内部的、面向具体业务功能的，因此也是局部的SOA。
SOA是面向服务的软件架构，既然是面向服务的，SOA就应该首先是一种业务设计方式，指导着业务服务的构思、创建、使用、变化和终结。那么，在电子政务领域，电子政务需要SOA吗？是过去需要、现在需要，还是将来需要？本文将围绕电子政务的SOA如何开始等问题，阐述“从SOA开始，从面向构件的SOA开始，是电子政务保持可持续发展的最佳实践”这一论断。
“政绩导向”转为“服务导向”
我国的电子政务建设格局像一个纵横交错的大棋盘，在刚刚过去的“九五”和“十五”期间，我国各级政府部门纷纷规划和建设起各自的电子政务系统工程，在很多方面都取得了显著的阶段性成果。纵向电子政务建设以“金税”、“金关”等工程的成功实施为代表，目的就是利用信息化的手段，达成自上而下的业务标准和业务资源的统一，实现数据自底向上的快速准确汇集和业务自上而下的高度协同。从某种程度上讲，能够自上而下地推进涵盖“部、省、市、县、乡”等五个层次的纵向综合业务系统，本身就是SOA的一种体现，只不过此时SOA的设计仅仅是面向内部的、面向具体业务功能的，因此也是局部的SOA。
局部SOA的后果就是，局部的统一不能带来全局的统一，如果跳出局部看整体，在更宽广的范围内来看，满眼尽是一个个划地而治的信息孤岛，需要为整体去做集成。而这恰恰成了横向电子政务所需面临和解决的信息共享和资源整合的挑战。
横向电子政务正在逐步实现由“政绩导向”向“服务导向”的转变。以服务为中心，使老百姓能得到更广泛、更便捷的政府信息和服务，使政府真正转变为服务型政府，党和政府为此都做出了重要决定。
因此，以公众服务为中心，服务公众就成为电子政务建设的出发点和落脚点。电子政务建设必须面对以下几个挑战：
1. 如何做好电子政务的顶层设计？尤其是在跨部门电子政务项目中，如何加强牵头单位、协作单位、信息主管、决策领导之间的联系？
2. 如何克服以部门为中心的思维方式，设计出既满足局部功能，又符合发展要求(如快速适应变化)，同时又能参与全局协同的服务？
3. 如何有效评价服务的质量和更好地理解各部门的互相关系？
4. 如何把以单个部门为核心的不兼容的信息系统升级为以服务为中心的、可集成的统一的服务或服务组合？
这些挑战正是使电子政务能够持续发展的前提。以服务为中心，使老百姓能得到更广泛、更便捷的政府信息和服务；以服务为中心，梳理和重组业务流程，使各个业务系统能够互联互通和资源共享，有效降低实施和运行成本；以服务为中心，加强评价和绩效体系，提高监管能力和公共服务水平。因此，电子政务的发展需要以服务为中心的设计和方法指导，需要给出服务的业务模型和服务的评价模型，业务模型描述服务业务的可持续发展，不仅包括它的创建态，还可以包括其变化态和协作态，评价模型描述服务的评估态。这充分说明了电子政务和电子政务的可持续发展需要SOA。
电子政务何时需要SOA
现在，电子政务需要SOA已毋庸置疑，但随之而来的问题就是，电子政务在什么时候需要SOA？是过去、现在还是将来？
其实，人们在考虑这个问题的时候，往往会想到过去已经建了哪些系统，现在还需要建设哪些系统，哪些系统需要整合，至于将来，有个规划就可以了。实际上这是走入了一个误区，即将建设与整合孤立看待。这一误区的主要表征就是以孤立的、静态的、割裂的，而不是发展的眼光看待电子政务的应用建设和应用整合，将业务需求和业务发展割裂开来，以致建设出来的电子政务系统需要整合，整合的电子政务应用仍是按静态需求建设起来，如果需要则再次整合。
而走出此误区的方法就是将建设和整合有机统一起来。要从设计上就能够充分意识到系统总是在整合一切可以利用的资源(内部的、外部的)的基础上发展起来的，是为了满足新的业务变化需求。新系统就是旧系统的利用整合，同时它又是将来能够被新业务整合的资源。
实际上，面向服务的架构已经存在很多年了。因为面向服务是一种设计理念和基于一系列设计原则的，而这些都是与技术无关的。在过去，可用于实现SOA的技术是多种多样的，它们包括CORBA、J2EE、COM/DCOM、MQ、ebXML、EAI、E 等。在这些技术中，有的适于构建SOA，有的则不然。
电子政务的SOA如何开始
在电子政务的建设过程中，如何才能发挥SOA的最大功效？SOA该如何做起？面对我们所涉及到的众多重要概念，如面向服务、顶层设计、业务模型、流程重组、服务构件等，我们该如何入手呢？
首先，要把SOA看成方法论，要根据电子政务的业务需要，通盘考虑所需要的业务模型和数据模型。每一条业务线和数据线都要从服务的特征、管理的特征和适应变化的特征去审视，并且每次审视都要围绕上下左右中等多重视角，还要加上一个时间维度。可能需要建立新的面向服务评价模型，要打破单个业务使用独立IT系统的模式，特别是那些可以重复使用的服务，必须要求服从一个统一的SOA架构，开发出有层次的、可重用的体系。
其次，要把SOA看成架构平台，或者说要根据业务模型建立支撑重用软件的运行和管理平台。在可重用的层次模型支持下，平台要做到技术无关性，就要以统一的标准去运行和管理重用软件。
再次，要把SOA看作是软件工厂里的产品装配线。它是一笔对将来业务运营的投入，所以在这笔投入发挥效益之前，需要做相关的计划、设计和开发工作。正如生产线上制造的第一辆车的花费要比第一千辆高出很多一样，用SOA部署的第一个服务所需的花费要比部署第一百个多出很多。SOA的主要优势是逐渐体现出来的，不能一蹴而就。
最后，必须投入足够的精力和人员进行技术和业务流程的培训，才能确保所开发的服务是可重用的。任何服务的开发，不能只顾及眼前利益，也要考虑长期利益(或许是更重要的)。换句话说，各个服务的单独存在并无太大价值，除非这些服务能与其他服务一起使用，并能根据业务的变化，快速组合成各种新的应用。
如何使上面所述的SOA方法落地呢？
SOA的方法论就是电子政务的领域构件库，它们在业务模型的支持下呈现出层次结构，构件粒度可大可小，大构件是小构件的组合，上层构件是对下层构件的抽象，在一定的层次上，构件表现出一定功能的服务特征。
SOA的架构平台就是一个标准的构件容器，它负责解释、运行、监控实例化的构件。这个构件容器是能够跨技术平台的，允许不同服务之间交互数据、参与协同流程，无论它们各自背后使用的是何种操系统或采用了何种编程语言。
SOA的装配线就是构件的图形化集成环境(IDE)。可以在这里创建构件、复用构件、嵌套构件、组装构件，可以在这里通过构件的组装生成一个个服务。而服务因为具有了内部的构件化特征，使得服务成为一个柔性的结构，而一个柔性结构在适应变化方面要远远优于一个钢性结构的服务，从而延长了这个服务的生命周期。
所以说，SOA可从面向构件开始。
SOA从面向构件开始
从面向构件开始，电子政务的SOA就建立在了可被管理的业务单元基础之上，而不是建立在不可被管理的代码之上，构件成为业务的技术无关性基本单元。
从面向构件开始，电子政务建设将最终达成我们梦寐以求的标准统一，架构统一，建设统一，管理统一。
从面向构件开始，电子政务将实现一个同构的世界。
因此说，从SOA开始，SOA从面向构件开始，是可持续发展电子政务的最佳实践。
网友评论