计算机科学论坛--Web Sevice原来与web无关 ——自己对现实中的WS的看法，欢迎拍砖

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

许多写Web Service的“学术论文”中谈起题目背景时总喜欢说的“将来在Internet上出现大量的Web Service时怎样怎样”（当然，自己已经发的小论文中也这么干），但现在的自己，越发认为：这是一个越来越不现实的假设。现实情况是：Web Service在企业计算中，作为SOA的主流实现应该颇有前途。但在web或说Internet上，前途越发暗淡。

    这一点在5月30号CSDN召集的SOA实践大会中感受较深。会上IBM/MS/BEA/Oracle等公司的资深专家或技术高管对SOA在企业中的应用前景充满了信心，但一句也没提过在web上的应用。在发达国家，几十年来，各行各业的企业（尤其是大企业）为管理自己的产品、原料、人事、客户信息等所建立庞大的IT系统，对提高企业的运转效率已经发挥了不小的作用，但现在面临两个问题、需要SOA来拯救：
    1. 庞大、复杂，改动困难。而在目前“扁平世界”时代中，业务环境变化迅速，企业IT系统需要能根据企业战略战术的变化而迅速调整，但现在的IT系统做不到这一点。据说，现在很多企业的CIO经常为这种变化的困难而疲于奔命。
    IBM developerworks上讲了自己公司的一个例子：其具有25年历史的"订单分析跟踪系统（Customer Order Analysis and Tracking System [COATS]）"，能实现以客户提交的订单为输入、以发给各个特定工厂的制造车间的配置，如物料单、配置计划等。so cool！！但是：其包含 140 万行 PL/1、OS/390 汇编语言、Java 和其他编程语言代码，峰值时已非常接近其处理容量极限。批处理瓶颈和冲突数据对订购和配送造成延迟。而且具有硬编码的业务规则、过程、逻辑和数据访问。为了支持新活动、新产品和业务机会，对应用程序进行了更新的代价十分之大：每个版本的开发时间都要花费六个月时间，占用超过 8,000 小时开发时间。
    对此，SOA的对策是：通过加大复用单元的粒度，把企业业务流程中复用价值大的部分封装成一个服务，以此来实现松耦合、更好的模块化，在IT系统需要变化时能更好地复用现有系统，从而实现灵敏的变化。
    但对这一点自己尚不太理解。复用、模块化的概念在软件工程中从来就很受重视，到难道说以前的复用粒度恰好小了那么一点点正好搞不定现在的需求、需要SOA的大粒度复用来拯救？现在的复用单元“服务”根以前的复用单元——函数、类、构件/组件——之间的本质区别在哪里呢？据说区别是：通过服务的IO传递的东西都是大块的数据（XML形式），而函数的IO往往是简单的数字、字符串、一个个对象，但窃以为：函数的IO也能传递大块数据，以前没有那么干只是以前没需求而已。换句话：假设本公司的IT系统全是基于一个平台开发的如J2EE，甚至纯C/C++，如果结构设计得很好、恰当地把业务流程中复用价值较大的部分封装成一个个单独的组件、函数，是不是也能实现灵活应变、是不是也可以称作SOA了呢？  实际上，鼓吹者也说：理论上讲，SOA可以通过Web Service之外的方式比如CORBA/J2EE来实现，现在需要确认：前面这个问题的答案是不是“是”。
    2. 不同平台的系统进行集成的需要。具体的需求有：同一个企业内上述不同种类的系统可能基于不同的平台而开发，形同孤岛，但彼此间往往有逻辑上的联系，需要集成；同一个供应链上上下游企业的产品、原料系统现在需要集成、以便能够以最快的速度下订单。这时，SOA，或者Web Service便不可替代了。异构系统之间交换数据，只能通过文本格式，其中的XML被所有人看好，而Web Service就是一种能在交换XML文件的同时能提供企业级的可靠异步消息传输、安全、事务等性能需求的技术。舍它其谁？
    （微软的李志霄博士还提到了企业原有IT系统的第3个需要SOA来拯救的困境：后台的强大的IT系统与前台的企业员工之间隔阂太深，两张皮。自己尚不太理解，或许也不重要）
    值得注意的是，中国的企业却有不同的特点：十分灵活、过于灵活。普遍就没有起实质性作用的IT系统，主要的流程都是人工完成，修改起来倒是十分灵活，但长远来看缺乏竞争力。所以在中国企业SOA应用的重点是新建一套符合SOA风格的IT系统，与欧美企业的重构遗留系统稍有不同。

