WebService第一天

WebService第一天 java

 

【課程安排】:web

總體安排:2天:面試

第一天:webservice入門,JDK規範和實現:jax-ws,相關概念spring

次日:CXF框架,和spring的集成開發。Hessian的開發。數據庫

 

今日安排:(jax-ws)編程

  1. 爲何要用ws?
  2. 第一個ws應用(聯網,在網上鍊接已經提供的服務,來獲取數據。)
  3. Ws概述(概念、三要素wsdl.soap.uddi)
  4. Jax-ws(sun規範,開發服務端和客戶端)
  5. Ws深刻探討(理解、應用場景)--閱讀
  6. WSDL詳解(規範)
  7. SOAP詳解(規範)
  8. WebService註解
  9. 複雜類型的支持+回顧
  10. 調試工具SOAPUI

 

【學習目標】:json

  1. 理解遠程調用的思想
  2. 學會JAX-WS的服務端和客戶端的開發(接口的開發和調用)
  3. 調試工具的使用。

 

  1. 爲何要用Webservice

Webservice是什麼?是一個遠程調用技術。api

遠程:相對於本地,不是當前應用服務的。服務器

調用:數據交互網絡

  1. 原來的數據傳輸處理方式

原來的都是單機系統,

特色:數據的存儲和調用都是透明的。好比數據庫的存儲方式、類型等。都是知道的、模塊之間的調用也是隨意的、透明的。

 

  1. 業務需求的問題

1.本身想要,但沒有

2.本身有數據,別人想要

 

  1. 如何解決上述問題

  • 開放數據庫權限?(在一個機房,是一個單位的不一樣系統)
  • U盤拷貝?(高考業務,每一年只查詢一次,教育局纔有)
  • 本身收集數據?
  • ……

 

  1. 咱們的需求

  1. 能夠經過接口的技術來獲取數據。

接口的概念:

  1. 須要什麼接口呢?

 

之前學過socket技術,就是一種接口技術,它有服務端和客戶端,相互傳遞數據。

咱們須要什麼樣的呢?

 

  1. 第一個Webservice應用

    1. 業務需求

咱們在本地編寫客戶端,來調用網絡上現成的服務端的ws,獲取手機號歸屬地的信息。

http://www.jisuapi.com/api/

咱們用:http://www.webxml.com.cn/

 

  1. 編寫客戶端調用遠程的手機號歸屬地信息

 

1.建立一個java工程

ws_day1_firstclient

 

2,。根據Webservice的wsdl地址生成客戶端代碼

wsdl就是個xml,咱們看不懂,讓程序看,讓程序生成java代碼就能夠了。

打開cmd窗口,輸入命令:

會自動生成java文件,將class刪掉。

 

【提示】

若是生成的代碼提示錯誤:

緣由:jdk的緣由。

jdk6和jdk7對ws的客戶端的代碼支持的不太同樣。

解決方案:

1)若是工程必定要用1。6,則須要手動修改生成的代碼,將方法的參數刪掉一個:

2)就將工程的jdk版本變成1。7

 

3.編寫客戶端調用程序

客戶端代碼:

運行結果:

 

 

  1. Webservice概述

    1. 什麼是Webservice

 

W3C組織對其的定義以下,它是一個軟件系統,爲了支持跨網絡的機器間相互操做交互而設計。Web Service服務一般被定義爲一組模塊化的API,它們能夠經過網絡進行調用,來執行遠程系統的請求服務。

 

簡單的說:WebService即Web服務,它是一種跨編程語言和跨操做系統平臺的遠程調用技術。

 

  • Web服務:基於HTTP和XML的技術,HTTP是互聯網上應用最爲普遍的一種網絡協議,而XML是跨平臺的基礎。
  • 跨編程語言和跨操做平臺:就是說服務端程序採用java編寫,客戶端程序則能夠採用其餘編程語言編寫,反之亦然!跨操做系統平臺則是指服務端程序和客戶端程序能夠在不一樣的操做系統上運行。
  • 遠程調用:就是一臺計算機a上的一個程序能夠調用到另一臺計算機b上的一個對象的方法,譬如,銀聯提供給商場的pos刷卡系統,商場的POS機轉帳調用的轉帳方法的代碼實際上是跑在銀行服務器上。再好比,amazon,天氣預報系統,淘寶網,校內網,百度等把本身的系統服務以webservice服務的形式暴露出來,讓第三方網站和程序能夠調用這些服務功能,這樣擴展了本身系統的市場佔有率

 

