Web Service：你需要多熟悉？（1）

阅读更多

 

Part1: 缘起

 

     在上次的讨论中，我们跟随大师Don Box从C++游历到 COM，再从COM游历到CLR。一路而来，我们似乎领会到越来越多组件话编成的味道。这不禁让我勾起了些许联想。组件——Component，这个被业界已经喧嚣叫嚷了太多年的概念。从C++中的源代码复用，到Win32下OLE、COM的到来，到CORBA……

     走在二十一世纪的初期，时下的编成语言早已不是昔日类似C甚至Assembly那样孱弱的组件特性了。不错，肯定有许多人会为C甚至Assembly申辩。但凭心而论，现代的高级语言早已经不再是Eric S. Raymond所推崇备至的像C语言那样的薄薄的一层。他们和那浩繁巨大的API库为我们干了太多的事情，我们需要操心底层的越来越少，但我们所拥有的控制却并非少了。

在这蛮荒之时，走向组件化最重要的就是规避差异！

这些差异从何而来？

从CPU来！从OS来！从编程语言来！从语义来！

为什么一个语言写的代码不能轻易的成为一个可重用的组件？这里困难主要来自CPU和OS，数据类型在不同的CPU上有不同的存储格式！语言的运行时环境或者代码本身依赖于OS提供的专属API，于是自然你的代码被绑定在了特定的CPU & OS 组合的平台上。用C、C++等等原生高级语言（这类语言主要特征是：直接和OS打交道，如手动管理内存，借助平台特性进行线程管理，直接编译成特定平台的机器代码，平台间移植困难重重）编写的应用大多头符合上述两个特征。这也正是上个世纪90年代Win32风靡时，人人追捧微软那8万多API的缘由。在那个年代，一个操作系统的API确实占据举足轻重的地位。正如史蒂夫·鲍尔默在微软PDC大会上那样急切的期盼：“开发者！开发者！开发者！开发者！”。正是因为太多的Windows应用才真正撑起了Win32、MFC满天飞时的那个微软帝国！在这当中OS API扮演了很重要的角色。这也是那个原生语言时代的必然。

逃离OS！几乎是所有反微软的共同心声。程序语言的进步使这成为了可能。基于虚拟机的编程语言，在OS和编程语言之间增加了一层间接性——虚拟机(VM)！如果让VM及至的简化，那就是当年原生语言下的语言运行时（RunTime）！VM的出现就是为了规避来自CPU和OS的差异。这样一个新的间接层的出现，使得代码在跨越这些平台复用成为了可能！然而VM的出现甚至能解决各种编程语言之间的差异（这种差异更多的表现再类型系统上）！这两者最典型的代表分别是：JVM和CLR。一个支持跨平台，但到来今天，在JVM上面跑的语言岂止JAVA啊！beanshell、groovy、python、ruby如雨后春笋在JVM这个大观园里百花齐放！而CLR早已不是像微软一厢情愿的那样只在Windows下开花结果，Linux/Unix下猴子（Mono）搅扰了微软的黄粱美梦。由此也可窥见一二的是：即便厂商各自的策略不同，但规避差异的潮流会让它们渐渐趋同的。

值得多提的，是规避各种编程语言的差异所带来的一些麻烦。上面我说，CLR规避了各种编程语言之间的差异。但事实上它的能力是有限的！它基于它内部的CTS（公共类型系统），各种编程语言特有的类型是不能在语言之间交互的。也就是说，横梗在各种语言之间的最大困难就是：复杂类型的映射！

无论是IL（中间语言）还是byte-code它们描述特定语言类型的能力都不是最好的！而这个时候，历史的机遇走在了XML的当口。它的出现，如山洪般迅猛势足！或者在我看来用下面这个论点来解释其获得广泛巨大成功的原因：具备很好的描述性！XML从HTML而来，摆脱了狭隘桎梏般的几个标签，把描述权还归给开发者,XML的出现注定使它成为一种元语言！或者这样讲，XML作为一种语言本身来讲的话，它孱弱乏力。但作为一种元语言，它则变作了一个强有力的内核和引擎！使用XML来描述复杂的类型系统成为一种很必然的选择走上了IT历史的舞台！

在这些为之努力的人当中，不得不说的还是Don Box.。他早期在微软的辛勤工作，为SOAP规范的制定做出了卓越的贡献！SOAP就是在XML Schema出现之前使用XML描述复杂类型系统映射的一次具有开创意义的尝试。然而也正是因为SOAP自身早于XML Schema出现，也给现今的XML Web Service的使用带来了更多的复杂和混乱。在SOAP之后，在XML自身的DTD的演化下，XML Schema规范发布。这是一个非常重要的关于类型在XML中如何建模的规范！它的出现也是Web Service应运而生的必要前提！

除了规避差异，使组件可重用之外，我们也更希望一直快捷的使用方式，而不是烦笨的拷贝分发。通过Web进行链接那正是我们想要的！所以在这个时代，我们可以说：“链接就是API！！！”。在Web上，我们现成可用的就是如TCP，SMTP，HTTP等等协议。

于是，历史走到这个端口，一切都呼之欲出：HTTP、XML、XML Schema、SOAP！

 

 

Part2: 历史的明线

 

WSDL——Web 服务描述语言。这个用XML进行描述的一个规范！在那些支持协议上终于让组件编程能够跨越了CPU、OS、Programming Language之间的鸿沟，使便捷的组件交互成为了可能。

 

在上一部份中，我们从组件编程的角度谈了谈Web Service的发展之路！现在我们换一个角度来看Web Service。

 

RPC——远程过程调用，这是一个有相当年龄的词汇！早在面向对象语言大行其道之前，它早已如雷贯耳。在70年代那些基于COBOL构建的大型商业应用中，过程语言的RPC早已应用自如。等到了面向对象语言成为主流的今天，远程方法调用（RMI）依然在分布式编程领域占着很重要的位置！Web Service的出现大有该朝换代之势。从保守的眼光来看，Web Service不过是一个新的远程方法调用技术。然而我们应当发现消息与调用，方法（过程）与操作之间那微妙的差别。从更具颠覆意义的层次看，Web Service决不是单纯的远程方法调用。正基于这个原因，在Web Service中分为两大派系：架构流派和方法流派。

 

无疑，Don Box肯定是站在方法流派这边的。这和他早期的经历是密不可分的。早期在C++和COM的职业经历使Don Box在制定SOAP规范时就是为了解决在Ｃ++和COM中出现的许多问题，它依然保持着很浓烈的远程方法调用的味道！在SOAP１.1规范中的第５节和第７节更是使这种风格在整个规范中打上了深深的烙印。（SOAP规范的第５节描述了一套用于编码数据类型的XML（包括对多态类型的编码）。第７节则描述了如何将方法调用的响应模拟成XML结构。在使用Web Service时，当使用第５节和第７节一起用于模拟方法调用时，这种类型的SOAP通常被称为Rpc/Encoded SOAP）

 

两种流派的斗争也使得后来的互操作性话题变得那么异常艰难！回想CORBA因标准下各种实现不兼容而被弃用之前事，Web Service的处境也并非毫无隐患。Rpc/Encoded SOAP在Web Service的互操作性中就扮演着这样一样讨人厌的角色。