这一点在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而不是别的组织？还是因为别的什么？

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

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

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

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

如果能做一些虽然实践中看不到用途、但在理论上有所创新的东西拿去毕业的话，我也会很知足的。呵呵