提示:市面上接口應用的技術不少,不止是webservice。

 

web Service:有兩大類:

一類:傳統的webservice,大web service,相對複雜。

一類:輕量級的webservice

 

  1. 前世此生

 

 

  1. 三要素(面試)

WebService的三要素是:

  • SOAP (Simple Object Access Protocol):簡易對象訪問協議,soap用來描述傳遞信息的格式。
  • WSDL (WebServices Description Language):Web服務描述語言,用來描述如何訪問具體的接口。
  • UDDI (Universal Description Discovery and Integration):通用描述、發現及整合,用來管理、分發、查詢webService。

 

UDDI:

 

弱化uddi,緣由:如今的接口交互,通常服務方和調用方直接商量。

 

 

  1. Jax-WS的快速入門

 

  1. Jax-WS是什麼

 

  1. 解讀說明書

白皮書:《JAX-WS.pdf.pdf》

 

  1. 服務端的開發

 

1.先編寫sei(接口和實現類)

接口

實現類:

 

2.加註解

最基本的註解,在實現類上加@Webservice,該類就變成Webservice的服務類了。

3.發佈服務

api:

 

 

測試一下是否發佈成功:

方法就是經過訪問ws的說明書wsdl,看是否能顯示。

訪問的格式:Webservice地址+?wsdl

 

【擴展】

如何在Windows下查看端口占用狀況:

 

  1. 客戶端的開發

 

1.創建一個客戶端的工程

2.經過wsimport命令+wsdl文檔,獲取客戶端java程序(stub樁,本地代理接口類實例)

 

wsimport是jdk自帶的命令。

 

在cmd中輸入命令和參數:

將生成的代碼(樁    )直接拷貝到工程中

    

3.編寫客戶端調用代碼:

 

缺點:代碼過分耦合生成的代碼。代碼不靈活。

 

 

  1. 客戶端的開發-優化

問題:客戶端的代碼耦合到生成的代碼中了(好比訪問的服務端地址等,不便於移植)

經過分析Servcie類不能new:

 

新建一個客戶端:

 

客戶端代碼:

 

 

  1. WebService技術深刻探討

    1. 理解WebService

 

能夠從多個角度來理解WebService,從表面上看,WebService就是一個應用程序向外界暴露出一個能經過Web進行調用的API,也就是說能用編程的方法經過Web來調用這個應用程序。咱們把調用這個WebService的應用程序叫作客戶端,而把提供這個WebService的應用程序叫作服務端。從深層次看,WebService是創建可互操做的分佈式應用程序的新平臺,是一個平臺,是一套標準。它定義了應用程序如何在Web上實現互操做性,你能夠用任何你喜歡的語言,在任何你喜歡的平臺上寫Web service ,只要咱們能夠經過Web service標準對這些服務進行查詢和訪問。

 

WebService平臺須要一套協議來實現分佈式應用程序的建立。任何平臺都有它的數據表示方法和類型系統。要實現互操做性,WebService平臺必須提供一套標準的類型系統,用於溝通不一樣平臺、編程語言和組件模型中的不一樣類型系統。Web service平臺必須提供一種標準來描述Web service,讓客戶能夠獲得足夠的信息來調用這個Web service。最後,咱們還必須有一種方法來對這個Web service進行遠程調用,這種方法實際是一種遠程過程調用協議(RPC)。爲了達到互操做性,這種RPC協議還必須與平臺和編程語言無關。

 

  1. 優勢

 

優勢(摘自百度百科):

  • 可擴展的。SOAP 無需中斷已有的應用程序, SOAP 客戶端、 服務器和協議自身都能發展。並且SOAP 能極好地支持中間介質和層次化的體系結構。
  • 簡單的。客戶端發送一個請求,調用相應的對象, 而後服務器返回結果。這些消息是XML 格式的,而且封裝成符合HTTP 協議的消息。所以,它符合任何路由器、 防火牆或代理服務器的要求。
  • 徹底和廠商無關。SOAP能夠相對於平臺、 操做系統、 目標模型和編程語言獨立實現。另外,傳輸和語言綁定以及數據編碼的參數選擇都是由具體的實現決定的。
  • 與編程語言無關。SOAP 可使用任何語言來完成,只要客戶端發送正確SOAP 請求( 也就是說, 傳遞一個合適的參數給一個實際的遠端服務器)。SOAP 沒有對象模型,應用程序能夠捆綁在任何對象模型中。
  • 與平臺無關。SOAP 能夠在任何操做系統中無需改動正常運行。

 

  1. 應用場景

