Web Services 學習筆記（一）

作者：蔡煥麟
日期：Apr-3-2002

摘要：簡述 Web Services 的概念、由來、運作方式及應用時可能遭遇的問題，並分別以 Delphi 6 和 VisualStudio.NET 示範撰寫 Web Services 用戶端程式的步驟。

什麼是 Web Services？

平台中立的網路服務

Web Services 是一種平台中立的網路服務，應用程式可以透過 URL 指定存取 internet 上任何一台電腦提供的服務，不管對方的電腦是什麼作業平台或應用程式的類型，雙方只要遵循標準的協定就可以溝通。

分散式應用程式的基石（building blocks）

基於其平台中立的特性，軟體開發人員可以將設計好的 Web Services 公佈在 internet 上供其他應用程式使用，其他的開發人員則可以重複使用這些現有的服務來建構分散式應用程式，而無須花時間重新設計相同功能的軟體元件。

Web Services 使得「軟體即服務」的觀念更容易落實，同時也意味著分散式架構所涵蓋的範圍將更廣。

為什麼要有 Web Services？

前面已經大略點出，Web Services 基於其平台中立以及 internet 無遠弗屆的特性，將可提高軟體元件的重複使用率，這是它的好處之一，除此之外，我們還可以從企業的需求以及技術面兩種角度來探討為什麼需要 Web Services。

企業的需求

早期企業對企業之間的資料交換是以 EDI（Electronic Data Interchange，電子資料交換）達成，但由於 EDI 多為昂貴的專屬系統，使用特定的協定與資料格式，因此維護成本較高，擴充也不容易。隨著網際網路的興盛，具備高度開放性的架構、協定、及資料格式便大受歡迎，例如：TCP/IP，HTML，XML....等，並且促成了一波企業對客戶（B2C），企業對企業（B2B）的電子商務熱潮。而在 B2B 方面則逐漸形成了電子交易市集（eMarketplace）的商務模式，此模式由第三方提供一個交易場所（網站），讓各商家在此地進行交易，資料輸入仍以人工作業為主，以目前各行業競爭之激烈，速度可說是勝負的關鍵，如果能夠將人工輸入資料的方式改成電腦之間自動交換資料就可以大幅縮短企業間溝通及資料交換的時間，進而提昇企業的競爭力與反應速度。集各項公開標準於一身的 Web Services 正好符合這個需求。

由此觀之，也能看出 Web Services 的另一項特點：把以往使用者與應用程式的互動的情景，轉變成應用程式與應用程式之間的互動。

現有技術的不足

若以技術的角度來看為什麼需要 Web Services，可以先看看現有的分散式架構有何不足。目前大多數的分散式應用系統都是以遠端程序呼叫（Remote Procedure Call，RPC）的方式存取另一台電腦上的服務，例如：Microsoft 的 Distributed Component Object Model（DCOM），Sun 的 Remote Method Invocation（RMI），OMG 的 Common Object Request Broker Architecture（CORBA） 等，這些以 RPC 為基礎的分散式架構提供了開發人員熟悉的程式撰寫方式（函數呼叫）以及位置透明化（location transparency）的優點，但是它有以下缺點：

• 緊密耦合。用戶端與伺服器程式之間要規定詳細的呼叫方式，而且用戶端得事先知道如何存取這些服務的相關細節（例如函式有哪些參數及其型態），伺服器這邊稍有改變可能就會令用戶端無法執行。
• 只能同步執行（synchronous calls）。用戶端呼叫伺服器的某個程序時，必須等該程序執行完畢之後才能繼續其他動作，期間使用者能做的只有等待。儘管可以使用多執行緒的技巧來解決，但卻增加了程式的複雜度，程式也比較難撰寫。

當應用程式需要以非同步的方式執行工作時，便衍生出另一種所謂的訊息導向的架構，例如：Microsoft 的 MSMQ，IBM 的 MQSeries 等。有別於 RPC 的程序呼叫方式，這種架構使用非同步訊息傳遞的機制，訊息送出後用戶端便可以繼續執行其他工作，訊息保證會送達目的地，至於何時送達則不確定，這是它最大的特色，而其缺點為：

• 先收到的訊息先處理（佇列），無法提供特定工作流程（workflow）的執行順序。
• 程式設計師必須處理訊息封包的包裝、解讀與驗證，是一項不輕的負擔。
• 各家廠商提供的解決方案彼此不相容。

不管是 RPC 還是訊息導向的架構，它們都有一個共同的缺點，就是會跟特定的作業環境或軟體綁在一起，而且各種產品使用不同的傳輸協定或資料格式，使得彼此不能相互溝通。另外，DCOM、RMI、CORBA 等二進位協定通常會被防火牆擋在外面，使外界無法直接存取企業內部的資訊服務，若要讓它們能夠穿過防火牆，網管人員就必須在牆上打洞，如此勢必引發網路安全的問題，這也是現有的分散式架構中一個比較讓人頭痛的地方。

為了解決這些問題，Web Services 便應運而生。它具有以下特點：

• 寬鬆的（loosely-coupled）分散式架構。
• 平台中立，與實作（開發工具、程式語言）無關。
• 無狀態（stateless）。
• 提供同步與非同步的程序呼叫。
• 容易穿越防火牆。

但並不是說 Web Services 就可以完全取代傳統的分散式技術，只能說各有其適用的時機吧，在評估要使用哪一種技術來開發應用程式時，除了瞭解技術本身的優缺點，也要確實瞭解應用程式的需求及環境的限制，才不會發生以尖端科技製造無用軟體的情形。

Web Services 是如何運作的？

Web Services 要能運作，首先必須解決的問題是：

1. 應用程式如何透過 internet 遂行遠端程序呼叫，而且不用知道對方的作業環境及應用程式型態？
2. 用戶端程式如何知道怎樣使用某個 Web Service？或者說，如何得知該服務的介面（提供哪些方法呼叫）？
3. 當應用程式需要某種特定的功能時，怎麼知道網路上已經有人提供這類功能的 Web Services？到哪裡找到這些 Web Services？

第一個問題的答案是需要一個標準的訊息格式以便可以順利在各平台之間傳遞。第二個問題則需要一個描述 Web Services 的文件，用戶端可以透過解讀這個文件來了解如何使用它。第三個問題可以透過一個描述的答案則是要有一個類似目錄服務的機制，提供外界查詢現有的 Web Services。

Web Services 有三個重要的元素可以解決上述問題，它們是：

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有