webservice原理WebService基本原理和特点？

什么是web service?

上楼只是说了它的表层次的。

我补充一下 　从深层次上看，Web Service是一种新的Web应用程序分支，它们是自包含、自描述、模块化的应用，可以在网络(通常为Web)中被描述、发布、查找以及通过Web来调用。

　　Web Service便是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web Service能与其他兼容的组件进行互操作。

它可以使用标准的互联网协议，像超文本传输协议HTTP和XML，将功能体现在互联网和企业内部网上。

Web Service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。

你可以用你喜欢的任何语言(笔者用的是C#)，在你喜欢的任何平台上写Web Service。

求高人解惑，webservice到底是什么？

简单答一下： 1.web service本身不能做太多事，各种功能都是你自己编程实现的，但是你的程序只能自己用，自己看，别人根本不知道你的程序是什么样的。

而web service就是规定了一种方式，告诉你将你的程序如何的部署到服务器上，然后大家通过一种协商好的地址能找到你的程序的说明，说明的格式也是大家都协商好的，所以可以读懂……然后你就可以根据那个地址来调用这个程序的方法了。

你看，web service 本身貌似没干什么，它就是让你可以发布自己的程序和调用别人发布的程序。

2.协议基本就是上面提到的那些大家协商好的东西了，什么形式？什么格式？什么样式？之类的，可以说协议被库支持，其实顺序应该是先有了这个协议，然后这个库遵从这个协议来解析，就说支持这个协议。

3.其实webservice传的数据可以是任意啊，规定用各种格式只是考虑到webservice是牵扯到多方的，不规定的话就好像两个人用不同语言交流，完全互相都不懂，那么就没意义了。

xml是最通用的，你也可以说是和库绑定的，但是因为它简单通用，基本各种环境都支持解析xml

.Web服务的原理是什么，描述一下Web服务的基本架构和主要技术。

提供一种统一的、面向组件的编程模型。

Web Service的体系结构描述了三个角色（服务提供者、服务请求者、服务代理者）以及三个操作（发布、查找、绑定）。

Web主要技术特征：在传输层和网络层采用TCP/IP协议，缺省断口的80；在应用层采用HTTP协议，使用HTML文档实现信息交互；基本上运行在C/S模式下。

能否细说一下所谓的web service到底是什么。

一种通信交互技术，我举个例子来说就是：假如你做的网站需要用到淘宝的支付宝，或者银行的转账结账功能的时候..你就需要用到web service。

。

。

因为银行或者支付宝是绝对不会给你说它们是怎么实现这些功能的，你只有去申请他们的接口，得到他们的同意以后，他们就会给你一个API ..就是他们转账查账功能的接口，你通过操作这个接口获得你想要的数据！

这一系列的工作的完成就可以说是一个web service!

架构Web Service: 什么是Web服务?

本文将结合技术驱动的发展需求，详细介绍从技术上来看，到底什么是Web服务，以及Web服务的应用分类。

就技术角度而言，无论从哪个角度来看，Web服务都是对象/组件技术在中的延伸。

本文所引用的资源主要包括两类，一类是Web服务的技术资源网站，包含了大量Web服务的技术信息，另一类是Web服务“stack"系列技术规范，他们是一个整体的技术体系，包括UDDI、SOAP、WSDL、XML等。

本文的最后给出了这些资源的链接，有兴趣的读者可以通过这些 资源链接找到所需的内容。

Web对象 从外部的使用者的角度而言，Web服务是一种部署在Web上的对象/组件，它具备以下特征：完好的封装性，Web服务既然是一种部署在Web上的对象，自然具备对象的良好封装性，对于使用者而言，他能且仅能看到该对象提供的功能列表。

松散耦合，这一特征也是源于对象/组件技术，当一个Web服务的实现发生变更的时候，调用者是不会感到这一点的，对于调用者来说，只要Web服务的调用界面不变，Web服务的实现任何变更对他们来说都是透明的，甚至是当Web服务的实现平台从J2EE迁移到了.NET或者是相反的迁移流程，用户都可以对此一无所知。

对于松散耦合而言，尤其是在环境下的Web服务而言，需要有一种适合环境的消息交换协议。

而XML/SOAP正是目前最为适合的消息交换协议。

使用协约的规范性，这一特征从对象而来，但相比一般对象其界面规范更加规范化和易于机器理解。

首先，作为Web服务，对象界面所提供的功能应当使用标准的描述语言来描述(比如WSDL)；其次，由标准描述语言描述的服务界面应当是能够被发现的，因此这一描述文档需要被存储在私有的或公共的注册库里面。

同时，使用标准描述语言描述的使用协约将不仅仅是服务界面，它将被延伸到Web服务的聚合、跨Web服务的事务、工作流等，而这些又都需要服务质量(QoS)的保障。

其次，我们知道安全机制对于松散耦合的对象环境的重要性，因此我们需要对诸如授权认证、数据完整性(比如签名机制)、消息源认证以及事务的不可否认性等运用规范的方法来描述、传输和交换。

最后，在所有层次的处理都应当是可管理的，因此需要对管理协约运用同样的机制。

使用标准协议规范，作为Web服务，其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。

这些标准协议具有完全免费的规范，以便由任意方进行实现。

一般而言，绝大多数规范将最终有W3C或OASIS作为最终版本的发布方和维护方。

高度可集成能力。

由于Web服务采取简单的、易理解的标准Web协议作为组件界面描述和协同描述规范，完全屏蔽了不同软件平台的差异，无论是CORBA、DCOM还是EJB都可以通过这一种标准的协议进行互操作，实现了在当前环境下最高的可集成性。

回页首Web Service "Stack" 在前一节中，我们已经了解到为了完成在松散耦合的环境下的对象访问，以及在基本对象访问之上的诸如事务、工作流、安全机制等。

实现一个完整的Web服务体系需要有一系列的协议规范来支撑。

Figure 1. Web Service "stack" 其中，绿色部分是先前已经定义好的并且广泛使用的传输层和网络层的标准：IP、HTTP、SMTP等。

而蓝色部分是目前开发的Web服务的相关标准协议，包括服务调用协议SOAP、服务描述协议WSDL和服务发现/集成协议UDDI，以及服务工作流描述语言WSFL。

而橙色部分描述的是更高层的待开发的关于路由、可靠性以及事务等方面的协议。

黄色部分是各个协议层的公用机制，这些机制一般由外部的正交机制来完成。

从以上这个技术层次图我们看以看到，Web服务追求的第一目标是简单性。

可能大家会觉得很奇怪，有那么多协议，怎么能说他简单。

首先，这些协议本身都是简单的，无论是HTTP, FTP等传统的TCP/IP系统的网络协议，还是SOAP, WSDL, UDDI, WSFL等基于XML的协议，他们设计原则中的一个最重要点就是力求简单性。

相信大家如果对XML、SOAP等有深入了解的话，一定会深深体会这一点。

其次，一个可以使用的Web服务应当按照需要选用若干层次的功能，而无需所有的特性。

比如在目前状况下，一个简单应用可能只要使用WSDL/SOAP就可以架构一个符合规范的Web服务了。

最后，所有的机制完全是基于现有的技术，并没有创造一个完全的新体系。

无论是IPv4、HTTP、FTP这些现有的网络协议，还是SOAP、WSDL等这些基于XML而定义的协议都是遵循着一个原则：继承原有的被广泛接受的技术，这样才能使得Web服务被广泛接受。

回页首Web服务的类别 综合当今的Web应用以及Web服务的特点，我们认为Web服务实施的领域可以分为四类：Business-Oriented Web Service: 该类服务针对的是那些面向企业应用服务，包括企业内部的ERP系统，企业间的SCM/CRM等系统。

当这些系统以Web服务的形式在网络(和)中出现时，企业内的应用集成将更未容易，而在企业间的众多合作伙伴的系统对接也将不再是无法完成的任务。

目前现有的解决方案和产品的提供商有Bowstreet、Epicentric等。

Consumer-Oriented Web Service: 此类服务针对的是那些原先的B2C的网站的改造，为这些Browser-Oriented的Web应用增加(注意是增加)了Web服务的应用界面，使得第三方的桌面工具或其自身提供的增值的桌面工具能够利用更优秀的用户界面提供跨越多个B2C服务的桌面服务。

这将使得用户使用更为方便，能够获得更加便捷的服务。

比如我们完全就可以在个人理财桌面系统中集成(调用)上的股票价格查询Web服务、机票预定Web服务等，使得个人理财应用的自动化程度更高。

Device-Oriented Web Service: 此类服务的使用终端一般是手持设备和日用家电，对于前者而言，可以在不用修改网络服务的体系架构的前提下，令先前的网络服务支持除PC以外的各种终端，比如Palm、PocketPC、手机等。

如此，那些天气预报服务、Email服务、主动信息服务等将更为有效和便捷。

而后者对于日用家电，则可能是一个市场的启动期，有了Web服务作为基础框架，智能型的日用家电将真正获得标准的支持，从而有了广泛使用的可能。

System-Oriented Web Service: 一些传统意义上的系统服务，比如用户权限认证，系统监控等，如果被迁移到全球范围的上，或者企业内部的上，其作用范围将从单个系统或局部网络拓展到整个企业网络或整个。

如此，基于同一系统服务的不同应用将得以在整个环境中部署，譬如跨国企业的所有在线服务可以使用同一个用户权限认证Web服务。

回页首Web服务: 当今的技术最亮点Figure 2. Web服务的当前发展状况 以上这幅图是Gartner Group在研究了所有IT主流时尚技术的发展道路后，作出的抽象模型。

Y轴表明技术的受关注程度，而X轴则表示技术的应用的成熟度。

每一项技术在从出现到成熟的整个过程都将沿着图中的曲线前进，而且典型地，都将被划分为五个阶段：技术显现：一门技术被发明或定义之后，开始进入公众的视野； 不断膨胀的期望期：由于该项技术的划时代的突破，使人们对这项技术有着无比美好的想象和期望，这一阶段类似"网络的泡沫器"； 希望破灭之后的醒悟期：由于每项技术都不是万能的，真正获得使用仍然需要务实的加以应用研究，因此此时人们发现这项技术似乎并没有期望中那么有用，这一阶段类似"网络的泡沫破灭"； 豁然开朗的应用发展期：经过了一个阶段的开发和研究，该项技术终于走上了良性发展的轨道，越来越多的人接受并使用了该项技术； 大量的工业化生产期：该项技术成为业界主流，大量应用在具体的环境中。

参考资料 Web Service 技术/评论网站 UDDI-China.ORG,以UDDI为主的Web服务技术网站。

WebServices.ORG, Web服务的综合类技术网站。

IBM developerWorks/Web Service Zone, IBM的Web服务技术资源中心 MSDN Online Web Services Developer Resources, Microsoft的Web服务的开发者资源网站 ITPapers/Web Service, ITPapers的Web服务评论文章 解决B2B电子商务应用交互和集成的InterOP Stack系列技术标准规范 UDDI执行白皮书, , UDDI技术白皮书, , UDDI程序员API规范, , UDDI数据结构参考, , Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000 SOAP: Simple Object ess Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000 Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000 关于作者柴晓路: 上海得易电子商务技术有限公司( DealEasy)首席系统架构师、XML技术顾问。

蓝色火焰工作室(Blue Blaze Studio)成员。

UDDI Advisor Group成员， WSUI Working Group成员。

2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。

专长于基于XML的系统集成和数据交换的技术研究，同时对数据库、面向对象技术及CSCW等技术比较擅长。

关闭[x]关于报告滥用的帮助报告滥用谢谢! 此内容已经标识给管理员注意。

关闭[x]关于报告滥用的帮助报告滥用报告滥用提交失败。

请稍后重试。

关闭[x]developerWorks：登录IBM ID：需要一个 IBM ID？忘记IBM ID？密码：忘记密码？更改您的密码 保持登录。

单击提交则表示您同意developerWorks 的条款和条件。

使用条款 当您初次登录到 developerWorks 时，将会为您创建一份概要信息。

您在developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。

您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

关闭[x]请选择您的昵称：当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。

您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。

您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

昵称：（长度在 3 至 31 个字符之间）单击提交则表示您同意developerWorks 的条款和条件。

使用条款. 所有提交的信息确保安全。

为本文评分评论回页首

WebService基本原理和特点？

(一).XML WebService作用 XML WebService在应用程序中所起的作用与.Net远程调用处理组件相同. 用户不能直接使用WebService,只能通过 Web应用程序或Windows桌面 客户端来调用. (二).XML WebService与.Net远程处理区别 1. XML WebService比.Net远程处理对象所受的限制更多。

它类似于.Net远程处理 的单独调用对象的工作机制。

不能创建一个单独的或是由客户端激活的对象. 2.XML WebService的创建和设计比远程组件更容易/简单. 3.Net远程处理二进制通信要比XML WebService SOAP格式通信要快捷. 4.XML WebService较.Net远程处理扩展性强。

它支持以跨平台使用为目的的开放标准. 5.XML WebService不需要专门的宿主程序，而是由承载。

可以访问一些重要的 平台服务，如：数据缓存/网络会话状态管理/身份验证/全局共享应用程序集合等。

而.Net 远程处理则很难实现这些功能. 6.XML WebService运行在IIS和ASP.NET之上，使用http信道(80端口)与客户通信。

可以自由跨越防火墙. (三).XML WebService创建与调用过程 I.服务端创建 1.使用IIS，在Web服务器上新建一个虚拟目录来存放XML Web服务. 2.建立XML WebService类，使用[WebMethod]属性来标记方法可以被远程调用. 3.在虚拟目录中部署XML Web服务的文件. II.客户端使用 1.客户端通过URL或文件查询或UDDI注册，发现XML WebService 2.客户端请求描述XML WebService的WSDL文档。

3.客户端在WSDL文档的基础上生成一个代理类。

4.客户端生成代理类的实例，并调用XML Webservice，发送消息并接受处理后结果. 也就是说调用XML WebService是由客户端生成的代理类实例对象完成的. (四).IIS作用 1.IIS通过虚拟目录提供对Web服务器进行访问。

简单的说： 就是将"c:MyWeb"映射 一个URL地址形式的虚拟目录:" 上计算机访问Webservice. 2.虚拟目录的权限与普通目录不同。

根据默认设置，不允许远程用户浏览虚拟目录，运行 可执行文件，新建文件和下载某些文件类型文件。

可以根据需要自定义IIS虚拟目录权限设置. 3.IIS对进行公开处理. IIS并不负责运行Asp或布面 或XML Webservice,而是 维护一个注册的文件扩展名列表。

如果IIS收到对某一种文件类型的请求，就把工作提交给 工作进程，由工作进程处理剩下的工作. (五).XML WebService和SOAP标准支持的数据类型 不知道读者有没有遇到这种情况，在调用WebService并给一个方法传递了一个DataRow参数时，运行 时会抛出异常： "没法将参数序列化！"，如果把DataRow加入到DataSet中，并将DataSet作为参数 传递再运行就OK了。

这是因为：XML WebService只能对数据集DataSet对象类型进行XML序列化， 不能对DataRow对象类型进行XML序列化造成的错误. 所以了解一下XML WebService支持序列化的基 本数据类型是比较重要的.它支持的数据类型如下: 1.基本数据类型. 标准类型，如：int float bool DateTime string等基本数据类型 2.枚举. 支持枚举Enum定义的类型 3.自定义对象. 可以传递任意基于自定义类或结构创建的对象。

但要注意一点： 它只能传输数据成员(变量和属性). 如果定义了方法，则方法不能进行序列化传输,序列化后只剩下数据成员. 4.DataSet对象 支持DataSet,切记：不支持DataTable和DataRow,DataSet已经是XML Webservice能够支持的最小的可序列化对象. 5.XmlNode对象 基于XmlNode的对象可以表示XML文档的一部分. 6.数组和集合 可以使用任何被支持的类型的数组和简单集合，包括: DataSet对象/XmlNode对象和自定义对象.