《（OA自动化）SOA_analyse》由会员分享，可在线阅读，更多相关《（OA自动化）SOA_analyse（13页珍藏版）》请在金锄头文库上搜索。
1、哪些行业会是面向服务架构（SOA）的先行者一项突破性技术产生后，总要有第一批勇于“吃螃蟹”的先行者来示范。这个道理应该同样对SOA适用，所以一直在思考和留心这个问题，“哪些行业会是SOA的先行者？”随着SOA实际部署项目的逐渐增加，答案也慢慢浮出水面。最近，Forrester出了一份关于亚洲SOA在各个行业应用情况的研究报告（Asia Pacific SOA Industry Adoption Trends），副标题就是“公共部门和金融行业将主导SOA投入（Public Sector And Finance Will Drive SOA Spend）”。另外还看到过来自易观国际的一篇分析报告，
2、“中国中间件市场及部署SOA趋势展望”，同样提到排名前三的行业需求来自电信、金融和政府。答案不算出人意料，这里倒是可以检讨一下其中可能的原因。提供增值服务是这些行业的特点之一。而且无论公共部门还是金融服务，行业内提供的服务基本是同质的。在提供同质服务的行业里，取得优势的通常方式是如何提供差异化和创新。在差异化和创新中，信息系统的支持应当是不可或缺的，特别是一个高效灵活的业务信息系统。SOA的理念正切合了这个需求。先说差异化，例如：金融行业里各个银行对个人提供的基本业务基本没有本质的差别。如果说差别，大多数是用户体验的差别。用户体验的差别源于业务流程的差别。而说到对业务流程的优化与重组的支持，S
3、OA无疑是有优势的。再说创新，现在的公共部门总是在不断推出各种各样的便利新服务，这些服务大多数也都要以信息技术支持。说到信息技术为支持业务创新应该要具备的柔性（Flexibility），SOA同样是有吸引力的。这些行业能够率先“尝鲜”SOA，也得益于其良好的信息系统基础。无论是公共部门还是金融，都应该算是信息化比较成熟的行业。就那国内来讲，这些年的信息系统建设投入，早让公共部门还有金融行业，实现了全面的信息化。不管是硬件设备、软件环境，还是管理意识、人员素质，都能说是万事具备。转向SOA，是一个自然而然的举措。因为SOA理念的运用，无疑会帮助加速整合其信息技术方面的优势，对业务发展提供更好的支
4、持。除了信息技术的原因，管理的标准化也便利了SOA的推广。公共部门或金融行业，管理上相对其他行业，例如制造业，可以说更加有规矩可循，在这些行业中大多数业务流程都已经在管理上被清晰定义，SOA的概念非常容易同业务模式互相映射。拿SOA中最困难的问题之一，关于业务流程中服务划分的颗粒度问题来讲，在这些行业能够比较好的参照原来的业务定义来做映射。而且，关于服务的对内对外接口也相对稳定。SOA理念和管理模式的契合，对获得各方面的认同和支持也是必要的。最后还有一点比较重要的因素，就是在公共部门或金融行业中个体占有的市场地位对采用SOA的影响。毋庸置疑，这些行业里的个体都占有相对垄断的地位。一方面垄断地位
5、说明其独享一个庞大的市场，服务具有相当数量受众。SOA概念的实施，能够受惠一大片，取得相当大的效益（经济的或者是社会的）；另一方面，垄断地位让其有能力来领导和掌控SOA项目，特别在项目早期，项目效益的示范作用还不明显的时候，一个强有力的领导者能避免项目的夭折。SOA项目的集成（Integration）效益是随同参与者的增加而增加的，也就是说越多人参与进来，不仅倍增参与者的增益，而且降低参与成本。总之，行业的垄断地位，能保证足够多的参与者，也能在避免不必要的犹豫不决和踌躇不前。检讨公共部门和金融行业能先行主导SOA的原因，是希望对其他行业的SOA推动有所借鉴。实施SOA并不是单纯的技术革新，而更
6、多的是方法论和业务模式的进化。SAP在这方面一直是强调“进化论”。从上面的分析，也能看到SOA的成功需要从管理到技术，从内部到外部，从设备到人员，等等，多方面协同推动。电子政务需要SOA，从面向构件开始SOA已经有很多人在讲了，并且讲的时间也不算短了。以此为题做论文，难度可不小。不过，既然是面向服务的体系架构，我始终以为，SOA是不能脱离业务的，它应该首先是一种业务设计方式，指导着隶属领域范畴的业务服务的构思、创建、使用、变化和终结。其次，这种业务设计方式应该在面对不同领域范畴的不同业务服务的各个生命周期中能够始终如一地贯穿技术标准化的策略原则。所以，要谈SOA，我还是把它放在一个特定的领域，
7、比如电子政务领域谈起吧。如此接下来的话题就自然而然地变成了以下几个：电子政务需要SOA吗？是过去需要、现在需要，还是将来需要？电子政务的SOA如何开始？电子政务需要SOA吗？我国的电子政务建设格局像一个纵横交错的大棋盘，在刚刚过去的“九五”和“十五”期间，我国各级政府部门纷纷规划和建设起各自的电子政务系统工程，从中央到地方竞相投入人力物力财力，在很多方面都取得了显著的阶段性成果。以国信办17号文件中所规划的12“金”工程为代表，国家各大部委正在积极借鉴“金税”、“金关”、“金盾”等工程的成功经验，努力而快速地推进自上而下的、涵盖“部、省、市、县、乡”等五个层次的纵向综合业务系统。纵向电子政务建
8、设的成功经验是围绕政府的某项具体职能，利用信息化的手段，达到业务标准和业务资源的统一，实现数据自底向上的快速准确汇集和业务自上而下的高度协同。“金税”、“金关”等工程的实施也确实证明了它们在强化政府的税收管理和外汇管理等方面所起到的巨大作用。从某种程度上讲，能够自上而下的推进涵盖“部、省、市、县、乡”等五个层次的纵向综合业务系统，本身就是SOA的一种体现，只不过此时SOA的设计仅仅是面向内部的、面向具体业务功能的，因此也是局部的SOA。局部SOA的后果就是，局部的统一不能带来全局的统一，如果跳出局部看整体，在更宽广的范围内来看，比如站在国家电子政务全局来看，或站在公众的角度去看，满眼尽是一个个
9、划地而治的信息孤岛，需要为整体去做集成。而这恰恰成为了横向电子政务所需面临和解决的信息共享和资源整合的挑战。横向电子政务正在逐步实现由“政绩导向”向“服务导向”的转变。以服务为中心，使老百姓能得到更广泛、更便捷的政府信息和服务，使政府真正转变为服务型政府，党和政府为此都做出了重要决定。党的十六届四中全会做出了加强执政能力建设的重要决定，提出转变政府职能，创新政府管理模式，是提高政府执政水平的重要措施。温家宝总理在主持召开国家信息化领导小组第三次会议上提出要从全面和战略的高度加快推进信息化建设，抓紧推进电子政务，提高政府的经济调节、市场监管、社会管理和公共服务能力，促进政务公开。因此，以公众服务
10、为中心，服务公众就成为电子政务建设的出发点和落脚点。过去的经验是功能性的、局部的，现在要求以公众服务的角度去看电子政务全局，面向服务去重新梳理业务流程，即面向服务去详细描述政府和公民互动的过程、政府履行的各种业务与功能以及关键的业务流程。电子政务建设必须面对以下几个挑战：1、如何做好电子政务的顶层设计？尤其是在跨部门电子政务项目中，如何加强牵头单位、协作单位、信息主管、决策领导之间的联系？2、如何克服以部门为中心的思维方式，设计出既满足局部功能，又符合发展要求（如快速适应变化），同时又能参与全局协同的服务？3、如何有效评价服务的质量和更好的理解各部门的互相关系？4、如何把以单个部门为核心的不兼
11、容的信息系统升级为以服务为中心的、可集成的统一的服务或服务组合？这些挑战有技术范畴的，也有业务范畴的。可以给出的解决方案是首先要给出一组服务业务模型和服务评价模型，业务模型描述服务业务的可持续发展，不仅包括它的创建态，还可以包括其变化态和协作态，评价模型描述服务的评估态。这个模型就是SOA提倡的方法论。在这个统一的方法论指导下，将模型细分为服务域、服务流程和服务构件，并始终贯彻统一的技术标准加以实现，就能基本解决上述的几个挑战。现在再来重新审视一下我们是如何做到了以服务为中心这一点的。“政务公开、公众服务、决策优化”正成为电子政务发展的新形势，以服务为中心，使老百姓能得到更广泛、更便捷的政府信
12、息和服务，以服务为中心，梳理和重组业务流程，使各个业务系统能够互联互通和资源共享，有效降低实施和运行成本，提高监管能力和公共服务水平。因此，电子政务的发展需要以服务为中心的设计和方法指导，这就充分说明了电子政务需要SOA的论断是必要而且可行的。是过去需要、现在需要，还是将来需要？电子政务需要SOA已毋庸置疑，但是什么时候最需要？过去、现在还是将来？人们在考虑这个问题的时候，往往会想到我过去已经建了哪些系统，现在还需要建设哪些系统，哪些系统需要整合，至于将来，有个五年规划就可以了。实际上这是走入了一个误区，即将建设与整合孤立看待。这一误区的主要表征就是以孤立的、静态的、割裂的，而不是发展的眼光看
13、待电子政务的应用建设和应用整合，将业务需求和业务发展割裂开来，以致建设出来的电子政务系统需要整合，整合的电子政务应用仍是按静态需求建设起来，如果需要则再次整合。而走出此误区的方法就是将建设和整合有机统一起来。要树立没有从头建起的系统的观念，要从设计上就能够充分意识到系统总是在整合一切可以利用的资源（内部的、外部的）的基础上发展起来的，是为了满足新的业务变化需求。新系统就是旧系统的利用整合，同时它又是将来能够被新业务整合的资源。 实际上，有些人可能会感到惊奇，但面向服务的架构确实已经存在20多年了！因为SOA是基于一种设计理念及一系列设计原则的，而这些都是与技术无关的。在过去20多年里，可用于实
14、现SOA的技术是多种多样的，它们包括CORBA、J2EE、COM/DCOM、MQ、ebXML、EAI、ESB等。在这些技术中，有的适于构建SOA，有的则不然。从某种意义上讲，SOA可以被看作是EAI的一种延续，但不是简单的延续。EAI与SOA同样解决企业集成的问题，但SOA解决的问题远比EAI解决的IT问题多得多、复杂得多，因此产生的影响要深远得多。有一部分应用集成问题是可以通过EAI来解决的。但是，EAI解决集成的问题往往是在事后，碰到了集成问题，才去想办法通过 EAI来解决。与之相反的是，SOA架构解决集成的问题是事先的，也就是说，在一开始搭建SOA这一IT架构的时候，就已经考虑了集成的问
15、题。这是SOA区别于EAI的一个重大不同，也是SOA能够帮助我们走出“割裂建设和整合”误区的佐证。 另外，EAI解决集成问题时，可能会带来更多其他集成问题，最终会带来一个更加复杂的IT架构。SOA解决这些集成问题时，是将现有的系统以统一的标准接口进行一次重新的梳理，不会再带来新的集成问题。因此，电子政务是时时刻刻都需要SOA的，过去需要，现在需要，将来也需要。尤其以服务为中心和导向的电子政务建设需要SOA，在它的指导下，我们才能够避免走进误区。电子政务的SOA如何开始？我们已经论证了电子政务需要SOA，但现在的问题是在电子政务的建设过程中，如何才能发挥SOA的最大功效？SOA该如何做起？面对我
16、们所涉及到的众多重要概念，如面向服务、顶层设计、业务模型、流程重组、服务构件等，我们该如何入手呢？首先，要把SOA看成方法论，要根据电子政务的业务需要，通盘考虑所需要的业务模型和数据模型。每一条业务线和数据线都要从服务的特征、管理的特征和适应变化的特征去审视，并且每次审视都要围绕上下左右中等多重视角，还要加上一个时间维度。可能需要建立新的成本/利益模型，要打破单个业务使用独立IT系统的模式，特别是那些可以重复使用的，必须要求服从一个统一的SOA架构，开发出有层次的、可重用的体系。其次，要把SOA看成架构平台，或者说要根据业务模型建立支撑重用软件的运行和管理平台。在可重用的层次模型支持下，平台要做到技术无关性，就要以统一的标准去运行和管理重用软件。再次，要把SOA看作是软件工厂里的产品装配线。它是一笔对将来业务运营的投入，所以在这笔投入发挥效益之前，需要做相关的计划、设计和开发工作。正如生产线上制造的第一辆车的花费要
