|
主持人：好，各位嘉宾下午好！非常感谢每位光临现场的组织，也非常感谢我们的协办组织，还有我们的合作媒体IT专家网等等。对于普元公司，我想简单说几句，普元公司成立于2001年，到今年已经走了六年的历程，在这六年当中，有很多很多的合作伙伴和客户，伴随企业在成长，我们从开始的十来人到现在的两百多人。我们现在的业绩每年可以做到每年五千万以上的产值，我们的用户有超过200家，包括金融、电信、政府，各个行业都有我们的客户存在。而且每个客户使用了普元产品之后，也深刻体会到普元产品给他们带来的价值。
今天的会议，主题是SOA，这个会议当中我们分成三个部分，第一个部分我们将谈谈SOA发展的趋势，第二个我们谈谈SOA的技术，第三部分我们谈谈SOA的实践。就是我们如何让SOA这个全球公认的标准和技术，能够使用到企业的信息化的建设过程当中，使得我们的信息化建设能够更好的服务于我们的业务活动、市场、客户。今天大会我们有三个关键核心词，第一个就是SOA，第二个就是SOA中国路线图，这个是由ADC对中国的广大客户进行了深入调查以后统计出来的数据，它将给我们一种趋势和未来方向的评判，使客户对SOA发展趋势有一个清晰的了解。第三个是实践，让我们更清楚地了解到在实施SOA当中我们准备些什么？做些什么？如何去做？
我先介绍一下主讲嘉宾，首先是普元公司CTO黄柳青先生，第二位是计世资讯的资深的分析师曹宇杰先生，他将给我们介绍SOA在中国的趋势是什么，未来怎么去实现。第三个是普元软件市场总监王满红先生，他负责产品规划的设计和对客户的了解，让我们的产品更加贴近市场。还有一位是普元的技术服务总监袁义先生，他在IT行业有非常深厚的功底，他负责普元的大项目建设，负责团队的管理客户对袁义的评价也非常高。还有一位合作伙伴的嘉宾黄海强先生，他将介绍如何使用SOA的体会。接下来，首先我们有请计世资讯的曹宇杰先生跟大家分享中国SOA认知现状以及发展趋势。 |
曹宇杰：各位领导、各位嘉宾，各位来宾，大家下午好！我是计世资讯的分析师曹宇杰，非常高兴有机会跟大家分享，我今天讲的主题是中国SOA现状和发展趋势。其实我周围很多朋友在理解SOA当中中遇到很多阻碍，的确是一个不容易理解的概念。所以今天我并不想对SOA的定义或者概念做一个过多的阐述，但是为了帮助大家的理解，我后面会具一个小例子，做一一个比喻，帮助大家来理解SOA。我后面还有几个专家对SOA的理念、技术乃至应用做更深入的阐述。
我这里面讲的比喻就是，其实当我们在座的很多朋友小的时候肯定玩过积木，现在作为家长肯定会跟小朋友玩积木。这里面说的话，我们选择一组积木的时候，我们需要这组积木具有什么特点呢？首先要具有变化，搭建出不同的模型，这样才会有乐趣。第二个，我们需要很灵活的改变形状，很灵活地搭建出我们需要的图形，那么，同时呢，当我们去玩一个积木的时候，我们可能想创新出一些很新的东西，很新的模样，这个时候我们需要很低成本的，就是花很少的钱就可以作出不同的样子。还有些时候，我们可能需要积木很快的搭出我们想要的任何模样，它能搭得出来，而且很稳定。正是积木的这些特性，其实我们想一想，在我们企业当中构件IT系统的时候，我们同样需要这些特点。我们需要一些特定的规则，一个大家共用的规则，把企业的系统构成一组搭积木一样的系统，我们也要适应变化，也要低成本的进行灵活性的集成，正是为了满足这样一些特点，其实我们企业的IT系统在构件和集成的时候，我们同样积木原理。那么积木原理在这里，我们称之为SOA。那么我想，举了这样一个小的比喻，我希望这个比喻在我们理解SOA中更容易理解，实际上换了一个角度来理解SOA。接下来我通过三个方面来阐述一下目前我们所发现的，目前市场上从用户、渠道、厂商层面对SOA的认知，对SOA的未来发展是怎样看待的。
首先我们看用户的数据，两年前我们曾经对于中国市场的用户、对SOA的认知做了大规模的调研，当时我们得到的数据是这样的，2/3的用户没有听说过SOA，我不知道在座的朋友有多少在两年前知道SOA，但是2/3的人两年前没有听说过SOA。还有1/3听说过SOA，但是并不了解。可能听过一次、两次，听到SOA面向服务的架构，说第二句话说不出来了。当时很多用户处于这样的状态。
2007年我们又做了同样规模的变化，我们发现了解的人从14%上升到28%，也就是说，真正了解SOA的人两年时间增长一倍，这是非常快速的速度。另外我们发现50%的用户从两年前不了解、没有听说过SOA，到两年后的今天，便成了对SOA非常深入的关注。这个变化非常关注的，我们看到在右边的饼图里面，有超过2/3的人对SOA非常关注，所以SOA真正进入了大家的视线，成为大家谈论的话题，而且在系统运用当中，每一位企业的CRO都会考虑SOA对我的企业、我的IT系统是不是适用的，我是不是要真正的要考虑它在我的企业中能否进行应用。
我刚才谈了对于SOA的认知在两年之内形成这样快速变化的过程中，企业用户到底都是从哪些途径了解SOA的？我们做了分析，发现目前用户最主要的方式是互联网和厂商的推广、介绍。这里面我们看到互联网的这个途径所占的途径非常高，但是这里面我要强调的是按：厂商的这种推广。这个途径是现在很多人、很多企业用户包括媒体，去接受SOA、去了解SOA最主流的一种方式。为什么？因为SOA的理念、技术、产品现在还没有形成一个完全的成熟化，这个概念很新，产品技术在发展过程当中，我们用户了解非常有限，应用的案例也是非常少、个别的典型案例，在供需双方都处于刚刚接触、刚刚发展的状态的时候，很多宣传、推广的渠道是没有办法把SOA解释清楚的，没有办法准确、全面、清楚地阐述SOA。这时候，只有厂商、技术标准制订的专家非常了解的，所以企业用户应该从他们的渠道了解SOA。对于用户所了解的SOA的主流厂商，我们也了解了他们的品牌的影响力，我们看到IBM和BEA作为在中间件领域积累很久的主流厂商、国际厂商的话，他们在SOA的品牌影响力应该是非常高的，从我们这边看到的情况就是，目前这两家在两年之内几乎在所有的公开市场的推广场合都在谈SOA。另外一家在所有的场合都在主导宣传SOA的，我们看到就是国内的厂商普元。在这里，他们共同来参与对SOA的推广，上述这三家品牌实际上形成的对SOA推动的第二层次的力量。接下来对于微软还有一些其他的厂商，形成了在SOA领域不同的影响力。
那么，相信我们所有人购买一样东西的时候，我们都经过这样一个过程，首先要听说它，第二有兴趣去了解它，接下来我们要去决定，是给予一种肯定的态度还是一种否定，如果我们认为这是一个好东西，给予了肯定之后，我们接下来才会去考虑这个东西是不是我要的，我要不要花钱购买它，应用它，都是这样的思考过程，针对这样的过程，我接下来就看一看，目前中国绝大多数的用户对SOA是什么样的态度。我们这里面看到，用户里面表示对SOA非常重要、比较重要、一般重要，总而言之认为重要的客户超过了3/4。显而易见，目前的中国用户对SOA持一种肯定的态度，是一种好东西，的确代表未来的发展趋势。但是，当我们去了解到底有多少企业在现在这个阶段就愿意去考虑采用SOA的时候，我们看到的是右边这张图，应用的24%，会考虑的2.4%，会考虑的41%，另外两种就不说了。当提到考虑应用的时候，很多用户对SOA的态度不明确了，这个状态就是目前中国主流的企业对于SOA肯定和应用考虑的倾向性，这是我们今年得到的最新数据。
在了解了应用之后，我们对那2.4%也进行了一些深入的了解，因为我们看到有一些主流的SOA的应用商已经有了一些很实际的案例，多的品牌可能已经有几十家大型企业的应用。我们总结了一下，基本上目前在这六个行业相对突出一些，蓝色的金融、电信、政府是目前应用相对较多的行业，在制造、医卫、流动也有一些集中的应用。在金融里面，银行的付款业务、保险代理商的合作业务，在电信里面，提高定单、收款流程效率，加快服务交付的效率，在政府里面，构件电子政务基础平台、建设信息共享交换平台都有很实际的案例。在制造领域，如产品生命周期管理，像医卫的文件登记、供应商协作等业务，在流通里面零售业店面个性化购物等都有一些案例。我们看到这些案例跟国外的SOA的典型应用非常相象。也就是说，目前在国内对于SOA的应用并不比全球在SOA的应用方面落后多少，几乎是同步，只是稍有差距，而且应用的领域基本上是相似的，也就是说，SOA发展上中国的企业并不落后，而且中国企业的应用需要跟国外没有非常大的差距。我们可以预测，如果按这个趋势发展下去，未来SOA在全球广泛推广、大规模应用的时候，中国的应用趋势也会快速的增长起来。
接下来，我们看第二个层面，也就是渠道对于SOA的认同情况。那么，从渠道这个角度，从SI的认可程度，认为SOA重要的是65%，这个比例对于刚才用户对于SOA的认可份额人数要超出10%百分点，也就是说SI比用户更认同SOA。同时我们也看到，目前有70%的SI已经或者准备考虑对SOA应用。我们看到，渠道对SOA的态度已经表现出明显的去向性，现在形成了一种市场范围，主流的软件厂商现在在推广SOA，在为SOA做技术、产品、方案的储备，而渠道现在也已经明显的倾向于SOA，而且在做准备。对我们用户的环境，所有的软件、渠道、应用上在为SOA方向转变、努力。那么实际上对我们用户而言，现在是真真正正需要开始关注SOA的时候。
同时，因为我们发现渠道对于SOA开始做准备，那么他们对于相比企业用户来讲，对于SOA有更多的了解，所以我们对于他们对SOA的这种优劣势的判断，我们也做了分析研究，我们看到，渠道商有50%的人提出了SOA在松偶合方面的优势，也就是说，渠道商认为在服务提供着和服务消费之间提供接口，这样可以给该更改服务的具体实现而不影响服务消费，而且80%的渠道商认为可重用的服务可在不同的应用程序中重用。在左边蓝色条块里面，列出的是一些担心，但是这正是SOA的优点，因为现在技术不成熟，极少部分对其中的一些特点产生了担心，我们可以看到，15%的渠道商认为SOA不可靠，8%的渠道商认为SOA没有安全性，11%认为缺乏编排功能，10%的认为SOA不能跨系统集成。当这部分逐渐减少的时候，当SOA技术更成熟化的时候，这些担心同样会转化到右侧来，实实在在形成SOA的优势。当企业用户应用它的时候，就会实实在在的感受到这些优劣。
讲完了渠道商之后，我们来谈一谈SOA的提供商。市场上我们关注到几个SOA的声音，第一个我们要提的是IBM，IBM可以说是第一个为构件、部署基于SOA的IT系统，提供一系列全面的工具、培训和服务线路的大型厂商，它涵盖了SOA生命周期的所有方面，我们看到了金融、政府、交通、通信方面的应用，如果现在在座的有来自于这些领域的话，我们可以就他们成功的一些应用可以分享。在BEA佛教，它是公的SOA的领导者，它将SOA定位为公司未来发展的唯一战略方向，而且提供了全面的基于SOA架构的系列产品，在电信、金融、政府、税务、电力、制造行业有它的一些典型的应用案例。那么在第三个，我们要提到的就是普元，普元其实从我们计世资讯来讲，从第三方研究来讲，我们认为普元是目前国内在SOA推广方面、在SOA技术准备方面，对于SOA的推动是非常领先的，也或者说，目前声音最大的、品牌影响力最大的一家国内的软件提供商。所以说，如果大家把SOA的提供商分为国内和国外品牌的话，一定要对普元有非常大的关注。普元，我们认为普元在参与SOA软件标准的组织，同时对于SOA架构提供商当中，我们认为都是国内的领导者。同时针对中国用户，需要新建大量系统的现状，他们在倡导SOA架构来构件服务，通过ESB来进程，强调面向构件技术SCA/SDO是构件服务的最佳方式。对于中国的 用户，还有很多系统没有应用没有构件，在第一页PPT的时候，我们看积木的组建，它是已经构件出来，但是当我们国内的很多企业去未来，还需要新建很多系统。那么这个是一个很典型的特点，那么普元针对这样的一个特点，提出了要有针对性的做好SOA，通过一些实现方法，一些构件的技术来帮助用户来搭建未来的系统的规划，那么我们认为这是非常有必要的，应该是大家来关注的一个，结合自身的一个特点来关注的。那么，接下来我们看到就是SAP和ORACLE，他们是SOA的积极倡导者。在未来十年中间件平台将是他们的重要产品之一。最后我提到微软，微软并不是最初就去开始推动SOA的品牌，它实际上是当SOA形成了一定的发展趋势之后，才开始迫于主流声音、主流趋势开始在SOA找结合自己的业务、自己的产品、自己的技术来找切入点。实际上微软是SOA的跟随点和推广者。他选择了从开发人员入手，引导开发人员进入SOA，向开发人员提供参考架构。我们认为他从另一个角度，形成一种对SOA的推广。
在前面谈完了用户、渠道、厂商对于SOA的一个态度和一些推进工作之后，我们现在再来看一下目前中国推广SOA存在的一些问题。首先从SOA的技术来讲，由于它的确现在还不够成熟，在可靠性、安全性、编制、遗留系统和语义方面还存在不足，我们看到为企业用户存在的问题有对SOA价值理解不够，同时，由于企业原有的系统和数据处理在考虑SOA的时候的确存在障碍，这些障碍还没有找到很有效的解决方案。同时对于SOA，我们缺少很专业的技术人才。在市场推广方面呢，我们也看到，前面也讲到了，由于目前SOA技术产品的供方面和应用需求不足，典型案例不足，供需双方的不成熟，导致现在舆论媒体全面、准确理解SOA也存在难度，所以市场推广方面也存在一定的阻力。而且我们也关注到不同提供商对于SOA是存在争论的，包括对市场推广的着眼点也是不同的，这时候会对于我们用户形成一定的混淆，理解上的一些问题。最后是从厂商和渠道商方面，我们发现一些问题：
第一点就是缺乏一个开发的共享标准用于开发。提到标准，这里我们要强调的一点就是，从我们来讲，我们来建议、倡导企业用户，当你未来考虑、应用SOA的时候，要尽可能的遵循国际化的、全球的标准。现在我们看到，有18家国际主流的供应厂商在SCA/SDO方面的标准在努力地做推广。我们强烈建议，如果未来我们的企业要去考虑采用SOA的时候，应该去争取遵循这样的一些国际标准。
第二点我们看到，目前缺乏对于IT、商业、开发生命周期、人、流程、合作伙伴、数据等整合的综合考虑。的的确确，现在每家品牌都在抓住SOA的一些重点，但是对于综合的考虑，现在还的确不够全面。
第三点，我们看到面对企业不愿大规模增加资金人员投入改造现有的业务系统，这个是目前所有的大中型用户全都面临的问题，在这一块，现在缺少一些成熟的解决方法。这不仅仅是中国面临的问题，全球也是一样。
第四点，我们看到就是目前在SOA市场上，还很难形成一些核心的渠道商。
前面讲完了SOA的一些问题之后，计世资讯对于中国用户SOA价值认同方面，我们有这样的研究，我们称之为中国用户SOA价值认同曲线，这个认同曲线我需要解释一下就是目前SOA在中国的发展受到三个影响，第一个是全球应用SOA的成熟化，第二是中国企业用户SOA系统建设水平的提升速度，第三是来自于媒体的炒作力量。由于这三方面的影响，中国SOA的发展将不是一帆风顺，同时也不是一个波浪就能解决的。我简单分析一下，我们看到，以过继的软件巨头为代表的对SOA的推广，是非常猛烈的，而且他们大量的、尽可能的去拓展在中国的一些典型的应用。这个时候，当国内SOA提供商也是这方面的领先者，07年应该是SOA的热点、高潮，随着之后SOA的产品继续向前发展，而同时由于国内的大部分软件厂商没有跟上，前期的典型应用可能会出现一些失败的个案，这时候会对SOA的进一步推广形成一些影响。我们看到08年可能会形成一个波浪，那么到09年，从我们的预测我们觉得一些国内的软件提供商也会跟上，这时候会形成像当年的ERP一样的情况，形成一种合力。这时候典型案例会很多，那时候我们认为会形成第二个SOA的高潮。之后，我们认为出现一个分水岭，这个时候，从前期的对SOA的相对盲目、相对不太了解的阶段，企业用户转变为理性的看待SOA、理性采购、理性应用。我们认为2009年SOA开始进入一个成熟的阶段，它可能是一种相对缓慢，但是匀速推进的状态。所以我们中国户SOA价值认同曲线认为，近两年对SOA的价值可能有这样的提升。
基于前面的判断，我们认为对SOA的相关预测，这里面，因为SOA是面向服务的架构，如果真正企业去采纳SOA的话，可能不仅仅是相关的中间件、软件的产品，还包括一些咨询、实施的服务在内，整个的软件服务市场的规模，我们预测到2010年可能超过30亿元人民币这个水平，这两年由于基础小，增速快，到2010年之后市场会形成一个稳定、快速发展的阶段。
最后，我们想对SOA提出一些建议，首先是针对用户，用户部署的建议，我们看到对于一些大型甚至超大型企业，目前很多的，他们的系统实际上是已经建好的，我们认为对于他们采纳的SOA的策略，也就是边破边立，就是说太落后的系统需要推倒重来，还能继续应用的系统，则需要包装、改进，而一些新的系统则需要重新做规划。但是对于很多还需要在未来去构件新系统这样的企业，我想在中国这样的企业数量非常多，而且占绝大多数。对于这样的企业，我们所要强调的是，如果你的企业在未来需要去构件新的系统，那么我们强烈建议，今天，既然你已经看到SOA了，而且SOA现在的这个趋势也已经非常明显，有厂商的推广、有渠道的支持，那么从现在你就要开始把你的系统架构，把你的系统去做出一个全局的规划，这时候你要考虑来应用SOA。因为虽然说每个企业上SOA的时间不同，但是你提早了解它，有助于你去选择最佳时机。你如果要考虑上一个系统，你现在就要开始考虑，这是非常典型的，有一个先见的优势。同时对于小步快跑，伴随着SOA的发展，SOA实施可以从部门级开始，SOA的灵魂就是允许用户搭建一个松偶合的平台，但SOA不可能一蹴而就，规划、实施、服务是一个长期的过程，我们企业可以早一点考虑，但是做的话，一步一步的去做。
对于渠道发展建议，SOA会给一中要ISV市场机会。过去因为人力、财力所限，只能服务于少量的用户的ISV，现在可以通过提供行业内“标准”产品，面向更多的用户。国内的ISV和SI的确面临着SOA开发的难度，应用设计与产品开发与以前都不一样，国外的企业如IBM、BEA在中国设立了SOA研发中心，为国内ISV和SI提供了很好的学习机会。
同时对于提供商发展趋势，我们看到随着SOA的标准化，每种中间件的生产厂商的数量会逐渐减少，每个厂商应专注于一种或集中中间件，努力提高中间件性能和质量。
从软件产业总体上看，这将降低软件开发成本，提高软件质量，而且大大减少目前各软件厂商之间相同软件部分重复开发的问题。
以上就是我们计世资讯对于整个SOA从用户渠道、厂商的认知，来对于当前SOA遇到的问题和现状，我们的一些建议等等，非常感谢大家来跟我分享计世资讯的研究成果，我的演讲到此结束，非常感谢！ |
主持人：谢谢曹宇杰先生，也谢谢计世资讯对SOA的总结。计世资讯已经说到了目前SOA已经成为一种趋势，这种趋势已经被像IBM、BEA、普元这样的公司大力在市场上推动SOA，帮助我们去建立一个灵动的IT环境，去支持企业的发展。在座的很多人可能会关心，在SOA国际标准上面，IBM和普元有什么区别呢？在SOA里面有两个互补的方面，一个方面是SOA服务的构件，一种是SOA服务的集成。在这两个互补的方面里面，国际的IBM、BEA的公司，因为各自不同的发展历史和现状，他们所倾向的是服务集成这一块，也就是说，将原有的IT系统通过他们的技术其产品，把他们集成起来，来满足我们目前的互联网的需求，满足我们不断变化的市场的需求。在中国的企业，面临很多跟国际的不同，在中国企业里面，有很多企业在重构他们的业务系统、业务流程，以及业务流程不断的调整过程中间，普元 立足的是对SOA构件之上，通过这一块，来帮助中国的企业去搭建一个满足SOA技术、架构的IT系统。普元的产品和国际上的产品之间这种互补的产品，其实也势必给我们的用户提供未来SOA规划上面的参考，让我们用户在新建系统和原有系统的整合上面去考虑一种实现SOA的策略。这里呢，我也提醒大家，如果在听的过程当中你们有什么疑问的话，你们可以用小纸条写下来，写上你们所提的问题，你们的名字，以及你们希望哪位专家来回答，你们写好之后，递给我们的工作人员，我们待会儿有一个互动时间，可以详细回答各位的问题。
刚才我们看到了SOA发展的趋势，这个趋势怎么实现，这时候我们需要一种标准，那么在今年的3月21号，SOA组织推出了SCA/SDO的标准，这一标准将不同的国际环境中间去遵循大家的意见，特别是SOA组织的一种意见，最终确定为业界标准，这两个标准有什么内涵，他们又是如何的，他们有什么重要性呢？下面我们有请黄柳青先生跟大家一起来分享SOA国际标准从思想到实践这个主题，有请黄柳青先生。 |
黄柳青：谢谢，各位朋友，各位专家下午好！我非常高兴有机会代表SOA组织来介绍一下SCA/SDO制订的一些情况。首先我们来看SOA是什么东西，它为什么对我们非常重要。大家熟悉的一点是从纯技术方面的定义，什么叫SOA，SOA为什么引起大家的注意呢？首先从技术上面来讲，我们以前写软件都是，最早期当然就是写代码放在一起，后来呢，有很多函数、过程把它封装起来，然后会有对象等等，这些的特征就是说调用跟被调用方必须是一体化的。比如我写一个软件要去调用EJB的话，我写的就必须是一致的，否则他们就不能交互。我要传一个进去，它要传出来，这就是互相之间有一致性。所谓服务，服务跟调用是什么意思呢？调用和被调用方可以用完全不一样的技术来实现。因为互相都是用服务来完成的。比如我调用一个services可以是不同的服务的。也就是说通过服务来达到调用方和被调用方的完全的松散的耦合。这是从技术层面来讲的。
这样一个技术给我们业务方面带来什么样的好处呢？为什么这样的一个耦合是非常重要呢？这个我觉得我们需要从业务的层次来思考，什么叫面向服务？那么我想，在比较合适呢，我们用一个比喻来讲一下，就是从业务层次来看SOA这样的东西。举例来讲，以前农村里面人非常少，可能就几千人一个村庄。在这样的村庄里面，每个人跟每个人都是认识的，我认识张三，张三是谁的亲戚，谁又是谁的朋友，比如我牙疼了怎么办？张三是搞牙科的，或者李四我朋友的朋友是搞牙科的，也可以找到牙科医生。比如你家里有一些喂猪没有人喂了，你可以找一个朋友来帮你看管一下。这是一个比较原始的社会结构下，人跟人关系非常紧密的，这个社会的结构主要是靠直接的依赖关系串起来。如果从现在软件架构来讲的话，我们写过各种各样的软件，我们的软件其实就跟刚才农村一样的东西。比如我要写一个软件，我这个软件要把数据放到数据库里面去，我知道张三的过程是专门把数据调到数据库里面的。李四是专门做数据转换的，我就找他把这个过程去调用，调用出来。实际上，现在这个软件本身都是通过一对一的，或者多对多的，但是比较直接、固定的关系来完成的。
那么什么叫SOA？从大的范围来看，我觉得我们花几分钟时间，这个东西还是非常重要，因为这个认识是我们对SOA认识至关重要的一点。来到我们现在成都这样的一个地方，那么我们会发现，比如就说这个宾馆，这个宾馆谁都可以来住，你要想住，我到成都谁都不认识，怎么办？有很多宾馆，你随便挑一个宾馆就能住进去。像银行也是这样的，我有钱要放银行，怎么办呢？有很多银行，所有银行是干什么的？帮你保管钱、贷钱服务的，银行是为所有人、所有企业、所有个人服务的，你只要有合法的身份证，你都可以开户。那么这个宾馆你只要交钱，所有人都可以居住，你也可以到任何地方去住，每个地方也所有人都可以居住。所以在我们一个大型的社会里面，就会看到其实这样的服务的特征，我们有银行的服务、餐饮的服务，我们很多饭店就是提供吃饭的服务的。从软件角度来讲，我们的企业应用就走过了这样的几个阶段，在早期呢，因为我们都是在部门一级来看我们的应用软件，我们总共有20个、100个、1000个函数，我们互相搞懂了，调用就行了。但是现在企业应用，企业发展到一个阶段，这个阶段里面企业的函数不只是一千个，可能是一万个，互相之间的关系非常复杂。
什么叫SOA呢？从业务层面了解，就是现在的软件模块之间，我可以画一个流程图把所有关系描述出来。不存在这样的描述，我们可以有很多服务，你可以当成银行，或者当成餐饮的角度来看，比如在一个大型企业里面，比如说我们会有一个人事资源管理服务，现在呢，我们写很多企业小应用的时候，都会去写一个人员管理模块，每个人都写一个，实际上来讲，在SOA的模式里面，那么我们就可以一个服务，这个服务就是人力资源管理。至于这个服务谁来用呢？我写这个人力资源管理的时候我是不关心的，我们公司的各式各样应用软件都可以用这个人力资源管理。同时呢，我们一个应用软件，可以用到多种服务，有人力资源管理的服务，有员工考核的服务，有项目管理的服务，也就是在一个非常大的系统里面，我们已经不需要、没办法，对一个应用系统做一个非常细化的描述，就是说每个模块之间的关系，我不管这个东西，因为太复杂的。我们就把主要模块抽象出来，让它变成一组公共的设施一样，就像一个社会一样，一个软件的社会，在这个社会里面我们有各式各样的服务，如果我们写一个新的应用软件的时候，比如我们现在做一个客户管理，做客户管理的时候，我们就可以把我们现在系统的服务提取出来组合成我现在要用的东西。所以这个就是面向服务的一个最核心的东西，就是面向服务SOA它一定是一个企业全面操作的大规模的阶段，使得软件的子系统之间有一个完全开放的、松散耦合的东西，这个东西从技术上来就是依托与我们刚才讲的通过服务来调用，而不是通过对象来传递这个方法，使企业的耦合度降到最低。所以确实是这样，因为从我们企业管理来讲的话，应用软件的复杂度，我们应用软件能够包含的范围越来越广，正是因为这样，如果我们没有面向服务怎么办呢？就像刚才讲的，我们一个小部门有五六个人，有10个、20个函数，我们可以编程编好了。但是在一个大型企业应用里面，我们会碰到五花八门的需求，他们涵盖的业务非常广，如果你一定把所有关系搞清楚的话不可能的。比如我们成都每天出生一千个小孩，这个新出生的小孩跟银行有什么关系呢？你根本就不要考虑这个问题。那么像SOA也是这样，在我们传统的一个应用软件的架构里面，比如说我们增加了考核这几个功能，那么你需要把考核跟员工、考核跟绩效、考核跟活动、考核跟财务描述清楚才可以写这个软件。因为这个是没法做的，比如我们现在系统里面已经有一千个函数了，那么如果你增加一个函数的话，就需要去描述这个一个函数跟所有一千个函数之间的关系。所以我们在这里的意思就是所谓SOA的架构，它最重要的就是达到了这个目标，就是我们在一个企业应用的总体的架构里面，我们看到的不是很多函数、不是很多对象，而是我们在一个共同的管道上面，这个管道是我们统一的通信机制。这个管道里面，已经有非常好的服务给大家提供，通过这个服务，我们能够快速的把我们企业应用建立起来。对于每个服务来讲，它设计的时候就满足了所有可能需要这个服务的人的要求，就像人事管理，不管是哪个部门，要人事管理，它这个功能就完备地提供出来，是这样的架构。在企业里面就可以看到，我们有统一的企业的服务总线，在服务总线里面，我们会看到10个、20个比较标准的服务。那么服务相对来说颗粒度是比较大的，完备性比较强的，那么它就可以通过服务总线给新的函数提供一些功能。同时的话，如果我们需要对现在系统的功能做一些调整的话，也可能对不同的服务之间的调用来进行重新的配置就可以完成新的功能。我认为从业务和技术方面来讲，就是SOA的本质。SOA的本质就是把个企业的应用重新打散之后变成一个社会一样的体系，这个社会体系里面，我们有很多服务，每个服务在专门的领域里面只提供一套完备的机制给大家使用。就像每个城市里面有银行、交通、餐饮等等，这些设施都完备了，我们城市就能运转起来。在企业里面，我们所谓SOA就是建立各种各样配套的服务，这个服务有了，我们再去做新的业务功能的时候很快就能实现。
SOA的特征就是它服务的颗粒度相对来说比较粗的，它是面向网络的，已经可以良好的理解，就是我们很清楚的知道那个是财务，那个是行政，那个是营销管理，这个是大的服务的措施。这是我们刚才介绍了什么叫SOA，SOA从这个角度来看，它是一个势在必行的东西。因为企业发展，从小到大，就像从原始社会发展到现代化的社会，作为企业应用来讲，它一定会走到面向服务这个阶段。实际上面向服务这件事情也不是说我们从零开始突然冒出来的东西。面向服务也是经过软件几十年的发展，就像八十年代也有面向服务的架构，即使没有ESB的东西，很多大型企业都是面向服务的接口来做服务的接口。作为一个思想来讲，面向服务是软件行业大型企业几十年发展的积累跟趋势，这样的一个趋势也是可以很长久的。SOA不像，比如说我们Java，C++的生命周期。SOA作为一个思想来讲，也许会超过Web services，作为一个思想来讲，SOA肯定是企业应用很长久的事情。
在这样的思想下面，SOA的实现就必须有三个非常重要、缺一不可的环节：
第一个环节，就是刚才最早讲的面向服务的通讯型的协议，就是我们开始讲过，所谓SOA就是把函数之间的调用，不要通过对象传递来完成，而是通过服务调用来完成，这样就可以把调用跟被调用者的实现手段、运行方法完全剥离开来。就是在一个城市里面，我到一个银行里面存钱，我住哪个地方，宾馆或者平民窟，对于银行来讲它对此不关心的，对于SOA来讲也是一样的，就是我一个services，用什么来调用这个事情我是不关心的。对于SOA的定义基本上已经达到了比较标准化的一点。有了面向服务的最基础的通信层之后，下面非常紧迫的也是我们标准协会来讲的，就是我们叫编程模型，什么叫编程模型呢，假设我们已经有很多的services，包括人事、行政、财务等等，那么这些服务，怎么去把它通过编程方法整合在一起，我去调用的时候，这个数据的载体是什么，那么它具体的是怎么样的一个协议，使得服务之间能够编程、整合在一起，那么这就是我们关心的SOA的编程模型，也是我们现在标准协会最重要的工作，就是SCA/SDO的国际标准，这个国际标准主要是承载了编程的模型。有了编程模型，假如说我们在系统里面已经有一组服务，已经有多组服务，我们就可以通过这个SCA/SDO的标准，就可以把我们现有的服务重新的组合成各式各样的新的业务模块。这就是我们编程模型的最重要的环节。除了这个以外，最高层次的一个事情是什么呢？假如说我们SOA这个协议非常好，我们可以通过它来实现，通过服务来管理一个大型应用。同时服务可以通过编排实现新的功能。第三个最重要的东西就是说这个服务本身怎么快速有效的开发出来呢？这个服务本身除了它对外提供的接口之外，这个服务本身是不是也需要一定的的灵活性呢？像在成都有很多银行，银行本身的业务也在发展的，不是银行大家不去用就结束了，银行可能今天推出代理购买基金的服务，现在又推出了为证券公司做第三方存管的服务。就是SOA里面最重要的一块，就是服务本身具备相当的灵活性，不然就无法适应企业的发展。因为企业应用的变化，相当部分来讲就是把现有的人事、财务，拼装成新的业务流程。也不排除，或者中国来讲，短期来讲重点是在于说我的人事管理要进行改革，我的财务管理制度要进行改革，也就是说，这些服务本身怎么样能够通过快速的变化，这个也是非常重要。所以这个如果我们能够理解到SOA是什么东西的话，那么我们下面就是需要理解到SOA的三个重要的组成部分，这三个重要组成部分就是说这个SOA的通信协议、SOA的编程模型以及SOA服务本身的快速开发以及通用问题，只有这三个问题都得到解决，SOA才能真正的进行大规模的推广。
我们下面就是主要介绍一下中间这个层次，因为Web services已经非常标准，我们看就是中间的SCA/SDO这样的东西。SCA/SDO是有一个美国的Open SOA组织来建立的，它的目标就是怎么样把Web services进行快速的组装，这个组织有四个成员，有IBM、BEA，以及应用软件里面全世界最大的公司ORACLE跟SAP，也吸引了世界上的其他公司，这也包括了普元公司。这个非常有意思的是，去年的时候，在上海举行了一个全球软件大会，IBM的CTO也来中国进行一些交流，那个会议上面他了解到普元公司在面向构件、面向服务领域其实已经有很多年的实践了，所以我们也很高兴的得到他的推荐，作为十五个成员参加了Open SOA的成员。所谓编程模型，就是包括几个重要的部分，像刚才看到，底层的话就是跨越异构环境的互操作性，就是SCA的一些基础。在这个基础上面，分成两部分，一个就是服务跟数据的简化复合跟实现，这就是SDO协议，这个上面就有三个业务流程，首先就是把服务变成很多服务构件，这个构件是通过流程，把它串在一起这皆是相互依存的关系。我觉得这里也是非常有意思，跟大家介绍就是普元公司参加这个Open SOA的协会，我们也了OASIS，因为Open SOA是一个半官方、半私人组织，他可以提交标准的申请。OASIS是可以发布标准的协会，所以我们也参加了OASIS的成员。在国外来讲，做标准是一个非常开放的环境。以前我们中国在标准制订方面比较落后的，通常来讲就是在国外已经有一个比较成熟的产品，有了这个成熟的产品之后，我们再到中国来进行推广，在这个过程中呢，我们才了解到标准的情况。我想普元公司能够参加这次标准的制订，也是一个比较早期的一件事情。这个标准协会，它其实非常开放的，我们有十八个成员，每个成员都可以通过WIKI这样一个开放的网站提交各式各样的建议，这些建议经过很开放的讨论环境。国内就是几个专家讨论就结束了，实际上像国内的SCA/SDO的标准，真的是每个厂商畅所欲言，每个人只要愿意就可以提交，得到大多数人的认可就可以成为一个标准，这个标准在编写过程中也是对外开放，我们专门有一个www.osoa.org的网站，我们可以进入这个网站进行更新和修改。
我们是在今年OASIS组织，我们今年三月份申请加入OASIS协会，这里面产生了一个构件化的成员服务。普元公司跟IBM、BEA、ORACLE一起成为了OASIS的核心会员。这是我们的总体的进程，那么，SCA V0.9是在05年制订的，SCA V1.0是今年推出的标准，这个不能说是完全的标准，是我们的一个基础版本，我们会在今年10月份左右，把SCA的标准正式提交给OASIS委员会，因为这个过程是比较严密的，它收到我们的申请之后，给我们六个月时间来准备具体的一些内容，也就是从四月份到十月份准备规范提交的具体内容，我们SCA1.0跟SDO2.0会在今年十月份会正式提交给开放的这个组织。在十月份提交之后，差不多一年到一年半时间，就是到2008年底或者2009年初SCA/SDO就会成为一个国际标准，目前的话相当于是厂商SCA/SDO标准，虽然现在国际上有很多厂商都在支持这个标准，真正成为国际标准会在2008年底或者2009年初这样的时间。
这就是我们刚才讲的标准协会的制订的一些具体情况，刚才讲过所谓编程模型就是封装了软件功能，通过构件组装的方法来实现企业业务的快速重组和变化，它就包括了SCA、SDO的标准，有关SCA/SDO的具体情况，等一下我们有王满红总结有具体介绍。除了SCA/SDO的标准之外，还有一些政策框架等等，所谓政策框架是什么意思呢？就像原来村庄小的时候，软件就是人对人。在新的社会里面，我们主要的东西都是通过服务，银行、餐饮等等服务来提供的，那么有了服务之后，就会出现一些新的问题，这个新的问题就是说我怎么知道你银行是真的，我如果钱放你银行里，你银行跑掉了怎么办？这就需要一套政策里管理，比如我开户跑掉了，所以你开户、你住宾馆都要身份证。这就需要SOA的政策，这个政策就是要印证你这个服务是不是真的，别冒出一个办身份证的服务，结果大家做的是假身份证。或者谁在我们企业服务总线上面放了一个财务管理的服务，我们都把钱送到这个服务里面，结果发现这个服务是一个假的。所以在一个新的体制里面，如果是我们的软件都通过服务来进行沟通的话，它的政策、它的控制、它的管理成为一个很新的科技，它的政策是我们SOA里面很重要的一个模块。这个构件的组装等等，这些我都不详细介绍了。
所以我觉得我们从几个概念上面来讲的话，进行了一些更清晰的理解，就是技术上面来讲，什么叫SOA，业务上面来讲，SOA是实现软件社会化管理的新的机制。这样一套机制，它确实给我们带来了很多好处，第一就是通过SOA的话，就能够实现低成本的集成，因为每个服务，它可以给任何人提供相关的业务，而不需要我们预先的编排跟固化工作，我们一旦写好一个服务，这个服务本身所有人都可以使用，所以可以做一个低成本的集成来获得更大的灵活性。使用SOA构件的SCA模型，更是提供了快速编程的模型，就是我们怎么很快的把各种各样的服务整合在一起。其中SDO大家说得相对少一点，但是我认为SDO是我们企业当中至关重要的一点，因为我们需要标准的模型，就是我们需要不同的数据，这个数据怎么传递，比如像到银行开户，填一个表啊，这个表里面我们要填个人的身份信息啊，地址啊，如果你没有这个信息，银行不给你服务，如果有的话银行才会给你服务。这个信息提供就是SDO提供的，以前我们的数据传输都是对象，都是Java，或者是C++，这个不存在问题。现在我们必须有一套新的、必须跨越语言规范的东西来描述我们的应用数据，比如我对一个员工的描述，不管是用C还是C++，它都应该是一致的，都一致了，我才能把员工的信息传输给一个人事管理，才能把员工的信息传交到一个考核管理。这个SDO就是脱离了具体的编程环境，脱离了具体数据库模型的一个数据模型，这样使得我们，你一个人到银行去，去吃饭，去干嘛，这个都是数据SDO给大家带来的价值。那么SCA和SDO不是一个小的可有可无的标准，像我们SCA的专家，他说的是SCA和SDO的标准是SOA实施的必须的标准，你没有SCA和SDO，你的SOA其实是不完备的，很难落地的。那么SCA和SDO也是SOA这样一个概念从思想到实践的一个落地点跟接触点。所以这个也是我们很多专家的看法，就是面向服务，服务组件、服务构件，这都是我们很重要的未来。
从我们整个实施来讲，我们看到第一就是，我们要把SOA服务构件作为未来的IT规划的中心。也就是我们刚才讲了SOA的这套体系，那么这套体系里面有SCA、SDO。最后我们讲的就是这三句话，第一，如果我们现在要规划一个大型的企业应用的话，我们一定要以服务为核心，特别是以服务构件为核心，作为我们IT的规划。就是我们再重新设计一个企业系统的时候，不要设计出对象，这些对象跟其他的对象之间的关系是什么，这个不可能，我们需要规划一套完备的服务构件体系，这个服务构件， 我们能够承载未来企业各种各样的要求。第二个我们必须选一个SOA服务构件的平台，因为SOA是一个平台支撑的。这个平台，一方面需要标准型，我认为很重要一点就是要有本土化特征，就是包含了SCA和SDO时间的各种各样的元素，特别是服务构件这个概念，我们在美国提出1.0这样的标准，像普元公司在面向服务、服务构件里面的实践，具体的应用就是从2001年开始到现在已经6年的时候，这个实践的经验，在里面积累的，除了标准以外，各种要素非常重要。我不知道IBM、BEA的系统性能怎么样，但是我们普元的SCA/SDO标准的基本内容来讲，已经在中国电信、银行等等，支撑百万级、千万级用户的运行，对大企业的运作非常重要。另外一个非常重要，就是我们做一个SCA/SDO，作为面向服务构件的体系的话，不可忽略的一点就是说服务构件本身它需要一个更小的构件，能够把它打造出来。也就是说，我们需要一套，不光是在服务层的构件服务体系，我们还需要通过更小的构件来组装服务。因为在中国的环境里面，我们不可能规划出一套SCA的服务构件，这个服务构件本身就一成不变，这个服务构件本身就要求变化，银行有新的业务，证券公司有新的业务，电信有新的业务，所以我们一定要有一个体系，能够超越IBM、BEA这样的基于服务构件来组装的套路，这个上面我们还需要一套体系来快速打造一套新的应用、新的服务，让新的服务快速变化。这样的话，普元公司在标准协会里面，不光是普通的一员，实际上我们在SCA/SDO实践上面走得比较远，时间关系，今天就说到这里。谢谢。 |
主持人：谢谢黄博士给我们精彩的演讲。从黄博士演讲中间，我们发现在实践SOA的时候已经给我们制订了一些规范，它们是松耦合的可以互用的，跟具体的技术没有更多的关联，使我们的IT真正的灵动。所以刚才也提到了，我们一些简单的编程模型是如何去实现SOA，使得我们从SOA这种心动变成行动。
下面我们将对SOA进行进一步的研讨，接下来，我们有请普元产品部总监王满红先生为我们介绍面向构件的SOA模型，有请王满红先生。 |
王满红：各位来宾下午好，我今天的主题是面向构件的SOA编程模型。
首先我们简单回顾一下IT应用的变化，这里有几个指标，一个是从存储上来看，我们在60年代的时候一个软盘就可以做一些应用，到80、90年代的时候变成了硬盘，刚开始是多少字节、多少兆。到互联网时代，2003年，计算格式已经成了TB了，而且这个应用是越来越复杂。从最开始的单机应用，到现在的Web模式，以及SOA的复杂应用时代。
从技术上，我们从对象到了服务，经历了大概三个阶段，一个是面向对象的是我们强调的封装，以及多态性等等非常底层的技术。到了90年代，我们强调构件的时代，我们特别讲元数据以及耦合，它解决的是系统的问题。到现在面向服务的时代，我们已经到了整个组织结构和企业之间的关系。随着这样的话，技术也会越来越先进，越来越复杂。现在关键词已经便成了机遇消息的和松散耦合的等等。
技术也走过了三个时代。SOA主要强调哪些价值呢？首先，服务和业务越来越复杂，我们要求业务和IT要高度保持一致，在很多时候，我们的业务是领先于IT，它的要求和IT的能力是不相一致的，在SOA时代应该有一致性。基于构件的、松散耦合的、基于网络的、还有就是动态构建，按需求构建，有了服务，也可以更高的有代码复用率。然后可以更加标准化的把整个应用的流程见建立起来，有了SOA，整个企业的应用，都可以有效的整合起来，更加有利于集中控制。
SOA技术也走过了几个时代，今天我们发布SCA/SDO规范的时候，真正有了实现的技术，因为它不仅仅可以整合一个系统，更加有效的开发一个新的应用，开发新的应用的时候把已有的整合在一起，其中特别讲了组装模型，这个组装模型就可以把异构的构件组装到一个服务网络进去，有机组合起来变成新的应用模型。另外还有SDO一个是可以有效管理异构数据，可以有效的用语义的方式来访问。还有一个集成，集成考虑到两个特点，一个是是绑定，一个是策略，这之上是业务流程管理，有了服务的组装，我们更加有能力关注整个企业的业务流程怎么组建的。一会儿也会讲到，在SOA一个成熟的模型，有了业务流程之后，还要一个软件治理，现在讲软件治理，很类似于居民和警察的关系，或者是建筑里面的监理，有的时候一个需求来的时候，在一个实施过程中可能有很多的变化，有可能会偏离最初原始的需求，这时候需要独立的软件治理，能够更好的满足需求和业务的变化。
我们来看SOA这个规范由一系列规范组成的，现在发布了SCA和SDO，其实还有一系列的规范，分为几个层面，一个是操作层面的，接下来就是数据交互规范，以及数据访问管理的等等。
我们现在来重点看一下SOA的编程模型，SOA实际上它是一个新的时代，我们说刚才回顾的过程中，就是每当一个编程向上走的时候，增加了一层抽象模式。我们回顾一下这个过程，从汇编到应用到服务，当我们去看汇编语言的时候，这个是适应机器的。到了过程的时候，就可以稍微脱离一下机器的方式，就是我怎么解决一个问题，怎么把一个问题解决掉。当面对对象的时候，我们提升到一个系统，就是我们构件一个应用，我们怎么分解成计算机能理解的模型上。到面向构件的时候和面向服务的时候，我们考虑的整个周期就是一个企业，一个跨企业的组织。这样的话，我们关注的环境越来越复杂了。现在在SOA的时代，我们需要知道很多技术，首先Web技术啊，各种各样的编程语言，以及增加建模一个应用啊。所以现在SOA的技术，其实它不是一项新的底层技术，它给我们更多的业务抽象。SOA一开始我们讲是让计算机人员面向业务，让业务人员参与到IT建构中来。刚才黄博士讲，我们看任何一个系统的功能，它首先不用考虑怎么实现的，我们关注的是一个应用怎么组建，然后第二个你才可以用更多的手段来实现，所以这样的一个层面就是给了我们更多的抽象，可以让我们站在业务的角度来思考。一旦有服务，服务的组装就特别重要。所以SOA基本上是讲，最重要的问题有了不同的服务之后如何组装。我们最开始就是从集中和整合的角度来考虑的。但是我们现在会发现，整合也不会那么简单，不是两个东西放在一起就可以了，还有深度的服务的编排，还是有一定的业务语义的。所以在这个层面上，服务的组装，还有附加上类似的编程语义在里面。还有就是服务构件的开发，因为服务构件虽然是有不同的实现的组成，但是要最终符合一定的规律才能组装起来。第三个服务数据对象。有了这三点就构成了整个SOA的编程模型。
什么是SCA呢？SCA我的理解就是一个可执行的模块，然后将不同的模块用不同的服务组装起来。其实这个非常类似于我们刚开始面向对象的需求，业务分析和设计。这个东西给到一个切切实实的工具，把它映衬起来。但是不同的是，面向服务的SOA时代，这个是直接可以运行的，有了SOA的容器，这些东西不在仅仅是一个图形而已，而是实实在在可以运行的系统。这样的话，面向服务的话，它会借用，不会有新的语言，它是利用现有的语言，包括Java、C++、BPEL等等。SCA不是什么，首先它不是新的里它是借用现在的语言，它也不是Web services，这是完全不同的两个层次。再一个它是不局限于特定的运行时，它不仅在语言上不依赖于现在的语言，比如它可以同时运行在Java和C之上，再一个它不会强制使用特定的编程语言。
首先来看，有了这些东西有哪些好处，首先是松散耦合的。第二就是无须知道其他构件的实现方式，所以耦合是非常松散的。再一个灵活性，就是在开发应用的时候直接给一个接口，有了这个接口，它可以在第二次或者是运行期都可以换别的方式来替代。再就是服务，服务这个观念，刚才也讲了很多，既可以是同步的，也可以是异步的。再就是解决方案的复合，前面已经介绍了，组装可以带来灵活性，而且这些组装在不同的时期都可以进行组装。再一个效率，因为它是基于构件的，因为构件都是灵活系统，所有的服务都是以前调用……再就是异构性，多种实现语言/不同的框架等等。再一个就是声明式的语言，不在是紧密的绑定。我是直接定义到一个语言，还是契约式的语言，契约式的语言的好处就是灵活性。再一个就是简化，有利于人员的分工，有些人可以只懂…，有些人可以只懂Java，他们可以在一定层面上组合起来。我们可以利用图形化的编程工具，这样的话，对于所有的开发、集成人员大大降低了对他的要求。
再来一个高的层面来看，SCA的一些细节性的描述，我们看首先是一个统一的声明式的模型，它里面定了很多模板主要是通过配置和组装来完成的，皆是你的新的引擎基于这些描述和组装就能完成编程，不再需要很多编程的细节。再一个就是声明式的策略，就是很多时候我是灵活的，我定义一个安全，就是说我现在需要一个安全，运行的时候配置就可以了，它策略有一个策略的框架和规范来说明，一会儿我会讲为什么策略特别重要。再一个就是基于业务级别的模式，我们一直讲SCA提供了业务模型，它肯定是介于业务人员和开发人员之间的，这些都是高层次的，只有高层次的东西才会真正面向业务，不会是技术型的，没有任何技术性，在SCA里面只讲事物本身，我需要什么样的事物，它不会说我怎么来实现。再一个它是一个绑定的策略，绑定也是相辅相成的，就是说具体使用的时候，绑定很多地方。再一个是基于交互式的，特别是在网络环境中，我有时候不是同步的，我们可以是异步的，或者离线的，包括数据、服务，都会让你得到一个高质量的、无缝的连接。
我们再看一下SDO，SDO就是简化的SOA数据处理工具。它首先是统一的数据格式模型，就是说他和某种数据库联系在一起的。但是它缺乏语义，像姓名、性别等等，就是某个数据存在数据库里面的时候，针对不同的数据库需要迁移，但是在SDO里面有两种方式，就是因为它需要把数据库的具体实现映射到一个具体的数据处理方式上。SDO也可以解决这个问题，可以以对象的方式来访问，因为在关键处理中和对象，要很多匹配的，大家编程都明白这一点。SDO解决了语义性，比如数据建模的时候是有语义的，但是后来这个语义消失了，SDO中还保持这个语义格式，不会因为数据库的差异而造成访问的差异性。它的数据不能不管是元数据还是目标数据，还有非结构化的数据。还有就是SOA设计的交互方式，它是离散的、乐观更新的策略方式。
上面讲SCA那个具体元素包括几种关键元素，一个组装，组装主要是关心有了构件之后如何把构件组装成一个子系统或者模块，这个子系统如何被组装成一个应用。另外就是客户端和实现，这是两种方式，我们知道当有一个服务的时候，有几种调用方式，有一个服务的时候，也可以有很多实现方式。绑定规范刚才讲到，就是当有一个服务之后，如何绑定到一个具体的服务上面去。最后一个是策略就是安全啊、事务啊、可靠消息传递啊，有了这些策略就实现了高度的灵活性。
具体来看一下，SCA构件有几个基本的要素，其实普元定义的构件在四五年前已经有一个方式，就是说在SCA里面特别强调有什么服务，有服务定义了接口的功能，然后服务是通过接口来描述的，接口是具体的实现一种服务，就类似于Java，Java的接口就映射到SOA里面就是服务。构件可以有多种实践，这个可以看到，就是描述了具体这个构件是通过什么方法来实现的，而且这个实现是可变的。再一个就是属性，属性就是一些可配置的参数，我们有了这些属性，数据就有丰富的特征。还有就是一个引用，就是说一个功能可以用别的构件来实现。另外还有几个关键，就是两个构件之间如何组装一个新的构件，一个是连线，连线其实有点像就是说当一个构件和另一个构件发生关系的时候，就是我的服务怎么映射到，比如我这里叫A，那里叫B，可能A就等于B。接口，接口是一个描述服务和引用服务的业务功能。再一个绑定，就是服务怎么实现的。
SCA关注点分离，有一个获奖的诺贝尔学者说过，我们解决问题的方式只有一种，就是分解。我们计算机发展起来，就是一个裸机，加了操作系统就加了一层关注点分离。所有解决问题的方式就是把关注点分离，SCA给我们提供的关注点分离是那些呢，就是有了构件和复合体之后，我们只关注业务逻辑，我不关注它的具体实现，这就可以描述一个业务解决方案。另外一个就是从基础架构的方式，一种就是绑定和策略，这个特别关键。这些观点是以前没有的，正是由于这些观点，使SOA能够弱化，这就增加了通信和实现的分离。另外就是策略，策略就说类似事物、安全、消息这类的东西，就是我把具体的SOA的基础设施能力，也分离出来。
首先看绑定，什么叫绑定呢，绑定是比较泛化。比如，现在有对应的几种，比如常见的Web service绑定、JMS绑定、JCA绑定、EJB（RMI—LLOP）绑定，可替代的Web框架，我们称为框架绑定，我现在许多一个MVC的模式，客户端解决方案，具体哪一种呢，我可以用任何一种。另外一个就是框架绑定，我定了一块服务，一个结构，我在部署期间，我说这个绑定在哪个上面的，再换一种情况，可以到再下一层，就是说现在SCA的绑定不限于方法，就是针对某种情况，指明它如何实现都统称为绑定。
再就是服务的引用，一个服务我引用到另外一个构件的时候，我也可以绑定，我这次绑定到这个服务构件，下一次可以绑定到另外一个服务构件。另外绑定有两种方式，一种是内部绑定，动态的绑定，另外一种绑定非常少，通常的绑定是开发期的，就是编程的时候有一个接口，SCA的绑定是部署期的绑定，这时候给了很多灵活性，就是不同事情可以交给不同人来解决。我们跟华为接触的过程中，他们有很多要求，就是它的开发人员、部署和实施人员完全分离的，很多事情它需要在部署的时候来制订，有了这个特点就适应那个需求，就是很多时候他需要很多开发需要的特性，SCA已经具备了这样的特性。当前我们有Web services的绑定等等。
我们在新的ES6.0的开发里面，就有一个新的绑定，就是增加了US自己的绑定。
我们SCA策略和基础设施能力，基础设施有许多可配置的能力，像安全、事物、可靠消息等的传递，都是跨多个关注点域的复杂配置集合，SCA利用声明试模型抽象掉复杂性，它不受实现代码的影响；通过声明试策略意图简化了使用；易于应用和修改；在策略集中保存了复杂的细节。就是说它可以大大降低复杂性。
大致的策略分为两步骤，第一步是抽象的，第一步只告诉你我想做什么事，比如我想有安全，但是不知道怎么实现安全。二第二步，可能在部署期间实现，一种是通过消息的方式得到一种具体的策略，一种是与构件的实现直接相连，这两种方式都可以实现。就是那个，它这里分两种，一种叫意图，意图就是说我在开发期告诉一种意图、一种服务，我要实现什么样的功能，什么样的质量，这样的意图形成一个策略集，这是一组，有了这些绑定，在具体的部署的时候，可以把具体实现映射过去。所有的策略都是基于WS-Policy来完成。
下面看一个具体的复合体，叫Composite，它主要是讲一个复合，原先我们讲具体的构件就是一个实现，如果我用各应用只有一个构件组成的，那就很简单，但是那是不可能的。这个是一个复合体，它是由构件A和B组成的，其中A引用了B的一个服务，然后他们两个有他们两个的属性，其中两个是被暴露出去了，成为Composite本身的属性，B又应用了Web应用，就是在形态上Composite有构件本身的属性，但是又是一个新的。就是整个系统可以分解正确不同的构件，就是可以有了一个分解体系。
目前规范里刚才提到，服务有两种描述方式接口，一个是Java本身的，一个是，WSDL PortType，实现也有几种，Java的，C++，BPEL、COBOL、PHL等等。
这个是Composite的示例，这个是银行的的。我们看它是怎么描述的，其实SCA规范只不过定义了一个部件，首先Composite，这个构件本身的描述就是Composite这个节点，以及看它的实现，就是这个构件是由这个Class来实现的，它引用了两个构件，棕色的是外部的一个服务，蓝色的是自身形成的。这个服务构件是自身的，所以要对它进行描述。这个是个引用，这个就是这个构件不是这个系统本身实现的，所以只需要描述引用就行了。然后最后描述了这个Composite本身的一个服务。我们看的话，它是非常结构化的一个描述方式，有了这个描述方式可以非常轻松地描述任何一个复杂的系统。
们看一个比较经典的HelloWorld例子，非常简单，假如我们写了，HelloWorld services，右边是服务器本身，这个服务构件，我们称为回调功能，这个服务本身又回调了，就是我服务这个构件还是一个构件，这两个构件其实是一个，这两个构件是通过回调的方式又调用出去了。就是这个是最简单的应用，只不过体现了所有的SCA的特征。这是它的一个描述的示例，这个和刚才一样的，由一个构件组成，引用了一个Web应用，这就是客户端右边的应用，这个服务端的应用。
那么SCA通过服务组装，它首先保证了整个可组装性，然后基于服务的系统模型，有几个方式，首先是构造，然后组装，组装成一个系统，然后需要部署，部署的时候需要策略和绑定。然后它可以是多语言、多容器技术的。
今天时间关系，我们介绍到这里，谢谢大家。 |
| 主持人：谢谢王满红先生精彩的演讲。刚才我们看到SOA的编程模型和传统的编程模型已经有非常大的区别了，这里面我们需要掌握三个核心概念，首先是服务构件，服务组装和服务数据对象，我们有了这样的一个编程模型以后，对于我们的CIO、CTO来讲，怎么区市县SOA，怎么管理我们的项目，怎么开发，这是普元的项目总监袁义给大家介绍的内容，那就是面向构件的项目管理方法与实践。 |
袁义：各位下午好，时间关系的话，因为作为一个方法与实践来讲，它是你采用了这种技术之后，才会去用的到的内容。而因为今天的话，主要还是侧重于SOA的技术的传播，在这一块的话，本来这样一个项目方法和项目管理的培训，在普元对外对客户进行培训的时候，是两天的课程，不太可能在很短的时间内完成，今天主要通过这个机会给大家介绍一下，也让大家看看这个面向SOA的平台的方法是怎么实现的。
这里面，从面向构件的管理与传统模式来看，因为从传统的从需求、分析到设计，是在不断的转换你的技术语言，到了分析设计的时候，你又用了其他的语言，到了开发用了J2EE等，这样的话，使得你软件的生产在不同的环境、不同的描述方法上进行转换，这也是导致软件生产出来问题的主要根源。那么面对构件的话，它是试图在软件生命的各个周期的话，基于构件的模型，在这样方式里面进行软件的组织，我先简单给大家看一下，在普元面向构件的平台里面的模型，首先你的企业肯定有你的流程，而流程中的每一个处理包括你人机交互的界面来组织在一起的，而人机交互的流程也是以图形化的方式来表达，而表达业务操作的业务逻辑在构件体系里面是逻辑的构件，也是通过图形化的方式来表达。而逻辑构件所依赖的一些原子的操作是基于提供的一些最稳定的原子服务，成为预算构件来组装的。同时解决各个构件之间的交互的时候，基于一个数据总线的模式。基于这样一个模式的话，我们看到这个构件系统，跟王满红提到的模式也是很相似的，这里面业务构件相当于构件体，而不同的业务构件构成一个构件子系统，从而组成企业的业务构件系统。从开发、部署、到运行都是基于构件包展开的。作为这个方法，它是一个非常可操作的，就是具体结合普元面向构件平台，通过很多的沉淀，通过五年多，在包括电信、金融里面应用案例实践沉淀下来的参考方法，在这些方法里面包括到你的组织机构的设计、你相互成员的设定，知识结构、要求等等，分工，这里面包括关键性角色支持性角色和辅助性角色。这个里面从应用开发的过程来讲，在我们方法体系里面提供了一套统一的方法，进入这个阶段需要什么条件，然后这里面具体推动需要那些控制点，在满足这个条件的情况下，推出这个阶段。所以从这里面，从需求到设计、开发、设计、上线部署到维护，生命周期的各个阶段来做这个描述。我们不会针对每一个阶段进行细化的讲解，我们大概过一下。
作为需求来讲的话，就是说从每个阶段来讲，它从开发方法，就包括你的开发过程和项目管控两个视角来看你的内容。从需求来讲，主要是对你的领域分析模型啊，领域知识需求进行一些抽取之后，变成这种系统实现的过程，这里面的内容的话，如果大家有兴趣，可以推荐大家看，就是在去年清华大学出版的《面向构件的管理方法与实践》这本书，这是普元编纂的。这个阶段的输出和阶段的控制点，以及模板，同时我们也提供了工作量评估模型。作为设计阶段，在这里面，设计阶段里面技术视角工作做了很多弱化。在这里面有个具体工作任务的相关图，在我们对外发布的开发过程的书，包括文档和模板中，都做了很详细的描述。它的过程就是传统上复杂的业务关系，分解成构件，构件又分解成不同力度的构件来构成。这个阶段会输出很多内容，包括项目规范，包括项目分解举证等等这些内容。到了开发规范这一块的话，就是我们提供了一个参考的规范，在规范里面包括命名、开发、设计、使用、配置管理都有比较多的描述。
我们接下来再继续，刚才中断了一下。我们前面讲到了设计这一块是把一个复杂业务化的内容通过构件的方式变成一个构件化的过程，在这里面，这些输出里面，其中有一部分是开发规范，刚才也提到了。针对到开发阶段的话，主要是基于SOA的平台，包括可视化的页面开发，包括页面流转，到具体某一个业务操作，业务构件的开发，最终在这样一个完全图形化的方式上进行一个组装的过程，是企业应用开发的过程。当你开发完之后，基于这样的平台，还会生成一个详细的文档。我这里面也给大家生成了一个小的项目的文档，这个同样还支持包括PDF、RTF的文档格式，在这个文档里面我们可以看到，帮助你形成一些统计数据来了解一共有多少构件包，以及多少个页面文件、展现流、业务流程一共是多少，以及每个构件包来做统计，这样的统计对于评估我们系统的规模，以及量化项目的生产率，在项目管控上都有很重要的意义。然后点到项目层次上，我们这只是很小的项目，只有四个构件包，一个大的企业可能涉及到四五十个构件包，这些提供什么样的功能都有具体的描述。所谓构件包，就是我们王满红总监也提到，就是业务的构件，相当于一个业务模块，我针对机构管理的构件包，有哪些具体的构件，以及具体的构件逻辑里面，构件的创建信息、具体内容，以及每个逻辑图上面我们可以直接看到它的业务逻辑、业务逻辑的名称以及业务逻辑具体的调用时候的参数，同时你还可以通过这个链接进入到业务逻辑层，这就是整个体现了这样一个文档就看到了各个功能之间的调用关系，接口之间的关系，而且整个关系通过图形化方式表达出来，这就是基于构件组装、图形化开发的显著的特征。再回到我们的方法论上面，到了开发阶段，这里面同样可以应用到我们传统开发过程里面，这些都是一样的手段，这里面在测试阶段，我们有这样一个对应关系，从需求到分析到设计到实现是一个软件的过程，你针对这个过程也要做一个逆向的测试，从实现来讲，我做一个单元测试，每个构件都提供了进行测试的工具，然后上升到集成测试，就是传统上面的一些功能性的测试，这个可以按照传统的方式来进行，包括进行相应的系统测试、验收测试都是一样的。因为单元测试划分到开发阶段，所以测试阶段主要是系统测试、验收测试上面。这我不多介绍。
到了集成、部署阶段，你采用了面向基于构件平台，这里面的话，在产品里面提供了一个系统管理维护的平台，成为EOS manager，可以进行项目的管理，构件包的配置，日志级别的配置等等。运维阶段，提供了一个，我们在任何时刻看到当前系统被请求功能有哪些，以及他调用的时长和频度都可以看到。就比如我们现在突然系统上线了，业务部门出现了一个故障，点击按纽没有响应了，你如果用这个基于构件的话，你就可以非常迅速地看到，从功能层你可以跟踪到，具体这个阻塞是因为具体某一个业务的阻塞，又是由于数据库的操作，由于时锁或者查询时间过长等等，这些可以迅速地定位问题。比如历史的情况，我系统已经运行了，这个问题是昨天晚上发生了，通过这个也很容易可以检测，在昨天什么时间，你认为这个时间长度不合理的，如果运行了60秒钟，这60秒钟消化到那些业务上，你可以看到业务逻辑消耗的时间，在业务逻辑里面一般涉及到数据库的操作，如果业务逻辑60秒，其中有50秒时间消耗在某一个业务逻辑上，你会去关注一下，这50秒业务逻辑当中，具体操作了那些数据库处理，以及每一个数据库处理所消耗的时间，通过这个层次，你就可以把你的系统定位你的系统问题在哪一层，这就是运维阶段的工具。
同样的话，你获得这些数据之后，还可以基于一个工具来形成你整个的一些系统运维的报告，这样提供一个检查体检报告，这里面可以基于日志可以看到访问量的分析，看到活动用户的分析，看到内存变化的分析，而这样的数据可以一线的操作，我们可以看到，我给大家看到，这次提供的分析的工具，你可以基于很多的参数制作成一个Excel的报告，你可以看到，这个时间段里面经历的时长，时间段内请求数、平行请求数、每秒最高并发数、请求功能数、时间段内未执行完的请求数、执行超过20秒的请求数等等，同时的话，帮助你形成了这样的一些文档，我们可以看到访问量的变化情况，活动用户的变化情况，以及当时内存的变化情况，还有请求对应的功能和功能执行的频度，最短执行的时间，最长执行的时间，最早访问和最迟访问，以及这些时间里面没有调用成功的点，是分别在什么时间，由什么人执行的什么功能，它的内存的移动情况怎么样，还有就是说你设定的超过20秒的功能请求具体发生在什么时间点上，由谁做的，以及内存移动情况，这样的话就帮助你形成了整个运行系统的体检报告，你可以很容易地判断你的系统当前是健康还是不健康的，不健康的点在哪些功能上面。这是运维阶段的一些特点。还有其他的人员管理、进度管理，迭代开发以及学习曲线的一些研究，由于时间关系，我不具体介绍。
我们前面讲的就是一些具体方法和过程，我们看一下具体的实践。这里面就以交通银行在采用面向构件平台进行IT检测的案例来进行分析。这个分析是完全以用户视角来看的，为什么选择这个平台，以及这个平台怎么使用以及获得什么效果。当时交通银行转型做这个事情的时候，是04、05年时候，因为当时交通银行完成了它的大集中，他需要基于它的总部，它面对很多的问题，这里面我就不具体深入，大家可以看一下，这个也正是很多企业面临的问题。在这个背景下它觉得要解决这个问题有几个思路，一个是购买成型套装软件，这样的话它不需要考虑架构的问题。通过很多的调研，它发现就这个用户来讲，这些并不是合适选择，因为它要被动的去实行这些软件的管理方法、投入也比较大，而且一旦不适应，调整这些软件的时间成本、产业成本都比较大。这样的背景下，第二个方案就是自己建立一个IT架构，因为银行跟其他行业有区别，他们的IT技术服务投入成本非常大的，他们的人员、规模本身足以做这个架构，但是他考虑到这不是它的核心竞争力，包括以后技术演进、跟进等问题，最终也放弃了。最终希望选择一个第三方架构平台，当时也从各个方面，从平台架构先进性、开放性等等，包括开放性、灵活性，当时选择了EOS平台，当时的实施也是分步做的，并没有大规模铺开，因为涉及到一些风险。当时就做了一个客户综合信息系统，在这个系统里面它是多期建设，突出了一些很重要的特征就是在多期建设里面它选择了多个项目团队，这个也有它的背景，并不是有意为之，但是我们看到的结果是各个期里面选择不同的 相关团队，它的后期建设是在前期增量做的，并不是要推倒。这是一个显著的特征，另外就是它的整个统计数据来面，是40%到60%的缩短，另外适应能力变化方面得到了很大的体现，业务的需求，原来2-3周才能改变，现在2-3天就可以满足。项目维护方面，另外就是运行期间运行稳定，到现在两年时间，除了人为迁移、版本更新亿，没有无故宕机的行为。他认为这是非常少见的，以前或多或少出现过这些问题。当时随着项目的实施，它也发现一些局限性，因为前面也提到了，面向构件，在分布式上面体现了一些优越，没有办法形成一个联动的效应，整个IT部门整体建设能力没有得到提升，整体规划和多系统整合能力没有得到体现，另外没有在企业信息系统上面复用。另外它又进一步提高，它选择了一个统一的架构平台，EOS。在这样的选择之后，它就马上着手整个IT组织进行了调整，使得适应这个统一架构平台，同时的话，在这个组织上，基于他们具体的需求来定义了项目管理的方法，软件过程的方法和规范，同时它的各个合作伙伴形成了一个生产面的建设，同时规范了统一用户权限和统一复用机制，这样的话，它去年建了11个系统，今年这个系统会更多一些，包括管理性应用和业务化经用。它树立了一个架构规划组、设立了项目组，设立的构件库评审委员会，这样的话，我前面讲的方法作为这个方法的基础，而且放到整个论证里面去。另外架构规划组的工作就是规划整个企业里面公共的构件库，比如组织机构、用户管理、业务日志等等，这些规划之后，同时基于构件平台进行实现，同时对于一些不能规划的构件，提供了一条开发规范，这个规范在各个项目里面去执行。真正的项目开展之后，它可能会选择一个项目团队，就是一个开发商形成一个团队，在这个相关团队，就是采用一个统一项目管理方法，以及马上去复用这个构件内容，最终它的整个项目开发完之后，通过评审委员会评审，这是它的整个架构。这是一些标准化的文档。另外在页面开发这一块，也充分利用了面向构件模板的效用。就是它的企业应用的效果通过美工固化下来之后，通过基于EOS的开发环境，通过设计人员把风格固化下来，开发人员把这些模板导入开发环境里面，不管做什么，都会体现一个同样的开发效果。这样的话，一个企业开发时间、项目团队也是不同的，但是这样的话，保证的效果就是一个业务部门的人员使用不同的业务系统，它需要在不同的业务系统之间进行体验、转换，提升这种培训，培训成本也会很大提升。它要做的事情就是首先把企业应用界面整合起来，这里面有很多内容，在这个基础上，无论你什么时候开始的项目，无论是由谁，哪一个公司的什么团队做的项目都是基于这样的风格来实现，当然风格里面会提供了几种模板。另外与开发商之间形成了很好的生态链关系，这就是说，要求招标的时候，要求选择面向构件的平台，同时要求开发团队有这样的资质，普元因为提供了相关的一些认证，它要求进行去相应的认证，这样有效的保证了它的技术的能力和技术的质量。同时的话，这里面有很多经验积累。
通过这个带来的效果就是IT管控能力的提升，所以我给大家讲的主要是强调方法与实践的重要性，然后在软件质量提高方面，包括在模块的积累、项目之间的复用，包括软件周期方面，最后的话，在我们面向构件的IT建设路线图上面，确定了三个阶梯，第一个是项目级，主要是快速开发，灵活调整，以及构件组装，到了规划级的话，获得价值就是说你可以建立一个统一的项目规划体系，有效的保证你的项目质量。另外你可以统一数据模式和权限模型，方便信息继承和权限整合，因为有些企业统盘考虑，有些还是在烟囱式的考虑。然后基于统一架构可以减少技术风险，因为统一的技术库可以真正沉淀企业的知识。今年在交行我们已经开展了回归级的模式，因为规划期都是预先的规划，但是预先的规划并不能非常完善，所以通过回归不断的提升和持续的改进。这是回归级别的特征，另外就是说随着规划的开展，你有很多的积累，而这些积累需要统一的管理，包括你构件库的管理，基于构件库的方法和知识，那么这些知识怎么管理，这里面就考虑到知识库的管理和建设。另外需要整合，怎么去整合，还有就是统一架构的平台的实施，你可以积累很多的经验值，这个经验值会为你新的业务的实施提供评估模型，这就是回归技术能做的工作。所以我们现在为交行做一些持续改进。
这是相关内容，由于时间关系，我本来想做一些产品的演示，让大家真正体会到面向构件开发的效果，但是可能我们只能有机会再给大家做深入的交流，我希望通过这个交流让大家感受到EOS的诠释，就是能够很享受这个东西，然后它的很开放的、也是很简单的，我的内容到这里，谢谢各位。 |
| 主持人：我们下面进行下一个。刚才我们是一个SOA的技术问题，下面我们将会谈到SOA的实践，就是我们有了SOA这种规范和标准之后，我们如何去实现SOA，我们第一步应该怎么走。下面我们还是请我们产品总监王满红给大家介绍如何跨出SOA的第一步。 |
王满红：大家好，这一个主题是如何迈出第一步，这个我可能也很没资格讲这个话题，但是这个是一个命题作文，所以给大家讲一下。SOA其实在国内国外，我听说至少已经五年了。如何走出第一步呢，这个也是一家之言，仅供大家参考，我们的观点是面向构件至少可以助力SOA的编程。前面讲得比较抽象，接下来我们看一下普元有什么观点和产品来应对。
首先还是从问题出发，一般我们解决问题的方式是由问题出发。现在企业面临很多应用的现状，也出现了很多问题，首先全球化的压力非常大，无论是联想还是海尔、还是华为，都在走向全球化，全球化带来很多问题，首先是异构网络以及语言的问题，对于软件而言，什么分布式网络等等。再一个经济压力，要求高的同时对成本控制非常严格的，又要马儿不吃草，又要马儿跑得快。再一个就是外包，为什么要外包呢，就是全球资源有效利用的方式，一个是利用人家的专业性，另外一个就是成本，我们和华为合作就很明白，华为的胸怀是国内很多厂家不具备的，他们后来犯了很多错误以后意识到专业性。其实在公司发展过程当中，慢半拍或者成本增加一点就使你的机会在丧失，可能华为能作出比普元公司更好的产品，但是它的时间在哪里，以及它的专业在哪里，他和我们合作两年了，也是给我们一个非常正面的答复，就是说用1%10的成本解决了很多问题。还有一些问题，就是外包有一些问题，就是外包之后，对外包公司的能力提出了考验。还有就是法规，全球化之后有很多法规，全球的、技术的也要遵从。再一个就是技术，技术的变化是日新月异的，我们做IT知道，半年后看半年前就落后了，这个怎么办？就是要有快速的应对。再一个缺乏聚合性的业务信息战略，这个我们刚才谈到了，像右边的图一样，现在哪一个大型企业有单纯的业务系统呢？它有相互的复用性以及不同的数据，不同厂商，不同的基础服务，所有的东西都缺乏一个整体的业务规划，我们所说的业务规划就是真正针对它的业务的，比如中国电信、中国移动，他们关注的是我如何快速的推出一个业务、一个套餐，现在竞争非常激烈了，怎么才能快速推出，这是一个很大的挑战。再一个标准，标准也是压力，现在SOA有56个标准，都是和SOA相关的，而且有些是重复的，有些是冲突的。为什么呢？我们参加标准也知道，其实标准它是双刃剑，标准一方面是商业利益的产物，就是当大家去，有一个市场出来的时候，我们厂商如果相互不协作，时市场是不认可的。SOA出现，没有标准的话，市场是不认可的。但是又有不同的阵营，这样在SOA产生的过程中，导致了两三套标准，有些标准是冲突的，这对用户来说也是一个两难的选择。好在我们出台了一些比较实在的标准。比如说Sun自己出了，微软也出了。
我们看看中国吃上，这是去年IDC调查的结果，就是在中国也有这样那样的问题，就是纯粹的新建应用很少了，只有5%左右，其实大量的是，一个是对原有系统的优化和改造，就是原有的东西我不能丢弃，但要去升级。另外就是整合，有一部分新开发，要优化和整合系统。它也面临和全球差不多的现状，就是整合的环境下开发，开发和整合已经很难区分。其实在整个企业也有这个趋势，我们整个信息化，其实刚开始是部门为主，现在以企业为主的，一个部门是没有能力、没有资格去规划一个应用的。一个就是从项目走向规划，再就是单一走向整合，再就是功能走向架构，我的理解就是说以前业务人员只考虑功能，不关心架构，说这是你们IT人员的事情，这么多年以后，他意识到没有架构也不行，现在讲企业架构，就是说我在开发功能的时候，一定要有可集成性、标准化、安全性等等，这些东西就是架构和本身同时关注的。 再就是技术走向业务，走向一个融合的趋势。这就是IT提升的结果，使IT更好地为业务服务。
所有的问题都需要技术来解决，这就是SOA出现的前提和必然。现在讲EA，企业架构非常火，当然不光是IT，包括人力资源、财务等等，整个企业是一体化的架构，只有一体化考虑的时候，才能良好互动。这和我们前几年做ERP差不多。
刚才讲SOA的出现就是集成和开发的统一，仅仅集合是不完整的，一定要和开发结合。再一个讲了软件治理和监管，就是说我现在开发的同时，要能够关注到用户的最终需求以及它过程的参与，所谓的监管就是在开发过程以及运营过程都希望有用户的参与，也希望有监管的视角。还有一个一体化的，很多东西SOA讲了这么多年，需要技术来落地，需要产品来统一起来。
基本上业界比较认可的SOA的生命周期就是一个SOA从做的过程到实施到追踪，不断优化有几个过程呢？首先是开发和组装，部队，首先是建模，建模之后组装，接下来部署，接下来管理，这个形成了一个完整的生命周期，就像我们传统的过程一样，只是更加庞大，多了一层就是说整个过程当中需要有一个监管和治理在里面。
这个是普元的观点，也代表了大部分技术观点。首先我们看最上面是不同的介入层，接入层现在从移动设备、外部设备，以及传统的都可以接入。第二层是渠道层，通过不同的渠道接入到系统当中。下面是个服务层，就是在这里也有很多可能是比较专业的服务观念在里面，首先注册，很重要的是需要把服务注册起来，管理起来。然后就是策略，然后通讯、组装、安全、事务、绑定等等，接下来是服务的实现者，就是说因为服务和实践是分离的，我们需要有不同的实现来的时候需要不同的映射回去。最下面是数据访问层，包含有不同的数据整合，不同的数据访问，以及SDO本身的管理。最左边是一个开发环境，就是刚才的生命周期里面，我们最重要的是开发和建模，包含了设计和编码调试、测试和部署。然后右边是治理，治理也包含服务的管理、系统安全的管理、认证以及多样性的管理等等。这是比较完整的技术架构来看一个新的SOA应用的架构。在这个技术架构下，我们有一个平台策略，最重要的是什么呢？我们有一个形象的比喻的话，其实面向构件最核心的部分就是需要从构件出来，没有服务谈不上管理，也谈不上治理。所以我们的第一步就是服务的构件，我认为。服务的构件包括对原有系统的分装，也包括新开发的应用。所以SCA是SOA最核心的部分。第二个是流程的管理，就是有了服务之后，我怎么考虑对服务整个流程化的管理，这里面有两方面，有页面流、工作流，业务流程，这是规则的固化，再就是整个企业规范化的描述。第三个是统一服务管理，就是ESB，就是所有的服务需要统一的管理，包括路由、消息转换等等。最后一步就是治理，有了这个之后，我们可以更高级别的规划，可以进行监控和优化。所有这些形成了我们这个SOA平台。
作为企业本身，这里有两个视角来看SOA的成熟度，就是SOA，这个是模仿软件开发过程做出来的，这个不是一个标准，只是一个参考和建议，有几个模型就是说第一个是初始化阶段，就是一个企业刚开始的时候是一个最基础的状态，项目级的，而且项目之间是鼓励的，可重用的构件很少，如果你没有SOA，就是第一个阶段。第二个是可重复的，可重复有类似的第二级，就是有了项目级有了可重复性，就是做的时候这个应用可以再重复，它是有范围的。第三个是已定义，已定义就是说我知道我可以做成什么样子，但是并不是每一个都这样，就是说在一定的团队之间可以做到一定的复用。第四个是已管理，就是一个比较高级的阶段，SOA被认为是体系结构活动的终结点。这个很像CRM第四级，但这个状态是固化的，和人、团队没有关系的。第五级，优化，认为SOA是一个起点，CRM认为自己是在，就像武林派别一样，无招胜有招。从应用级别来看，第一个是Web应用，第二个是Composite，就是复合应用，这个在业务层面有体现。第三个级别是优化，优化的业务流程，关注的是整个企业的业务流程，这是通过我们，就是随着不同的时间，不同的企业可能会朝更高的级别走，而且它的业务价值越来越高，就是每个企业，你的能力体现在你对整个企业的管控和优化能力上面，这是我们认为的核心价值，就是说你有多大能力调配企业的资源，能够去重组、优化，以及你能够有多少精力花在业务上，而不是重复建设以前的底层的系统。
所以我们必须走出第一步，就是对所有的应用进行构件，而且是牵连到可服务型、可集成的，就是面向服务的系统。那么EOS5包含了最基本的服务引擎在中间，然后有一个BUS，然后它会提供一个基础的构件库，可以满足应用开发需求，然后客户可以定制，或者第三方参与进来。左边是一个开发环境，右边是管理和监控，上面是一个，首先有一几个基础的应用框架，然后有一个引擎，和一个副客户端，可以快速的开发部Web应用，以及EOS报表，可以有效的展现。所以EOS5可以帮我们走到二到三个层次，就是首先可以构件一个很完整的Web应用，然后因为这些构件可以很好的组装和复用，可以帮助走到SOA的第二个第三个级别，更高的级别可能需要企业和我们一起努力。在下一个产品中来体现。
我们简单的看一下这个产品，我们有些用户已经体验过了。这是一个图形化的开发环境，左边是一个项目管理、视图，这个管理是基于构件的，就是说一开始我们把整个应用分解为构件包，构件包里面我们分解为，我们叫做不同类型的构件，有业务的，有展现的，有工作流的等等，这些构件在不同层面进行组装，组装成为业务构件，业务构件可以被组装成模块，模块之间可以被相互复用。最重要的是图形化拖拽化的编程，我认为图形化是我们整个计算机软件编程的进步，大大提高了。最右边是基础构件库，有很多数据访问的，以及用户可以自己加入新的、自己开发的构件。这是我们提供的复用构件库，包括各种各样的等等，大概有1000多个。
这里有几个理念，我们原来称为设计即是编码，就是说其实在传统那个，我认为软件开发周期里面，可能有一个问题就是它那个过程太繁杂，其实我们从需求到最终的部署，经历了太多了过程，如果我们有所简化，就是对软件工程的贡献和提高。我们认为EOS走出了第一步。第一个是图形化，就是说提供了图形化的建模手段，这个建模在开发期就消失了。而普元本身的建模就是开发，它本身是不需要再被写的，就是在设计期你画这样的图，在开发期你配置之后就形成了可运行的系统。就是说第一简化了阶段，第二个就是降低了成本。另外，变化的时候可能也变得非常简单，因为我们知道作为设计变化的时候，在传统开发模式的时候，你需要改很多代码。或者另外讲，我们最终的设计文档没用了，可能就是实现那些底层代码才是真正有用的东西。EOS设计本身可以用图形表达，可以快速的适应变化，同时有效的保持了设计和开发的推一行。
这个是我们工作流的建立，我们可以看到是和EOS紧密结合的，再一个也是图形化，再一个有效地利用了SOA的底层构件。这个在电信、金融得到了很多应用，因为这个加入了很多中国特色。同时我们有一个在线的监控，大家看到这个监控和开发期的图形是一样的，而且可以看到目前的状态以及每一个节点的信息，这个很像我们的监理，我认为整个软件在部署期间，可能丢失了很多信息，我们下一步计划就是说能够在运行期，更多的反映开发期的设计思想。就是说我们看到经过编译之后，很多信息会丢掉。我们只能看到部署的特征，比如Java的、EJB的包啊，我们工作流很好的地方就是说运行期和开发期的状态是一模一样的，就是可以看到有效地体现了设计人员的思想，这样在维护和优化阶段可以大大提高人员效率。 这是我们的管理监控，它分为管理日志、错误异常以及一些统计。因为在整个过程，我们认为软件开发过程完成之后，才是一个软件生命周期的开始，就像一个孩子孕育和出生一样，孩子生命是出生那一刻才开始的，软件也是一样的。有了这些监控的东西，我们可以有效地优化和维护。
这里面比较有特色的是你可以看到我刚才讲的业务化的信息在里面，每个构件运行的状态，以及运行的频度，当前占用的系统资源等等，有了这些信息，可以让维护人员更有效地优化和排出故障。
这个已经讲过了，就是我们构件的体系，我们认为构件的关键有两个特征，我们认为构件有两层含义的，一个就是技术含义，就是任何系统都是分为业务逻辑等等，这些是业务构件，业务构件和技术构件是交叉、编织，形成是一个完整的构件体系和应用。
这个体系我们开放的 系统结构，首先这个构件，类似于绑定，我们一个构件可以绑定到不同的实现，而且是部署期绑定的，你可以一个系统在部署期决定是EJB还是Java，你可以用Web services来访问。就是在开发期你可以只写一个构件，我们赋予了多种访问的模式。再一个不同的数据访问，使我们的数据访问非常有效统一。这样的话，而且将来和Web services的集成也变得非常容易和天然。
另外我们提供了强大的拓展能力，就是我们的构件体系建立在EJB之上的，就是说你可以在任何时候写一个原始的计算模式的，这时候我们还提供了很多的横切能力，就是你在业务层，我们分了很多层次，这些层在引擎级提供了扩展能力，就是你在每个逻辑处理前、处理中、处理后做你的处理，这样大大加强了扩展性，而且本身构件是非常容易扩展的。
另外就是应对复杂的技术环境，当你接触应用的时候，你可能基于Web逻辑的开发，但是EOS的开发是不需要考虑这些问题的。就是你部署期你可以部署到任何一个数据库。在集成方面也有天然的有时，有了这一层引擎，你可以在数据层、业务层、界面层，形成了多种集成方式，而且这个力度是任意扩展的，图形化的。我们提供了一些基础的Web services的访问方式以及传统的访问方式，这样就可以粗粒度的集成。
这是对我们EOS5.0的介绍，针对SOA我们也有一个规划，包括正在开发的6.0是完全基于SOA的平台。服务层的支持里面，我们会降到最核心的知识层，把SOA的规范全部降低下来，然后我们会有一个流程层，刚才讲的FLOT，而且这个流程可以分为业务流到工作流，分成几个层次。而且依然是核心化的，可能也会提供一些基本的构件库。我们的产品大致的路线图会在今年发布一个6.0的基础版本SOA平台，它包括了SCA/SDO的支持，以及对某一些框架的兼容以及工作流、报表的迁移。在这个基础上，大家可以开发一个非常标准的、非常容易开发的SOA的应用。在下一步版本，对业务整合啊、建模啊进行一个加强，再下一个版本将对策略方面进行加强，希望我们共同打造一个SOA平台，把我们的SOA推向前进，谢谢大家。 |
主持人：谢谢王满红先生，刚才我们也知道，根据IDC的统计，有52%的企业都会重建，所以SOA的实现不是一蹴而就的，我们只能通过一个一个的实践，使我们的企业信息化慢慢实现。
接下来一个课题是请四川创立科技，我们的合作伙伴来介绍他们在使用普元产品进行项目开发、项目建设以及在这个过程当中，他们的一些体会和认识，下面有请黄海强先生。 |
黄海强：各位下午好！已经下班了，下次建议普元再进行这样的活动最好把饭也包了。我用普元已经两年多了，也有这个资格。下面我们把应用普元一些经验跟大家进行沟通和共享。我今天的议题主要分四个部分，我先把公司做一个介绍，第二、第三、第四结合我参与的项目，到现在我负责的产品线来讲，也是用EOS，结合整个过程，我们在项目中遇到的困扰，以及我们遇到困扰之后寻求解决思路的过程，还有最后实现EOS运用SOA的体会。
我们公司全称为四川创立信息科技有限责任公司，是2006年8月成立，由四川电信实业集团投资成立的全资子公司，公司注册资本为3500万元，我们公司软件研发人员有300人的规模。我们的产品是服务于通信服务商。另外公司处于快速发展的一个时期，希望大家想了解我们公司的话，直接通过网站，先去搜索一下四川创立，然后进去了解一下我们公司的产品。现在我想暂时不多说了，有兴趣可以登陆我们公司网站进行详细了解。
下面进行我的主题，我做一个具体项目的时候遇到一个困扰，首先把我所做这个项目的背景情况给大家简单介绍一下，我们这个项目是给某省电信公司做一个管理的支撑系统，这个项目其实起步很早的，2002年8月份，差不多一年多时间，2003年底这个项目全省推广上线，到04年年底的时候，我们系统处在一个不断完善系统用户变化的过程当中，我们遇到一个问题，就是用户变化非常大，这个变化应该是跟中国电信集团这几年的重大举措是相关的，首先是2003年6月份，已经在实施BPR业务流程重组，然后中间集团的一个验收，在一年多期间内变化非常大的，而且这个变化是整个运营体制的变化，而不是一个简单的小功能。这导致我们原来修修补补的方式满足不了用户的要求。这是我们面临的第一个问题。第二个就是我们这个项目由于周期非常长，对周期非常长的项目来讲，可能大家也有体会就是项目上线之后，其中一部分人员可能会投入到其他项目的研发，由于我们一直在满足客户的需求方面，不但人员没有剥离，反而还在不同的补充。第三个平台的基础，02年做的平台基础非常薄弱的，等我们想整个重新来做这个系统的时候，发现这个代价非常大，另外还有要提出的一个就是流程，因为用户流程的变化也属于需求变化里面的。我们的用户对于我们项目团队，尤其是流程变更的响应非常不满，而且每一次变更对我们系统都是伤筋动骨，牵一发而动全身。我们04年2月份有一个检查，我们整个团队研发人员每天睡五个小时，用了半个月时间才把流程从头到尾实现一个预期目标，后来在调整一个子系统的时候也差不多也是这么大的一个投入，持续一个月才把这个流程做完了，这也体现了我们系统架构的问题。用户对我们的流程要求非常高的。我们04年年底的时候省公司要求我们做第二次开发，时间也是非常紧迫的。这是我们一个项目上线之后遇到的困扰。
遇到这些问题以后，我们就在寻找一个解决的出路，当时我们高层把我们部门经理、我、项目团队骨干召集到一起说下一步怎么做，我们提出的思路肯定不是在原有基础上重构了，我们当时没有想到借用第三方的平台，我们当时想到团队里面有Java的人才，我们当时想用比较流行的框架和一些开源的流程，04年有一个契机就是北京网通的一个类似的系统，我们用开源的框架去实现这个系统，实现起来还是比较快的，但是实际上在运行的过程中我们发现，它虽然用开源的工作技术实现了所有的业务流程，但是它在实现流程变更或者新增流程等等这些，依然是达不到用户的要求，也是周期非常长。最后我们就把这个结论拿到公司分析的时候，我们公司副总说，现在必须得考察第三方厂商提供的先进的平台或者符合这种SOA架构的一个产品，借助这个产品抓紧实现我们的系统，而且不想让我们开发用一年，上线用一年，再以后，就又再推倒重来这种重复。当时SOA的概念也不是特别的流行，我们当时对这个平台要求非常简单，就是第一，这个平台要有工作流的产品，它的工作流要符合我们复杂的业务流程。第二个就是，我们当时已经跨度两年多了，我们整个团队的流失也比较严重，当时Java我们只有六个人了，我们希望这个平台能够缩短它的开发周期或者降低成本。当时非常明确的目标，我们考察几个厂商的产品，包括国外的，有四个厂商的产品，我们来进行体验、评估，其实这个时间也比较短，那是05年的4月份，用了一个月的时间，我们评估包括普元在内的几个产品之后，我们最后觉得还是通盘来看，EOS这一块跟我们实际要求比较贴切的，时间比较紧了，我们就决定用EOS了。我们用了半个月的时间，用了一个EOS并且经过培训，我们项目二期的启动就是05年6月份，二期开发整个用了半年的时候，就是05年年底二期上线。其实最开始应用普元的时候，我们也是有一定的顾虑的，到现在应用普元两年多时间，我们项目团队也有一些真切的体会。这里跟大家说一下，因为刚才袁义也说了交总行的一些体会，我结合一些具体项目给大家说一下。
首先就是EOS的随需应变，这一点还是非常明显的。我们二期上线，我们原先的系统依然存在客户提出新的需求，依然在改变以及加入新的需求，我们用了这个EOS才真正满足了用户的需求方面了。以前原来的架构响应用户的需求平均来讲要三周时间，应用了EOS时间缩短非常明显，基本上就两天到一周左右的概念，我觉得这一点体会非常明显，用户也是因为这个，本来对我们这个团队是不抱什么信心的，现在又转变对我们的态度。结果我们那个项目团队得到客户和公司内部的高度认可。
另外说一下工作流这一块，要说太细了，可能要结合产品的特性，什么自由流等等的东西。我想说的就是在我们那个，因为这套系统二期的时候，我们所有的业务流程都可以通过普元的EOS工作流程来实现。
第三个是图形化的开发平台，这里有两点，第一个就是降低了开发人员的门槛，我06年7月份当时招聘了两个新毕业的大学生，他们一个月时间完全就可以上手做EOS做一些不是特别复杂的开发，两个月之后就可以独立承担开发任务，包括工作流这一块，就是说开发门槛明显降低。另外我说为什么要图形化平台，真正体现了面向业务、面向客户的平台，以前传统的开发模式，一个功能和一个需求拿到以后，我们就要去想，我要去怎么实现，然后实际上我们在，尤其我这个项目体现得比较明显就是，用户今天说是，我觉得这样做比较好，然后我们就改了，用了一段时间用户说原来的方式比较好，又改了。调整起来比较方便，但是开发人员非常郁闷，就是说你需求人员怎么不把用户需求分析清楚，你怎么不告诉他原来的方式更好，或者怎么改进不会出现反复的状况。所以我要求不管是需求分析人员还是开发人员，重心很大部分来学习业务知识，你去来分析，什么样的客户需求是它最终想要的，而且在实现过程中，通过这种图形化界面，你的思路就会一层一层的展现出来。我觉得这一点是体现非常明显的。另外一个我想强调的一点，因为有EOS，我们招人、用人的时候，他们有这样的顾虑就是职业上、职业发展的顾虑，就是用了EOS之后底层开发接触很少了，我将来假设功能化有问题怎么办？或者普元哪天走不下去了，我将来去干什么去？肯定会有这样一个顾虑，实际上我们在实际应用过程中，发现它本身是基于行业的技术标准的，可以跟，当然现在是5.0、5.1、5.2的版本，今年年底6.0的版本了，目前的版本的话，主要还是对Java这一块还是有一定要求的。实际上我们发现，能够很好的EJB的开发技术结合起来。我们当时与其他系统接口的时候就可以非常方便的使用。同时我们5.0的时候，我们开发工程师就可以拿这个技术来实现界面的一些效果。这个是普元在5.1的时候才提出跟EJB的无缝结合。另外就是子业务流程的时候，我们当时也用开源的技术包。它可以跟当前的技术非常好的结合起来，而且我也给大家灌输一种思想，如果你想更好的驾驭、掌控EOS，相关的知识你也去了解，只有这样你才可能更好的去使用EOS，你SOA的体验肯定会更深刻。
提到EOS，肯定要说到构件化开发的理念，首先第一点就是提高了代码的复用度。这个在我第一次用EOS，时间比较紧迫，当时规划没有做得太好，所以复用没有做得太好，当我们用其他项目上的时候，这个就体现出来了，一个项目开发的构件，可以直接拿到另一个项目用，而不是重复开发。同时我们以前，这个项目从一期、二期到三期，纵向项目经验的积累，或者知识的积累，以及各个产品部横向的互动，以前没有一个非常好的途径去共享这些知识，沉淀这些知识。我们应用了EOS平台项目，这一点就提供了一个非常好的途径。还有就是应用EOS之后，这种构件化开发降低了人员流失带来的风险。我们对于跨度比较大的项目来讲，人员流失还是比较频繁，人员更迭的话，以前传统开发模式，原来每次人走之后，工作交接对项目影响非常大，现在你可以导出文档，工作交接基本上不存在什么问题。所以人员流失带来的风险降低了。
还有一个就是管理控制台，提高对系统管控的能力。我们一直用得比较广的就是统计数据，当然袁义说的分析到处报表还没有用过。但我想常用的就是统计信息，我们会分析我们所做的这些东西，运算路线这些，哪一些是使用频次最高的，那些是耗时最长的，我们去分析、优化，同时也会出一些共用系统，一些附件，达到共用附件的目的。
还有就是我们用了EOS两年多，最开始我也还是没有底，用了两年之后，普元的一些活动给了我们最早吃螃蟹的人一些信息。因为从5.1，我们发现业务开发没有大的减少，用了5.1之后，在这一块的工作有所减少。还有就是5.2和5.3平台的不断升级，同时我觉得普元EOS能够加入到国际化的标准组织，以及EOS在其他行业，比如交总行等等，还有电信等其他大型企业成功案例，也坚定了我们的信心。
最后我想，还是要提一下普元的服务水平和质量。因为从最开始到现在两年多合作关系来讲，他们的服务和服务质量我觉得还是非常满意的，这也体现到三点：首先就是非常周到的售前服务。在我们想了解的时候，它会寻求各种支持来介绍这个平台的特点。我体会比较深的就是我们通过这个普元的售前人员，他成了一个纽带作用，让我们了解同行业的信息，让我们和其他厂商或者合作伙伴加强这种交流，这种碰撞往往使我们平台的演进等等都会起到一定的促进作用，我觉得这一点还是非常好的。另外就是普元提供远程的支持，就是MSN、电话等等，我们举一个例子就是5.0升5.1的时候，这个版本升级跨度比较大，那一天我专门打一个电话，今天晚上要升级了，你要留一个人，当天晚上出了一点小问题，他们也一直陪伴我们到12点左右。另外就是我们团队不断新人加入进来，要不断的培训，我们又没有太多精力去培训，我们每次都请办事处的人进行培训，以及我们系统升级等等普元都在现场有效的支撑，这一点效果还是非常明显的。
我的EOS的体会相对比较仓促，如果大家有兴趣了解沟通的话，我们下来可以再沟通。我就讲这些。谢谢！ |
| 主持人：谢谢黄海强先生，黄海强用了EOS两年多三年时间了，而且这期间给我们提了很多中肯的意见和建议，我们随时也在反省自己，怎么样对合作伙伴、客户支持得更好一些。 |
| 主持人：第一个问题是刘军提出的，他提出的一个服务有100个系统使用，而这个系统并不遵循SOA架构，而且都封闭，是否这100个系统都要改造？就为了使用这个所谓的公共服务？比如，一组存储过程，如何能使用这个服务？ |
| 主持人：谢谢黄海强先生，黄海强用了EOS两年多三年时间了，而且这期间给我们提了很多中肯的意见和建议，我们随时也在反省自己，怎么样对合作伙伴、客户支持得更好一些。 |
| 黄柳青：我觉得这个问题其实有两个答案，一个是比较短的答案，一个是比较长的答案。从短的答案来讲，就是短期来讲，我们上SOA，我们不可能也不必要把所有的系统全部重新来做，所以从短期来讲，现在的系统进行一些封装的比较多，像重组过程，我们可能，把它封装成一个服务，然后就可以在其他地方进行使用。但是在封装的时候，因为是比较直接的封装，没有做大的改变，所以它的功能适应性比较差一点。从长期来讲的话，我们发现，SOA并不是一个新的技术，更重要的是它是一个全新的思想，毫无疑问所有的软件都要重构的。比如我们社会变革，我们一个小城镇，开放改革之后，所有的服务都会改变。这个并不是一个时间发生了，而是在时间轴上面发生的。 |
| 主持人：他还有一个问题，SOA对性能方面的考虑如何，是否可以说其性能其实是由各个服务本身的实现决定的，和SOA无关？ |
| 黄柳青：其实SOA性能跟SOA的实现相关的，特别是数据库相关，因为在一个平均的操作里面，数据库的数据比较小的时候，可能70、80%都在前台、中期的处理，但到上千万的时候90%都在数据库，所以对越大的系统来讲影响越小。但是SOA确实会对数据库带来损失，但是这个性能损失是非常有限的。实际上计算机的运转速度是越来越快，这一点代价应该来说在整个系统里面是完全可以接受的。 |
| 主持人：下面是余先生提出的问题，问题是采用普元的产品怎么实现多个已有应用系统之间的业务整合以数据交换和共享，主要想知道和了解其实现的架构。 |
| 袁义：我先认识一下这位余先生。关于这个的话，多个业务整合数据的集成，实际上这一块的话，它的主要的问题就是在业务整合的时候，每个业务单元是可以在原来的系统里面是不是可以被分离出来，也就是说SOA里面强调原有服务的包装，这一块的话，传递的一个重要信息是SOA平台是面向新的服务的创建。一旦把服务分离的时候，可以基于普元的业务流程协作起来，这一点可以达到的。实际上我感觉的情况就是，因为我参与项目比较多，真正一个已经做好的系统，可能是一个COS系统，也可能是BOS系统，如果你没有考虑到未来变成服务的话，你现在变成服务的话，这个难度非常大的，一个是工作量，还有就是架构不合理性，你改变的代价可能不亚于你重构的代价。所以我强调的是，SOA在中国环境下面可能重构合理一些。你通过EOS整合的方式都是可以的。 |
| 主持人：如果大家有兴趣的话，欢迎大家以后到办事处。 |
| 主持人：基于SOA和项目培训管理培训，怎样的方式提供？能达到怎样的效果？ |
| 袁义：这个有两个形式，华东今年做了四期了，这个是公开的，包括像交行、建行、江苏电信、浙江电信、联通等等一些IT部门的项目经理，我们开为两天的公开培训，我们也会针对用户的具体需求，包括具体的IT情况做针对性的咨询，这样的话可能会深入一点，可能先做一个培训，然后结合它的情况做一些客户化的工作，因为这里面讲的两个内容，一个是开发过程，一个项目管理，这凉快怎么结合起来的，怎么完成管控的手段，这个是需要咨询的，刚好这周六还要为交行做一个培训。这个是一个参考的东西，并不是一个纯理论的，所以相对来讲可操作性非常强的，包括项目规范等等，都是很细节性的东西。所以一般接受这个培训的对象最好的方式就是说你接受了这个产品的培训，对它的使用有一定的了解，这个时候可以做这样的培训。 |
| 主持人：还有一个问题是王满红先生提出的，什么时候构件的产品能够开源？ |
| 王满红：开源我们有几个策略，一个是直接参与开源组织的，关于SCA的规范贡献一些模块。我们本身的开源分几个模块，一个是构件库在不断开源，我们那个Studio可能早一点时间开源，模块分阶段，基础服务可能逐渐开起来。再一个根据客户的具体需要部分开。 |
| 袁义：现在我们EOS这边，建立了一个开源的网站，那里面我们建立了很多的机制，已经放进去小的项目，包括组织机构管理也是一个开远的项目，另外构客网也有一个知识库，把一些知识性信息也放进去了，慢慢的这些东西会越来越多。 |
| 王主持人：还有没有什么问题？如果没问题，今天就到此结束，非常感谢大家能够坚持到现在！成都办事处是开放的，欢迎大家随时光临我们办事处，高棚大道12号。 |
现场精彩组图
