java面試：Web Services面試問題集錦

Q. 應用集成方式有哪些？

A. 應用能夠採用如下方式集成：

1. 共享數據庫

2. 批量文件傳輸

3. 遠程過程調用（RPC）

4. 經過消息中間件來交換異步信息（MOM）

Q. 應用集成能夠採用的Web服務方式有什麼？

A. SOAP WS（Simple Object Access Protocal） 和RESTful Web Service（REpresentational State Transfer）

Q. SOAP WS 和RESTful Web Service之間有什麼不一樣呢？

A. 

• SOAP WS支持既遠程過程調用（例如，RPC）又支持消息中間件（MOM）方式進行應用集成。而Restful Web Service僅支持RPC集成方式。

• SOAP WS是傳輸協議無關的。它支持多種協議，好比，HTTP(S)、 Messaging、TCP、UDP SMTP等等。而REST是協議相關的，只支持HTTP或者HTTPS協議。

• SOAP WS僅容許使用XML數據格式。定義的操做經過POST請求發送。其重點是經過操做名來獲取服務，並將應用邏輯封裝爲服務。而REST方式則容許多種數據格式，例如，XML、JSON、文本、HTML等等。並且因爲REST方式採用標準GET、PUT、PSOT和DELETE 方法，所以全部的瀏覽器均可以支持。其重點是經過資源名來獲取服務，並將數據封裝爲服務。AJAX支持REST方式，它可使用XMLHttpRequest對象。無狀態CRUD操做（建立、讀、更新和刪除）更加適合這種方式。

GET – represent()

POST – acceptRepresention()

PUT – storeRepresention()

DELETE – removeRepresention()

• 沒法緩存SOAP方式讀取的內容。而REST方式的則能夠，並且性能和可擴展性都更好一些。

• SOAP WS支持SSL和WS-security，針對企業級應用能夠有更多的安全保障，例如按需提高安全指數、經過第三方來保證身份認證信息的安全性、除了點到點SSL（point to point SSL）以外，更針對消息的不一樣部分來提供不一樣的保密算法等等。而REST只支持點到點SSL。並且不管是否是敏感消息，SSL都會加密整條消息。

• SOAP對於基於ACID的短壽命事務管理以及基於補償事務管理的長壽命事務有深刻的支持。同時，SOAP也支持分佈式事務（譯者：在一個分佈式環境中涉及到多個資源管理器的事務）的兩階段提交（two-phase commit）方式。而REST因爲基於HTTP協議，所以對於事務處理既不兼容ACID方式也不提供分佈式事務的兩階段提交方式。

• 即使是要經過SOAP的第三方程序，SOAP經過內置的重試邏輯也能夠提供端到端可靠性。REST沒有一個標準的消息系統，於是寄但願於客戶經過重連去解決通訊失敗問題。

 

Q.如何選擇採用哪一種Web service？SOAP WS仍是REST？

A.通常而言，基於REST的Web service的優點在於其簡單、性能不錯、可擴展性好，而且也支持多種數據格式。而SOAP則適用於安全性和事務處理可靠性方面要求比較高的服務中。

對於這個問題的答案，更多的考慮依據是設計者對功能性和非功能性需求的要求。經過回答下列問題能夠幫助你作出選擇：

• 所提供的服務會暴露數據或者業務邏輯嗎？（若是會暴露數據的話能夠選擇REST方式，若是會暴露業務邏輯的話能夠選擇SOAP WS）。客戶或者服務提供商須要一個正式的契約（contract）嗎？（SOAP能夠經過WSDL（Web Service Description Language）提供一個正式契約）

• 須要支持多種數據格式嗎？

• 須要進行AJAX調用嗎？（REST能夠採用XMLHttpRequest來發送AJAX調用）

• 同步調用仍是異步調用？

• 有狀態調用仍是無狀態調用？（REST適合無狀態CRUD操做）

• 對於安全性的要求？（SOAP WS對於安全性的支持更好些）

• 對於事務處理的要求？（SOAP WS這方面更有優點）

• 有帶寬限制嗎？（SOAP消息比較冗長）

• 哪一種方式更適合開發者呢呢？（REST更好實現，也更好測試和維護）

Q.有什麼能夠用來測試Web Service的工具嗎？

A.測試SOAP WS可使用SoapUI，測試RESTFul service能夠採用Firefox的「poster」插件。

