[转载]SOAP--新一轮竞争的三八线？(三)

SOAP--新一轮竞争的三八线？(三)

在上一篇文章中，我们通过一个应用例子粗略地覆盖了这个所谓的三八线架构，下面我们将回过头来重新审视这个计算架构。

真正的优势？

对于服务器端，不管它的配置多么复杂（在我们这个小小的实验中，已经用到了6个来自三个不同厂商和组织的软件包），因为它是集中的，总归可以在一间屋子中搞定。那么关于总体拥有成本和维护难度的焦点应该在客户端。

例子中VBClient这个程序看上去非常简单，作为一个简单的例子，它并不会比同样的Java例子冗长或难于理解（参见参考资料1中的Java客户 端），考虑一下如何部署(Deploy)它的问题吧，当你把它部署到企业中的几十台电脑上或者你分布在全球的客户和商业伙伴那里去的时候，每套系统都需要 SOAP Toolkit和VB Runtime，这些东西个头可不小，而且在客户眼里它们甚至和机器中的电路板一样，客户根本不知道它们到底是什么，很恐怖吧？这正是我们这篇文章要讨论 的问题之一。在将来的新的Windows中为了配合.net战略，SOAP Toolkit一定会内置到操作系统中，VB Runtime也不成问题（现在的Windows 2000中已经是这样了），VB写的程序如果不考虑Runtime库的话，很复杂的可执行程序文件也只有几百K，那么部署这些程序变得非常简单，从 Active X控件一直到System Management Server甚至直接下载或用软盘拷贝都是很实用的方案，而且新的VB.net和C#将能够更好地与Java互操作，它们的支撑环境CLE也是内置在 Windows系统中的。

反过来看Java，如果你用Java写这个客户端程序，会怎样呢？文章开头中提到的那些服务器端的Java包除了TOMCAT和Linux以外，你都得在客户端背着。目前JRE最小的也有7M，无论如何，你至少要先在每台PC上部署Java VM，然后还得"一个也不能少"地把那些第三方的Apache SOAP 2.1、JavaMail、JAF、XML4J等等都部署到客户端，因为你的Java客户端程序要import那些东西。那么请考虑它的可用性！

我认为在可以预见的将来，世界上最多的桌面系统仍然是PC和Windows。主要的理由是：其一，Linux要在Desktop端成为主流还有很长的路要 走，且不说市场、用户习惯等问题，即使在技术上Linux在Desktop端仍然缺很多东西；其二，SUN所定义的Thin Client这个概念也仍然存在很多局限性，"瘦"与"肥"客户端，对于最终用户而言其实并不是一个技术概念而是一个管理概念，是以应用程序部署和维护的 方便性为准的。因此，Microsoft在以后的IE6和Windows XP中不再装入Java VM其实是一招很厉害的杀手锏，大大降低了在世界范围内的Desktop上部署Java程序的可能性或可操作性。

现在可以看到我所理解的Microsoft .net战略的真正内涵了，她对自己的Desktop阵地仍然将会是一种巩固，同时以客户端为根据地来进攻服务器端的市场。

再 回来看服务器端， Java技术已经经历了5年的风风雨雨，越来越多的程序员和体系结构设计师熟悉并掌握了Java语言和Java技术，尽管Java并没有按照SUN原先设 想的"统一全世界的程序设计语言和计算环境"的方向走（其实那是不现实的），现在的Java已经成了一个服务器端开放、可伸缩的优秀计算技术集合，如果现 在仍然认为Java仅仅是一种语言，那就大错特错了。Java Application Server、Beans、EJB、Servlet等技术已经有了很多成功的大型应用，如果要将Web Service与这些已有的应用系统平滑对接，那么Java技术无疑是最方便和直接的，同时可以充分地利用Java Application Server上成熟的负载平衡等技术。

同时，本文描述的体系结构导致了在客户端，我们可以使用Microsoft的功能丰富且易用的开发工具，我们可以尝试C#等新语言，在客户端即使遇到问题 对整个项目而言风险不大且可控。更大地降低项目成本的理由是：全世界程序员中比例最大的VB程序员可能比较平滑第过渡到Visual Studio .Net上，SOAP成了客户端与服务器的桥梁。

.net产品正式发布后，以Microsoft的实力，相信它一定会占有一定的市场份额，但是.net的server部分仍将与Windows 家族紧密结合，那么用户将被锁定在Windows家族上。另外，就技术的成熟性来看，.net在服务器端比Java要年轻得多，保守的IT经理或CTO/CIO们会倾向于选择成熟的服务器端技术。

回页首

对SOAP的一点感想

根据本文和目前能够看到的一些材料，我有一些粗浅的看法想在这里与大家分享。

SOAP 真正的伟大之处并不是技术，而是标准。 SOAP巧妙地利用了目前大家都认可的XML统一了Client到Server之间通信协议的表示层标准，从某种角度来说更象是一种政治智慧。从字面上看 SOAP用于对象的访问，但从技术的某个角度看，例程或者对象仅仅是软件功能逻辑的存在形式而已。下面的简略历史回顾可能会给我们一些启示。

