主题：SOA实践经验谈
时间：2009年7月29日（下午）
地点：赛迪大厦17层新知堂
嘉宾：中国石油化工有限公司信息系统管理部副总工程师 吴正宏；某政府部门高级技术架构师 王翔；首都之窗运行管理中心技术总监 王喆；中国气象局国家气相信息中心副总工程师沈文海；中国农行银行总行软件开发中心技术架构师 丘永萍；IBM Websphere大中国区产品经理 吴启新。
主持人：大家下午好，三人行必有我师，我们这个栏目取名叫CIO三人行，我是中国信息主管网的记者张静，今天非常欢迎大家下午来参加我们SOA实践经验谈的小型的圆桌沙龙活动。在上个月我们搞过连续三期的Web 2.0访谈，当时也是请了一些信息主管讨论大家的需求和想法，当时给我印象比较深的是商品折扣的信息主管叫吴晓鑫，他就讲多数的情况下业务部门本身并不了解自己的需求，或者他认为他们需求并不是真的需求。他举了一个例子，如果一个人驾着一辆马车他就会考虑我这个鞭子不好用我要换一个鞭子，但是他并没有看到本质上也许他需要的是一辆汽车，而不是继续在这辆马车上进行更新。可能更多的时候SOA能解决我们业务上的需求问题。今天我们请到在座的现在目前是四位嘉宾。
我给大家介绍一下，这位是中国石油化工有限公司信息系统管理部副总工程师吴正宏老师；中国气象局国家气相信息中心副总工程师沈文海先生；首都之窗运行管理中心技术总监王喆；中华人民共和国某政府部门高级技术架构师王翔；缺席的是农行的一位同志，这位是IBMWebsphere大中国区的产品经理吴启新。大家今天过来，咱们是各个行业的一些IT信息主管的经营都汇集到这儿，我们也非常感谢大家一直对我们信息主管网的支持。我们搞这样的沙龙活动也是通过这样比较轻松的交流环境，打破行业之间的壁垒，搭建一个交流平台。
今天讨论的是SOA实践的问题，其实今年1月份的时候，大家在互联网上可能也关注到了曾经有一位国外的分析师就讲过《SOA已死》这样的一篇博文，在业内引起了一场轩然大波，他认为SOA下一步会被类似于BPM或者云计算这一类的基于网络的服务的架构方式所替代，但是他尽管说SOA已死，但是他也想这只是面向服务的架构比以前更加迫切，只是用另一种方式进行表现。事实上我们也是想了解到到现在SOA概念出现到今天已经有好几年的力士乐，在这个过程中到底用户实践的情况怎么样，在7月份的时候我们上线了一个专区叫SOA实践方案征集令，建设这个专区的时候我们也对一些SOA做了大量的调研，我就发现像南京油运公司的就讲他们之前有很多旧的系统需要改造，SOA的理念他们从2005年开始运用SOA建的企业应用集成系统的项目，SOA对他们有很大的帮助，但是相反中国医药集团的CEO就明确的告诉我们说我们现在用ERP做运行和管理已经足够了，我们没必要再用SOA。我们觉得有很多问题现在需要了解，一方面是国内SOA的现状到底怎么样，另一方面，在我们实践的应用中，我们是否对SOA有很明确的需求。我们今天把大家召集过来讨论一下。首先我们想请IBMWebsphere的产品经理吴启新先生为这个沙龙，我们特意请他为我们做了一个国内SOA的实验报告。请他抛砖引玉，先给大家介绍一下这方面的情况。
吴启新：各位老师，各位同行，大家下午好。非常感谢组织者的很好的安排，我这算不上一个报告，只是我们看到的一些情况跟大家分享。2009年下半年SOA确实应该方方面面的人坐在一起谈一下它现在具体的状况。SOA在中国我们已经大致的热烈宣传推广和普及了至少三年以上的时间。在这三年的时间之内，我们分为前后两半段。从我个人的角度来说，作为一个IBM厂商的角度来说我们看到分为前后两半段。前面一段是普及SOA的概念，因为SOA我们大家都已经很熟悉了，它不是一个产品，不是一个非常专业的用于某一种客户需求的解决方案，它不专门，它是非常普及型的，各个厂商共同参与的构架的理念，实际上SOA的诞生是为的应运整合而生的，原来的我们系统都是为专门的客户需求，为专门的客户应用缔造的。像ERP也好，那些都是专门的。如果已经有很好的ERP应用，并且没有互联系统，还有必要做SOA吗？短暂来看，就这个时点来看确实没有太大的必要。但是我们前一段时间为什么要普及SOA，因为应用整合为什么多，大家以自己的企业为核心，以自己的技术为核心，你是想整合别人，你做好了应用谁来整合你？我们说大家不要各做各的，我们讨论一个共同的框架，共同的理念，不一定是一个共同的协议，但是我们一定遵守一个共同的规范，构架一个跨平台，跨语言，跨厂商的构架方式。
为什么我们花了这么长时间普及SOA，就是原来我们所有应用程序的产品，产品的产品都是为了解决专门的需求，而SOA有一个特别的特点，就是我解决所有的需求，为什么要花很长时间介绍SOA还有一个原因，做一个SOA的项目跟做一个专门的谋划某个客户的项目而言要花更长的时间，更大的精力和更多人员的投入。原来我们做应用有什么需求摆出来大家做就可以了，系统规划就可以了，现在SOA等于我们一定要把所有的原来满足应用而写的应用程序都一定力度上细化成服务，再重新编排。真正的SOA的益处在后期。也就是随着你的应用越来越复杂，互联的需求越来越多，它的高效，节约时间，节约成本在后期才能体现。真正在一个SOA项目前期其实我们都看得到花得精力和人工要比原来多得多。让客户接受这些理念是要花很长时间的，所以，整个SOA推广中前半期都是在做客户教育。真正的从2008年下半年这个情况发生了变化，SOA被大家，可能被在座的很多单位都已经接受了，因为你不用SOA，你的竞争伙伴也好，你的合作厂商群也好，他们已经用SOA，你们之间互相的信息交流就会有瓶颈，它是Websphere，你还没做好，你没法交流。所以，很多客户得有一种迫切感，觉得大势所趋，我要上。
在这种情况下我们很自然的从SOA的客户培育和市场培育阶段过渡到落地和实践的阶段，这个实践应该在2008年下半年开始，销售业绩从2008下半年跟SOA相关的销售业绩一下增长得非常快。所以，我觉得后半段我们是在针对这张图说明。我们分了四个层面，下面是原有的客户的应用，我们说是一种孤立的客户应用，各个部门的应用，满足客户需求的，都是互相没有沟通的。原来就是把它互相连接起来，等于AB之间加个C，C什么也不干，就是做个格式转换，协议转换。而我们现在是先不作转换，不作交集，不做整合，先进行一个封装，把它都变成一个一个服务，这个时候先不说最后形成什么样的，我们先把原有的孤立的应用，一种架构，一种协议的应用变成服务的一个一个的（英文），这就是服务化的过程。到了第三个阶段，把这些已经封装好的服务进行编排串联和重新组合，来真正的形成客户的应用，客户的工作流。当然我们也知道客户界面，来把这种后台的应用逻辑、商业逻辑展现出来。
这张图从2008年下半年已经深入人心，在我们很多招标的过程中各位比我有更多的发言权，我们系统架构过程中我们都是针对这张图做系统架构设计，所以，从那时候到了下半阶段真正实践和实施了。刚才说SOA已死我觉得也对，就IBM而言，原来我们凡会必讲SOA，但是我们现在单纯讲SOA这三个字的会议内容文章越来越少，为什么？大家都知道我们何必要说呢？我们说的更多的是EPM，ESP。所以，其实我个人的感觉现在SOA的落地，从我掌管的产品部门来说应该分为这么几个层面，真正的落地一步一步的，应该这么一个先后的次序。
第一个所谓的ESB，构造一个做系统整合的服务的架构，ESB也是一个逐渐深入人心的过程，现在再讲ESB客户都说这就是一个规范，我就是要通过ESB做物流，做协议转换，做格式转换，做消息的处理和转发，已经形成规范了。我个人感觉ESB跟原来的ENI最大的区别，ENI是一个厂商一个路数。如果有一点做得不够好就在于（英文），现在ESB是所有厂商都遵从一个规范，大家把所有信息都封装好以后放在一个Bar上，我们都是开放的。这就充分表明了一个根据的精髓，就是开放式。
所以，一个要做ESB的第一步，我觉得首先先要把原来的应用封装成服务之后形成一个胡同互联，这种数据级的互通互联的平台是什么？就是ESB。讲落地的第一步，我们叫入门的第一步就是先搭建企业内部的ESB进行数据的互通。数据互通了我们做什么？流程的编排，从我个人的感觉和接触的一些案例来说，所谓流程的编排体现了SOA的精髓所在，因为一个Servise最大的好处第一点它的可重用性。第二个好处就是它的易变性，今天ABCD形成一个工作流，明天BCDA，非常快的发生变化，每一个封装好的具有一定颗粒度的Servise又不用被打破。所以，这种情况下前面构建好的通路上炒什么？炒的是工作流。在这一点上，现在客户的落地有很多企业已经到了这个阶段，购买什么产品呢？就是业务流程管理。
很多人说BPM是什么？就是一个（Workflow）的引擎，我们认为不是这样。我们分成大约五个步骤和五个产品，第一个步骤是建模，这一点是我们觉得最重要的。离真正的实施部署，其实建模的过程更关键，他完全不是IT人员，他是由业务人员用图形化的方法把日常的工作模型化，而所有的Servise的精髓就是什么呢？就是你的封装。怎么封装Servise，力度多大，在哪一步决定。不是在部署那一步，是在建模。这一步非常非常重要，在SOA实施得不太成功的不好的案例里，我们觉得太重部署，不重建模的过程。反复的在这个地方花了大量的精力，不行再来，而没有早期把业务人员引入进来，由业务人员的视角，业务人员的出发点进行服务的划分。我觉得这一点特别特别重要。
下面模型建设了，这步跟IT是无关的，它就是用画流程图的方法把你的模型建立好，我们会通过一个内置的引擎转到我们下一个工具，这个工具做编排，你的一个一个服务都已经建立好了，谁先谁后，由谁到谁，谁成功之后怎么样，不成功之后又怎么样，真正到了流程的编排这一步一定要有一个非常强有力的图形化的工具能把它承载起来，这两步都是工具，其实Websphere的强项还不在这儿，做流程管理和软件开发的，模型编排好了，真正要让它变成一个JAVA的应用程序真正能转起来，一个部署的（BP）的业务流程引擎，就像G—E的服务器一样，只是增加了更多的应用和更多的对象，变的更丰富了，它可以把以前建好的模型，工作流完成自动化部署，真正跑起来的程序，它是一个运行的程序。第三步部署阶段。
再下一步是什么？在这一步里很多的厂商其实没投入太多的精力，我前面能改，改完又能部署，就够了。很多的我们的客户在留预算的时候，在监控这个环节留的预算不太大，这个时候其实会发生一个问题，因为SOA的项目跟原来的项目真的不太一样，因为它有很多的独立的子节连产生，如果一个流程的性能不好，你很难说它到底错在其中的哪一步，或者哪一步是性能的瓶颈你看不出来，尤其是一个流程。当你成千上万个流程，成百上千的服务一起运作的时候，谁来帮你找到瓶颈所在，问题的根源所在非常关键。而且找出了以后他还要用智能化的方法帮你提供一个改进的意见，我们有一个监控的环节。
第四步大家慢慢把精力开始往这儿放，从我直接的数据来看，这个产品上我们的销售业绩从2009年上半年开始突飞猛进，这四步构成大多数的SOA的项目，BPM的项目都已经构成了，但是还有一步也是2009年上半年出来的衍生品，就是对服务的管理。就好象当年我们用DOS，我能监控文件的数量可能以千或者以万为单位，到Windows就是以百万。一个SOA的项目里，S太多了，Servise太多了，怎么查找一个服务，怎么发布一个服务，怎么对服务进行版本控制，这些都要有专门的应用来解决。原来我们很多合作伙伴开发能力非常非常强，他自己做网页，后来他发现当他的服务太多，尤其产生版本控制的问题下，他自己编写的东西可能会不够用。这个时候我们就会有一类工具产生，就叫服务的管理，服务的注册或者服务的质量。干嘛用？非常简单，寻找一个服务，有没有人已经做好了。发布一个服务，我做好了让大家都知道，就是一个服务版本的控制。
所以，这五步我认为是SOA落地的第二个阶段的一个完整的过程。分别是建模、编排、部署、管理和治理。有关产品的介绍我们不在这里讲了。如果感兴趣我们再单独讨论。这是我跟大家分享的内容，抛砖引玉，希望得到大家的指正。
主持人：谢谢吴启新先生精彩的报告。在座的各位有没有对吴经理的报告有什么问题？
王翔：SOA需要业务监控我感触很深，做一些项目，做完以后发现项目上线反而不可控了，当我把各个系统之间的交互连接在一起的时候，这里面更容易出现问题。我们最后反过来找原因，为什么？发现我们之前在熟悉SOA的时候把它想成一个后端的问题，但其实它是一个全程的，甚至我们一个想法客户端不仅仅是你服务的一个消费者，你客户端可能本身就是一个服务的提供者，我们从客户端能直接拿到用户在一线时的一些因素。这样我们将我们系统的监控从后端各个服务点一直到我们客户端，把这个做圆了之后再去看我们做完，不一定是一个完整的SOA的项目，可能只是SOA实施的一个点都能真正从业务角度了解我们上了这个获得的收益，我们用户用了这些东西是不是能把以前需要多个屏幕看到的东西在一个屏幕上看到，他是否能在做一线的同时把风险控制的东西比较好的呈现出来。
王喆：我们可能属于起步比较早，但是现在效果并不是很明显，今天主要想跟各位老师学习一下，看看怎么把SOA的东西能够更好的实施下去。我大概是在2004年底的时候发现SOA的概念，当时觉得这个概念正好是我很长时间以来正在追寻的一个都是。大家了解政府里的异构根本不是你在技术上比较成熟的一些产品能够解决得掉了，因为政府协调很困难。当你的手段不够先进或者你的东西不够安全或者不够简易的时候就会受到各种各样的阻挠造成你实施的失败，所以，SOA这个理念一出来的时候，我的直观感觉觉得这个东西对于我可能是一个非常全新的思路。所以，2004年底鼓动我们领导，我们上级单位原来是信息办，我们开始考虑引入SOA。当时初步了解了之后，主体考虑找一些产品，怎么能够实现SOA。当时也是考虑首都之窗内部先实施，先不整合其他的公安局啊，如果整合可能比较难，我们本身当时有60多个大大小小的应用，也是很多年以来很多个开发公司积累下来的，其中编码的方式方法，包括规则也都不太一致，有一些异构的联动。
当时，我就考虑有没有可能尝试性的做一个SOA的小规模的试用，当时正好碰到一个机会，因为北京市监察局要做一个政风行风热线的系统，它其实就是一个在线的网络投诉举报的平台。你投诉举报以后政府部门会给你做相应的回复。其实本身需求并不复杂，但是我们一开始相当于是没有用，我们一开始的时候是用传统的方式下做了一个版本，但是效果不是很理想。做改造的时候提到SOA的概念，其实现在回想起来，当时所做的一些步骤跟刚才吴老师讲的理念还是比较吻合的，只是我们没有从理论的角度把它总结到这么高的一个层面。当时我们也考虑一期的失败最大的原因需求分析第一是不够细，第二需求和技术之间的转换出现问题。需求人员和技术人员总是在一些大家觉得很基础的，应该说概念或者理念上产生非常大的差异，其实刚才王老师也谈到这个问题，经常会出现需求的人员说我已经跟你说明了我就要什么东西，但是我做完以后他说你做的这个不是我要的，我跟你说得很清楚，但是你做的这个不对。我们下狠心这个东西一定要好好的做一遍，当时对SOA还不是特别理解。
所以，找了一大堆国内的各种专家，包括IBM，包括其他公司很多专家，包括清华的一些教授，过来大家研讨一下。研讨完了之后大家说一上来需要一个专业的咨询团队给你做咨询，你的业务人员要深入到需求分析里，不能上来技术人员做需求分析，而且你必须有工具。当时还没有IBM的解决方案，我们到处找一个东西，因为（ROS）虽然开发人员在用，但是对做内容的人来说过于深奥了，你给他讲这个图那个图他就听晕了，根本没办法做沟通。（VC）展现力和描述性还比较差，当时也是一个比较巧合的机会，我们发现英国有一家公司出了一个绩效考核的软件，他那个软件本来是挂在你一个公司的ERP或者OA上，通过跟你ORP或者OA上，上面已经内置了一系列绩效考核的体系，通过把你OA的数据提交出来运算就可以告诉你你这个公司绩效不好是因为什么原因，是你进货出货有问题或是什么有问题。我们发现这个软件做流程图的功能特别有趣，为什么特别有趣呢？它不是一个平面流程图，它的流程图是一种立体的可不断递进的流程图，比如我上面画一个开始的处理，结束，点处理又出来一个流程图，出来这个流程图我可以第一支，第二支，可以不断的往两添，每一个节点可以连数据库，可以挂附件，可以做好多好多东西。我们把需求做完没有形成一个Wrod文档，而形成一套流程图，看上去是60多个流程，但是每个节点都有（披路），有辅路，有链接，有说明文档。
这个工作做完以后我们又到处开始作模SOA一开始不知道怎么做出来，大家说有些相关的工具。有一个机会碰到，因为政府有一些特殊的需求，比如你是国产什么之类的，当时碰到上海普源推广他的东西，当时碰到他这个东西以后，虽然我跟他聊了之后我觉得不是像我想象得那么理想，我觉得他所谓的构架，所谓的SOA，第一个，可能对SOA标准化的支持并不是像我想象得那么负责，再一个力度太细，都是底层构建，没有业务构建。但是发展方向跟我的思路还是一致的，而且他那里面包括BPM都是在里面内置的，这样的话我们跟它合作，又找了中科软，找了几家CSSM的公司。它直接把我们做的流程用它的流程图的工具一模一样的照搬上去，开发只用了一个半用。开发完了以后发现40多个问题，半天的时间就处理完了，这个系统2006年上线的，到现在为止三年多了，基本上没有做过任何大的变动，也没有出现任何问题。它的稳定性很强，而且当时一个主系统整合了七个相关的系统，包括视频，包括BBS，包括其他的一些，都是不同的厂家生产的东西，当然都做了SOA改造。
当时考察了，感觉还是IBMWebsphere稳定性比较好一些，所以，部署用的Websphere。当时也是考虑到监控，感觉（英文）对这个东西监控的力度没有我们想象得那么细，而且我们系统有异构，我的几个主平台还有用其他的东西，很多跨界的问题我们找不到了，又到处找，找了半天，这个公司还没有被CA收购，WLY这么一个软件，他就是运行时监控的软件，把这个软件挂上去以后，本来开发的时候发现一点问题没有了，但是过了20天突然宕机，这种情况在以往是没办法发现的。因为用了之后，后来没再追踪，我估计IBM可能也不断的会发展，现在可能功能更强了。但是我们发现第一点我们知道类似于这些东西，它可以事先给我发现出来，它可以精确到给你指出是哪一行代码，不会告诉你哪一段程序，直接告诉你哪一句代码有问题，而且告诉你应该改成什么样更，当时我整合了七个系统，它会很容易指出来到底哪一个厂家的产品出问题了，这对我们找问题确实起到了很大的作用。
因为我们的服务比较少，就六七个，所以，自己做服务的管理，确实没有像吴老师讲的治理的层面。但是我觉得刚才吴老师讲的确实是豁然开朗的感觉。当时碰到很多问题，一路这么做下来，但是确实像吴老师刚才讲的，根据更清晰了，这样可能以后做一些相关的工作会比较清楚一点。包括2006年的时候ESP，当然当时ESP的人也不太多，现在挂了四五年，五六年了，现在确实都有所发展，包括IBM这块，都是出一些新的东西，我们下一步可能会逐渐的再了解一下新的动向。吴老师说的跟我们很相似，有感而发。但是我们规模比较小，现在已经过了三年多了，能整合的部分还是很少，问题比较多。所以，也希望听听其他的老师的经验。
主持人：首都之窗在政府网站还是做得比较好的，SOA应用也还不错。刚才王喆总监跟咱们分享了一下首都之窗的SOA的时间过程，王翔老师可能从他个人谈了一些他对SOA的理解和看法。我们今天主要想围绕三方面来谈一谈SOA实践。首先是刚才这两位嘉宾谈到的关于异构和整合方面的。我们在不同的行业可能面临的异构应用整合这方面的问题情况也不太相同。所以，我们也希望借鉴更多的嘉宾的经验。我不知道吴正宏老师这边，因为中石油我知道，中石油本身是一个非常庞大的企业，它下属有很多个分公司，有集团和下属企业之间，还有部门之间的应用，包括系统整合，可能也有自己的特点，我不知道吴老师能不能谈一谈你们的经验？
吴正宏：经验谈不上。SOA我们跟踪得时间很长，跟IBM有很多的合作。我们从石化来讲面临一个系统，规模很大，很复杂，显得变化很多，从这几个条件来讲适合用SOA。你不是一个大型的企业，不是一个复杂的系统不要上SOA，显不出优势来。一个很小的系统很稳定，结构很简单，你上SOA干什么？一共就三个系统，直接一连就完了。集团的机动化管理造成你必然是一个很复杂的结构，股份公司下面八九十家单位，有油田、炼化企业、科研单位、工程建设单位，分布在全国各地，甚至分布在海外，事业部直接管这些企业，还有企业、财务、人事、IT、审计，各个部门，交叉的一个巨人，很复杂，非常复杂。正因为它太复杂，太大，所以，做事这种大企业很小心，我们自己搞IT的，做每一件事都是如履薄冰，生怕一件事没想全出自己想不到的后果，给我们企业带来意料不到的。因为像中石化这样的企业，它不仅仅承担经济的责任，更重要是给国家创造多少价值，交多少利润，还有政治责任和社会责任。三天买不到油大家很难受，老百姓就上街了，政府出面干预了。
李××到中石化检查工作也提到这个中石化承担着社会责任。所以，我们相对比较小心。SOA像中石化这样一个很大很复杂的系统怎么能够充分发挥它IT的作用。你建一大堆系统，如果不能有效的把它整合起来，你的效力很低的，你应用系统连不上，系统虽然建起来了，但是效果可能并不见得好。所以，有一些负面的。所以，必须整合，从上到下都需要整合，包括董事长、总经理经常问我信息规划，系统是不是又信息孤岛，经常问到这个，他们提出这样的要求。所以，我们很早就关注这方面，当时讲了EAR，从这个世纪初我们就开始关于EAR，也做了一些实验工作，但是也没有大规模的推。在讲的时候大家都讲的非常好，都跟我们讲了都有很好的产品，国内国外的都有很好的应用案例。但是我们觉得对于我们这么大的一个系统，我们对它理解不够的时候，我们感兴趣。
后来从EAR发展到SOA，我们从IBM和其他的厂商和咨询公司沟通，相对比较小的项目做一些实验性的工作。我们内部和外部两方面的原因。内部的原因来讲，我们搞IT的人来讲，我们对SOA的理解没有足够的经验，没有十足的把握做这件事。刚才也讲了，他们做的过程中经过很长的摸索，积累了经验。我们觉得我们这方面没有很大的把握。因为我们觉得SOA给我们带来的思路和理念上的变化是全新的，你比如说以前我们搞规划，搞设计的时候讲什么？向下设计，向上实施，这是一开始搞软件工程讲的一套，我估计大家在学校学的时候老师都给大家讲这个。这么做对不对呢？对。但是我们做的时候这个方法有很多毛病，你这么大的系统从下往上规划规划几年？少的一个企业规划几个月，大家经常规划一两年，你规划完以后很多业务都变了。计划经济到市场经济变革的过程中我们企业自己的管理也是在变化的，不断的跟国际接轨。这样的话这种方法显然是不行的，但是你又不能做得不行。所以，我们我们也总结出规划要宜粗不宜细，否则的化你花了两三年的时间搞规划最后没法用。
SOA我们觉得做规划的思路可以发生变化，因为我们现在规划的不是整个体系最后是什么样，而是我规划的是将来我的各种服务怎么给它接在一起，当一个服务发生变化的时候怎么让它对其他的服务影响最小，这是SOA的长处。我不用从上到下一步一步规划得很细，就像一个网卡插一个网卡，两个网卡插两个网卡，把服务一个一个往上插就可以。最后我们理解，我们能不能很好的去理解。我们以前我在一个财务系统，他在人事系统，我们去交换，做ESB的时候我怎么去做呢？我在什么范围做呢？比如中石化这样的企业，特别炼化企业，它的生产网络、管理网络需要互相隔离，你敢不敢把生产系统和管理系统做在一个ESB上呢？没有一个厂商说可以做。你不可以做。为什么？炼化企业的生产是时时的，是易燃易爆的，弄不好会出问题，会发生爆炸的，你敢跟你的管理系统放在一起吗？但是有很多数据的交换，管理系统的信息你的数据是从生产系统输过来的，你搁在一起不搁在一起呢？中石化的体系机构我们是一个四层的结构，上面才是供应链管理这种，最上面还有企业监控，谁跟谁能放在一起，谁跟谁不能放在一起。
ESB本身我们怎么规划，我们看总的我们的历程，绕了一个大弯的历程，这个弯又是非绕不可的，一开始跟着应用，财富系统要上了，有20个人，20个岗位，可能要上十几台微机，给它拉一台销网先连起来，不行，一个企业上一个网，最后也不行，那就在一个企业集团里一个多层次的分层汇聚的网络，而且网络的建设和应用的建设是逐步分离的，我不是说因为有这个应用才建这个网络，是因为有这个企业要建这个网络。我需要一些什么路径建设它呢？要不要走这个弯还是一步到位，一个企业集团一个企业集团建设呢？这都是我们存在的问题。没有一个人或者没有一个企业能给我们一个完整的答案，这需要我们自己去理解，需要我们自己去摸索。内容我们现在不敢大动，因为我们没吃透。
我说的还有外因，外因有两方面。一方面我的技术手段，刚才讲的IBM一开始做推广跟我们讲你要做一个可以，要拿这个工具，那个工具。根据我们的了解，相应的产品没有跟上，介绍的时候我们也看到讲了平台，它的开发的平台，运行的平台，监控的平台是不是都具备了，包括它的效率，它的稳定性是不是可信的。IBM我觉得这点好，适合卖给你卖给你，不适合可以给你讲，跟你沟通，等你合适了卖给你，这是大企业风范。所以，IBM也没有说你赶快上。我们觉得这个是在逐渐的完善过程中，我们希望能在它比较完善，比较成熟的时候应用。
还有中石化我们做的时候自己开发的软件和外购的软件关系上我们是能买到尽量买，虽然我们有七百人开发搞软件搞硬件，有很强的开发能力，但是我们能买到尽量买。这样就存在一个问题。我买的这些产品是不是按照SOA的要求去做，它接得上去接不上去。我们后来看到他们自己内部的结构是往这个方向演化的，像SAT他们都像这个方向演化，有的厂商做内部软件，把它自己的用户分装成很多模块，相当于很多服务，然后他对外有另外一套软件，然后它的门户，它用Web做它的访问界面，但是它并没有形成标准。当时很多厂商跟我们介绍的时候，EAR一个问题是没有标准，有标准，大家各自的标准。所以，在应用方面不能指望所有的应用都让我拿一个开发工具去做，我要能买到。在外部条件上，在平台上和应用上，这里面标准非常关键。包括你IT技术标准，也包括你的业务标准。你比如说我们很重视有一个（SO1664），一个制造企业业务划分成几个域，这些域之间数据流是怎么样的。国内大家对它重视度不够，但是像GE也好，在国外宣传的时候都讲我的产品是符合，在国内不太讲。为什么？符合264，接得起来。一般的来说这个东西你横着切，我竖着切，你切成三角，我切成方块怎么整合？肯定有接不上的，肯定有重合的。所以，业务标准也非常重要。
再有就是刚才提到的数据标准，无论你多灵活，如果你的数据标准不统一，做很多转换，有的转换能做，有的转换不能做，对你的平台要求非常高，你平台的运行效率，你平台的安全性等等都要解决。这方面我们非常关注标准。这样我才可能在对它理解的基础上在比较大的范围实现。我们希望要稳妥的实施路径。因为什么呢？大家讲这是搞整合的，其实一个企业像中石化这样的企业在发展的过程中，它是在一个快速发展阶段，还没有到成熟阶段。咱们在第二阶段第三阶段，人家可能已经到了第五阶段，第六阶段的，我们是在变化，我们有新建的，也有原来继承下来，希望整合进来的。我们怎么兼顾这两方面的关系，这都是很有挑战性的问题。这对我们的能力提出了挑战，特别对我们的规划设计能力提出很严峻的挑战。
上次那个人需求用户说不清，其实需求说不清我理解是IT环境下的业务应该是什么样的，这个用户说不清。我是赶马车的，我不知道有汽车，我需要什么样的汽车我说不清，我只有知道这个汽车怎么回事，也知道马车怎么回事，马车干什么，汽车干什么，才知道买什么样的汽车，是买个小卡车，还是买个大卡车。我们IT人员要对业务有深刻的理解，对IT发展有深刻的理解，同时我们业务人员对IT也有深刻的理解。这对我们提出了一些难题。只有这些难题逐渐得到一定程度的解决之后，我们才有把握做那么多事情。
主持人：吴老师讲得很深刻。首先他强调实质上咱们的业务需求是第一位的，至于很多的这种技术概念事实上最终的咱们的信息主管为了了解这个，重要的是和自己的业务结合起来。另外，技术的概念推广和产品真正的应用可能目前还有一个并不是同步的问题我们需要解决。还有比如标准的问题需要解决。这个话题如果咱们继续这样探讨可能会比较宽泛，咱们还是从具体的业务去谈。咱们导入第二个话题，咱们XML源在应用的时候是大量的网络应用基础性的，但是对于它本身来讲，可能对于服务器就是一个很大的考验，我想问问永萍这边，咱们农行有很多的线上线下的业务系统，包括服务器，或者现在的数据交换方面，农行现在有哪些经验可能跟大家谈一谈呢？
丘永萍：其实这个问题是我想提出来的。
主持人：你可以谈谈你的困惑，你的需求。今天咱们同行探讨一下。
丘永萍：刚才听了吴总工程师讲的比较有感触，我们也是这么一个情况，尤其是像一个IT的基础架构跟现在日益发展的业务需求中间怎么整合的问题。我们2007年的时候曾经尝试在一些项目中引入SOA，所以，你刚才讲的话题，因为我不是做系统的，我是做应用架构的，可能不是特别的经验，但是也看到一些问题。在项目的时候，刚才说到业务，我们当时的业务是国际卡收单系统，我们当时为什么考虑实施这个？是因为这个项目符合一些异构的特性，平台各方面也很多。做到一定程度我们发现很难实现下去。为什么呢？因为首先是传统的开发观念我们习惯性的，跟现在技术推导的话很困难。所以，XML我们实施到了一半最后还是在传统数据去做。现在我们做了一下工作，在测试DB29
吴启新：可以把XML直接存在数据库里。
丘永萍：现在我们在做这块的测试，我们也在做一些规划核心系统。刚才您说的这个问题我也很想听一下吴经理有没有好的建议。
吴启新：XML是这样的，不能单纯的讲XML结构或者数据文本，而要想我们到底怎么用它。一般来说在SOA里月到XML的方式主要是用到Web Servise。因为我们在实现异构整合的过程中，像刚才吴老师讲的，我们要遵循一个规范，怎么能够把我们自己编写的应用和SAP或者其他任何一个打包厂商的应用进行一个互联，原来根本不可能的。怎么来做呢？现在基本上业界推崇的规范在协议上和结构上主要是Web Servise。而Web Servise尊崇的最基本的结构就是XML。实际上这个技术并不复杂，但是我们具体实施的时候，XML如果是一个简单的几十行的报文的话还可以，如果你报文比较大，系统的承载能力会不行，我用XML做大报文处理的时候，做XML剪切的时候，CPU的瓶颈，内存的瓶颈马上就能出现，这是我们真正讲SOA实施过程中的一个实际问题。
一般的用户早期不会暴露，为什么？因为你用的量很小，对中国客户而言，实际上这个问题我们在国外两年就看到了，在中国主要是从去年下半年开始。什么样的客户居多呢？我们正在测试，比如中航信，它主要涉及各个航空公司之间，酒店机票代理等等之间要进行一个数据结构，怎么做到？这是我们现在看到的一个。航空公司是一大类。还有另外一大类比如像发改委。发改委采购了我们非常多的一个产品，他也做XML，但是他做的不是解决性的问题，解决S的加密。因为Web IBMWebsphere的提出是有问题的。我们一般的防火墙防的是网络层，当我能够认证Web S的IP地址是合法的，这个就没问题。但是里面是否有恶意攻击的代码，一般的防火墙是没法解析的，因为我细不到一定程度。我们怎么解决呢？性能的问题我们解决方法是这样的，好多年以前，最早有多媒体电脑的时候，我们希望在电脑上看到一些，但是那个时候基本上是奔腾，CPU到不了，第一买更强大的电脑，第二我们加一块硬的（M派克），等等。我用这张卡上的重要数据端，这样一下就解决了。我们对于XML采取了同样的方法，我们不再把XML解析这种负载引导到CPU做，我们单独有一个路由器做XML解析，我把所有XML解析的工作从主机上减掉，加到这个设备上。这个设备所有的功能负责露友、协议转换、格式转换和消息的处理。它最独特的地方它等于把一个ESP的产品固化到一个服务器上，它就是一个IP出口，它就做XML的解析，协议转换、格式转换。这是我们第一种解决方式。
第二种解决方式跟第一种非常类似的。比如我们收了一个Web IBMWebsphere，我打开看有没有恶意攻击的问题，有，退回去，没有，转到下一个。传统的为什么做不到？你打开一个XML要很长时间，我们现在的防火墙都是10兆，一百兆，或者上千T的，你打开一个S，看完以后再封上再传出去它的吞吐量时延是接受不了了。我们用硬件进行解析，硬件进行解读。IBM的规范就是我们用硬件解决传统厂商解决不了的问题，技术上没新花样，但是实施上专用的服务器专业干，这我们的竞争对手不太容易做到。我们的竞争厂商主要还是软件厂，它没有做硬件的能力。当然，以后可能有。类似这种方式，把软件固化到硬件的方式越来越多，在我们日常生活中非常多，苹果把一个硬件固化到一个小盒上就卖得非常非常好。到了企业应用的领域，我们也会越来越多的看到不再单是一个路由器这么简单，我们会把一个企业的应用固化。我们现在还把云计算的部署模式封装在一个硬件的盒子里，我们对不同的云不同的计算模式都放在里面。接上去我就可以，不用每次进行修改。
主持人：沈总，平时咱们数据的量肯定挺大的，存储大量的数据，你们在Web服务方面有什么经验或者什么需求？
沈文海：今天的主题是SOA，我个人讲SOA在过去来说它更像一个魂，它必须得附着到某个实体上它才能真正的活起来。关键它怎么附着，附着到哪个实体上，现在主要是这样一个问题。我个人理解，某个单位，比如像气象行业要想实施SOA的话，我个人觉得是一个相对比较漫长而又很痛苦的过程，因为前期是很难看得到效果出来的。气象行业可能跟我们在座的各个单位的行业不是特别一样，因为什么呢？气象行业的系统建设的资金来源和建设的项目来源是多渠道的，有相当一部分是依靠政府，发改委、财政部的投资，也就是大规模的项目建设，SOA咱们刚才说了，它只有到达一定规模之后才能发挥出效应，而规模一大了以后，这个国家对你资金的使用的进步就有了比较严格的要求。这样的话，可能你想在这个项目上SOA的话，由于你前期准备并不是很充分，各种各样的准备，再加上攻击上的要求和其他方面的原因使得你想上，但是上不了，或者上不好，这也就是气象行业目前为止SOA这样一个概念还是作为一个魂在气象局上空飘荡，但是还没有真正的落到某一个具体项目中的主要原因。
主持人：时间关系，咱们谈谈第三方面。王翔老师和沈总都是政府行业的，对信息安全的要求会更高一些，涉及到一些行业机密，王翔老师是我们2008第二届数据库工程师的总冠军，我觉得他肯定很想想法，在信息安全，Web安全这方面您有哪些想法，您作为政府行业的代表，这方面有哪些需求？
王翔：我把这两个问题一起谈，这两个问题是互补的。一方面我们有一些技术，包括公司的技术。另外，我们捆绑了一个硬指标的要求。涉及到信息安全的采购都有要求，包括草案和非草案。在交换报文数据的时候，我们需要根据书局的性格有很多选择。第一种，比如我们针对国内的或者我们海外这些机构（）+存储的方式，我们一些专用的厂商。第二个，我相信对一些比较大的软件行业来说都有自己的中心，它进行安全计算的过程中并不使用软件+（），其实也使用硬件的加密机。所以，如果涉及到一些应用的东西，这个方案其实和IBM的Websphere非常类似。有些方面有特殊要求，我们这种部分主要是使用专用加密机+安全固件来做的。通道加密存储。SOA环境如果对外要进行一种服务的话可能有几种方式，如果直接服务的是终端用户的话，可能在终端用户这一端我们有一些特殊的要求，比如它有一些专用的设备，尤其是当你这个网络不是在内部，在日本、美国这些地区的话，终端用户使用我们国产自己的特殊算法加安全固件是一个比较好的算法。但是如果他在国内做机构之间的交换的话，自己国家通过建立相关的通道，隔出很多隔离区域。我们泵不是有很多量说我去消灭攻击者，我们先把自己保护起来。保护的办法用自己的一些东西来保护。
SOA建立之后，它有一个安全管理中心的概念，对于安全的监控我们有一个专门的划分，攻击采用我们什么常规的服务器监控，我们怎么发挥的呢？来自于安全监控设备和安全软件，我们认为这是面向安全自己的，它是交由安全管理中心有统一的安全策略，可能是中心节点到各级网络都可能做，有这么一个安全中心的职责来负责。而且这里面非常重要的一点恶意攻击的操作非常多，内网，外网，内网里不同的域，域里不同的功能域之间的，管理中心对资源的控制。有了域的隔离，有了通道的保护，专业安全加密机，安全固件的三重保护。这是我们现在的一个做法。必须在一个整体监控的环境下来做。
主持人：其他嘉宾还有什么想法，对安全这块？
吴启新：在这一点IBM的想法主要是这样，他刚才说的非常好，安全领域我们有非常多的评估系统，传统的IBM不是做安全的公司。但是现在我们产品的定位是什么呢？我们希望能够把ESP和安全做起来，这是我们希望的一个方式。传统方式大家要采用ESP，软环境的ESP好处在于规范，缺点在于效率差。我们所谓的一件事情如果什么都能兼容，它的性能一定差。比如两个人之间讲话，我们之间一定要通过翻译，我们通过一个万能语的翻译互相可以讲话，但是翻译的过程是需要时间的。所以，ESP功能很大的一个问题是效率差，所以，我们通过硬件来解决.
比如安全的问题，传统的ESP是没有安全的范畴的，因为我们认为一个ESP两端的互联会在同等级的安全域里，一般来说是这样，但是我们现在考虑的是我们在ESP第一固化，第二我们把安全认证也加到这里面。
王喆：因为看到这三个问题，我觉得也是有针对性的。就像吴老师讲的，刚才王老师没说之前我也想说，政府比较图书，它要求必须是加密的，安全可能在底层解决掉了，但是并不否定IBM做这个工作或者实用性。因为首先对于我们来讲，领导总讲的一句话，安全我们怎么做都不过分，你加了一层不保险，加十层，十层不保险加一百层，只要不出事。因为去年奥运的时候，首都之窗网站习近平提，一群人批，奥运网站和首都之窗一定要确保万无一失，所以，去年光设备就上了两千万。你想得到的安全设施就上。
这两个问题提出来之后，我觉得IBM像吴老师讲它的设备最大的用途或者最大的出发点不是说从安全的角度，还是效能上。因为大家都知道，SOA通过SSM做Web IBMWebsphere的时候，最核心的一点是协议造成性能上很差。当然对于我们这种小应用，七八个系统，数据量很少的情况下感觉不到，但是像沈老师或者丘老师特别大的数据量一旦通过这种简单协议传输的时候，一定会遇到非常严重的。如果我需要这种大数据量传输的时候，肯定会选择IBM专门解决方案去做。当然，它是不是更安全了，可能对于我来讲只是锦上添花的东西，反正我已经加密了，你再加一层密对于我也无所谓。真正的是它的效率，如果我使你这个设备，我的效率上不去影响我的业务。这个才是一个焦点。尤其对于政府领域来讲，其实你没有必要讲我加密解密更加安全了，它所做的安全层面的东西一定要比你想想得还要多得多。因为政府领导，包括首都之窗，领导说你停了，宕了，甚至关两三个小时都无所谓，但是不能封面出一个法轮功，这样所有的工作就都白做了。所以，安全是第一位的。
安全与应用产生冲突的时候，一定牺牲的是应用。上期讨论Web2.0，其实跟叶总之间都非常熟。2002年他做博客中国我一直帮他的忙，虽然这些东西都很熟，但是我就是用不上，就是因为他跟安全有冲突。对我们来讲，只要影响到安全，没有安全，一切都等等零。其他的领域如果安全做得不到位的时候，IBM的解决方案是一个很好的东西。安全做得很好的地方其实也无所谓，多加一腾安全也不影响。最关键的是解决效率问题，这是一个非常非常重要的东西。对SOA是很重要的，因为很多人上了SOA发现这个东西不但花了我很多钱，最后效率可能还下降了，这是很痛苦的一个事情。因为领导不清楚怎么回事，你给我吹嘘了半天，最后弄完了还不如原来了，这就挺麻烦了。我觉得它这个问题的核心还是性能上的优化比较强一些。
主持人：对。刚才听了吴老师介绍这个也是，它能把软件和硬件结合，这个等于在某些程度上简化了我们实际上需求的工作。
丘永萍：对于安全和应用来说，安全永远是第一位的。为什么我们在网银层面一直比较不敢大动，一直也是很小心翼翼的，我其实想问的问题跟这稍微有关，又不完全相关。自从2007年我们尝试SOA不是特别成功之后，我们后来已经不太愿意提SOA的概念了，因为我们更多的还是搭建传统的数据库，还是在C层面的。JAVA的应用也有。我们在架构的层面考虑安全方面也是考虑得很重要，所以，不太愿意动太多传统的，一般都会有一套比较成熟的架构去做。我的问题是这样，XML在传播过程中，我们觉得是不是不一定非得在SOA框架上采用，传统的架构行不行？这个层面碰到的问题就是跟数据库的兼容上。所以，我刚才问的其实是这个。不过也学习了很多内容。
吴启新：很简单。XML是一种标准的数据保存格式，最大的好处就是通用性，我可以把任何两不同的协议都转换成XML。讲到XML，其实我们非常坦率，跟SOA不是XML一定要用SOA的建构方式，但是反过来说SOA跟XML什么关系呢？因为我们会讲到SOA里使用到（SP）协议，（SP）协议的报文格式就是XML，就用到它的通用性。所以，完全不一定用SOA。我们现在已经能够做到把一个XML的格式不用转换成文本，直接把XML作为对象存到数据库里，我不用转成文本。
主持人：时间关系，今天我们一个半小时的小型的沙龙就到此结束了。非常感谢大家今天能够抽空参加我们SOA沙龙活动。今天大家谈的这些精彩观念，包括需求我们会后会给大家汇总一个文字的材料，在我们网站上开了一个关于SOA的实践公社，希望大家有时间加入我们的圈子，大家一起来聊聊，非常感谢大家。