Q. SOA和Web service的區別是什麼？

A. SOA是一種軟件設計準則，一種實現鬆耦合，高可複用性和粗粒度的web服務的設計模式。開發者能夠選擇任意協議實現SOA，例如，HTTP、HTTPS、JMS、SMTP、RMI、IIOP（例如，採用IIOP的EJB）、RPC等。消息能夠採用XML或者數據傳輸對象（Data Transfer Objects，DTOs）。

Web Service是實現SOA的技術之一。也能夠不用Web service來實現SOA應用：例如，用一些傳統的技術，像Java RMI，EJB，JMS消息等。可是Web service提供的是標準的平臺無關的服務，這些服務採用HTTP、XML、SOAP、WSDL和UDDI技術，所以能夠帶來J2EE和.NET這些異構技術（heterogeneous technologies）之間的互操做性。

Q.若是可使用傳統的中間件方式，例如，RPC、CORBA、RMI和DCOM，爲何還要選擇Web service？

A. 傳統的中間件跟應用關係緊密，對應用的任何修改均可能會引發對應中間件的修改。所以這種方式下應用很差維護，複用性也比較差。通常狀況下也沒法支持異質系統（heterogeneity）。另外，採用這種方式應儘可能避免互聯網訪問應用。還有，這種方式代價更高而且可用性差。

Web service採用鬆耦合鏈接，即在客戶端和服務器端之間提供了一個抽象層。這種鬆耦合應用能夠減小維護成本並增長可複用性。Web service提供了一種基於XML和Web的新的中間件形式。Web service是語言和平臺無關的，任何語言均可以用來開發一個Web service，而且部署到任何平臺上，包括小型設備到大型超級計算機。Web service採用語言無關協議，例如HTTP，而且經過Web API來在不一樣的應用程序之間傳輸XML消息。Web service能夠經過互聯網訪問，開銷少而且可用性好。

Q.開發基於SOAP的Web service有哪些方式呢？

A.有兩種方式;

• 契約先行（也稱爲自頂向下，contract-first）方式：經過XSD和WSDL來定義contract，而後根據contract生成Java類；

• 契約後行（也稱爲自底向上，contract-last）方式：先定義Java類，而後生成約定，也就是從Java類獲得WSDL文件。

注意：WSDL描述這樣一些信息：服務所提供的全部用戶操做、終端位置信息（例如，調用服務的URL），請求和響應中的簡單或者複雜元素等。

Q. 上面兩種方式各有什麼優缺點嗎？你更推薦哪一種？

A.

契約先行方式的Web service

優勢：

• 客戶端程序和服務器端程序分離，所以重構服務器端代碼不會影響到客戶端。

• 因爲遵照相同的規範，所以客戶端和服務器端的開發能夠並行進行。

• 開發者能夠控制請求\響應消息的結構：例如，「status」應該是做爲消息的一個元素仍是一個屬性？契約規定的很是明確。所以開發者能夠大膽的去修改OXM（Object to XML Mapping）庫，而不用擔憂是否會致使「status」從元素變成「屬性」。不只如此，甚至Web service框架和工具箱均可以更換，好比從Apache Axis變成Apache CXF等等。

缺點：

• 開發前期須要額外的一些搭建XSD和WSDL的工做。使用XML Spy、OxygenXM等工具能夠簡化這些工做。另外，還須要開發對象模型。

• 開發者須要除了Java以外，還須要去學習XSD和WSDL。

契約後行方式的Web service

優勢：

• 開發者不用去學習XSD、WSDL和SOAP相關知識。能夠經過框架或者工具集利用已有服務來快速構建新的服務。例如，經過基於IDE嚮導快速構建應用。

• 學習曲線和開發時間會比契約先行方式小。

缺點：

• 項目初始的開發時間會縮短，可是一旦contract發生變化或者須要加入新的元素，那麼隨之而來的維護和擴展應用所帶來的開發時間會是怎樣呢？採用這種方式，因爲客戶端和服務器端之間緊密耦合，所以將來潛在的變化可能破壞客戶端的contract，致使全部的客戶都會受到影響，爲了不這中狀況的發生，項目開發時須要很當心的開發和管理將來要發佈的服務。

• XML的有效負載（payload）沒法控制。這也就是說修改應用的OXM庫會致使某個元素錯誤的變成了屬性。