为什么需要Web Service

从前，分布式的应用程序逻辑需要使用分布式的对象模型，诸如：微软的分布式组件对象模型(DCOM)、对象管理集团的公用对象请求代理程序体系结构(CORBA)或Sun的远程方法调用(RMI)。通过使用这种基本结构，开发人员仍可拥有使用本地模型所提供的丰富资源和精确性，并可将服务置于远程系统中。

当我已经有了我中意的中间件平台（RMI, Jini, CORBA, DCOM 等等)时，为什么还要为Web而烦恼呢？中间件确实提供了强大的服务实现手段，但是，这些系统有一个共同的缺陷，那就是它们无法扩展到互联网上：它们要求服务客户端与系统提供的服务本身之间必须进行紧密耦合，即要求一个同类基本结构。这样的系统往往十分脆弱：如果一端的执行机制发生变化，那么另一端便会崩溃。例如，如果服务器应用程序的接口发生更改，那么客户端便会崩溃。

要求提供紧密耦合的基本结构，无可厚非，许多应用程序均是基于这种系统构建而成的。但是，当各个公司需要相互合作、或信息技术提供商扩大业务范围时，便很难实现单一而统一的基本结构。您根本无法保证您希望与之进行远程通信的管道的另一端，具备所有您需要的基本结构：对于它使用的操作系统、对象模型或编程语言，您可能一无所知。

相反，Web服务彼此是松散偶合的。连接中的任何一方均可更改执行机制，却不影响应用程序的正常运行。从技术角度讲，人们已转向使用一种基于消息的异步技术来实现高可靠性的系统性能，通过使用诸如HTTP、简单邮件传输协议(SMTP)以及至为重要的XML来实现统一的连接。

Web作为信息发布者的力量就在于简单且无处不在，这对解决现在这样一个分裂中间件世界很重要。Web通过在传统中间件平台上更有效实现的Services，来提供一个统一且广泛适用的接口，这样就改善了这个平台。

从一个N层应用程序结构的角度来看，web service只是一个方便程序访问的包装，服务还是要靠中间件来实现。访问包括服务请求处理（监听者）和一个支持商业逻辑操作的接口，商业逻辑本身是由传统的中间件平台实现的。

从理论上讲，开发人员可通过调用Web应用编程接口(API)（就像调用本地服务一样），将Web服务集成到应用程序中，不同的是Web API调用可通过互联网发送给位于远程系统中的某一服务。例如，Microsoft Passport服务使得开发人员能够对某应用程序进行验证。通过Passport服务编程，开发人员可以充分利用Passport的基本结构，通过运行Passport来维护用户数据库，以确保它的正常运行、定期备份等等。

消息传递系统将通信的基本单元打包成自我描述型的数据包（又称作消息），并将其放到网络缆线中。消息传递系统与分布式对象系统之间的本质区别在于：要求发送方辨识接收方的基本结构的程度有所不同。在分布式系统中，发送方需对接收方的情况作出种种猜测：应用程序是如何激活或拆包的，调用的是什么样的界面，等等。

另一方面，消息传递系统会在缆线格式级上创建合同。发送方既不需考虑消息被接收后的情况，也不需考虑接发双方之间的通信情况，唯一需要考虑的是接收方是否能辩识发送的消息内容。

在缆线格式级上创建合同的优势不言而喻。例如，接收方可在任何时刻进行更改，而不会干扰发送方的消息发送，只要它仍可辩识原有消息的内容。另外，发送方无需任何特殊的软件即可与接收方通信：只要它发出正确格式的消息，接收方就可以响应。