Scott Shaw主题演讲

主持人：SOA和迭代开发如何能够结合在一起，和敏捷方法如何能够结合在一起为企业创造更大的价值，我们现在请来自ThoughtWorks澳大利亚公司的给我们Scott Shaw做关于“SOA塑造敏捷企业”的演讲，大家欢迎！

Scott Shaw：大家下午好！感谢大家给我机会下午能够来到中国做这个演讲。我是在澳大利亚工作，对澳大利亚来说他们是非常关注中国的，中国是亚太地区的一个国家，中国和澳大利亚他们的未来应该是互相联系的。澳大利亚认为中国是他们很好的机会，所以我觉得接受邀请来到今天的大会是非常高兴的事情。

首先请问一下大家是否听说过SOA面向服务的技术构架？你们知道这里面所谓的服务是指什么吗？比较典型的是大家都听说过SOA但是并不是特别清楚了解SOA里的服务是什么？我参加过一个面向服务平台的项目，是上千万欧元的一个项目，再请问大家SOA和我们的网络服务有关吗？我认为SOA和网络服务是相关的。首先讨论一下今天为什么要谈SOA，同时要谈一下它和敏捷的关系，再谈一下什么是敏捷和SOA的综合。

　　我认为我们是轻量型迭代性的SOA的方法。首先我们敏捷的团队如何帮助SOA的交付和面向服务的架构？有什么促使我们能够完成这些工作的驱动力？敏捷在架构里面的作用，最后做一个简单的结论。发言快结束的时候大家要提醒我一下做一个总结。

　　我是一个编程师，也是一个软件开发师，我非常荣幸ThoughtWorks给我这个机会，跟大家相比我可能年龄稍微大一些，当你年龄大的时候大家会把你称为构架师，对SOA的参与我过去认为是不大可能全面参与的，因为我们对所谓的构架和构架师是持怀疑态度的。同时我也非常关注一个系统在大规模范围内如何进行交流和互动？系统如何互相联系和互相交流呢？计算机互相联系的时候也是比较有意思的时候，我整个工作生涯中就比较关注电脑能够如何互动？不是每一个单独的电脑个体的一些活动，电脑作为一个互相联系的网络它的方式就比较有意思。

　　有许多组织受到误导，认为做SOA就必须买非常昂贵的中间件，我们是希望用演进式、迭代式的方法并不一定买昂贵的中间件做SOA。也可以用轻量级小团队一块一块的做，最后组织成一个大的构架。

　　一个组织如果要有SOA构架的话，就可以用我们的敏捷方法来做。作为一个项目如果用敏捷方法来做，很可能这个项目是与SOA相关的。几乎现在所有的项目都有一定的服务成分，比如说要和远程系统进行处理，但是在敏捷方法中对外部环境是有一定依赖性的。现在我谈一下什么是服务？传统的SOA方法，服务它是耦合，异步的，这是服务的比较稳定的定义，但是还不够精确，服务它还有不同的具体表现形式。还有什么是服务呢？（图）灰色它是代表服务，绿色是代表服务的质量，下面是传输，这几点是要分开的，我们的业务服务应该是独立于服务的质量，也就是比如说安全的要求，或者可靠性的要求，或者是交互性的要求。同时还要独立于传输，就是各个服务之间互相联系的传输也应该独立于其他两点。服务的重要之处在哪儿呢？它必须要实施拟定的业务流程。比如说一个贷款应用服务它与邮件审批服务、信用评级、与支付服务之间是互相联系的，这里面当然可能有一些人的成分。所有这些服务就我们敏捷SOA的方法来看它不仅仅是一种技术性的服务。同时必须是信息驱动型，也就是说它们不是把这些参数进行互相的传输，而是把文档进行互相的传输，同时也不一定要获得回应。我们可以把新的业务程序通过过去旧的流程重组之后再融入到现在有关的程序当中。也就是可以把每一个部件拿出来换一个新的模块。要不就是把新的业务的流程融入到旧的业务流程里面去，领域也要有一定的独立性。所有的这些服务都不知道谁是客户，谁是顾客，这些服务它的开发都应该是独立性的有自己的独立性。

　　另外一点也是大家经常忽视，它不应该在乎什么传输方式，所有这些服务都是与传输无关的。也就是说不管是用FTP传输什么都无所谓，你所重视的只是这个服务要实现什么流程。总体来说我们一般是用XML方式在服务之间进行传输信息。

