博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
webservice之入门一
阅读量:7044 次
发布时间:2019-06-28

本文共 4406 字,大约阅读时间需要 14 分钟。

hot3.png

        昨天有了第一篇博客后,感觉自己必须坚持下去,所以今天就根据工作需求,来系统的去学习一些跟工作有关系的东西!首先是webservice。

        那么什么是webservice呢?那么下面我就用博客记录一下我学习的过程!我的学习思路如下:

        1.它是个什么玩意?

        2.它基本怎么使用?

        3.它还能怎么使用?

        4.来把它拆开看看里面是个什么玩儿?

--------------------------------------------------------------------------------------------------------------------

webservice之简介:

        webservice:是一个平台独立的,低耦合的,自包含的、基于可编程的web的应用程序。再说的简单明了一点就是它是一种跨编程语言和跨操作系统的远程调用技术。

        webservice优势和劣势:在早期的WebService开发中,由于带宽与存储容量的限制,令它并不被人关注。随着技术的发展,带宽与存储已经不成任何问题了,随便一条光纤就有1000M,家庭用的计算机都有160GB,更不要说服务器用的动辄就上TB的磁盘阵列了。然而,随着Internet的飞速发展,人们都应该感觉到网络给人们带来的新惊喜了,那就是网上办公。现在的网上办公系统是越做越先进,但是有一个通病——兼容性问题,因此沟通十分的困难,然而WebService则让人的沟通更加顺畅。打个比方:两国的人交流需要翻译,十分麻烦,因此不如统一两国的语言。而WebService就是这样的一个新的概念。WebService的发展时间很短,因此导致了一个问题——安全性。由于XML传输全部是明文传输,因此导致了安全性问题也不奇怪,但只需在要传输的数据上做点手脚就解决了。 

分布式应用程序和浏览器 
研究一下当前的应用程序开发,你会发现一个绝对的倾向:人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面,而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高,一半是因为应用程序安装和配置的问题,另一半是因为客户和服务器之间通信的问题。 
传统的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进行通信,不论两个程序的平台和编程语言是什么。(这里是摘抄的部分)说白了,它的优点就是可以跨平台和跨语言调用,缺点就是数据传输中的安全问题,不过这个可以加密,也不算很大的问题!

webservice的组成:

    在学习中我看了一些网上的介绍,大部分都是说Web Service = SOAP + HTTP + WSDL。

其中soap(simple object access protocol)协议是webservice的主体,他通过HTTP或者SMTP等应用层协议进行通讯,自身通过xml文件来描述程序的函数和参数信息,从而完成不同语言和不同操作系统之间的计算处理。这里的WSDL(web service description language) web服务描述语言也是一个xml文档,他通过通讯协议向外发布。

SOAP协议介绍:

        soap协议指的是简单的对象访问协议,它是一种基于xml的消息通讯格式,用于不同语言,不同操作系统的应用程序间的通讯。因为他是基于xml,所以它有可自定义和可扩展的属性。so  一条soap消息就包含以下元素:

       Envelope 元素,标识XML 文档一条 SOAP 消息

  Header 元素,包含头部信息的XML标签

  Body 元素,包含所有的调用和响应的主体信息的标签

  Fault 元素,错误信息标签。 

  以上的元素都在 SOAP的命名空间http://www.w3.org/2001/12/soap-envelope中声明;

  SOAP的语法规则

  SOAP 消息必须用 XML 来编码

  SOAP 消息必须使用 SOAP Envelope 命名空间

  SOAP 消息必须使用 SOAP Encoding 命名空间

  SOAP 消息不能包含 DTD 引用

  SOAP 消息不能包含 XML 处理指令

  SOAP 消息的基本结构

    
    
         ...    
    
         ...      
          ...      
    
    

SOAP Envelope 元素

  Envelope 元素是 SOAP 消息的根元素。它指明 XML 文档是一个SOAP 消息。它的属性 xmlns:soap的值必须是http://www.w3.org/2001/12/soap-envelope。

  encodingStyle 属性,语法:soap:encodingStyle="URI"

  encodingStyle 属性用于定义文档中使用的数据类型。此属性可出现在任何 SOAP 元素中,并会被应用到元素的内容及元素的所有子元素上。 