WebService是一門新興和有前途的技術,企業中應用愈來愈普遍。

 

建議使用:

不建議使用:

 

你們能夠看一下課前資料:

 

  1. 平臺技術構成

XML+XSD,SOAP和WSDL就是構成WebService平臺的三大技術。

 

XML+XSD是WebService的數據傳輸的基礎(瞭解便可):

WebService採用HTTP協議傳輸數據採用XML格式封裝數據(即XML中說明調用遠程服務對象的哪一個方法,傳遞的參數是什麼,以及服務對象的返回結果是什麼)。XML是WebService平臺中表示數據的格式。除了易於創建和易於分析外,XML主要的優勢在於它既是平臺無關的,又是廠商無關的。無關性是比技術優越性更重要的:軟件廠商是不會選擇一個由競爭對手所發明的技術的。

 

XML解決了數據表示的問題,但它沒有定義一套標準的數據類型,更沒有說怎麼去擴展這套數據類型。例如,整形數到底表明什麼?16位,32位,64位?這些細節對實現互操做性很重要。XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數據類型,並給出了一種語言來擴展這套數據類型。WebService平臺就是用XSD來做爲其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時,爲了符合WebService標準,全部你使用的數據類型都必須被轉換爲XSD類型你用的工具可能已經自動幫你完成了這個轉換,但你極可能會根據你的須要修改一下轉換過程。

 

 

下面分別詳細說一下WSDL和SOAP的概念和內容:

  1. WSDL說明書詳解

    1. 什麼是WSDL

WSDL:

比如咱們去商店買東西,首先要知道商店裏有什麼東西可買,而後再來購買,商家的作法就是張貼廣告海報。 WebService也同樣,WebService客戶端要調用一個WebService服務,首先要有知道這個服務的地址在哪,以及這個服務裏有什麼方法能夠調用,因此,WebService務器端首先要經過一個WSDL文件來講明本身家裏有啥服務能夠對外調用,服務是什麼(服務中有哪些方法,方法接受的參數是什麼,返回值是什麼),服務的網絡地址用哪一個url地址表示,服務經過什麼方式來調用。

 

WSDL(Web Services Description Language)就是這樣一個基於XML的語言,用於描述Web Service及其函數、參數和返回值。它是WebService客戶端和服務器端都能理解的標準格式。由於是基於XML的,因此WSDL既是機器可閱讀的,又是人可閱讀的,這將是一個很大的好處。一些最新的開發工具既能根據你的Web service生成WSDL文檔,又能導入WSDL文檔,生成調用相應WebService的代理類代碼。

 

WSDL文件保存在Web服務器上,經過一個url地址就能夠訪問到它。客戶端要調用一個WebService服務以前,要知道該服務的WSDL文件的地址。WebService服務提供商能夠經過兩種方式來暴露它的WSDL文件地址:1.註冊到UDDI服務器,以便被人查找;2.直接告訴給客戶端調用者。

 

Wsdl你們常常稱之爲webservice的說明書。

 

注意:

 

wsdl的地址:http://127.0.0.1:8888/mobile?wsdl

Webservice地址:http://127.0.0.1:8888/mobile

 

  1. wsdl的基本結構

w3c中規定:

注意:規範和實現仍是有少量差異的。:java的服務端生成的wsdl和.net生成的會有少量差距。

 

  1. wsdl的閱讀(看懂便可)

從下往上閱讀

 

  1. Service服務視圖

描述Webservice服務的一些信息,名稱、地址、提供的服務端點等

 

 

  1. Binding:綁定

描述端口的一些傳輸協議等

 

  1. PortType:端口類型

做用:描述Webservice服務的具體服務操做(方法)

 

  1. message:消息

描述,請求或響應的數據內容

  1. type:數據類型

描述參數的類型、個數等

 

【瞭解】