　　前面我没有谈大家为什么要用SOA？对这个我是比较热衷的，我也是一个推动者，除非它对你的业务有好处，否则就不要用SOA。面向服务的架构它使你们的业务更加敏捷，它可以不断的适应变换的环境使你们保持竞争性，这是一个生态的系统，应该是一个欣欣向荣的架构。这和过去大家对SOA的看法是不一样的，我听到一些企业的架构师他们把SOA看作最终能够实施秩序的过程。也就是把所有的数据都放在一个架构里面，完全用一个技术解决所有问题，我认为这是完全背离于SOA的本质。SOA的架构是一个有呼吸、有生命的东西。现有的服务会慢慢的消亡，新的服务又会进入这个系统中，作为一个构架师要确保找到有土壤的价值，帮助我们的服务不断适应服务变化的流程。SOA是一个散列性的结构。也就是说不可能是完全有秩序的IT的架构，应该是让各个服务能够有创新的交流这是SOA的目标之一。服务也可以出现新的使用，企业也会出现新的方式，又会出现一些新的服务，这些服务可能是软件开发商从来没有服务过的。

　　不幸的是这跟敏捷是有一定距离的。我们过去知道如何用敏捷的方法做单独的应用，做SOA是管理整个业务流程的一个大的框架。做SOA的时候必须要了解每一个具体的业务，首先这些服务可能属于不同的组织。可能在不同的时间、不同的地点进行开发，这样很难有一个单一的团队。敏捷的基础点就是一个团队来做，这是我们的价值观而已，也就是单一的团队包括我们的测试员、开发员、业务员。总体来说SOA的服务意味着应该有多个团队，这是用敏捷方式进行SOA的基本困难之一。

　　另外这些服务之间是通过XML信息传输进行交流的。这好象也没有什么意思，这是违反敏捷方法论的。我们敏捷项目重要的问题就是当我们编程完成之后要进行交流，进行功能测试，我们要找BA过来，BA说把这个故事签发，实际上你是给他看一个网页，99％的系统都是这么做的。我们有一个实物的东西，BA他们亲眼能够看到的最终的产品。XML怎么做呢？不可能让BA过来读，我现在是做一个项目，把XML送到外包公司，我们现在做了6个XML文档，我们给他们做一些目录，这些目录挺无聊的，也不知道客户到底是不是赞同这个成果。另外一个问题是传统的SOA的方法强调大型的前期的，也就是CIO确定，现在要这样一个SOA的系统。我们的咨询师就把博士学位的设计者带过来，他把所有的资源都给你，他告诉各种各样的服务，我们按照他们的计划来做。我做一个服务的项目的时候，当我开始编程，他们计划对我来说是毫无意义的。而且对于我们的这种方法论还没有进行具体的实践。尤其是我们看到在方法论具体实践过程中会出现各种各样的情况。所以在业务的运作过程或者组织运作过程中可能会出现一个非常大的不弥合的情况，很多人遇到不弥合的情况可能会非常的受挫，如果一个大公司做一个大的改变的时候，也许非常困难去运作。因为公司有些东西是固有的，做任何改变可能要做其他的连带改变。当我们做各种改变的时候应该就细小的细节做短期的改变。

　　所以，我们必须把它连接起来，也就是说要有一个好的驱动因素，比如说在每一个单个项目中我们并不知道它的规模应该是多大的。然后还要讲一下其他的做法，尤其是现在正在做的SOA的方案，首先就是临时的测定解决方案，或者是点方案。我们之前的团队做事时候可能是系统和指令系统之间对话，是端对端的沟通，要做这个工作我们要有一个特定的解决方案，就是点对点的解决方案。但是它所存在的整个生态环境并不适合，因为也许这种生态环境并不是长期的，的确如果这种解决方案合适于某一个特定时间大家都很开心，但是如果随着时间的推移整个生态环境不适合生存下去。所以我们必须要看这个临时的解决方案是否有一些可取之处，然后再下一步解决。

　　我们看到的是大的前沿的或者是前期的服务设计，我们看到的是比较前沿的团队，他们开始的时候就必须参与其中，有些服务他们是参与其中，有些是他们可以决定是否是今后运作的服务。所以要有一个沟通协议的签订，尤其在进行网站服务的时候他们也必须要明白这些服务的设计，从一开始就应该面临不断的变化。而且他们每天沟通的时候要知道自己所运作的内容应该有一个互相的衔接性。我们希望有个更加具有容纳性而且更广泛的生态系统。我知道做这两点非常困难，然后他们会进行软件的开发，有些人会说我们做的产品可能会非常复杂，而且需要的时间比较长。我们要看到终端的开发它仍然是处于非常孤立的而且是无声的，可能需要不同的传输层运作，需要依赖于传输层之间的运作，这样我们开发的时候没有一个重点。

　　要做这个演讲可能要花很长时间，但是我要说，我们也在考虑终端的衔接。做互联网和做软件是有一定区别的，我们需要有一个协议，然后根据这个协议不断的进行开放的信息沟通。而且这种想法在互联网领域是非常合适的。最后就是网站出来的时候可能会在终端缺乏一种衔接性。

