2019獨角獸企業重金招聘Python工程師標準>>>

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庫會導致某個元素錯誤的變成了屬性。

轉載於:https://my.oschina.net/bravozu/blog/202410