wsimport客戶端生成樁是根據wsdl文件生成的。

問題:客戶端是從服務端直接拉取下來的代碼嗎?

不是!!!!!!!客戶端根本就不知道服務端的代碼怎麼寫的。

 

  1. 離線wsdl

在線解析:

但有時候,須要離線解析。

場景:你開發客戶端的時候,不能和服務端網絡鏈接。但程序還要開發,經過分析發現,客戶端開發主要有wsdl的文檔就能夠了。由於有該文檔,就能夠生成樁(客戶端代碼)。

所以咱們能夠將wsdl保存下來,在不能訪問服務端的狀況下使用。

 

等開發完成,再將客戶端程序拿到能訪問到服務端的環境中測試。

 

  1. SOAP協議詳解

 

  1. 什麼是soap(能看的懂)

 

 

 

SOAP,Simple Object Access Protocol,簡單對象訪問協議,簡單的說就是用於訪問網絡服務的協議;它是基於 XML 的簡易協議,可以使應用程序在 HTTP 之上進行信息交換。

 

SOAP是一種網絡通訊協議,用於網絡上、不一樣平臺、不一樣語言的應用程序間的通信。

WebService經過HTTP協議發送請求和接收結果時,發送的請求內容和結果內容都採用XML格式封裝,並增長了一些特定的HTTP消息頭,以說明HTTP消息的內容格式,這些特定的HTTP消息頭和XML內容格式就是SOAP協議。SOAP提供了標準的RPC方法來調用Web Service。

SOAP協議 = HTTP協議 + XML數據格式。

SOAP協議定義了SOAP消息的格式,SOAP協議是基於HTTP協議的,SOAP也是基於XML和XSD的,XML是SOAP的數據編碼方式。

SOAP很就簡單並可擴展支持面向對象,容許跨防火牆。

SOAP被做爲 W3C 標準來發展。

SOAP現行兩個版本:1.1和1.2。

 

更多信息能夠參考W3C文檔:

http://www.w3school.com.cn/soap/soap_intro.asp

 

  1. SOAP、Http、TCP/IP之間的關係—瞭解

打個比方:

 

SOAP協議,其實不僅是ws使用,郵件smtp傳輸協議也是這個。

 

  1. 代理工具TCP/IP Monitor

 

代理的基本原理:

 

eclipse內置的插件代理工具:

配置方法:

啓動代理:

 

 

 

  1. SOAP1.1協議分析

使用:直接將客戶端調用的端口改爲代理服務器的端口:

再次訪問,在代理服務器上看傳輸的消息。

 

請求報文:

響應:

 

 

  1. SOAP消息的標準格式

消息的傳遞至關於一個信封。

信封頭(皮)(報頭):地址,收件人。。

信紙:(報文):具體的業務信息內容

 

完整結構:

 

  1. SOAP1.2協議分析

更改服務端的soap版本

啓動服務,報錯:

說明少包,無法生成soap1。2協議的wsdl。

該包支持soap1。2的服務。

將lib中的jar所有導入到工程中,引入類路徑。

請求消息:

響應的:

  1. SOAP1.1和SOAP1.2協議的異同

SOAP1.1和1.2版本之間的大部分差別一般也是能夠忽略的

SOAP1.1只能夠綁定到HTTP協議,而SOAP1.2除了HTTP協議以外還支持SMTP綁定。在JAX-WS中,相似於大多數框架,SOAP1.1做爲默認實現,儘管如此在JAX-WS中能夠隨時採用SOAP1.2。

  1. 不一樣版本協議的調用關係

 

應用的價值:

  1. 儘可能使用同版本的來相互調用,緣由,兼容性好,性能高。
  2. 若是服務端使用1。1,那麼客戶端只能使用1。1,但服務端使用1。2,那麼客戶端可使用1。1或1。2。,優先用1。2。但國內,不少客戶端的開發爲了適應不一樣版本的服務端,會用1。1來開發。

 

jax-ws客戶端會自動適應服務端的版本,沒法演示。明天用cxf來演示。

 

  1. Webservice註解(重要)

    1. 爲何要用註解

 

反過來講:只要使用了註解,那麼服務端的代碼怎麼改其實都對wsdl或客戶端沒有影響。

 