SOAP Header 元素 

  actor 属性,语法soap:actor="URI" 

  通过沿着消息路径经过不同的端点,SOAP 消息可从某个发送者传播到某个接收者。并非 SOAP 消息的所有部分都打算传送到 SOAP 消息的最终端点,不过,另一个方面,也许打算传送给消息路径上的一个或多个端点。SOAP 的 actor 属性可被用于将 Header 元素寻址到一个特定的端点。 

  mustUnderstand 属性 ,语法soap:mustUnderstand="0|1" 

  SOAP 的 mustUnderstand 属性可用于标识标题项对于要对其进行处理的接收者来说是强制的还是可选的。假如您向 Header 元素的某个子元素添加了 "mustUnderstand="1",则要求处理此头部的接收者必须认可此元素。

  
  
  

SOAP Body 元素

  必需的 SOAP Body 元素可包含打算传送到消息最终端点的实际 SOAP 消息。Body元素中既可以包含SOAP定义的命名空间中的元素,如Fault,也可以是用户的应用程序自定义的元素。以下是一个用户定义的请求:

  
  
     
        
Apples
       
  

 上面的例子请求苹果的价格。请注意,上面的 m:GetPrice 和 Item 元素是应用程序专用的元素。它们并不是 SOAP 标准的一部分。既然有请求,那么肯定是要有响应的,下面就是对应soap的响应:

SOAP Fault 元素

  Fault 元素表示 SOAP的错误消息。它必须是 Body 元素的子元素,且在一条 SOAP 消息中,Fault 元素只能出现一次。Fault 元素拥有下列子元素:140937_sBiI_2606929.gif

常用的SOAP Fault Codes

141041_DpyT_2606929.gif

HTTP协议中的SOAP 实例

  下面的例子中,一个 GetStockPrice 请求被发送到了服务器。此请求有一个 StockName 参数,而在响应中则会返回一个 Price 参数。此功能的命名空间被定义在此地址中: "

SOAP 请求:(注意HTTP的Head属性)

POST /InStock HTTP/1.1  Host: www.jsoso.net  Content-Type: application/soap+xml; charset=utf-8  Content-Length: XXX    
  
    
      
        
IBM
      
        

SOAP 响应:(注意HTTP的Head属性)

HTTP/1.1 200 OK  Content-Type: application/soap+xml; charset=utf-8  Content-Length: XXX    
  
    
      
        
34.5
      
        

HTTP协议中的SOAP RPC工作流程

141729_FPud_2606929.gif

    

        

转载于:https://my.oschina.net/u/2606929/blog/601347

你可能感兴趣的文章
装饰器和分布式计算
查看>>
Vue.js+Bootstrap构建todo
查看>>
Python27+Opencv3 VideoCapture FALSE问题记录
查看>>
如何在 Linux 系统查询机器最近重启时间
查看>>
jQuery插件学习(二)
查看>>
地图服务器控件GIS Map Server v3.6发布,新增航空影像数据集功能
查看>>
Root WebApplicationContext
查看>>
Maven私服Nexus3.x环境构建操作记录
查看>>
java 线程 Lock 锁使用Condition实现线程的等待(await)与通知(signal)
查看>>
dubbo服务配置sentinel
查看>>
亚马逊下架一款智能玩具,几维安全提醒智能终端安全不容忽视
查看>>
计算机指令在CPU中的执行过程(图文版)
查看>>
理解 iOS 和 macOS 的内存管理
查看>>
Ajax (部分一)自己做的,总结页面向后台传Form值、单个值和后台向前台传一个或是一组值...
查看>>
web缓存技术
查看>>
集合知识点
查看>>
Linux快捷键
查看>>
文档对象模型DOM
查看>>
2019北京国际康复及个人健康博览会将在中国国际展览中心举办
查看>>
JVM——类加载机制(一)
查看>>