读《Grady Booch 讨论 IBM Rational 桌面工具的 V7 发行版、SOA 和 Eclipse》

读《Grady Booch 讨论 IBM Rational 桌面工具的 V7 发行版、SOA 和 Eclipse》

         刚刚读了Grady Booch主持的一个关于SOA的在线讨论的谈话记录，它被发表在IBM developerWorks，你可以访问该链接看到这个记录——《 Grady Booch 讨论 IBM Rational 桌面工具的 V7 发行版、SOA 和 Eclipse》。 
         我在2005年末开始关注SOA的相关主题，我的视线主要是从技术角度深入的，同时我是从需求与过程认识SOA的。这一点与Grady Booch所持的观点相同（大多数人也可能认同这种观点，这也是我最初坚定不移的，然而随后许多做市场宣传的人出来讲SOA，把我最初对SOA的认识改变了，甚至迷失了，而从Grady的顾虑来看，是我看到的很多人对SOA理解存在错误——“SOA 的最大顾虑的问题：我的体验是组织未能理解正确的体系结构——以及导致该体系结构的过程——是正确使用 SOA 的前提。”）——

Bill Higgins：Grady，是什么在过去几年来导致人们对 SOA 产生了浓厚的兴趣？它是技术驱动的还是市场驱动的？

Grady Booch：我认为它是事物发展的必然结果。曾经有一段时期，各个组织忙于 Web 化 (Webify) 他们的系统（如果“google”是一个动词，那么我当然也可以使“Webify”成为一个动词）。在此期间，各个团体设法获得合适的体系结构来将过去对客户不可见的功能置于在线。因此，随着 Web 标准和最佳实践的发展而存在技术“推动”，还存在着象征需要此类访问的客户的业务“拉动”。大多数组织都完成了较易访问的资产的 Web 化，现在最引人注目的潮流是使较难访问的资产变得可访问——即传统上处于非以 Web 为中心的遗留系统中的资产。所以，体系结构问题就是……如何做？