说其web上的应用集成，目前国外众多的网站已公开了开发接口供其它应用、网站调用，如google的map/search等等，yahoo map/search等，Flickr的、Youtube的。根据programmableweb.com网站所搜集的情况，到今天为止，已有448个这样的API；同时，已至少有1979个使用了这种API的带有集成性质的应用（被称作“Mashup”）出现在web上、且以每天3.19个的速度在递增。so cool！但这些API采用SOAP作为接口的相当的少。根据自己对被超过50个mashup使用的API的统计，12个里面REST接口有8个，XML-RPC接口2个，JavaScript 4个，SOAP接口也只有4个（Flickr, Amazon eCommerce, eBay, Google Search），但这4个同时也都提供了别的方式，而且相比之下SOAP更不占优势，至少在两家已经确认：Amazon的开发者用户中60-85%使用REST接口；而Google则已于半年前停止了对SOAP接口的继续开发，正如孟岩的一片博客文章所认为的那样。
其中原因不难理解：SOAP在HTTP上多加了一层，在对可靠异步消息传输、安全、事务性要求较高的企业计算环境中，这一层加的还有必要。而在web上，集成还处于初级阶段，目前尚看不到对这些要求的需求，根据“奥卡姆剃刀原理”，当然没必要引入SOAP了。只是，不知道在尚不能遇见的将来，web上会不会出现强大的、需要可靠异步消息传输、安全、事务的集成需求？若然，则那时或许有必要引入SOAP了。否则，只能说：Web Service原来与Web无关！

至此，想起许多写Web Service的“学术论文”中谈起题目背景时总喜欢说的“将来在Internet上出现大量的Web Service时怎样怎样”的情景（当然，自己已经发的小论文中也这么干），有点想苦笑。人家IBM/MS本来是在企业计算的背景下提出Web Service的，怎么就被研究界这么多人看作是web上的发展方向了呢：是因为名字里面包含了一个"web"？是因为SOAP/WSDL被这几家公司提交给了w3c而不是别的组织？还是因为别的什么？

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

企业计算、web、Internet这些概念不是对立的，不好直接对比。

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

这种假设还是有存在的必要的，目前来看，不是因为它正确，而是有了它才可以做research，长远点看，若干年后也许就真的变成了可能：）其实还有很多在ws中禁不住推敲的假设，不过ms牛人们总能用这些假设做出NB的东西出来。或许这就是研究：）

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

以下是引用ryanliu在2007-6-7 12:18:00的发言：
这种假设还是有存在的必要的，目前来看，不是因为它正确，而是有了它才可以做research，长远点看，若干年后也许就真的变成了可能：）其实还有很多在ws中禁不住推敲的假设，不过ms牛人们总能用这些假设做出NB的东西出来。或许这就是研究：）