　　看一下这种迭代式的方法是具有革命性的，而且是先驱性的，我们所关注的是业务本身。而且不会去关注你要使用的是什么样的工具，不管你用的是什么样的方式和基础，我们所要做的是关注业务本身。当我们看这种服务的时候，或者真正运作这些服务的时候要关注的就是最终的解决方案。我们不用购买终端服务，我们所要做比如说可以自由下载，方法是多种多样而且很容易获得。我们不用购买非常昂贵的软件，我们只用做的就是请一个非常聪明的开发者来提供服务。网络服务基础设施首先它需要的是非常高端的应用，什么样的服务是可以得到高端应用的呢？就是这些服务之间是需要互相对话的，在一个共同的界面上进行对话。其他的一些高质量的服务他们是否能够编写和拓展？服务如果能够互相对话的话可以通过一个方法也就是信息交换来实现。这种设施的集合也是网络服务的一个非常好的应用，如果你们有非常有用的工具进行转变的话那就很好。但是网络中也许不是传统的技术可以获得很好的体现，也许有些时候不需要一些传统的技术，因为某些技术比较昂贵。

　　　（图）这是一个传统的Agile的模型，比如说有一些小组的结构开始开发SOA，首先第一种形式就是垂直型的小组，这种方法是非常好的，在各种不同的层面上都可以运用。这幅图就是整个系统，我们有一个工作小组，它包括了客户和服务之间的连接。而且中间会有一个共享的平台，或者有一个共同的协议，协议体现了两者之间的连接。而且这也是非常传统的，敏捷的，但是不幸的是它不是可以获得很好的推广的。尤其是它可能在某一个层面上会出现孤立的情况，因为它可能会出现时间的滞后，所以最后可能它在时间上会有分割，或者落差，或者组织和组织之间有障碍，但是不管怎么样我们有更多的组来收集服务的要求和服务最终的提供。

　　我们希望进行这种服务的协议，尤其是应该对文件进行说明，对于我们所获得的信息和消息进行说明而且还要进行互相的交流。我们不可能像以前敏捷所说的在基础设施上进行共享。我们能共享的只是服务的要求或者信息的共享。我们如何能够鼓励这种变化带来更优化的敏捷服务？这个问题非常艰难，而且我们不断寻找这个问题的解决方案。看一下我们有什么样的方法？

　　首先是业务和架构上的方法。我们可以去使用一些已经成型的商业程序或者模式，我们不仅仅只是关注一个技术上的解决方案，如果我们能够更好的说明收入和产出之间的关系的话，也许就能寻找出一个很好的服务方案。尤其是在整个过程中对于一个业务来说，对于我的最终要求来说它可能都是一个很好的解决方案。比较典型的就是如果只是用一些业务程序的话可能不能解决很好的服务，所以业务和服务有一个很好的沟通。我们要有一个实物形式的文件来表示业务的具体需求，包括比如说发票、专货单、信用评级文件以语言的形式来形容出来整个过程中这些文件应该是以什么样的方式体现。尤其是一些非常技术性的语言我们都必须以实物的形式体现出来。

　　我们的业务本身应该跟这些条件参与服务的交付。我认为我们的服务改善过程中是从XML转变成实物的过程，是需要时间建立服务的发展。而且从XML一种语言文档转变成实实在在的服务这需要保证各个环节都能够衔接得上，而且还要进行最后的测试。尤其是这些功能的测试，还有整个框架是否能够通过最后的测试？我们可以定义一个转变过程，但这需要一个外部测试检验。我们刚才讲到了测试非常追求，而且也需要一个标准进行互动，对互动和参与进行一个标准的制定。我们每一个游戏都需要有自己的规则，这些标准就提供了规则的框架。

　　当然了还要提供传输、治理的标准。刚才讲到了治理，在讨论SOA的时候治理总是我们不断要探寻的话题。有些人会说这个事情非常难做，是因为什么？是管理出了问题还是其他的问题？作为一个团队如果要和其他的团队进行高效率合作的话我们需要互相的衔接。而且我们也需要非常好的环境，这个环境需要我们很好的治理才能营造出来。

　　（图）这是一些软件的开发工具，比如有应用工具，首先就是可伸展的具有包容性的服务协议。大多数人在说SOA的时候没有人质疑标准文档的服务，但是文档非常有局限性，而且表达性也不一定非常好，我们首先要考虑时间的推后性，尤其是我们看到了这个文档对于整个过程有异议的时候才能说应该开发一个Schema，我们必须要用动态的方式进行文件的交互，尤其是获得新消息的时候需要非常动态的方式及时的反应交互。我们也需要测试框架，同时我们还有很多工作，在测试框架的时候具体工作是非常复杂的。尤其是对功能进行测试，对它的服务模式要进行测试，而且还要进行单元测试。我们这些自动功能的测试就变得非常重要了。

