Web-Service填空題簡答題掃描版

1/9填空題1．從模式派生類生成內(nèi)容對(duì)象樹,此過程稱為_________。解組2．將內(nèi)容對(duì)象樹轉(zhuǎn)換為XML文檔的過程稱為___________。編組3．將類定義為Web服務(wù)接口的實(shí)現(xiàn)類的批注是________。WebService5．JAX_WSAPI中的批注__________定義Web服務(wù)的引用。WebServiceRefs7．在javax.ws.rs包中,批注____________定義資源類的方法所接受的MIME類型。Consumes8．WSDL文檔將Web服務(wù)的描述分為兩種截然不同的模型_________和__________。抽象模型、具體模型封10．Web服務(wù)可使用兩種方法來創(chuàng)建：________________和____________。從下到上的方法,從上到下的方法11．SAAJ對(duì)象客戶端使用__________對(duì)象中客戶端應(yīng)用程序和Web服務(wù)之間創(chuàng)建連12．SAAJ客戶端使用__________對(duì)象中客戶端應(yīng)用程序和Web服務(wù)之間創(chuàng)建連接。SOAPConnection14．_________是解決編程問題的經(jīng)過深思熟慮且以前使用過的解決方案。設(shè)計(jì)模式Web中出現(xiàn)性能瓶頸的主要因素有：網(wǎng)絡(luò)等待時(shí)間、____________和執(zhí)行2/9術(shù)語解釋,寫出英文完整名稱及中文概念及其含義WSDLSAAJJAXBSAXUDDISOAPJAXPStAX等等WSDL:WebServicesDescriptionLanguage,Web服務(wù)描述語言；基于XML的文檔,用于描述基于XMLWeb服務(wù)功能。SAAJ:SOAPwithAttachmentsAPIforJAVA是用于Java的SOAP附件API。JAXB:JavaArchitectureforXMLBinding是用于XML綁定的JavaAPI。SAX:SimpleAPIforXML,是用于XML解析的簡單API。UDDI:UniversalDescription,DiscoveryandIntegration即通用描述、發(fā)現(xiàn)和集成。SOAP:SimpleObjectAccessProtocol,即簡單對(duì)象訪問協(xié)議。JAXP:JavaAPIforXMLProcessing,是用XML處理的JavaAPI。StAX：StreamingAPIforXML,用于XML解析的流式處理API。簡答題1.SOA的功能可發(fā)現(xiàn)和動(dòng)態(tài)綁定：此功能描述服務(wù)使用者中運(yùn)行時(shí)根據(jù)其需求查找或發(fā)現(xiàn)服務(wù)。服務(wù)使用者通過服務(wù)注冊表查找符合其需求的服務(wù)支持互操作性：互操作性是使用不同平臺(tái)和語言的系統(tǒng)相互通信的能力松散耦合：SOA中服務(wù)使用者和服務(wù)提供者之間推行松散耦合,中松散耦合系統(tǒng)中,在一個(gè)應(yīng)用中所作的更改不需要在其他集成的應(yīng)用程序中進(jìn)行相應(yīng)更改。位置透明：服務(wù)使用者無需知道要使用的服務(wù)位置。使用者中服務(wù)注冊表內(nèi)搜3/9索服務(wù)。確定服務(wù)后,在運(yùn)行時(shí)綁定它,確定服務(wù)后,在運(yùn)行時(shí)綁定它,這使服務(wù)能夠從一個(gè)位置移動(dòng)到另一個(gè)位置。2.SAXAPI的工作原理〔需要繪制圖形進(jìn)行說明SAX應(yīng)用程序借助SAXParserFactory類創(chuàng)建SAXParser類的實(shí)例。實(shí)例化SAXParserSAXParserSAXReaderXMLSAXReader對(duì)象的parse<>方法以根據(jù)在XML文檔中執(zhí)行的操作調(diào)用任一回調(diào)方法?；卣{(diào)方法中r3.JAXBAPI的工作原理〔回答方式同上,需要繪制圖形在上圖中,綁定編譯器使用XML模式生成一組類。換句話說,這些生成的類遵循Web服務(wù)的XML模式。XML模式是確定XML文檔中可以出現(xiàn)的元素、元素出現(xiàn)必須遵循的順序以及元素可以具有的屬性的規(guī)范。然后這些模式派生類由綁定編譯器進(jìn)行編譯和實(shí)例化,以便生成內(nèi)容對(duì)象樹。此樹表示源XML文檔的結(jié)構(gòu)、組織和內(nèi)容。從模式派生類生成內(nèi)容對(duì)象樹的此過程稱為解組。這些生成的內(nèi)容樹對(duì)象可以被轉(zhuǎn)換回XML文檔。將內(nèi)容對(duì)象樹轉(zhuǎn)換為XML文檔的此過程稱為編組。此編組過4/9程包括對(duì)象樹的處理。對(duì)象樹的處理允許客戶端應(yīng)用程序修改XML數(shù)據(jù)。此XML數(shù)據(jù)由內(nèi)容對(duì)象樹通過由綁定編譯器生成的類表示。然后此經(jīng)過處理的內(nèi)容對(duì)象樹被編組到一個(gè)或多個(gè)XML輸出文檔。4.Web服務(wù)的功能支持?jǐn)?shù)據(jù)交換：Web服務(wù)使用XML數(shù)據(jù)格式完成Web服務(wù)間的信息交換。信息交換以XML消息形式完成。XML是獨(dú)立于供應(yīng)商和平臺(tái)語言,可用于中企業(yè)內(nèi)甚至跨企業(yè)平臺(tái)支持文檔交換：Web服務(wù)通過將文檔附加到業(yè)務(wù)之間交換的XML消息來支持大型非XML文檔的交換。此類非XML文檔可以是PDF文件、視頻文件或圖像文件。支持同步和異步客戶端：Web服務(wù)支持與客戶端進(jìn)行同步和異步通信。同步客戶端是指等待服務(wù)完成其操作的客戶端。另一方面,異步客戶端是指調(diào)用服務(wù),然后執(zhí)行其他函數(shù)而不是等待服務(wù)完成的客戶端5.舉例說明異步交互模式的工作原理<P8.4,需繪制圖形進(jìn)行說明上圖描述了異步交互模式的Web服務(wù)的工作原理。客戶端ProcessP1向Web服務(wù)5/9發(fā)送了請求,并在ProcessPl暫停時(shí)啟動(dòng)另一個(gè)ProcessP2.Web服務(wù)接收請求并將其分配給正確的操作以進(jìn)行處理。在將請求成功委托給Web服務(wù)操作后,Web服務(wù)操作向客戶端返回請求ID.隨后,啟動(dòng)并處理該請求以生成響應(yīng)。但是,根求處理使用：Web服務(wù)以檢査具有Web服務(wù)所提供ID的請求的狀態(tài)?！鋈绻蛻舳吮旧硎钦{(diào)用其他Web服務(wù)的Web服務(wù),那么所請求的Web服務(wù)將調(diào)用具有最終結(jié)果的調(diào)用Web服務(wù)。6.HTTP負(fù)載平衡使用的主要算法循環(huán)：在此算法中,在所有服務(wù)器上等量的分配負(fù)載。當(dāng)群集中的所有服務(wù)器具有類似的處理能力時(shí),此算法最適合。在此方法中,按順序向服務(wù)器分配請求。例如,如果服務(wù)器群集中有四個(gè)服務(wù)器,那么第一個(gè)請求將分配給第一個(gè)服務(wù)器,第二個(gè)請求分配給第二個(gè)服務(wù)器,以此類推?，F(xiàn)在,如果接受到第五個(gè)請求,那么它將分配給第一個(gè)服務(wù)器。通過此方法,能處理所有請求。加權(quán)循環(huán)：此算法在各服務(wù)器具有不同處理能力的服務(wù)器群集上實(shí)現(xiàn)。根據(jù)處理能力,管理員向群集中的每個(gè)服務(wù)器手動(dòng)分配性能權(quán)限。性能權(quán)重定義為基于性能能力對(duì)服務(wù)器的平均評(píng)級(jí)。因此,每個(gè)服務(wù)器的負(fù)載調(diào)度將根據(jù)服務(wù)器性能權(quán)重自動(dòng)決定。最后,以循環(huán)方式將請求重定向到服務(wù)器。最少連接：在此算法中,根據(jù)服務(wù)器與客戶端所建立的連接數(shù)來確定服務(wù)器。然后將請求定向到具有最少連接數(shù)的哪些服務(wù)器。基于負(fù)載：在次算法中,根據(jù)服務(wù)器上的負(fù)載來確定服務(wù)器。然后將請求定向到具有最小負(fù)載的那些服務(wù)器6/97.Web服務(wù)日志器模式包含的組件〔p8.7在下圖中,安全日志器模式的應(yīng)用程序組件<web服務(wù)>生成日志信息并將其發(fā)送到安全日志器組件。安全日志器組件加密日志信息以對(duì)其進(jìn)行保護(hù),要讀取此安全信息,需要使用日志讀取器組件。它確保提供給用戶的信息僅用于讀取目的,因?yàn)樗辉试S在日志信息中進(jìn)行修改。日志查看器組件使用戶能夠查看日志讀取器組件提供的信息。8.Web服務(wù)緩存模式的工作原理〔p8.5,需繪制圖形進(jìn)行說明>在上圖中,ClientA首次向新聞門戶Web服務(wù)發(fā)送請求。新聞門戶Web服務(wù)將響應(yīng)發(fā)送回ClientA下次,當(dāng)ClientA向新聞門戶Web服務(wù)發(fā)送請求時(shí),它將先檢査緩存。如果在緩存中找到所請求的資源,那么它將由緩存來完成。否則,該請求將被轉(zhuǎn)發(fā)到新聞門戶該請求將由緩存來完成。否則,該請求將被轉(zhuǎn)發(fā)到Web服務(wù)。7/99.RESTfulWeb服務(wù)的設(shè)計(jì)原則使用HTTP方法顯示無狀態(tài)特性公開目錄結(jié)構(gòu)以XML和Javascript對(duì)象表示法<JSON>格式傳輸數(shù)據(jù)10.SOAP消息元素組成〔p2.15>和正文元素。信封元素是SOAP消息的必需元素.SOAP報(bào)頭：這是提供額外信息<如服務(wù)器路由信息>的可選部分,同時(shí)也是SOAP信封元素的第一個(gè)子代元素。直接位于報(bào)頭元素之下的所有元素稱為報(bào)頭條目,所有擴(kuò)展信息<如消息驗(yàn)證和事務(wù)管理>在報(bào)頭元素中給出。SOAP正文：這是包含消息數(shù)據(jù)的必需部分。如果SOAP信封元素不包含報(bào)頭元素,則正文元索便成為SOAP信封元素的第一個(gè)直接元素,正文元素<<SOAP:BODY>>的所有直接元素稱為正文條目,在<<SOAP:BODY>>元素中,每個(gè)正文條目都被視為一個(gè)單獨(dú)的元素。正文元素包括如下信息:Web服務(wù)方法的名稱、參數(shù)以及方法調(diào)用的值.SOAP故障:此元素用于確定SOAP消息是否存在故障,并顯不錯(cuò)誤.<<SOAP:FAULT>>e元素包含以下四個(gè)元素:〈faultcode〉:此元素始終存在于SOAP故障元素中。XMLWeb服務(wù)使用者使用此元素識(shí)別SOAP消息中發(fā)生的故障,SOAP定義了包括基本SOAP故障的一組故障代碼?！磃aultstring〉:此元素以人可讀的形式提供故障解釋。此外,還提供故8/9障類型相關(guān)信息?！磃aultstring〉元素始終存在于SOAP故障元素中.faultactor導(dǎo)致消息路徑內(nèi)故障的因素相關(guān)信息。SOAP消息通過包含-組節(jié)點(diǎn)<如發(fā)送方和接收方節(jié)點(diǎn)>的路徑進(jìn)行傳輸。APURI.〈detail〉:此元素提供與〈SOAP:BODY〉元素相關(guān)的特定于應(yīng)用程序的錯(cuò)誤信息。如果正文元素的內(nèi)容無法成功處理,則此〈detail〉元素必須存在。如果〈detail〉元素不存在,則表明故障與正文元素的處理無關(guān)。Web服務(wù)可使用兩種不同方法來創(chuàng)建基于XML的方法和REST方法,基于XML法為Web應(yīng)用程序開發(fā)定義新規(guī)范,而REST方法使用現(xiàn)有Web標(biāo)準(zhǔn)開相比基于XML的Web服務(wù),REST更常用,因?yàn)樗哂休p量級(jí)的特性和簡單的設(shè)計(jì),而且,RESTWeb服務(wù)可在您只想使用HTTP/HTTPS時(shí)使用。組織可以根據(jù)其業(yè)務(wù)曾求選擇其中任方法并開發(fā)Web服務(wù),因此,在開始應(yīng)用程序開發(fā)之前,技術(shù)架構(gòu)師和開發(fā)人員需要分析業(yè)務(wù)需求并決定哪個(gè)方法將適合其應(yīng)用程序。盡管要使用的Web服務(wù)類型取決于組織需求,有時(shí)會(huì)出現(xiàn)一個(gè)類型的方法優(yōu)于其他方法的情況。在以下情況下可優(yōu)先選擇RESTful樣式架構(gòu)：要開發(fā)的Web服務(wù)在本質(zhì)上是無狀態(tài)的。無狀態(tài)特性幫助增強(qiáng)Web服務(wù)的性能和可伸縮性。9/9如果每次客戶端請求數(shù)據(jù)時(shí)未動(dòng)態(tài)生成Web服務(wù)要返回的數(shù)據(jù)。在此情況下,可以在緩存中存儲(chǔ)數(shù)據(jù)并在需要時(shí)使用該數(shù)據(jù)。這有助于提高Web服務(wù)的性能。但是,在大多數(shù)情況下,注意事項(xiàng)。當(dāng)正開發(fā)的Web服務(wù)將從具有有限因特網(wǎng)帶寬的設(shè)備進(jìn)行訪問時(shí),這些設(shè)備包括移動(dòng)和個(gè)人數(shù)宇助理<PDA>。在此情況下,帶寬管理將是開發(fā)Web服務(wù)時(shí)要考慮的至關(guān)重要的方面,這是因?yàn)槿绻诖饲闆r下使用基于XML-的架構(gòu)樣式,那么將會(huì)產(chǎn)生SOAP元素的報(bào)頭和附加層的開銷,這需要更大的帶寬來進(jìn)行數(shù)據(jù)傳輸,這將使請求/響應(yīng)周期變慢,并同時(shí)帶來帶寬問題.在以下情況下可優(yōu)先選擇基于XML的架構(gòu)：當(dāng)客戶端需要用于定義客戶端與服務(wù)交互時(shí)必須使用的格式的合約才能與Web服務(wù)通信時(shí)。此合約使客戶端能夠根