為什麼需要Web Service (轉)

為什麼需要Web Service (轉)[@more@]從前，分散式的應用邏輯需要使用分散式的模型，諸如：的分散式物件模型(DCOM)、物件管理集團的公用物件請求程式體系結構()或Sun的方法()。透過使用這種基本結構，開發人員仍可擁有使用本地模型所提供的豐富資源和精確性，並可將服務置於遠端中。

當我已經有了我中意的平臺（RMI, , CORBA, D等等)時，為什麼還要為而煩惱呢？中介軟體確實提供了強大的服務實現手段，但是，這些系統有一個共同的缺陷，那就是它們無法擴充套件到網際網路上：它們要求服務客戶端與系統提供的服務本身之間必須進行緊密耦合，即要求一個同類基本結構。這樣的系統往往十分脆弱：如果一端的機制發生變化，那麼另一端便會崩潰。例如，如果應用程式的介面發生更改，那麼客戶端便會崩潰。

要求提供緊密耦合的基本結構，無可厚非，許多應用程式均是基於這種系統構建而成的。但是，當各個公司需要相互合作、或資訊科技提供商擴大業務範圍時，便很難實現單一而統一的基本結構。您根本無法保證您希望與之進行遠端通訊的管道的另一端，具備所有您需要的基本結構：對於它使用的、物件模型或語言，您可能一無所知。

相反，Web服務彼此是鬆散偶合的。連線中的任何一方均可更改執行機制，卻不影響應用程式的正常執行。從技術角度講，人們已轉向使用一種基於訊息的非同步技術來實現高可靠性的系統，透過使用諸如HTTP、簡單傳輸(SMTP)以及至為重要的來實現統一的連線。

Web作為資訊釋出者的力量就在於簡單且無處不在，這對解決現在這樣一個分裂中介軟體世界很重要。Web透過在傳統中介軟體平臺上更有效實現的Services，來提供一個統一且廣泛適用的介面，這樣就改善了這個平臺。

從一個N層應用程式結構的角度來看，web service只是一個方便程式訪問的包裝，服務還是要靠中介軟體來實現。訪問包括服務請求處理（者）和一個支援商業邏輯操作的介面，商業邏輯本身是由傳統的中介軟體平臺實現的。

從理論上講，開發人員可透過呼叫Web應用程式設計介面()（就像呼叫本地服務一樣），將Web服務整合到應用程式中，不同的是Web API呼叫可透過網際網路傳送給位於遠端系統中的某一服務。例如， Passport服務使得開發人員能夠對某應用程式進行驗證。透過Passport服務程式設計，開發人員可以充分利用Passport的基本結構，透過執行Passport來維護，以確保它的正常執行、定期等等。

訊息傳遞系統將通訊的基本單元打包成自我描述型的資料包（又稱作訊息），並將其放到纜線中。訊息傳遞系統與分散式物件系統之間的本質區別在於：要求傳送方辨識接收方的基本結構的程度有所不同。在分散式系統中，傳送方需對接收方的情況作出種種猜測：應用程式是如何啟用或拆包的，呼叫的是什麼樣的介面，等等。

另一方面，訊息傳遞系統會在纜線格式級上建立合同。傳送方既不需考慮訊息被接收後的情況，也不需考慮接發雙方之間的通訊情況，唯一需要考慮的是接收方是否能辯識傳送的訊息內容。

在纜線格式級上建立合同的優勢不言而喻。例如，接收方可在任何時刻進行更改，而不會干擾傳送方的訊息傳送，只要它仍可辯識原有訊息的內容。另外，傳送方無需任何特殊的即可與接收方通訊：只要它發出正確格式的訊息，接收方就可以響應。