论文部分内容阅读
第一步 判断
“上不上SOA呢？”这是国内某保险公司信息中心王主任犹豫不定的事情。最近王主任注意到，几乎天天都有媒体报道SOA，上门游说SOA的厂商也是络绎不绝，但他对于怎么判断公司现有系统是否适合上SOA这个问题有点拿不准。尽管他对SOA很是动心，依然迟迟没有下定决心。
在众多IT厂商的推动下，SOA成为一个家喻户晓的概念。俗话说，世界上没有两片相同的树叶。同理，每个企业的IT系统都是独特的。即使SOA是个好东西，也不见得就是一剂包治百病的灵丹妙药，就能够适合所有的企业。另外，还有一个不容忽视的话题是，很多来游说的厂商都不能解释清楚什么是面向服务的架构。面对波涛汹涌的SOA大潮，作为用户，首先要判断的就是自己企业的IT系统是否适合SOA。
在这个客户就是上帝的时代，银行、保险等企业面临的迫切需要就是整合为客户提供的多种服务。通常，不同的服务是由企业不同IT系统支撑的，整合服务就需要集成各个不同的支撑系统，然而，集成的高昂成本让许多企业望而却步。SOA正是在这样的大背景之下应运而生的。简单地说，SOA是一种拥有很多大小不同、功能各异的应用组件的软件架构，它可以根据需求通过网络对各种应用组件进行分布式部署、组合和使用，从而满足用户统一服务界面、快速部署新业务等需求。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
可见，在异构的系统妨碍企业为客户提供整合服务时，SOA才能更好地发挥优势。对于某些企业来说，IT系统并没有这样的问题，实施SOA的优势会受随之而来的负面影响而打折扣。
对于一些企业来说，采用了单一厂商的技术和产品，拥有同构的IT环境，实施SOA就并不显得那么急迫。但是，当企业需要通过信息系统和合作伙伴建立更紧密联系时，SOA就是解决跨企业平台不可避免地会遇到的灵活性问题的良好途径。
实时或被动系统也不是实施SOA的最佳选择。SOA依赖异步通信模式实现服务提供者与服务消费者之间的松耦合，对大量并发的实时系统并不支持。当然，对不同企业来说，实时的内涵并不相同，对SOA也就有不同的判断。
当一切运转正常，信息中心主任也没有必要自作聪明去尝试SOA。尤其对于早早就使用了应用系统的金融行业来说，很多年前就已经成形的业务支撑系统，虽然经过了很多次修修补补，但是一直在正常运作。这种系统，轻易改变架构会是一件“不可完成的任务”—结构老，补丁多，又肩负重任，与其对它再做大手术，还不如等这种系统寿终正寝，重新开发符合SOA架构的新系统，进行自然淘汰比较好。当然，市场竞争激烈，业务人员可能随时要求改变企业为客户提供的服务，对系统修正、升级是必不可少的。
有了这样一番分析，王主任对是否该上SOA的认识比较清晰了。对他来说，目前最重要的核心业务系统是核保系统，这是很多年前建设的，当时还是使用C/S结构开发的，现在修修补补一直在用。除此之外，还有一些新系统，比如数据挖掘等系统是最近两年做的。王主任深知，在金融行业中，保险业开放最早，竞争也最为激烈，为用户提供更好的服务是必然的趋势，SOA也是必要的。但是，他考虑到，现在就在核心系统——核保系统上尝试SOA的话，成本太高，风险也很高。再者，公司高层也在考虑换核心系统，还是等等看吧。而数据挖掘系统不一样，是新上的系统，本身就是三层架构，向SOA进军条件比较成熟。那就先拿数据挖掘作为SOA的试验田吧。
第二步 算账
对于一个保险公司来说，核心业务系统的SOA建设是伤筋动骨的事情，慎之又慎很正常。但是，这并不意味着所有的系统都不能上SOA。恰恰相反，鉴于所有的系统都早晚要SOA，因此从很多新建系统或边缘系统练手是最容易想到的事情。
对于很多用户来说，上SOA要算好投入产出账。尤其对于那些预算有限，很多系统要上线的用户来说，如果没有充分的理由，又不能核算投入产出比，上SOA会面临很多问题。对于用户来说，在算经济账时有四点要注意。
首先要有充分的規划。如果仅仅是对现有系统进行整合，或者将服务构建在新的分支机构上，而不是通盘考虑，往往会导致单项计划的成本迅速增加，甚至导致失控。SOA是一项长期的工程，而在项目初期要明确哪些目的是要达到的，哪些目的是下一次才能实现的。最忌讳的是，在项目开始时设计了一个大而全的目标，结果实施越久发现需要解决的问题越多，最后导致项目无限期拖延下去，投入大而长时间见不到效益，让领导和实施者都丧失信心。
其次，要选择合适的合作伙伴。现在基本上所有大的IT厂商都推出了各种SOA解决方案，国内很多服务提供商也打出了SOA的牌子。其实，宣布能做SOA并不意味着真的就可以帮助用户实现。从实际操作角度上说，SOA是个长期工程，而且相当于把以前的系统打散了用一种新理念重新构筑，所以国际上成功实施的案例并不多。这就更要求用户在选择合作伙伴时要慎重。合作伙伴首先要具备一定的实力，起码知名度要高，研发实力要强，这样才能保证他们的方案经过反复的验证。同时，合作伙伴最好有一定的行业背景，甚至用户可以优先考虑从以前系统的建设厂商中挑选，这样，在进行系统迁移和重整时，不用从零开始。
第三，要有模块化意识。从这一点上来说，SOA与系统的开发和实施没什么区别。最大可能地将系统模块化，这样通过多次调用降低开发成本，从而获得最佳性价比。只是，模块化思想以及实施与项目初期的规划息息相关，只有良好的长期规划，系统才具有可复制性。
第四，人力资源是重要因素。毋庸置疑，SOA虽然不是新概念，但真正具备成功实施经验的人才还是弥足珍贵的。尤其对于用户来说，不可能一味依靠乙方的力量完成全面转向SOA这一浩大的工程，所以，培养自己的人才队伍对于很多用户来说是个长期工程。尤其刚开始时，不妨拿一些小范围的SOA迁移项目练手，等技术力量成熟时，再进行大一些的项目，循序渐进，逐步成功。当然，这其中不可避免的问题是“为他人做嫁衣”，人才培养出来了，却成为别人挖墙角的对象，损失当然不小。不过，这个问题的解决就像目前用户信息中心人才流失问题一样，需要用体制来保障。
BEA的专家对SOA的成本问题有自己的看法，他们反对四处出击，重要的是按成本受益顺序确定服务开发的优先级，这样SOA从一开始就显示出ROI(Return on Investment，投资回报率)。通过仔细规划，启动成本要限制在现有预算内。经过一段时间后，服务模块的重用会确保以后每个新业务应用程序的启动成本很低。同时，用户需要在实施开始时设置好基线，确保可测量性，避免临时修路的效果。
第三步 避险
成本的问题考虑清楚之后，SOA的实施风险就摆到用户面前。
尽管SOA的技术基础已渐趋成熟，但这并不意味着从此SOA就可以飞入寻常百姓家，相反，很多企业用户对部署SOA顾虑仍存。
联邦快递有限公司（FedEx）亚太区副总裁兼首席资讯总监莲达·C·柏勤（Linda C Brigance）表示：联邦快递对SOA的态度比较谨慎。花旗软件技术服务（上海）有限公司董事主席周亚贵是花旗集团亚太区IT系统规划的重要参与者。他透露，花旗集团亚太区并不打算在近期采用SOA。中国平安保险（集团）股份有限公司信息总监罗士礼曾经表示：部署SOA需要花费企业大量的时间和精力，而业务部门不会有那么好的耐心。对于IT部门来说，改变系统架构还必须考虑业务层面的现实压力。
实施SOA潜在的风险迟滞了部分用户迈向SOA的脚步。
要将现有的IT架构转变到SOA架构除了需要资金，用户还需要时间、勇气，以及抗风险的充分准备。
一般来说，部署SOA主要面临两类风险。
一是技术风险。首先，用户选择的SOA平台和开发队伍对Web服务、J2EE等技术标准的掌握程度，都可能潜藏着技术准备失利造成SOA项目失败的风险。SOA还处于发展阶段，一些技术并不是完全成熟，正处于从理念付诸实施的探索中。早有国外专家指出，SOA作为一个具有发展前景的应用系统架构，尚存在许多有待改进的地方，例如在可靠性、安全性、编制(Orchestration)、遗留系统(Legacy support)支持和语义(Semantics)方面均存在不足。其次，SOA可以讓原本不同的IT系统快速整合在一起，只须调用系统组件就可以进行业务整合。然而SOA目前还没有确定调用系统组件的统一标准。譬如税务部门与公安部门交换车辆数据，公安管理的是车辆，一辆车是一个数据，而税务管理的是纳税人，一个人可能有好几辆车，这就涉及数据约定的问题。SOA能做多大，就要看它能在标准化这个方向上能走多远。
二是管理风险，传统的企业管理模式执行垂直管理，部署SOA必须要改变企业内部的IT文化、IT组织，这对管理有很大的冲击。从已有的系统迁移改造成SOA架构，是一个长期的工程。尤其是如果企业打算向外部推广一些服务，和它的供货商、分销商、代理商、客户等一起来构建SOA架构的应用，那就还有更长的路要走。这里有一个实际的例子。商业银行现在向客户提供很多代缴固话费、手机费、水费、电费、煤气费等服务，一个省级分行要和几十个需要收费的单位互联，实现应用的相互访问。从纯技术的角度看，这无疑是基于Web服务的SOA架构应用的最佳用武之地。但现实是，没有人这么做—因为需要改造自己的业务系统，牵涉很多人员和投入。此外，也有安全的问题、效率的问题等，目前还没有成熟的解决办法。
为了实现这一目标，对企业内所有的员工——既包括IT部门员工，也包括其他部门的员工，都需要转变对业务流程的固有看法。这需要相关的职能部门为了长远的目标而放弃眼前的利益，也要求IT系统设计师及开发人员从服务的角度来考虑系统的构成，同时，他们可能会放弃某些环节的控制权，如版本控制等。整个SOA系统可能要涉及变更管理、技术管理、风险管理以及日常业务管理等多个已有的业务系统。
实施SOA存在风险，但我们也不可能因为存在风险就因噎废食。对于SOA项目的实施，专家提出的建议是，用户不能一次实现所有的功能，不能一口吃个胖子。在SOA项目中将风险最小化的一个方法，是先将一些小的或有利于业务的流程使用SOA模式，构建相应的服务模块。这样可以让员工先适应这种新的服务模块。不至于使整个公司因为引入了新的IT系统而陷入混乱。
记者手记
SOA应用 70度
当改革大潮轰轰烈烈而来时，我们要做的是隔岸观火还是顺势而动？
看现在这架势，好像隔岸观火者并不能完全袖手旁观。因为各大厂商实在是在用各种各样的武器—媒体报道、学术会议等等各种手段讲述SOA的好处。弄得好像谁要是不上SOA，就被社会抛弃了一样。
其实，任何一个新事物给社会带来的变化可能都是颠覆性的。但是，这并不代表它一面世就会有如此惊人的效果。早在上个世纪80年代，互联网就已经诞生，但其真正普及却在十年之后，其所带来的翻天覆地的变化也在很多年后才凸现出来。
SOA也是如此。SOA为我们描述了如此动人的场景，以至于让每个从事信息化的人都热血沸腾，但它什么时候才能真正普及，谁也说不清楚。很多厂商为我们提供了各种各样的方案，他们说，只要按照他们的指引，就能实现那些梦想。于是，很多跃跃欲试的用户开始摩拳擦掌，他们纷纷在一些关键或者非关键的旧业务系统改造、新业务系统初建的过程中，开始了SOA之旅。他们中的一些人有了收获，一些人有了经验，他们发现，SOA仅仅是个长期过程的代名词，阶段性成果并不那么遥不可及。
于是，SOA终于有能力进入实质性的高温阶段，用户的应用热情也逐渐高涨起来。要说现在的温度，100度不够，70度刚刚好。
“上不上SOA呢？”这是国内某保险公司信息中心王主任犹豫不定的事情。最近王主任注意到，几乎天天都有媒体报道SOA，上门游说SOA的厂商也是络绎不绝，但他对于怎么判断公司现有系统是否适合上SOA这个问题有点拿不准。尽管他对SOA很是动心，依然迟迟没有下定决心。
在众多IT厂商的推动下，SOA成为一个家喻户晓的概念。俗话说，世界上没有两片相同的树叶。同理，每个企业的IT系统都是独特的。即使SOA是个好东西，也不见得就是一剂包治百病的灵丹妙药，就能够适合所有的企业。另外，还有一个不容忽视的话题是，很多来游说的厂商都不能解释清楚什么是面向服务的架构。面对波涛汹涌的SOA大潮，作为用户，首先要判断的就是自己企业的IT系统是否适合SOA。
在这个客户就是上帝的时代，银行、保险等企业面临的迫切需要就是整合为客户提供的多种服务。通常，不同的服务是由企业不同IT系统支撑的，整合服务就需要集成各个不同的支撑系统，然而，集成的高昂成本让许多企业望而却步。SOA正是在这样的大背景之下应运而生的。简单地说，SOA是一种拥有很多大小不同、功能各异的应用组件的软件架构，它可以根据需求通过网络对各种应用组件进行分布式部署、组合和使用，从而满足用户统一服务界面、快速部署新业务等需求。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
可见，在异构的系统妨碍企业为客户提供整合服务时，SOA才能更好地发挥优势。对于某些企业来说，IT系统并没有这样的问题，实施SOA的优势会受随之而来的负面影响而打折扣。
对于一些企业来说，采用了单一厂商的技术和产品，拥有同构的IT环境，实施SOA就并不显得那么急迫。但是，当企业需要通过信息系统和合作伙伴建立更紧密联系时，SOA就是解决跨企业平台不可避免地会遇到的灵活性问题的良好途径。
实时或被动系统也不是实施SOA的最佳选择。SOA依赖异步通信模式实现服务提供者与服务消费者之间的松耦合，对大量并发的实时系统并不支持。当然，对不同企业来说，实时的内涵并不相同，对SOA也就有不同的判断。
当一切运转正常，信息中心主任也没有必要自作聪明去尝试SOA。尤其对于早早就使用了应用系统的金融行业来说，很多年前就已经成形的业务支撑系统，虽然经过了很多次修修补补，但是一直在正常运作。这种系统，轻易改变架构会是一件“不可完成的任务”—结构老，补丁多，又肩负重任，与其对它再做大手术，还不如等这种系统寿终正寝，重新开发符合SOA架构的新系统，进行自然淘汰比较好。当然，市场竞争激烈，业务人员可能随时要求改变企业为客户提供的服务，对系统修正、升级是必不可少的。
有了这样一番分析，王主任对是否该上SOA的认识比较清晰了。对他来说，目前最重要的核心业务系统是核保系统，这是很多年前建设的，当时还是使用C/S结构开发的，现在修修补补一直在用。除此之外，还有一些新系统，比如数据挖掘等系统是最近两年做的。王主任深知，在金融行业中，保险业开放最早，竞争也最为激烈，为用户提供更好的服务是必然的趋势，SOA也是必要的。但是，他考虑到，现在就在核心系统——核保系统上尝试SOA的话，成本太高，风险也很高。再者，公司高层也在考虑换核心系统，还是等等看吧。而数据挖掘系统不一样，是新上的系统，本身就是三层架构，向SOA进军条件比较成熟。那就先拿数据挖掘作为SOA的试验田吧。
第二步 算账
对于一个保险公司来说，核心业务系统的SOA建设是伤筋动骨的事情，慎之又慎很正常。但是，这并不意味着所有的系统都不能上SOA。恰恰相反，鉴于所有的系统都早晚要SOA，因此从很多新建系统或边缘系统练手是最容易想到的事情。
对于很多用户来说，上SOA要算好投入产出账。尤其对于那些预算有限，很多系统要上线的用户来说，如果没有充分的理由，又不能核算投入产出比，上SOA会面临很多问题。对于用户来说，在算经济账时有四点要注意。
首先要有充分的規划。如果仅仅是对现有系统进行整合，或者将服务构建在新的分支机构上，而不是通盘考虑，往往会导致单项计划的成本迅速增加，甚至导致失控。SOA是一项长期的工程，而在项目初期要明确哪些目的是要达到的，哪些目的是下一次才能实现的。最忌讳的是，在项目开始时设计了一个大而全的目标，结果实施越久发现需要解决的问题越多，最后导致项目无限期拖延下去，投入大而长时间见不到效益，让领导和实施者都丧失信心。
其次，要选择合适的合作伙伴。现在基本上所有大的IT厂商都推出了各种SOA解决方案，国内很多服务提供商也打出了SOA的牌子。其实，宣布能做SOA并不意味着真的就可以帮助用户实现。从实际操作角度上说，SOA是个长期工程，而且相当于把以前的系统打散了用一种新理念重新构筑，所以国际上成功实施的案例并不多。这就更要求用户在选择合作伙伴时要慎重。合作伙伴首先要具备一定的实力，起码知名度要高，研发实力要强，这样才能保证他们的方案经过反复的验证。同时，合作伙伴最好有一定的行业背景，甚至用户可以优先考虑从以前系统的建设厂商中挑选，这样，在进行系统迁移和重整时，不用从零开始。
第三，要有模块化意识。从这一点上来说，SOA与系统的开发和实施没什么区别。最大可能地将系统模块化，这样通过多次调用降低开发成本，从而获得最佳性价比。只是，模块化思想以及实施与项目初期的规划息息相关，只有良好的长期规划，系统才具有可复制性。
第四，人力资源是重要因素。毋庸置疑，SOA虽然不是新概念，但真正具备成功实施经验的人才还是弥足珍贵的。尤其对于用户来说，不可能一味依靠乙方的力量完成全面转向SOA这一浩大的工程，所以，培养自己的人才队伍对于很多用户来说是个长期工程。尤其刚开始时，不妨拿一些小范围的SOA迁移项目练手，等技术力量成熟时，再进行大一些的项目，循序渐进，逐步成功。当然，这其中不可避免的问题是“为他人做嫁衣”，人才培养出来了，却成为别人挖墙角的对象，损失当然不小。不过，这个问题的解决就像目前用户信息中心人才流失问题一样，需要用体制来保障。
BEA的专家对SOA的成本问题有自己的看法，他们反对四处出击，重要的是按成本受益顺序确定服务开发的优先级，这样SOA从一开始就显示出ROI(Return on Investment，投资回报率)。通过仔细规划，启动成本要限制在现有预算内。经过一段时间后，服务模块的重用会确保以后每个新业务应用程序的启动成本很低。同时，用户需要在实施开始时设置好基线，确保可测量性，避免临时修路的效果。
第三步 避险
成本的问题考虑清楚之后，SOA的实施风险就摆到用户面前。
尽管SOA的技术基础已渐趋成熟，但这并不意味着从此SOA就可以飞入寻常百姓家，相反，很多企业用户对部署SOA顾虑仍存。
联邦快递有限公司（FedEx）亚太区副总裁兼首席资讯总监莲达·C·柏勤（Linda C Brigance）表示：联邦快递对SOA的态度比较谨慎。花旗软件技术服务（上海）有限公司董事主席周亚贵是花旗集团亚太区IT系统规划的重要参与者。他透露，花旗集团亚太区并不打算在近期采用SOA。中国平安保险（集团）股份有限公司信息总监罗士礼曾经表示：部署SOA需要花费企业大量的时间和精力，而业务部门不会有那么好的耐心。对于IT部门来说，改变系统架构还必须考虑业务层面的现实压力。
实施SOA潜在的风险迟滞了部分用户迈向SOA的脚步。
要将现有的IT架构转变到SOA架构除了需要资金，用户还需要时间、勇气，以及抗风险的充分准备。
一般来说，部署SOA主要面临两类风险。
一是技术风险。首先，用户选择的SOA平台和开发队伍对Web服务、J2EE等技术标准的掌握程度，都可能潜藏着技术准备失利造成SOA项目失败的风险。SOA还处于发展阶段，一些技术并不是完全成熟，正处于从理念付诸实施的探索中。早有国外专家指出，SOA作为一个具有发展前景的应用系统架构，尚存在许多有待改进的地方，例如在可靠性、安全性、编制(Orchestration)、遗留系统(Legacy support)支持和语义(Semantics)方面均存在不足。其次，SOA可以讓原本不同的IT系统快速整合在一起，只须调用系统组件就可以进行业务整合。然而SOA目前还没有确定调用系统组件的统一标准。譬如税务部门与公安部门交换车辆数据，公安管理的是车辆，一辆车是一个数据，而税务管理的是纳税人，一个人可能有好几辆车，这就涉及数据约定的问题。SOA能做多大，就要看它能在标准化这个方向上能走多远。
二是管理风险，传统的企业管理模式执行垂直管理，部署SOA必须要改变企业内部的IT文化、IT组织，这对管理有很大的冲击。从已有的系统迁移改造成SOA架构，是一个长期的工程。尤其是如果企业打算向外部推广一些服务，和它的供货商、分销商、代理商、客户等一起来构建SOA架构的应用，那就还有更长的路要走。这里有一个实际的例子。商业银行现在向客户提供很多代缴固话费、手机费、水费、电费、煤气费等服务，一个省级分行要和几十个需要收费的单位互联，实现应用的相互访问。从纯技术的角度看，这无疑是基于Web服务的SOA架构应用的最佳用武之地。但现实是，没有人这么做—因为需要改造自己的业务系统，牵涉很多人员和投入。此外，也有安全的问题、效率的问题等，目前还没有成熟的解决办法。
为了实现这一目标，对企业内所有的员工——既包括IT部门员工，也包括其他部门的员工，都需要转变对业务流程的固有看法。这需要相关的职能部门为了长远的目标而放弃眼前的利益，也要求IT系统设计师及开发人员从服务的角度来考虑系统的构成，同时，他们可能会放弃某些环节的控制权，如版本控制等。整个SOA系统可能要涉及变更管理、技术管理、风险管理以及日常业务管理等多个已有的业务系统。
实施SOA存在风险，但我们也不可能因为存在风险就因噎废食。对于SOA项目的实施，专家提出的建议是，用户不能一次实现所有的功能，不能一口吃个胖子。在SOA项目中将风险最小化的一个方法，是先将一些小的或有利于业务的流程使用SOA模式，构建相应的服务模块。这样可以让员工先适应这种新的服务模块。不至于使整个公司因为引入了新的IT系统而陷入混乱。
记者手记
SOA应用 70度
当改革大潮轰轰烈烈而来时，我们要做的是隔岸观火还是顺势而动？
看现在这架势，好像隔岸观火者并不能完全袖手旁观。因为各大厂商实在是在用各种各样的武器—媒体报道、学术会议等等各种手段讲述SOA的好处。弄得好像谁要是不上SOA，就被社会抛弃了一样。
其实，任何一个新事物给社会带来的变化可能都是颠覆性的。但是，这并不代表它一面世就会有如此惊人的效果。早在上个世纪80年代，互联网就已经诞生，但其真正普及却在十年之后，其所带来的翻天覆地的变化也在很多年后才凸现出来。
SOA也是如此。SOA为我们描述了如此动人的场景，以至于让每个从事信息化的人都热血沸腾，但它什么时候才能真正普及，谁也说不清楚。很多厂商为我们提供了各种各样的方案，他们说，只要按照他们的指引，就能实现那些梦想。于是，很多跃跃欲试的用户开始摩拳擦掌，他们纷纷在一些关键或者非关键的旧业务系统改造、新业务系统初建的过程中，开始了SOA之旅。他们中的一些人有了收获，一些人有了经验，他们发现，SOA仅仅是个长期过程的代名词，阶段性成果并不那么遥不可及。
于是，SOA终于有能力进入实质性的高温阶段，用户的应用热情也逐渐高涨起来。要说现在的温度，100度不够，70度刚刚好。