典型的Web Service结构

典型的Web Service结构 

不管你的Web service是用什么工具，什么语言写出来的，只要你用SOAP协议通过HTTP来调用它，总体结构都应如下图所示。 

通常，你用你自己喜欢的语言(如VB 6或者VB.NET)来构建你的Web service，然后用SOAP Toolkit或者.NET的内建支持来把它暴露给Web客户。于是，任何语言，任何平台上的客户都可以阅读其WSDL文档，以调用这个Web service。客户根据WSDL描述文档，会生成一个SOAP请求消息。Web service都是放在Web服务器 (如IIS) 后面的，客户生成的SOAP请求会被嵌入在一个HTTP POST请求中，发送到Web服务器来。Web服务器再把这些请求转发给Web service请求处理器。对VB 6程序来说，Web service请求处理器是一个与SOAP Toolkit组件协同工作的ASP页面或ISAPI extension。而对VB.NET程序来说，Web service请求处理器则是一个.NET Framework自带的ISAPI extension。请求处理器的作用在于，解析收到的SOAP请求，调用Web service，然后再生成相应的SOAP应答。Web服务器得到SOAP应答后，会再通过HTTP应答的方式把它送回到客户端。 

 


典型的Web service结构


远程过程调用(RPC)与消息传递 


Web service本身实际是在实现应用程序间的通信。我们现在有两种应用程序通信的方法：RPC(远程过程调用)和消息传递。使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC强调的是远程对象和它的界面，即属性、方法和调用时的参数。DCOM和.NET远程访问都是RPC的例子。 
消息传递一般是在耦合度更低的系统中。消息传递的概念是，客户端向服务器发送消息，然后等待服务器的回应。消息传递系统强调的是消息的发送和回应，而不是远程对象的界面。由于是基于消息的系统，客户端和服务器之间的耦合度比RPC方法更低。
RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而客户端就好像在使用本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。例如，你在VB 6中通过DCOM调用一个远程对象，你的代码看起来就与调用本地对象一样。而消息传递则不同，它强调传递的东西是什么，但不管消息传递过去后干什么。客户不需要知道服务器是怎么实现的，以及消息是怎么被处理的。
我们已经说过，你可以建立一个消息服务器，根据收到的消息来调用对象。这是通过消息传递方式有效的实现了RPC。如果客户仍然以消息的思维方式来进行操作，那么你可以把它叫做消息传递。但如果客户以远程对象的思维方式来进行操作，那么你就应该把它叫做RPC。 
如果你想实现一个基于XML的消息传递系统，大量的工作将集中在处理XML请求和应答消息上。虽然VB 6和VB.NET中，帮助你建立Web Service的工具已经做了许多对XML消息进行处理的工作，但毕竟所有的数据都是用XML的形式收发的，许多情况下你还是需要对消息进行一些自己的处理。深入理解XML和XML Schema对于有效地实现XML消息系统是至关重要的。


建立Web Service 


我知道你现在已经很心急的想要写点代码，看看Web service到底是什么样的了。那么我们现在就介绍怎样用VB 6和VB.NET实际做出一个Web service来。本节的目的只是向你展示一下这些工具的功能，而不是深入地讲解Web service的工作原理。本书后面的章节会向你慢慢说明Web service以及Microsoft SOAP Toolkit和.NET等工具的内部原理的。

使用SOAP Toolkit 

原文转自：http://www.ltesting.net