　　对于一个架构者来说有些工作非常重要，他必须要有一些职责，尤其是SOA要保证大的环境非常好，所以我们叫这为架构。作为一个架构设计者来说它最重要的工作就是要把自己适应整个环境中，比如出现新的问题是不能表现出自己不能适应。有些时候架构如果出现问题，有些服务不能运作的话我们的架构者要做的事情就是去磨合这种不适应性。我们也必须提供一系列好的标准，而且把这些标准整合起来。比如说我们有很多文档，如何把这些文档归类这就需要一个特定的标准。但是不同的生态环境中可能标准不一样，要做的事情就是择优。而且要保证我们的软件开发是演进式的。同时更重要的希望大家也到目前为止学习到了这一点，最重要的就是我们应该保证服务和服务之间是能够互相对话的。因为我们有很多项目要去运作，我们有SOA，在SOA整个架构下有很多项目是在不断的同时运作，这些项目之间要进行对话。

　　最后做一个小结非常感谢大家花时间听我的演讲。SOA不能进行大规模前期的投资，另外SOA是一个非常困难的问题，你要做的话必须在不同的层面都要解决不同的问题。包括我们有开发、另外有组织的方式，应该有迭代型的、轻量型提供的方法，也就是只做必要的东西就可以了，不要做太多。我认为现在服务描述的标准还不够充分，我们应该继续改变服务的描述方式，以便敏捷开发方式可以使用。此外我认为在需求方面的工作还有很大改善的空间。

　　我今天花了很多时间谈了敏捷方面，另外我明天也可以谈一下过程中的测试等等。

主持人：非常感谢Scott? Shaw给我们带来精彩的演讲。为了方便交流我们请ThouhtWorks中国公司副总经理郭晓先生统一回答大家的问题，这样可能会更方便一些。

问：SOA有很多优点，也可能有很多问题，比如说安全方面，如何保证它的安全？另外是一般是通过XML传递的，SOA可能比正常的服务低一个数量级，就是速度特别慢，如何解决执行效率问题？

Scott ?Shaw：安全性取决于你要什么样的安全级别，有的安全级别不可能完全安全，所以这取决于您要什么层次的安全的级别？也有低级的，比如两双向的访问权限，可能它就不行。如果想安全级别比较高，比如是做中介的工作很可能双向就不行，做中介很可能就要点对点。

郭晓：有一套安全机制，这需要访问者和接受者统一接受这个标准，这是有一套机制的。

问：SOA我感觉它跟Serevs还是有区别的，现在我们更多的是SOAP方式实现，我们有没有可能用别的方式实现？比如说解决效率的问题，SOA最好的是它提供了统一的接口解决了互操作和互访问。那我们能不能自己定一种标准来做？

Scott Shaw：您的这个问题我也问过自己，当然你可以用TCP、也可以用HTTP，但是这和SOAP不一样。在有限的联系和我谈到的网络服务的标准是不一样的，如果你要用其他的必须要有自己的标准。我们今天谈SOA，SOAP它确实不一样，如果你有其他的一系列标准能够满足你的需求，那你就做那个标准吧，我不知道现在还有没有其他的可以满足操作的标准存在？我还是希望你不要用HTTP，最好还是用MQ、MSQ它们可能比HTTP好得多。

问：在这些标准里现在有没有一些组织的既定关于识别技术，比如现在我们国家的一些web Serevs里面讲到识别技术，比如计费、身份识别、还有一些清算，是不是有一些组织和公司研究这些内容，它现在发展的状况是什么样的？

Scott ?Shaw：我不知道有什么人在做这个，但是这并不意味着没有人做，你必须要特别的小心，让运营商不要拿到这个服务。因为在网络运营商方面他们是完全有能力把这个市场份额拿走的，也就是说我们提供这样的服务我认为是非常和的想法。但是网络的拥有者当然想从你的手里面把服务份额拿走。

问：请问一下SOA的运用到底怎么样？

Scott Shaw：如果你不把其他东西拿走的话就不需要ESB，我认为是需要一个聪明的开发者。

问：如何使服务的合同也是敏捷的？我们的合同应该是可以修改的，可以敏捷的，合同都定下了怎么去改它呢？怎么适应新的需求呢？

Scott ?Shaw：这些服务的合同不会影响我们的变化，图式它在合同方面会有很多描述的选择，我认为一个小的需求级可以创造出其他的服务解决方案提供给其他的用户，这两个用户很可能是用不同的服务。

问：系统运行之前知道什么是符合什么是不符合的呢？

Scott ?Shaw：我认为我们应该用的是宽松的，松散的类型不应该用僵化的类型，我把网络看成一个服务的模型。许多人不喜欢现在的网络浏览器，我认为WEB是非常好的，它是全球建造的最好的分布式的系统，它有一定的灵活性，服务也具有灵活性。谢谢！

【发表评论 0条】