其实在十几年前，Oracle因为提出Client/Server结构而大红大紫时，包括后来的Informix、DB2、Sybase、MS-SQL Server等等都设计了Client和Server之间的通信协议，例如：Oracle的SQL*Net，Sybase的Open Client等等，但事实上当时谁也没有能力统一这个协议的标准，或者说，这个协议是它们核心竞争力或专有技术的一部分，它们都要求用户在客户端装点儿东 西，而且除了数据库Sever部分的基本费用外还按照客户端数目收钱（多好的商业模式啊！卖一个灯泡，还要额外按其照耀的平方米数再收一份钱），大家都做 过"恨不得全世界都用我的产品和计算架构的春秋大梦"。

第一次统一的尝试是十年前的ODBC和DRDA，前一个阵营的领导者是Microsoft，后一个领导者是IBM和Borland等，最后ODBC借Windows东风成功了。但是Oracle等主流数据库厂商仍然不肯放弃自己的专有协议，因此ODBC 接口之下仍然需要数据库厂商自己的驱动程序，ODBC只是把用户程序"垫高"了一层。第一次打的是"统一API的牌"。

第二次统一的尝试是5年前的Microsoft UDA体系中的OLE DB，结局是一样的，加上ADO用户程序又被"垫高"了至少两层。这一次打的是"面向对象的牌"。

再往后就是现在的结果，客户端越来越"肥"了，而且仅仅在数据库系统之外，一个对数据库的数据操作请求至少要穿过3-5层以上的API才能到达数据库。

纯Java的JDBC Driver（Type 3）也好不到哪里去，由于数据库厂商协议(比如SQL*NET)的专有，独立软件商开发Type 3 JDBC困难重重，而其它几种类型的JDBC Driver和ODBC面临同样的问题。

Microsoft 用.net基于SOAP包装了Web Service这个新概念。事实上，它的背后是Client/Server之间的通信方式因为有了开放统一的标准而成了一种平民化的技术。可以大胆地设 想，不久的将来，如果很多数据库Server都以SOAP方式提供服务，同时能够采用统一的Service集合和接口，那么全世界的数据库就真正统一成一 个客户端了，实际上就等于没有客户端了。那时因为任何用户只要有SOAP工具，可以轻易定制出自己需要的客户端，而不是象现在这样：整个程序中哪怕只需要 一条很简单的SQL查询，也得需要整个一个数据库API环境（不管是ODBC还是JDBC、不管是动态连接还是静态连接都是如此），由此，从某种角度来 看，客户端越来越"肥"的罪魁祸首是数据库的特殊客户端。

Microsoft的ADO.net在这方面已经露出了倪端（谁说Microsoft不创新？！）。

Web Service这个词似乎一夜之间在业界就热了起来，我想这与.net战略的发布不无关系，但是有一些缺乏专业精神的业界媒体对于Service这个词的 外延界定不统一，有时候在一篇文章的上下文中都不统一，一般是把外延无限扩大，由此造成了一些曲解和似是而非的误导，比如：很多媒体和技术预言家称， "net或Web Service将使软件业发展成服务业，其商业模式有可能演变成收取租用费和服务费……"其实作为Web Service之核心的SOAP离这一步还很遥远，甚至没有什么必然的联系。

由于SOAP标准是开放和非专有的，将来的.net在服务器端不可能是Microsoft一家的(事实上Microsoft自己非常清楚这一点)，其实 Linux社区反而不应该敌视.net，因为Microsoft为.net花了大把的钱教育了市场，使服务器端的市场空间扩大了，而且Linux上的第三 方产品也相对容易地在服务器端与Microsoft .net兼容（因为SOAP）。不管BEA、SUN、IBM和Oracle如何强，Microsoft .net一定会分在服务器端分一杯羹，但Desktop仍将被Microsoft占据着，以保证它的操作系统和开发工具的长期收益，这才是真正的.net 战略。

最后，请读者和编辑允许我在这里作个小广告，我出于研究目的，用VB和Microsoft SOAP Toolkit写了一个通用的SOAP RPC测试工具，现在已经完成了一些主要部分，我在调试本文的Server端例子时发现这个工具比较得力。我打算将来把它作为一个Freeware发布，图2是它的屏幕截图。

对SOAP RPC稍微有点了解的读者一看这个图就大概猜出了所有主要的功能，这个软件的内部展示了一些Microsoft SOAP Toolkit 的一些更为深入的用法，由于目前我实在没有时间和精力去维护一个个人网站，如果有需要这个小东西的读者请通过E-mail向我索取她的源代码。我的E-Mail是： tuppin@wuhan.cngb.com。

因为XML、SOAP作为目前热门的前沿技术仍然在快速地发展，我将在本系列后面的文章中，接着来讨论SOAP document oriented应用、WSDL、UDDI、SOAP RPC与DCOM、CORBA以及RMI的对比等内容，如果读者对于这个系列文章有任何的批评和建议，非常欢迎通过E-Mail与DW或我联系。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/374079/viewspace-130728/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/374079/viewspace-130728/