Web服务发展中的一些问题


日期: 2001年10月10日    

  
以前从来没有产生过如此激动人心的协议. 但是仅仅是不停的念叨诸如SOAP, WSDL, 和UDDI--定义Web 服务的三种协议--之类的缩略语并不能让组件软件结构和通用的XML集成的想法成为现实. 要使Web服务开始工作, 与之相关的协议必须被重新定义, 相应的开发工具也必须被发布出来, 而IT经理和开发者中必须来一场文化革命.

特别是微软和IBM在交流Web服务所能带来的好处方面发挥了另人惊讶的卓有成效的作用--可重用的软件组件, 企业间容易的集成过程, 等等. 虽然实际的Web服务的实现还处在实验阶段,新闻界已经使这些高层的概念深入人心. 作为反对人物的开发人员却有不同的看法. 对于Web服务, 他们有很多不满的地方.

下面是开发者对于Web 服务的通常的一些反对意见. 其中的一些已经得到了很好的解决但是也有一些没有:

安全和认证. 在对Web 服务的所有反对意见中, 这两点最先出现而且出现得最多. 幸运的是, 当你在处理敏感的数据的时候, SSL, 这种老的Web 解决方案, 能够很好的避免XML消息被截获. 但是在服务器上认证XML 文件是另外一回事. 有不下十种的认证方案--它们分别由不同的标准委员会提出--希望能够通过数字签名和类似的技术来解决这个问题, 但这些标准要稳定下来尚需时日.

事务完成. 当多个交易方同时交易的时候--就象在一个供货链中发生的那样--事务的处理过程是长时间的, 而且会很复杂. 必须找到一种方法来监视复杂的事务以便处理过程的每一个部分都被标识出来. 有几种不同的标准, 包括安全的断言标记语言(Secure Assertion Markup Language), 商业事务协议, 和IBM公司的可靠HTTP, 致力于解决这个问题, 但是各标准化协会还没有同意其中的任何一个.

性能. 对于这个问题压根就没有好答案. 基于HTTP的XML 根本就不是高性能的解决方案. 而且如果使用处于;这些协议顶端的安全协议, 那么用户想要服务器对一个特定的动作很快的作出响应是不可能的--比方说信用卡的验证--高延时的问题会使Web 服务在一段时间内被限制在企业内的工程和自动的B2B事务处理项目里.

增加的依靠性. 如果多个应用程序是基于同一个Web 服务, 对这个Web服务的改变可能使多个应用程序发生错误. 相似的, 个别的Web 服务的大量使用必须被小心的监视起来, 确保相应的硬件被正确的升级. 就象任何的组件架构一样, Web 服务组件必须为通用的用途者开发, 也就是说程序员必须估计出许多应用都要用的功能.

容量和可靠性. Web 连接比已经比以前更加可靠了, 但是当你调用防火墙外的组件的时候, 你必须忍受更低的上行速度. 你还不得不信任通过XML API访问的组件, 把它们完全看作是黑盒子. 在公司之间必须建立起老套的信任关系, 然后才可以接受使用其它人的Web 服务的风险.

额外的开发工作. 系个人都希望以正确的方式开发应用程序: 完整的开发文档, 时时想着代码最大程度的被重用. 但是在现实世界里, 项目必须在确定的时间完成并且有一定的经费限制. 第一次从Web服务组件创建应用程序会需要额外的工作和时间. 不管怎样, 许多IT 经理不想仅仅为了获得以后才能实现的代码重用的好处而使项目拖下去. 因为同样的原因, 一个IT 经理将能够正常工作的应用程序"组件化"的可能性也是非常小的, 即使将它们分割成Web 服务组件能为其它的应用带来好处.

但是没有一个困难能真正挡住它的脚步. 实际上, 我所访问过的开发者都同意Web 服务发展的大方向而且许多还正在为实验性的程序工作.

由于对Web 服务所需的时间和工作量有了更现实的估计--以及对Web 服务的限制的更清晰的理解--也许这种很有前途的技术不会象许多其它的技术那样遭受过高的期待.