WebService第一天 java
【課程安排】:web
總體安排:2天:面試
第一天:webservice入門,JDK規範和實現:jax-ws,相關概念spring
次日:CXF框架,和spring的集成開發。Hessian的開發。數據庫
今日安排:(jax-ws)編程
【學習目標】:json
Webservice是什麼?是一個遠程調用技術。api
遠程:相對於本地,不是當前應用服務的。服務器
調用:數據交互。網絡
原來的都是單機系統,
特色:數據的存儲和調用都是透明的。好比數據庫的存儲方式、類型等。都是知道的、模塊之間的調用也是隨意的、透明的。
1.本身想要,但沒有
2.本身有數據,別人想要
接口的概念:
之前學過socket技術,就是一種接口技術,它有服務端和客戶端,相互傳遞數據。
咱們須要什麼樣的呢?
咱們在本地編寫客戶端,來調用網絡上現成的服務端的ws,獲取手機號歸屬地的信息。
http://www.jisuapi.com/api/
咱們用:http://www.webxml.com.cn/
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.編寫客戶端調用程序
客戶端代碼:
運行結果:
W3C組織對其的定義以下,它是一個軟件系統,爲了支持跨網絡的機器間相互操做交互而設計。Web Service服務一般被定義爲一組模塊化的API,它們能夠經過網絡進行調用,來執行遠程系統的請求服務。 |
簡單的說:WebService即Web服務,它是一種跨編程語言和跨操做系統平臺的遠程調用技術。
|
提示:市面上接口應用的技術不少,不止是webservice。
web Service:有兩大類:
一類:傳統的webservice,大web service,相對複雜。
一類:輕量級的webservice
WebService的三要素是:
UDDI:
弱化uddi,緣由:如今的接口交互,通常服務方和調用方直接商量。 |
白皮書:《JAX-WS.pdf.pdf》
1.先編寫sei(接口和實現類)
接口
實現類:
2.加註解
最基本的註解,在實現類上加@Webservice,該類就變成Webservice的服務類了。
3.發佈服務
api:
測試一下是否發佈成功:
方法就是經過訪問ws的說明書wsdl,看是否能顯示。
訪問的格式:Webservice地址+?wsdl
【擴展】
如何在Windows下查看端口占用狀況:
1.創建一個客戶端的工程
2.經過wsimport命令+wsdl文檔,獲取客戶端java程序(stub樁,本地代理接口類實例)
wsimport是jdk自帶的命令。
在cmd中輸入命令和參數:
將生成的代碼(樁 )直接拷貝到工程中
3.編寫客戶端調用代碼:
缺點:代碼過分耦合生成的代碼。代碼不靈活。
問題:客戶端的代碼耦合到生成的代碼中了(好比訪問的服務端地址等,不便於移植)
經過分析Servcie類不能new:
新建一個客戶端:
客戶端代碼:
能夠從多個角度來理解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協議還必須與平臺和編程語言無關。 |
優勢(摘自百度百科):
|
WebService是一門新興和有前途的技術,企業中應用愈來愈普遍。
建議使用:
不建議使用:
你們能夠看一下課前資料:
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的概念和內容:
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
w3c中規定:
注意:規範和實現仍是有少量差異的。:java的服務端生成的wsdl和.net生成的會有少量差距。
從下往上閱讀
描述Webservice服務的一些信息,名稱、地址、提供的服務端點等
描述端口的一些傳輸協議等
做用:描述Webservice服務的具體服務操做(方法)
描述,請求或響應的數據內容
描述參數的類型、個數等
【瞭解】
wsimport客戶端生成樁是根據wsdl文件生成的。
問題:客戶端是從服務端直接拉取下來的代碼嗎?
不是!!!!!!!客戶端根本就不知道服務端的代碼怎麼寫的。
在線解析:
但有時候,須要離線解析。
場景:你開發客戶端的時候,不能和服務端網絡鏈接。但程序還要開發,經過分析發現,客戶端開發主要有wsdl的文檔就能夠了。由於有該文檔,就能夠生成樁(客戶端代碼)。
所以咱們能夠將wsdl保存下來,在不能訪問服務端的狀況下使用。
等開發完成,再將客戶端程序拿到能訪問到服務端的環境中測試。
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
打個比方:
SOAP協議,其實不僅是ws使用,郵件smtp傳輸協議也是這個。
代理的基本原理:
eclipse內置的插件代理工具:
配置方法:
啓動代理:
使用:直接將客戶端調用的端口改爲代理服務器的端口:
再次訪問,在代理服務器上看傳輸的消息。
請求報文:
響應:
消息的傳遞至關於一個信封。
信封頭(皮)(報頭):地址,收件人。。
信紙:(報文):具體的業務信息內容
完整結構:
更改服務端的soap版本
啓動服務,報錯:
說明少包,無法生成soap1。2協議的wsdl。
該包支持soap1。2的服務。
將lib中的jar所有導入到工程中,引入類路徑。
請求消息:
響應的:
SOAP1.1和1.2版本之間的大部分差別一般也是能夠忽略的
SOAP1.1只能夠綁定到HTTP協議,而SOAP1.2除了HTTP協議以外還支持SMTP綁定。在JAX-WS中,相似於大多數框架,SOAP1.1做爲默認實現,儘管如此在JAX-WS中能夠隨時採用SOAP1.2。
應用的價值:
jax-ws客戶端會自動適應服務端的版本,沒法演示。明天用cxf來演示。
反過來講:只要使用了註解,那麼服務端的代碼怎麼改其實都對wsdl或客戶端沒有影響。
好處:屏蔽了服務端的代碼的具體內容。
【推薦工具】
文件比較工具。
Webservice的sei的方法的要求:
1.新建項目:
2.服務端:
編寫步驟:
實現類:
提示:1。2的協議須要導入擴展包
測試:
訪問wsdl:
看版本:
1。1
1。2
複雜返回對象
1)使用wsimport命令生成樁
添加參數支持1。2的樁的生成:
將其拷貝到工程中
2)編寫客戶端代碼
小結:ws支持簡單的對象傳輸(一般是字符串),也支持複雜對象的傳輸,甚至mp3音樂、圖片。
【課後擴展選做】
提示:
會文件流的操做,就能夠作這個功能。
一般,實際業務開發過程當中,爲了保證ws真正跨平臺、跨語言,通常傳遞字符串。通常該字符串,使用xml或者json表示。不管複雜,仍是簡單的數據,均可以用其表示!
這樣設計以後,工做量會轉換到組裝和解析xml和json上面了,可能有大量的業務邏輯。
列表:
"[{},{},{},{}]"
如今企業對接口開發的思想:簡化接口的開發難度,難度轉移到業務上(解析和封裝json上了)
服務端的使用
做用:發佈一個服務,給別人用—提供數據(l相似於數據庫了)
代碼通常寫在業務層service層(由於1。代碼中邏輯須要事務控制 2。調用dao—查詢數據)
服務端沒有表現層。
客戶端的使用
做用:調用服務端,獲取服務端的數據---認爲服務端是個數據庫。(crud)
代碼放:dao數據持久層。你就把webservice當成一個數據庫來使用就好了。
問題:服務端開發完成後如何驗證其正確呢?
解決方案
1:寫一個客戶端。(該客戶端並非爲了知足業務需求的,浪費)
2:使用專業的測試工具soapui
免費版本(5.x)+收費版本(3.x)
安裝後:
介紹:
【提示環境】
須要jdk的配置。
新建一個測試項目
填寫wsdl的測試地址:
業務測試方式:
響應:
由於Webservice,提供業務服務,該服務容量(能同時併發多少請求)、穩定性。
步驟:
1.構建一個測試用例:模擬一個具體業務,好比咱們在用例中輸入業務數據,此時,該用例就成爲測試用例。
2.根據測試用例,創建壓力測試用例
若是過多,說明網絡或者該ws服務不穩定。找緣由?
擴展::
能夠體會使用web(三層架構)來調用web
擴展:webxml.com.cn—》獲取mp3複雜數據類型的方式(坑—解析wsdl時會發生-不一樣的平臺wsdl有點差異,java不認。)
必須掌握:
文件---》流:FileInputStream(new File(url))
流---》文件:弄一個輸出流(newFile(url)),將輸入流寫入輸出流