好處:屏蔽了服務端的代碼的具體內容。

 

  1. 常見ws註解的分類和使用

    1. 類上面的註解

  1. 方法上面的註解

 

【推薦工具】

文件比較工具。

  1. Webservice的方法的編寫要求和方法隱藏

Webservice的sei的方法的要求:

 

 

  1. 複雜數據類型的支持+JaxWS回顧小結

    1. 訴求(需求)

 

 

  1. 服務端

 

 

1.新建項目:

 

2.服務端:

編寫步驟:

  1. sei(接口和實現類)

實現類:

 

  1. 加註解

提示:1。2的協議須要導入擴展包

 

  1. 發佈

 

測試:

訪問wsdl:

 

看版本:

1。1

1。2

 

複雜返回對象

 

 

 

  1. 客戶端

 

1)使用wsimport命令生成樁

添加參數支持1。2的樁的生成:

將其拷貝到工程中

 

2)編寫客戶端代碼

 

小結:ws支持簡單的對象傳輸(一般是字符串),也支持複雜對象的傳輸,甚至mp3音樂、圖片。

【課後擴展選做】

提示:

會文件流的操做,就能夠作這個功能。

 

  1. 關於Webservice的傳輸數據方式

一般,實際業務開發過程當中,爲了保證ws真正跨平臺、跨語言,通常傳遞字符串。通常該字符串,使用xml或者json表示。不管複雜,仍是簡單的數據,均可以用其表示!

這樣設計以後,工做量會轉換到組裝和解析xml和json上面了,可能有大量的業務邏輯。

 

列表:

"[{},{},{},{}]"

如今企業對接口開發的思想:簡化接口的開發難度,難度轉移到業務上(解析和封裝json上了)

 

  1. 開發角度上的使用

服務端的使用

做用:發佈一個服務,給別人用—提供數據(l相似於數據庫了)

代碼通常寫在業務層service層(由於1。代碼中邏輯須要事務控制 2。調用dao—查詢數據)

服務端沒有表現層。

 

客戶端的使用

做用:調用服務端,獲取服務端的數據---認爲服務端是個數據庫。(crud)

代碼放:dao數據持久層。你就把webservice當成一個數據庫來使用就好了。

 

 

  1. SOAPUI調試工具的使用

 

問題:服務端開發完成後如何驗證其正確呢?

解決方案

1:寫一個客戶端。(該客戶端並非爲了知足業務需求的,浪費)

2:使用專業的測試工具soapui

 

  1. 下載安裝

免費版本(5.x)+收費版本(3.x)

安裝後:

 

介紹:

 

【提示環境】

須要jdk的配置。

 

 

 

 

  1. 業務測試

 

新建一個測試項目

填寫wsdl的測試地址:

業務測試方式:

響應:

 

 

  1. 性能(壓力、負載)測試

由於Webservice,提供業務服務,該服務容量(能同時併發多少請求)、穩定性。

 

步驟:

1.構建一個測試用例:模擬一個具體業務,好比咱們在用例中輸入業務數據,此時,該用例就成爲測試用例。

 

2.根據測試用例,創建壓力測試用例

 

 

若是過多,說明網絡或者該ws服務不穩定。找緣由?

  1. 網絡不穩定
  2. 服務器的問題

 

 

  1. 重點和小結

  1. 爲何要用ws?(爲何要用接口業務)
  2. Jax-ws:服務端的開發和客戶端的開發(會寫就行,企業中更多用框架開發)
  3. Webservice相關概念(三要素、理解、優勢—跨平臺基於xml、應用場景-課後文檔)
  4. Wsdl和soap詳解(看的懂),代理工具。
  5. Webservice的註解(規範wsdl文檔,影響客戶端代碼)
  6. 支持複雜數據類型(但通常不建議使用複雜類型,不容易跨平臺,就傳字符串:json或xml)-完整示例
  7. Soapui的使用(業務測試,壓力測試)

 

擴展::

能夠體會使用web(三層架構)來調用web

擴展:webxml.com.cn—》獲取mp3複雜數據類型的方式(坑—解析wsdl時會發生-不一樣的平臺wsdl有點差異,java不認。)

 

必須掌握:

文件---》流:FileInputStream(new File(url))

流---》文件:弄一個輸出流(newFile(url)),將輸入流寫入輸出流

相關文章
相關標籤/搜索