我对web service 也挺感兴趣的,可惜现在工作太繁忙.真的是没时间.
解决方案 »
- 请问javascript是否可以处理用户输入的表格数据，将处理后的结果提交到服务器？
- 请教高手帮忙解决，，在线等，谢谢！
- 问个关于showModelessDialog的问题！
- DOM删除节点内所有内容
- div漂浮的javascript代码为什么在火狐下无效
- 求一段靠显示器最右边的悬浮窗口代码
- 帮忙----------file的使用。。。。。。。
- 为何我用showModalDialog之后使主窗口的数据与showModalDialog窗口完全相同了？？？
- 请教：：：Html中，下拉列表框<select ..>如何控制成固定宽度，但是option的内容还可以悬浮显示
- 动态监控文本框值的问题！
- 怎样做一个将剪贴板内容粘贴到textarea中的按钮？
- 关于XMLHTTP的问题？
典型的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
Microsoft的SOAP Toolkit V2帮助你把COM组件变成Web service。这套工具分为三大主要部分：SoapClient是一个用于调用Web service的COM组件；SoapServer 是一个处理SOAP请求和返回SOAP应答的组件；还有一个WSDL向导，它可以把你的type library转换成WSDL文档，以暴露给Web service的客户。
假设你有一个COM组件，暴露出一个GetTemperature方法：
Public Function GetTemperature(ByVal zipcode As String, _
ByVal celsius As Boolean) As Single 要把这个组件变成一个Web service，你可以使用WSDL向导。给出你要转换的组件后，向导会要你选择你想暴露出的方法，指出生成的Web service所在的URL(如http://localhost/Temperature/)，以及你希望用ASP还是ISAPI做你的请求处理器(如图1-2)。然后向导还会问你生成的WSDL和ASP文件应该放在那个目录下。
使用SOAP Toolkit向导来转换COM组件，点击小图放大
现在该调用这个Web service了。方法是在VB或其他任何可以使用COM的语言里调用SoapClient组件。下面这段代码演示了怎样调用Webservice中的GetTemperature方法：
Dim soap As MSSOAPLib.SoapClient
Set soap = New MSSOAPLib.SoapClient
soap.mssoapinit _
"http://localhost/Temperature/Temperature.wsdl"
MsgBox ("气温是： " & _
soap.GetTemperature("20171", False)) 首先调用mssoapinit，把WSDL文档的URL传给SoapClient。WSDL文档的URL就是你在WSDL向导中给出的URL加上〈Service名字.wsdl〉。一旦初始化完成，SoapClient就得到了Web service的所有方法，你就可以直接调用这些方法了。
还有 .vsdisco 文件也可以上传对UDDI起作用。
帮你up一下！
同一套系统，在两个机器上跑，然后相互调用其中的WebService方法，传递的是DataSet。
但这也是在局域网里面测试，不知道真正通过WWW会不会有什么问题。
（可乐 2001年11月01日 18:35） 你可能早就听说过Web service了，你也可能已经对Web service有一些概念了。一时间，好像所有的计算机期刊、书籍和网站都开始提及Web service。然而，当前大多数对Web service的介绍都没能清楚的说明Web service到底是什么。他们只是鼓吹Web service是多么多么的好，简直就像是在做广告。在本文中会讲清楚两件事：Web service到底是什么；在什么情况下你应该使用Web service。 分布式应用程序和浏览器
研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。
传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。
关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。
许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。 什么是Web Service
对这个问题，我们至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可已建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求：
http://host.company.com/weather.asp?zipcode=20171 返回的数据就应该是这样：
21,晴 这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。
下面是对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。
Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。 新平台
Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web service平台的这三个技术。 XML和XSD
可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。
XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。 SOAP
Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。第三章我们会讨论SOAP，并结识SOAP消息的各种元素。 WSDL
你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。
（责任编辑 尤北 [email protected]）