请问各位，不使用SOAP调用某个网站提供的接口执行一些功能，这个网站算不算是“WEB Service”？
我能找到的关于WEB Service的信息都是在强调SOAP。
可是我对于“WEB Service”一词的理解是：通过网络得到某个服务器提供的某种服务。比较被大家多次强调的是天气预报“Service”、股票行情“Service”。
可是提供WEB服务，一定要使用SOAP吗？不用SOAP的难道就不算是网络上提供的服务吗？COM+或AJAX或者常规的动态网页不是也可以达到“调用远程服务器中提供的API，返回结果”的目的吗？
比如google广告，加入google广告的网页中只是简单地引用了google网站的一个JS文件，然后用JS定义几个变量，客户端浏览这个网页时就可以访问google网站，下载JS文件。google网站根据网页中设定的JS变量执行服务器端代码（业务逻辑应该是非常复杂的），产生一些HTML代码发送到客户端。于是客户端就可以被迫看到google广告了。
这个过程，我理解是“客户端通过简单的JS接口，调用了google服务器提供的WEB Service”。
我理解错了吗？
另外，火爆的AJAX也可以达到相似的效果。如果在open的URL中带入参数，服务器中的asp.net、asp、jsp、php或者其他什么p执行动态网页，返回一些文本或XML文件，客户端同样可以得到结果嘛。
我孤陋寡闻，AJAX不论是返回文本还是XML对象，这个发送、接收的过程中使用了SOAP了吗？
其实我在模仿google广告的调用方法，基本上只用JS调用我用VB写的dll。我的dll提供了一种功能，开始时准备改成标准的WEB服务方式，但我了解到WEB服务的效率很低，并行处理能力也只是每秒20次（不知道对不对），感觉还是用传统的asp中创建dll对象，客户端访问asp更可靠一些。
希望web serveice版的先行者们批评指教。谢谢！
[解决办法]
你这个页面就应该可以算作是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平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。
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的代码。
[解决办法]
个人认为从广义上说，“web”都可以认为是“web service”，比如，csdn给我们提供了一个讨论问题的“服务”。但csdn的这个“服务”是对人的，因为这里一个页面的响应最终是返回的是html，浏览器将html呈现为文字或图形，供人浏览，只要不是文盲，就能看明白；但对于机器，即其他应用来说（比如一个文章采集系统），就很可能必须实现一些复杂的算法处理这些html，从而达到自己所需的效果。
而你的“服务”，请求是一个普通的get，响应而是你自己response.write的，对于其他应用来说，除非也是你自己开发或你给对方的开发人员一套你详细的文档说明每个请求和响应的格式，否则这些应用也不可能正确的使用你的“服务”。
所以soap就是为了解决这些难题的而提出的，因为是一个标准，只要按这种标准开发的“服务”，就能较为方便的在不同应用甚至平台中使用。
因此如果只是自己用，那么确实按你的做法就足够了，但如果存在跨应用、跨平台等情况，还是考虑标准的webserivce吧，免得以后麻烦，总之还是那句经典屁话：“具体问题具体分析”。
=================
另外，效率上，个人认为Web service说白了也是一个Web，如果只能“每秒20次”，那么只能说明这台web服务器只能“每秒20次”。Web Service的效率低主要还是在soap的描述上，比如你的响应可能只是Response.Write( "OK ")，用来表示某个操作成功了，只有两个字节，但soap的则可能会有很多用于描述的信息，使得整个响应可能有500个字节（这里只是随便举例），自然就显得慢了，特别是网络不好时。
=================
基本上我个人是这样理解的，不一定正确，仅供参考:)
