HTTP下的Webservice功能及应用
一、引言
随着互联网技术的快速发展，Webservice已成为企业间实现信息交互的重要技术手段。
HTTP作为Webservice的主要传输协议，因其开放、通用、跨平台等特点，被广泛应用于各种业务场景。
本文将对HTTP下的Webservice功能及其应用场景进行深入探讨。
二、Webservice概述
Webservice是一种基于Web标准的分布式服务架构，通过SOAP（简单对象访问协议）或RESTful等协议，实现不同系统间的数据交互和集成。
Webservice使用HTTP作为通信协议，通过XML或JSON等格式的数据进行信息的传递和交换。
三、HTTP下的Webservice功能
1. 数据传输：HTTP协议为Webservice提供了可靠的数据传输功能。通过HTTP请求和响应，Webservice可以在不同系统间传输数据，实现信息的共享和交互。
2. 服务发现：通过HTTP的URL和SOAP协议中的WSDL（Web服务描述语言），Webservice可以实现服务的自动发现和描述。这使得客户端能够轻松地找到并调用相应的服务。
3. 身份验证和授权：HTTP提供了基本的身份验证和授权机制，如基本身份验证、摘要身份验证和OAuth等。这些机制可以确保Webservice的安全性，防止未经授权的访问和数据泄露。
4. 负载均衡：通过HTTP的负载均衡技术，如CDN（内容分发网络）和反向代理服务器，Webservice可以实现高性能的分布式部署，提高系统的可扩展性和稳定性。
5. 状态管理：HTTP协议中的Cookie和Session机制可以用于Webservice的状态管理。这些机制可以跟踪用户的访问状态，实现用户的个性化服务和无缝体验。
四、HTTP下的Webservice应用场景
1. 电子商务：在电子商务领域，Webservice被广泛应用于商品信息的同步、订单处理、支付通知等场景。通过Webservice，商家可以实现与第三方平台的数据交互，提高业务效率和用户体验。
2. 金融服务：金融行业需要实现跨系统的数据交互和业务流程自动化。Webservice可以通过HTTP协议，实现银行、支付机构、信贷公司等之间的信息交换，如账户查询、转账、信贷审批等。
3. 物联网：物联网领域需要将各种设备的数据进行收集、处理和传输。Webservice可以通过HTTP协议，实现设备与云端服务器的数据交互，实现设备的远程监控、数据分析和预测维护等功能。
4. 企业信息化：在企业信息化建设中，Webservice被广泛应用于系统集成和数据共享。通过Webservice，企业可以将各个业务系统的数据进行整合，实现业务流程的自动化和优化。
5. 软件开发：在软件开发过程中，Webservice可以作为应用程序之间的接口（API），实现不同应用程序间的数据交互和功能调用。这有助于提高软件的可扩展性和可维护性，降低开发成本。
五、结论
HTTP下的Webservice功能强大，应用场景广泛。
通过HTTP协议，Webservice实现了不同系统间的数据交互和集成，提高了业务效率和用户体验。
在未来，随着技术的不断发展，Webservice将在更多领域得到应用，推动数字化转型的进程。
六、建议与展望
1. 加强Webservice的安全性：随着Webservice的应用越来越广泛，安全性问题日益突出。建议加强Webservice的安全防护，采用加密技术、身份验证和授权机制等手段，确保数据的安全性和隐私性。
2. 优化Webservice的性能：随着业务量的增长，Webservice的性能瓶颈逐渐显现。建议优化Webservice的性能，采用负载均衡、缓存技术、异步通信等手段，提高系统的响应速度和并发能力。
3. 推动Webservice的标准化和规范化：建议推动Webservice的标准化和规范化，制定统一的规范和标准，促进不同系统间的互操作性和兼容性，降低开发和使用成本。HTTP下的Webservice功能强大且应用广泛。随着技术的不断发展，Webservice将在更多领域发挥重要作用。我们需要不断研究和探索Webservice的新技术、新应用和新场景，推动数字化转型的进程。
如何通过HTTPS方式访问web service
web service在企业应用中常常被用作不同系统之间的接口方式。
但是如果没有任何安全机制的话，显然是难以委以重任的。
比较直接的web service加密方式就是使用HTTPS方式(SSL证书加密)加密连接，并且只允许持有信任证书的客户端连接，即SSL双向认证。
这样就保证了连接来源的可信度以及数据在传输过程中没有被窃取或篡改。
通过HTTPS加密方式访问web service具体方法如下：【准备工作】(1)检查JDK的环境变量是否正确。
本文使用JDK 1.6(2)准备web服务器，这里选用TOMCAT 6.0(3)准备web service服务端和客户端。
【生成证书】这里用到的文件，这里存放在D:/SSL/文件夹内，其中D:/SSL/server/内的文件是要交给服务器用的，D:/SSL/client/内的文件是要交给客户端用的。
1生成服务端证书开始-运行-CMD-在dos窗口执行下执行命令：keytool -genkey -v -aliastomcat -keyalg RSA -keystore D:/SSL/server/ -dnameCN=127.0.0.1,OU=zlj,O=zlj,L=Peking,ST=Peking,C=CN -validity 3650-storepass zljzlj -keypass zljzlj说明：keytool 是JDK提供的证书生成工具，所有参数的用法参见keytool –help-genkey 创建新证书-v 详细信息-alias tomcat 以”tomcat”作为该证书的别名。
这里可以根据需要修改-keyalg RSA 指定算法-keystoreD:/SSL/server/ 保存路径及文件名-dnameCN=127.0.0.1,OU=zlj,O=zlj,L=Peking,ST=Peking,C=CN 证书发行者身份，这里的CN要与发布后的访问域名一致。
但由于这里是自签证书，如果在浏览器访问，仍然会有警告提示。
真正场景中建议申请CA机构(wosign)签发的SSL证书更安全。
-validity 3650证书有效期，单位为天-storepass zljzlj 证书的存取密码-keypass zljzlj 证书的私钥2 生成客户端证书执行命令：keytool ‐genkey ‐v ‐aliasclient ‐keyalg RSA ‐storetype PKCS12 ‐keystore D:/SSL/client/client.p12 ‐dnameCN=client,OU=zlj,O=zlj,L=bj,ST=bj,C=CN ‐validity 3650 ‐storepassclient ‐keypass client说明：参数说明同上。
这里的-dname 证书发行者身份可以和前面不同，到目前为止，这2个证书可以没有任何关系。
下面要做的工作才是建立2者之间的信任关系。
3 导出客户端证书执行命令：keytool ‐export ‐aliasclient ‐keystore D:/SSL/client/client.p12 ‐storetype PKCS12 ‐storepass client‐rfc ‐file D:/SSL/client/说明：-export 执行导出-file 导出文件的文件路径4 把客户端证书加入服务端证书信任列表执行命令：keytool ‐import ‐aliasclient ‐v ‐file D:/SSL/client/ ‐keystoreD:/SSL/server/ ‐storepass zljzl说明：参数说明同前。
这里提供的密码是服务端证书的存取密码。
5 导出服务端证书执行命令：keytool -export -aliastomcat -keystore D:/SSL/server/ -storepass zljzlj -rfc -fileD:/SSL/server/说明：把服务端证书导出。
这里提供的密码也是服务端证书的密码。
6 生成客户端信任列表执行命令：keytool -import -fileD:/SSL/server/ -storepass zljzlj -keystoreD:/SSL/client/ -alias tomcat –noprompt说明：让客户端信任服务端证书【 配置服务端为只允许HTTPS连接】1 配置Tomcat 目录下的/conf/代码：<Connectorport=8443 protocol=HTTP/1.1 SSLEnabled=truemaxThreads=150 scheme=https secure=trueclientAuth=true sslProtocol=TLSkeystoreFile=D:/SSL/server/ keystorePass=zljzljtruststoreFile=D:/SSL/server/ truststorePass=zljzlj />说明：在里面这段内容本来是被注释掉的，如果想使用https的默认端口443，请修改这里的port参数。
其中的clientAuth=true 指定了双向证书认证。
什么是webservice，什么情况下使用,如何使用？
此后，我还会举出不应该使用Webservice的一些情况。
跨越防火墙的通信如果你的应用程序有成千上万的用户，而且他们都分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。
那是因为客户端和服务器之间通常都会有防火墙或者代理服务器。
在这种情况下，你想使用DCOM就不是那么简单了，而且，通常你也不愿意把你的客户端程序发布到如此庞大数量的每一个用户手中。
于是，你最终选择了用浏览器作为客户端，写下一堆ASP页面，把应用程序的中间层暴露给最终用户。
结果呢？运气好的话，只是开发难度大了一些，运气不好的话，就会得到一个根本无法维护的应用程序。
想象一下你应该怎么在你的应用程序里面加入一个新的页面：你必须先建立好用户界面(Web页面)，以及在这个页面后面，包含相应商业逻辑的中间层组件。
这还不够，你还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把”结果页”送回浏览器。
要是客户端代码不再如此依赖于HTML表单，客户端的编程不就简单多了吗？还有，建立ASP页面的那一步可以省略掉吗？当然。
如果你的中间层组件是Webservice的话，你完全可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。
要调用Webservice，你可以直接使用MicrosoftSOAPToolkit或这样的SOAP客户端，也可以使用你自己开发的SOAP客户端，然后把它和你的应用程序连接起来。
这样做，不仅可以缩短开发周期，还可以减少代码的复杂度，并增强整个应用程序的可维护性。
同时，你的应用程序也不再需要在每次调用中间层组件时，都跳转到相应的”结果页”了。
以我的经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Webservice这种结构，可以轻松的节省花在用户界面编程上的20%的开发时间。
这样做还有另一个好处，就是你将得到一个由Webservice组成的中间层，这一层是完全可以在应用程序集成或其他场合下被重用的。
最后，通过Webservice把你的应用程序的逻辑和数据暴露出来，还可以让其它平台上的客户重用你的应用程序。
应用程序集成企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发的力量。
你的应用程序经常都需要从运行在古老的IBM主机上的程序中获取数据；或者再把数据发送到主机或UNIX应用程序中去。
即使是在同一个平台上，不同的软件厂商生产的各种软件也常常需要集成起来。
通过Webservice，应用程序可以用标准的方法把功能和数据暴露出来，供其它的应用程序使用。
例如，你有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等信息。
同时，你还有一个订单执行程序，用于实际货物发送的管理。
这两个程序是来自不同软件厂商的。
一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。
通过在订单执行程序上面增加一层Webservice，订单执行程序可以把”AddOrder”函数暴露出来。
这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。
进而通过Webservice集成应用程序B2B的集成用Webservice集成应用程序，可以使你公司内部的商务处理更加自动化。
但当交易跨越了你的供应商和客户，突破了公司的界线时又会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。
Webservice是B2B集成成功的关键。
通过Webservice，你的公司可以把关键的商务应用暴露给指定的供应商和客户。
例如，把你的电子下单系统和电子发票系统暴露出来，你的客户就可以以电子的方式向你发送购货订单，而你的供应商则可以以电子的方式把原料采购的发票发送给你。
当然，这并不是一个新的概念：电子文档交换(EDI)早就是这样了。
Webservice和EDI之间的主要区别在于，Webservice的实现要比EDI简单得多，而且Webservice是运行在Internet上的，在世界任何地方都可轻易实现，这样其运行成本就相对较低。
不过，Webservice并不像EDI那样，是文档交换或B2B集成的一套完整的解决方案。
Webservice只是B2B集成的一个关键部分，还需要许多其它的部分才能完成这个集成。
用Webservice来实现B2B集成的最大好处在于可以轻易实现互操作性。
只要把你的商务逻辑暴露出来，成为Webservice，你就可以让任何指定的合作伙伴轻松的调用你的商务逻辑，而不管他们的系统在什么平台上运行，使用的是什么开发语言。
这样就大大减少了花在B2B集成的上的时间和成本。
这样的低成本让许多原本无法承受EDI的投资成本的中小企业也能实现B2B集成。
软件重用软件重用是一个很大的主题，它有很多的形式和程度。
最基本的形式是源代码模块或者类一级的重用。
另一种形式是二进制形式的组件重用。
当前，像表格控件或用户界面控件这样的可重用软件组件在市场上都占有很大的份额。
但这类软件的重用都有一个很严重的限制：重用仅限于代码，而数据不能被重用。
原因在于你可以很轻易的发布组件甚至源代码，但要发布数据就没那么容易了，除非那些数据都是不会经常变化的静态数据。
而Webservice允许你在重用代码的同时，重用代码后面的数据。
使用Webservice，你不再像以前那样，要先从第三方购买、安装软件组件，再从你的应用程序中调用这些组件。
你只需要直接调用远端的Webservice就可以了。
举个例子，你想在你的应用程序中确认用户输入的邮件地址，那么，你只需把这个地址直接发送给相应的Webservice，这个Webservice就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址的确在相应的邮政编码区域。
Webservice的提供商可以按时间或使用次数来对这项服务进行收费。
这样的服务要通过组件重用来实现是不现实的，因为那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。
另一种软件重用的情况是把好几个应用程序的功能集成起来。
例如，你想要建立一个局域网上的门户站点应用，让用户既可以查询他们的联邦快递包裹，察看股市行情，又可以管理他们的日程安排，还可以在线购买电影票。
现在Web上有很多应用程序供应商，都在其应用中实现了上面的这些功能。
一旦他们把这些功能都通过Webservice暴露出来，你就可以非常轻易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。
用Webservice来集成各种应用中的功能，为用户提供一个统一的界面许多应用程序都会利用Webservice，把当前基于组件的应用程序结构扩展为组件和Webservice的混合结构。
你也可以在应用程序中使用第三方的Webservice提供的功能。
你还可以把你自己的应用程序的功能通过Webservice提供给别人。
所有这些情况下，你都可以重用代码和代码后面的数据。
总之，Webservice将是软件重用的一种非常有力的形式。
什么时候不应该使用WebService一个对Webservice的完整介绍还应该包括什么时候不该用Webservice。
经过前面的介绍，我们知道了Webservice在通过Web进行互操作或远程调用的时候是最有用的。
不过，还有许多情况，Webservice根本不能给你带来任何好处。
单机应用程序目前，我们还有很多桌面应用程序是供商用和个人使用的。
其中一些只需要与运行在本机上的其他程序通信。
在这种情况下，我们最好就不要再用Webservice，只要用本地的API就可以了。
COM非常适合于在这种情况下工作，因为它既小又快。
运行在一台服务器上的服务器软件也是这样：最好直接用COM或其他本地的API来进行应用程序间的调用。
当然Webservice也能用在这些情况下，但那样不仅消耗太大，而且不会给你带来任何好处。
局域网上的同构应用程序在许多应用中，你所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。
例如，你有两个服务器应用程序需要相互通信，或者你有一个Win32或WinForm的客户程序要连接到局域网上的另一个服务器程序。
在这些程序里使用DCOM会比SOAP/HTTP有效的多。
类似的，如果你的一个程序要连接到LAN上的另一个程序，那么你应该使用。
有趣的是，在中，你也可以指定使用SOAP/HTTP来进行Webservice调用。
不过最好还是直接通过TCP进行RPC调用，那样会有效得多。
总之，只要你从应用程序结构的角度看来，有别的方法比Webservice更有效，更可行，那就不要再用Webservice。
总结Webservice是创建可互操作的分布式应用程序的新平台。
Webservice的主要目标是跨平台的可互操作性。
为了达到这一目标，Webservice是完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。
Webservice在应用程序跨平台和跨网络进行通信的时候是非常有用的。
Webservice适用于应用程序集成、B2B集成、代码和数据重用，以及通过Web进行客户端和服务器的通信的场合。
当然，Webservice也不是万能的，你不能到处滥用Webservice。
在有些情况下，Webservice会降低应用程序的性能，而不会带来任何好处。
例如，一台机器或一个局域网里面运行的同构应用程序就不应该用Webservice进行通信。
11 用gridview如何把其中一行添加下拉列表框并绑定数据库？如何分页和动态排序？答：先生成模版，在EditItemTemplate里放一个下拉筐进去，选择数据源即可 。
请教httpservice和webservice的适用范围
1.基于不同协议：HTTPService基于http协议，而WebService基于soap协议 2.处理数据效率不同：HTTPService效率较高，WebService能处理较复杂的数据类型 3.跨域的处理：HttpService方式不能处理跨域，如果调用一个其它应用的服务就要用webService
