http协议和webservice.docx
《http协议和webservice.docx》由会员分享，可在线阅读，更多相关《http协议和webservice.docx（9页珍藏版）》请在冰豆网上搜索。
http协议和webservice
竭诚为您提供优质文档/双击可除
http协议和webservice
篇一：
通过httpwebRequest对webservice进行动态调用
本文章设计到使用的代码示例的webservice为
服务路径：
http:
//localhost/webservicetest/service1.asmx
服务接口:
[webmethod]
publicstringhelloworld（stringstudentname,stringpassword）
{
return"helloworld";
}
1后台调用webservice的业务需求
在实际开发环境中，我们常常调用webservice时，通过项目中引用现实部署的webservice的asmx文件，生成客户端代理类的方式。
这种方式将和webservice进行了二次封装，并以代理类的方式进行调用，有利用简单，快捷的开发。
这种开发方式包含了两个重要的问题
1）在开发环境中必须可以访问需要调用的webservice，在开发一些大公司的内网系统时，我们往往在开发环境中访问不到，只仅仅在部署环境中访问。
2）webservice的接口发生版本变更，我们的应用系统需要重新编译并部署。
在发现以上的困惑后，直觉告诉我们，我们需要一种直接通过交互协议的方式进行访问webservice。
就像网页爬虫一样，去交互业务操作。
2webservice支持的交互协议
webservice支持三种方式
1）httppost方式（注意这种方式只对于本机调试使用，在web服务部署在其他机器上，应用程序不能通过httppost方式调用）
具体交互格式如下：
post/webservicetest/service1.asmx/helloworldhttp/1.1
host:
localhost
content-type:
application/x-www-form-urlencoded
content-length:
length
studentname=stringcharset=utf-8
content-length:
length
soapaction:
"http:
//tempuri.org/helloworld"
string
string
3）soap1.2协议
交互格式如下：
post/webservicetest/service1.asmxhttp/1.1
host:
localhost
content-type:
application/soap+xml;charset=utf-8
content-length:
length
string
string
3如何配置webservice支持的协议
webservice支持的协议包含两种soap1.1soap1.2对于webservice来讲可以通过配置文件配置，支持那些协议，默认的情况下两种协议都支持。
具体的配置方式为：
在配置文件中
4后台对webservice的调用
4.1soap1.1后台调用实例
stringstr1="\"双引号\"";
console.writeline（"新开始进行连接测试"）;
stringparam=@"
1
1
";
byte[]bs=encoding.utF8.getbytes（param）;
httpwebRequestmyRequest=（httpwebRequest）webRequest.create（"http:
//fox-gaolijun/short_message/service1.asmx"）;
myRequest.method="post";
myRequest.contenttype="text/xml;charset=utf-8";
myRequest.headers.add（"soapaction","http:
//tempuri.org/helloworld"）;myRequest.contentlength=bs.length;
console.writeline（"完成准备工作"）;
using（streamreqstream=myRequest.getRequeststream（））
{
reqstream.write（bs,0,bs.length）;
}
using（httpwebResponsemyResponse=（httpwebResponse）myRequest.getResponse（））
{
streamReadersr=newstreamReader（myResponse.getResponsestream（）,encoding.utF8）;
responsestring=sr.Readtoend（）;
console.writeline（"反馈结果"+responsestring）;
}
console.writeline（"完成调用接口"）;
}
catch（exceptione）
{
console.writeline（system.datetime.now.toshorttimestring（）+"lbsexception:
"+e.message）;
console.writeline（e.stacktrace）;
}
篇二：
webservice到底是什么？
一、序言
大家或多或少都听过webservice（web服务），有一段时间很多计算机期刊、书籍和网站都大肆的提及和宣传webservice技术，其中不乏很多吹嘘和做广告的成分。
但是不得不承认的是webservice真的是一门新兴和有前途的技术，那么webservice到底是什么？
何时应该用？
当前的应用程序开发逐步的呈现了两种迥然不同的倾向：
一种是基于浏览器的瘦客户端应用程序，一种是基于浏览器的富客户端应用程序（Ria），当然后一种技术相对来说更加的时髦一些（如现在很流行的html5技术），这里主要讲前者。
基于浏览器的瘦客户端应用程序并不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。
发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。
传统的windows富客户应用程序使用dcom来与服务器进行通信和调用远程对象。
配置好dcom使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多it工程师的噩梦。
事实上，许多it工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个dcom。
关于客户端与服务器的通信问题，一个完美的解决方法是使用http协议来通信。
这是因为任何运行web浏览器的机器都在使用http协议。
同时，当前许多防火墙也配置为只允许http连接。
许多商用程序还面临另一个问题，那就是与其他程序的互操作性。
如果所有的应用程序都是使用com或.net语言写的，并且都运行在windows平台上，那就天下太平了。
然而，事实上大多数商业数据仍然在大型主机上以非关系文件（Vsam）的形式存放，并由cobol语言编写的大型机程序访问。
而且，目前还有很多商用程序继续在使用c++、java、Visualbasic和其他各种各样的语言编写。
现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。
这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的api，如ibm的高级程序到程序交流（appc）等来完成的。
在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。
只有通过webservice，客户端和服务器才能够自由的用http进行通信，不论两个程序的平台和编程语言是什么。
二、webservice到底是什么？
一言以蔽之：
webservice是一种跨编程语言和跨操作系统平台的远程调用技术。
所谓跨编程语言和跨操作平台，就是说服务端程序采用java编写，客户端程序则可以采用其他编程语言编写，反之亦然！
跨操作系统平台则是指服务端程序和客户端程序可以在不同的操作系统上运行。
所谓远程调用，就是一台计算机a上的一个程序可以调用到另外一台计算机b上的一个对象的方法，譬如，银联提供给商场的pos刷卡系统，商场的pos机转账调用的转账方法的代码其实是跑在银行服务器上。
再比如，amazon，天气预报系统，淘宝网，校内网，XX等把自己的系统服务以webservice服务的形式暴露出来，让第三方网站和程序可以调用这些服务功能，这样扩展了自己系统的市场占有率，往大的概念上吹，就是所谓的soa应用。
其实可以从多个角度来理解webservice，从表面上看，webservice就是一个应用程序向外界暴露出一个能通过web进行调用的api，也就是说能用编程的方法通过web来调用这个应用程序。
我们把调用这个webservice的应用程序叫做客户端，而把提供这个webservice的应用程序叫做服务端。
从深层次看，webservice是建立可互操作的分布式应用程序的新平台，是一个平台，是一套标准。
它定义了应用程序如何在web上实现互操作性，你可以用任何你喜欢的语言，在任何你喜欢的平台上写webservice，只要我们可以通过webservice标准对这些服务进行查询和访问。
webservice平台需要一套协议来实现分布式应用程序的创建。
任何平台都有它的数据表示方法和类型系统。
要实现互操作性，webservice平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。
webservice平台必须提供一种标准来描述webservice，让客户可以得到足够的信息来调用这个webservice。
最后，我们还必须有一种方法来对这个webservice进行远程调用,这种方法实际是一种远程过程调用协议（Rpc）。
为了达到互操作性，这种Rpc协议还必须与平台和编程语言无关。
三、webservice平台技术
xml+xsd,soap和wsdl就是构成webservice平台的三大技术。
xml+xsd：
webservice采用http协议传输数据，采用xml格式封装数据（即xml中说明调用远程服务对象的哪个方法，传递的参数是什么，以及服务对象的返回结果是什么）。
xml是
webservice平台中表示数据的格式。
除了易于建立和易于分析外，xml主要的优点在于它既是平台无关的，又是厂商无关的。
无关性是比技术优越性更重要的：
软件厂商是不会选择一个由竞争对手所发明的技术的。
xml解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。
例如，整形数到底代表什么？
16位，32位，64位？
这些细节对实现互操作性很重要。
xmlschema（xsd）就是专门解决这个问题的一套标准。
它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。
webservice平台就是用xsd来作为其数据类型系统的。
当你用某种语言（如V或c#）来构造一个webservice时，为了符合
webservice标准，所有你使用的数据类型都必须被转换为xsd类型。
你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。
soap：
webservice通过http协议发送请求和接收结果时，发送的请求内容和结果内容都采用xml格式封装，并增加了一些特定的http消息头，以说明http消息的内容格式，这些特定的http消息头和xml内容格式就是soap协议。
soap提供了标准的Rpc方法来调用webservice。
soap协议=http协议+xml数据格式
soap协议定义了soap消息的格式，soap协议是基于http协议的，soap也是基于xml和xsd的，xml是soap的数据编码方式。
打个比喻：
http就是普通公路，xml就是中间的绿色隔离带和两边的防护栏，soap就是普通公路经过加隔离带和防护栏改造过的高速公路。
wsdl：
好比我们去商店买东西，首先要知道商店里有什么东西可买，然后再来购买，商家的做法就是张贴广告海报。
webservice也一样，webservice客户端要调用一个webservice服务，首先要有知道这个服务的地址在哪，以及这个服务里有什么方法可以调用，所以，webservice务器端首先要通过一个wsdl文件来说明自己家里有啥服务可以对外调用，服务是什么（服务中有哪些方法，方法接受的参数是什么，返回值是什么），服务的网络地址用哪个url地址表示，服务通过什么方式来调用。
wsdl（webservicesdescriptionlanguage）就是这样一个基于xml的语言，用于描述webservice及其函数、参数和返回值。
它是webservice客户端和服务器端都能理解的标准格式。
因为是基于xml的，所以wsdl既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。
一些最新的开发工具既能根据你的webservice生成wsdl文档，又能导入wsdl文档，生成调用相应webservice的代理类代码。
wsdl文件保存在web服务器上，通过一个url地址就可以访问到它。
客户端要调用一个webservice服务之前，要知道该服务的wsdl文件的地址。
webservice服务提供商可以通过两种方式来暴露它的wsdl文件地址：
1.注册到uddi服务器，以便被人查找；2.直接告诉给客户端调用者。
四、webservice开发
webservice开发可以分为服务器端开发和客户端开发两个方面：
服务端开发：
把公司内部系统的业务方法发布成webservice服务，供远程合作单位和个人调用。
（借助一些webservice框架可以很轻松地把自己的业务对象发布成webservice服务，java方面的典型webservice框架包括：
axis，xfire，cxf等，javaee服务器通常也支持发布webservice服务，例如jboss。
）
客户端开发：
调用别人发布的webservice服务，大多数人从事的开发都属于这个方面，例如，调用天气预报webservice服务。
（使用厂商的wsdl2java之类的工具生成静态调用的代理类代码；使用厂商提供的客户端编程api类；使用sun公司早期标准的jax-rpc开发包；使用sun公司最新标准的jax-ws开发包。
当然sun已被oRacle收购）
webservice的工作调用原理：
对客户端而言，我们给这各类webservice客户端api传递wsdl文件的url地址，这些api就会创建出底层的代理类，我调用这些代理，就可以访问到webservice服务。
代理类把客户端的方法调用变成soap格式的请求数据再通过http协议发出去，并把接收到的soap数据变成返回值返回。
对服务端而言，各类webservice框架的本质就是一个大大的servlet，当远程调用客户端给它通过http协议发送过来soap格式的请求数据时，它分析这个数据，就知道要调用哪个java类的哪个方法，于是去查找或创建这个对象，并调用其方法，再把方法返回的结果包装成soap格式的数据，通过http响应消息回给客户端。
五、适用场合
1、跨防火墙通信：
如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。
因为客户端和服务器之间通常会有防火墙或者代理服务器。
在这种情况下，使用dcom就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。
传统的做法是，选择用浏览器作为客户端，写下一大堆asp页面，把应用程序的中间层暴露给最终用户。
这样做的结果是开发难度大，程序很难维护。
如果中间层组件换成webservice的话，就可以从用户界面直接调用中间层组件。
从大多数人的经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用webservice这种结构，可以节省花在用户界面编程上20%的开发时间。
2、应用程序集成：
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。
应用程序经常需要从运行在
ibm主机上的程序中获取数据；或者把数据发送到主机或unix应用程序中去。
即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。
通过webservice，可以很容易的集成不同结构的应用程序。
3、b2b集成：
用webservice集成应用程序，可以使公司内部的商务处理更加自动化。
但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？
跨公司的商务交易集成通常叫做b2b集成。
webservice是b2b集成成功的关键。
通过webservice，公司可以把关键的商务应用
“暴露”给指定的供应商和客户。
例如，把电子下单系统和电子发票系统“暴露”出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。
当然，这并不是一个新的概念，edi（电子文档交换）早就是这样了。
但是，webservice的实现要比edi简单得多，而且webservice运行在internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。
不过，webservice并不像edi那样，是文档交换或b2b集成的完整解决方案。
webservice只是b2b集成的一个关键部分，还需要许多其它的部分才能实现集成。
用webservice来实现b2b集成的最大好处在于可以轻易实现互操作性。
只要把商务逻辑“暴露”出来，成为webservice，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。
这样就大大减少了花在b2b集成上的时间和成本，让许多原本无法承受edi的中小企业也能实现b2b集成。
4、软件和数据重用：
软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。
最基本的形式是源代码模块或者类一级的重用，一种形式是二进制形式的组件重用。
采用webservice应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用，达到业务级重用。
六、不适用场合
1、单机应用程序：
目前，企业和个人还使用着很多桌面应用程序。
其中一些只需要与本机上的其它程序通信。
在这种情况下，最好就不要用webservice，只要用本地的api就可以了。
com非常适合于在这种情况下工作，因为它既小又快。
运行在同一台服务器上的服务器软件也是这样。
最好直接用com或其它本地的api来进行应用程序间的调用。
当然webservice也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。
篇三：
soapwebserivce和Restfulwebservice对比及区别
soapwebserivce和Restfulwebservice对比及区别简单对象访问协议（simpleobjectaccessprotocol，soap
）是一种基于xml的协议，可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（http），简单邮件传输协议（smtp），多用途网际邮件扩充协议（mime），基于“通用”传输协议是soap的一个优点。
它还支持从消息系统到远程过程调用（Remoteprocedurecall，Rpc）等大量的应用程序。
soap提供了一系列的标准，如wsRm（ws-Reliablemessaging）形式化契约确保可靠性与安全性，确保异步处理与调用；ws-security、ws-transactions和ws-coordination等标准提供了上下文信息与对话状态管理。
相对而言，soap协议属于复杂的、重量级的协议，当前随着web2.0的兴起，表述性状态转移（Representationalstatetransfer，Rest）逐步成为一个流行的架构风格。
Rest是一种轻量级的webservice架构风格，其实现和操作比soap和xml-Rpc更为简洁，可以完全通过http协议实现，还可以利用缓存cache来提高响应速度，性能、效率和易用性上都优于soap协议。
Rest架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应http协议提供的get、post、put和delete方法，这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。
Rest架构尤其适用于完全无状态的cRud（create、Read、update、delete，创建、读取、更新、删除）操作。
基于Rest的软件体系结构风格（softwarearchitecturestyle）称之为面向资源体系架构（Resource-orientedarchitecture，Roa）。
按照Rest原则设计的软件、体系结构，通常被称为“Rest式的”（Restful），在本文中以下称之为Restfulweb服务，以便于和基于soap的web服务区别。
服务器端采用j2ee，客户端采用jsp、Flex、javaFx、aiR等可以直接调用servlet，其他的实现技术基本上不能直接调用，但是无论是那种客户端，对于基于soap的web服务或者基于Restfulweb服务务都是支持的，如ajax的xmlhttpRequest、Flex的httpservice等。
客户端和服务器端的通讯方式：
http的get、head请求本质上应该是安全的调用，即：
get
、head调用不会有任何的副作用，不会造成服务器端状态的改变。
对于服务器来说，客户端对某一uRi做n次的get、haed调用，其状态与没有做调用是一样的，不会发生任何的改变。
http的put、delte调用，具有幂指相等特性,即：
客户端对某一uRi做n次的put、delte调用，其效果与做一次的调用是一样的。
http的get、head方法也具有幂指相等特性。
http这些标准方法在原则上保证你的分布式系统具有这些特性，以帮助构建更加健壮的分布式系统。
一、安全控制
为了说明问题，基于上面的在线用户管理系统，我们给定以下场景：
参考一开始我们给出的用例图，对于客户端client2，我们只希望它能以只读的方式访问user和userlist资源，而client1具有访问所有资源的所有权限。
如何做这样的安全控制？
通行的做法是：
所有从客户端client2发出的http请求都经过代理服务器（proxyserver）。
代理服务器制定安全策略：
所有经过该代理的访问user和userlist资源的请求只具有读取权限，即：
允许get/head操作，而像具有写权限的put/delte是不被允许的。
如果对于Rest，我们看看这样的安全策略是如何部署的。
如下图所示：
一般代理服务器的实现根据（uRi,httpmethod）两元组来决定http请求的安全合法性。
当发现类似于（http:
//localhost:
81
升级会员 