所以，对这样的所谓“研究”，俺有些失望:( 我想，长远点看SOAP能否风行于web，要取决于web上是否能产生对具有安全、事务、和可靠异步消息传输等质量保障的集成应用的需求。现在的集成google map 这样的API的应用中还看不到这个需求。

[此贴子已经被作者于2007-6-7 14:01:17编辑过]

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

以下是引用zhaonix在2007-6-7 13:14:00的发言：

记得SIGMOD Record 05年有一个对当前公共ws的调查，有一类的查询类服务，我想在该类服务中应该不太关注安全，事务，可靠性的问题，不过对于电子商务类的服务，可能还是需要的吧

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

作者的见解确实比较独到，说明也非常有说服力！！！

作者在上面提到：
　　　复用、模块化的概念在软件工程中从来就很受重视，到难道说以前的复用粒度恰好小了那么一点点正好搞不定现在的需求、需要SOA的大粒度复用来拯救？现在的复用单元“服务”根以前的复用单元——函数、类、构件/组件——之间的本质区别在哪里呢？据说区别是：通过服务的IO传递的东西都是大块的数据（XML形式），而函数的IO往往是简单的数字、字符串、一个个对象，但窃以为：函数的IO也能传递大块数据，以前没有那么干只是以前没需求而已。

　　但是我想复用粒度并不是服务的IO传递的“大小”，而是一种功能实现的大小把！！！

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

以下是引用ryanliu在2007-6-7 14:33:00的发言：
[quote]以下是引用zhaonix在2007-6-7 13:14:00的发言：

[/quote]

en, 现在的B2B电子商务中需要IT系统对接、集成的，可能基本上还局限于供应链集成，跟web尚没有关系；或许，在将来会出现跨越Internet建立起来的B2B电子商务的集成系统？目前Amazon的许多服务是要收费的（如S3），应该可以看作这种系统的一个雏形。但Amazon的各种服务，似乎都提供REST, SOAP/WSDL 两种接口，让开发者自由选用。也就是说光凭简单的REST，也能满足目前的安全需求！但将来还能不能满足，或许值得关注、研究？

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

以下是引用timothy在2007-6-8 9:40:00的发言：
……
　　但是我想复用粒度并不是服务的IO传递的“大小”，而是一种功能实现的大小把！！！

是，俺说得不清楚:( 服用粒度与IO数据的大小是两回事。根据自己现在对SOA的模糊理解，这两个似乎都是SOA区别于以往体系结构的特点。（或许还有第三个：异步？至于松耦合，或许可以看作是粗粒度和异步的结果？）

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

以下是引用fengmz在2007-6-7 10:26:00的发言：
企业计算、web、Internet这些概念不是对立的，不好直接对比。

en, 两者应该不是对立的关系，或可看作桔子和苹果的关系。有些东西，对桔子、苹果都适用，但有些不是。以前我写小论文时，认为Web Service是前一种，即对web领域和企业计算领域都适用，以为将来web集成大量出现时，Web Service将担当主力；但现在，感觉它是后一种，只对苹果适用:)
或许，将来web上的深层次的B2B电子商务（即能够使不同企业的IT系统直接对接、直接下订单、传数据的那种）出现之后，企业计算和web集成的区别就会更模糊了，好比是油桃、苹果梨 :) 那时，Web Service会重新回到web？
但现在还看不到这个需求，现在的那种假设下所“研究”的web上的Web Service问题，想必也很少抓住将来这种场景出现后的真正的问题，是轻率的假设，我失望的是这个。

姓名：(无权查看)
城市：(无权查看)
院校：(无权查看)

和我老板交流了一下，他认为做研究的时候可以跳出一些现有框框的束缚，比方说web service，不一定就非要是基于soap或者wsdl等等的，关键是里面所蕴含的思想。很多东西不是刚出来的时候就能看到其发展前景的。就像当年web刚出来的时候，在db领域，很多人不知道web能做什么研究，无非就是文本的显示，传输，而短短几年，web/xml就成了一个巨大的研究领域。

学术界应该还是倾向于理论的，不像工业界的研究院，是以商业产品为目的的。sigmod07上就能感觉到这一点，往往一篇文章的思想可以用于多个application，而他们并不关注在这些application中这些思想还需要做哪些小的修改。而这些思想正是当前ws研究中缺乏的。比方说，对于mobile web service，学术界对于研究如何高效的压缩xml可能比如何扩展wsdl来支持user profile and other contexts 更有兴趣，而如果工业界想推出真正的moblie service产品时，可能他们更关注那些context如何表示，至于xml的压缩，够用就行了。


	W 3 C h i n a ( since 2003 ) 旗下站点苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》	156.250ms