当然，此类异类系统之间的连接并不新鲜。远程过程调用、文件共享、FTP 等全都是众所周知的机制，诸如 CICS 等消息传递机制或诸如 CORBA 及其后继者最近所展示的机制也是如此。如果您有以 Web 为中心的系统，并且您希望通过防火墙传递消息，好了，这就是 SOA 的起源。我们如今看到的 Web 服务实际上解决的是使用标准 Web 协议来通过防火墙传递消息的问题——即带大 S 的 SOA。这就是我认为人们当今在为 SOA 而努力的原因，也是为什么支持它们的工具现在是如此及时的原因。 
       作为分布式体系结构的一种，SOA主要解决异构系统的远程调用问题，和EJB等一样。而在SOA中主要采用Web Service，大写的Web Service特指SOAP Web Service，经过一年多的发展，它越来越成为业界的标准了。
       我曾在2006年4月份写过一篇有关SOA的文章，主要讨论Web Service——实现SOA的首选方案——的本质，和ESB，其实那时我的设想还是从模仿硬件体系结构出发，进行隐喻的。后来我接触的澳大利亚维多利亚理工大学的研究成果，其主要是构建中间件——在我看来就是Workflow和Adapter的结合。在我和国内某中间件厂商的技术人员——他主要就是研究SOA——时，感到大家对SOA的理解越来越泛化了，使用传统的CORBA或者自行研发的远程协议实现“服务”亦被称为SOA。
        SOA的概念其实很简单，就是将程序功能（就是函数、方法function,procedure一类的东西）封装成可以互相调用的“服务”——服务就是粗颗粒度的方法。如果仅仅讨论SOA理论的话，应该不会涉及到具体技术，互相调用暗含了异构系统互相调用的意味，而这种调用在面向对象理论中就被称为消息传递了。
        IBM、BEA等公司做的事情就是在做上层的封装，也就是说通过他们的工具你不需要学会.Net下编写Web Service的方法，也不需要学会配置Axis——其实软件开发的发展就是一层层的向上抽象，计算机科学家不断将重复的劳动进行封装，交由编译器、虚拟机、中间件等去完成。我们接触到的澳大利亚那个项目就是针对遗留系统产生适配器，比如一个系统使用的是.Net构建的，那么我们只需要通过我们的软件做一些配置，比如选择“.Net”接口，就可以将原系统的某个方法变成Web Service，如果是用Java编写的，也同样只需要做配置就可以了。BEA的那套东西也大概如此，你不需要自己动手写Web Service了。
        其实这都是听上去很简单的事情，实现起来考虑的事情比较多，比如访问失败，重复调用，安全问题等等，这只不过是IT领域公共的问题，在SOA研究的一个分支而已。程序实现只是操作步骤，比如很容易就学会使用Eclipse+Axis创建Web Service，使用Net调用该Web Service。困难的是将什么设计成service？
        我们最近在规划的一个项目就涉及到很多的遗留系统，不同平台、不同的程序语言、不同的数据库。所有的功能只创建一次是个很好的决策，我认为，我们主要会使用Delphi和Java，要创建30多个系统，原来是不可能Delphi和Java互操作的，但现在可能了，因此设计很重要，比如Delphi进行了一个复杂的处理，而且是跨数据库的（这样估计是不能使用存储过程来避免重复了），这样Java就不必重写一个了，只要给需要调用的方法穿一件Web Service的外套就好了。而以前用VB、PB编写的系统也可以复用了——其实这是Web Service的初衷。
       我依然觉得找到硬件体系结构的感觉来划分服务就比较好了。然而分布式调用的性能问题、安全问题、稳定性问题等，也会影响服务的划分。
       
       Grady谈到的另一个Web Service好处就是其使用公共协议，无论是XML还是HTTP，都可以解决防火墙阻断问题（当然原来用防火墙避免的安全问题现在只能另想办法了）。
 
       SOA的发展（也就在过去的一年里）让各个层次的IT人员都可以找到自己的位置，有服务提供商（据说很多公司已经盈利很多了），这包括之间面向最终用户的service，比如我们把Office Live一类的都可以称为web service；另外还包括面向客户端程序员的service，比如利用google提供的map service来构建自己的地图系统。还有服务创建者，有的服务提供商同时也是这个角色，服务创建者可能会赤裸裸的手工编写SOAP文档，WSDL等，但大多数会使用.Net平台，Eclpse、RAD等工具，更抽象的创建则会使用中间件。然后就是提高这些工具的厂商，比如IBM，BEA，Oracle，Microsoft等，当然还有就是更高层次的协议、规范的制订者和领导者，比如IBM、BEA、Oracle等提出的SCA/SDO标准。而针对该标准的工具也已经被集成在IBM、BEA的集成环境中了。如果SOA的出现就像当年J2EE的出现一样的话，那么标准的推出特别是相应的产品的推出，就会像当年的J2EE一样将分布式系统，或者企业级信息系统的实施遇到的困难比如跨数据库事务处理、远程过程调用等变得容易，而且是提供一揽子解决方案，来解决前面所说的问题，当然还包括不同语言特殊类型转换、跨服务事务操作等现实问题。另外架构师、领域专家要划分或设计服务，这与在J2EE领域的研究发展是类似的。
       
        国际厂商都在宣传SOA落地，然而我们对于SOA的理解还过于朴素，很关键的问题是我们又落后了，当咱们战战兢兢编写Web Service来实现异构系统互操作时，国际厂商已经经过大量项目的实践研究出种种模式、最佳实践、特殊问题的解决方案，甚至已经提出标准了。我虽然还没有仔细研究两个规范，但是从对于J2EE的经验来看，标准肯定是用来简化服务的创建、调用、部署的。而这又会是一场新的拼杀，Microsoft、各种学术机构也都有自己的套路，来解决相同的问题。就像.Net和J2EE同样解决企业级问题一样的，IBM在SOA占据了领跑者的位置，就像SUN领导J2EE规范一样。