微軟.net介紹資料

文章目錄

• .NET 帶來了哪些變化
• 哪些內容保持不變

何謂.NET？它是Microsoft面向XML Web服務的平台。但可能您又會問道“準確地說，什麼是XML Web服務呢？” 它是未來的計算。請瀏覽我們為您提供的資源以瞭解.NET將如何改變我們的Web體驗。 

 是否曾經因為試圖在 Web 網站、應用程式和裝置之間移動並反覆輸入相同的資訊、跟蹤多個使用者名稱和密碼以及權衡費力的同步資料方法而沮喪過？

Microsoft .NET 對“方便使用”重新進行了定義。您可以漫遊智能的、個人化的 Internet，它記住您的喜好設定並在適當的時間將適當的資料傳送到您選用的任何智慧型裝置。

您的企業是否因為整合系統太難而且費用過高而受困於特定的系統或夥伴？

Microsoft .NET 平台對用於資料交換的 XML（WWW 聯合會 (W3C) 維護的開放標準）和模組化的 XML Web services 的依賴，消除了資料共用和軟體整合的障礙。

您的客戶、僱員和夥伴在他們的首選裝置上與您的組織進行串連時是否遇到困難？

對於 .NET，一種 XML Web services 可以與所有裝置一起工作，無需不同的版本。將 .NET 體驗與顯示特性分開，可使添加新介面技術（如語音和手寫辨識）變得容易，而無需重編應用程式。

是否擔心採用新技術需要替換舊式系統？

一些 Microsoft .NET 產品（如 BizTalk Server 和 Host Integration Server）就是為簡化將現有成果整合到新的 .NET XML Web services 和 .NET 體驗的過程而設計的。

是否因為產生和整合應用程式所花費的時間過長而錯過業務機會？

通過 .NET 架構的公用語言運行庫，.NET 平台使各種 XML Web services 能夠互動操作，而不管其源語言的不同。開發人員可以產生可重用的 XML Web services，而不是產生單個應用程式。通過使您能夠輕鬆地為他人提供 XML Web services，.NET 為您開啟了新的財源之門。

繁雜的基本事務是否侵佔了核心業務的資源？

輕鬆找到可用的 XML Web services 的能力意味著您能夠購買應用程式構件，將時間和資金集中在最重要的事情上，而不是從頭開始產生一切。

首創第三代計算技術

2002 年 1 月 14 日

Microsoft .NET 將從根本上改變我們考慮和使用計算裝置的方式。當前，伺服器和用戶端案頭這兩個概念是計算技術的最重要的概念。Microsoft .NET 將此模型擴充為松耦合服務的豐富的、分散式運算範例。不管是在伺服器、PC、掌上型電腦還是在其他智慧型裝置上，只要是最適於進行處理，就會進行處理，而不必按照傳統方式對案頭和伺服器加以區分。這是新一代智慧型裝置的智能計算。

.NET 帶來了哪些變化

Microsoft .NET 計算模型以不同方式影響企業、個人和開發人員。對於個人：這些變化將產生極其個人化的、整合的計算體驗。對於企業和開發人員：它將改變企業和開發人員產生軟體和銷售產品的方式，使 IT 成為企業成功的重要因素並引入新的業務模式。

哪些內容保持不變

儘管 Microsoft .NET 在計算技術領域帶來了一些根本性變化，但是很多內容仍然保持不變：

• 個人在 .NET 體驗中仍將使用他們所熟悉的介面，如 Microsoft Office。這減少了重新培訓的費用，意味著個人可以立即使用支援 .NET 的軟體。

• 硬體仍將運行一些作業系統，如 Microsoft Windows、UNIX、Windows CE 和 PalmOS。實際上，.NET 在降低開發負擔的同時增加了軟體可以啟動並執行平台數。因為 XML Web services 只通過 XML 與裝置進行通訊，所以任何智慧型裝置都可以使用 XML Web services。
• 開發人員仍將使用他們首選的程式設計語言。藉助 .NET 架構的公用語言運行庫，.NET 平台使各種 XML Web services 可以互動操作，而不管其源語言的不同。Microsoft .NET 體驗同樣對源語言不置可否，您可以通過使用 Microsoft Visual Basic、Java，甚至是 COBOL 編寫的 XML Web services 產生這些體驗。這種中立性意味著無須為了利用 .NET 平台而丟棄和替換現有成果。
• 無需替換舊式系統。某些 Microsoft .NET 產品是為了將現有成果輕鬆地整合到新的 .NET XML Web services 和 .NET 體驗中而專門設計的。例如，Microsoft Host Integration Server 簡化對大型主機的訪問；Microsoft BizTalk Server 管理商務程序的編排，包括對現有的系統和資料格式的處理，同時進行到 XML 的必需的自動化資料轉換。
  因此，這一下一代分散式運算技術建立在當前這一代計算技術的基礎之上。正如我們所知道的，Microsoft .NET 並不是軟體應用程式的整批替換，而是將協作和互通性的好處帶給我們現有的技術“孤島”的自然演變。

什麼是 XML Web Service？

XML Web Service 是在 Internet 上進行分散式運算的基本構造塊。開放的標準以及對使用者和應用程式之間的通訊和協作的關注產生了這樣一種環境，在這種環境下，XML Web Service 成為應用程式整合的平台。應用程式是通過使用多個不同來源的 XML Web Service 構造而成的，這些服務相互協同工作，而不管它們位於何處或者如何?。

有多少個構建 XML Web Service 的公司，就可能有多少種 XML Web Service 定義。不過幾乎所有定義都具有以下共同點：

• XML Web Service 通過標準的 Web 協議向 Web 使用者提供有用的功能。多數情況下使用 SOAP 協議。
• XML Web Service 可以非常詳細地說明其介面，這使使用者能夠建立用戶端應用程式與它們進行通訊。這種說明通常包含在稱為 Web 服務說明語言 (WSDL) 文檔的 XML 文檔中。
• XML Web Service 已經過註冊，以便潛在使用者能夠輕易地找到這些服務，這是通過通用發現、說明和整合 (UDDI) 來完成的。

本文將介紹這三種技術，但首先需要解釋一下為什麼要關注 XML Web Service。

XML Web Service 體繫結構的主要優點之一是：允許在不同平台上、以不同語言編寫的各種程式以基於標準的方式相互連信。對這一行業有所瞭解的使用者可能馬上會說：“等一等，CORBA 和之前的 DCE 不是都做過相同的承諾嗎？這和它們有什麼區別？”最重要的區別在於：SOAP 比以前的方法要簡單得多，因此要實現與標準相容的 SOAP，障礙也要少得多。Paul Kulchenko 在 http://www.soapware.org/directory/4/implementations（英文）上提供了一個 SOAP 實現方案的列表。上次統計時，該列表已經包含了 79 項。正如您所預料，多數大的軟體公司都提供 SOAP 實現方案，但也有許多實現方案是由個別開發人員建立和維護的。相對以前的方案而言，XML Web Service 的另一大優點是使用標準的 Web 協議 - XML、HTTP 和 TCP/IP。許多公司都已經建立了 Web 基礎結構，同時它們的員工在維護方面也都具備相應的知識和經驗。因此，引入 XML Web Service 與引入以前的技術相比，其成本要低得多。

我們將 XML Web Service 定義為：通過 SOAP 在 Web 上提供的軟體服務，使用 WSDL 檔案進行說明，並通過 UDDI 進行註冊。那麼，您也許要問：“使用 XML Web Service 能夠做什嗎？”最初的 XML Web Service 通常是可以方便地併入應用程式的資訊來源，如股票價格、天氣預報、體育成績等等。我們很容易想到，可以構建一整類應用程式以分析和匯總所關心的資訊，並以各種方式提供這些資訊；例如，您可以使用 Microsoft Excel 試算表來匯總所有的財務資訊 - 股票、401K、銀行存款、貸款等等。如果能夠通過 XML Web Service 獲得這些資訊，Excel 就可以不斷對其進行更新。這些資訊中有些是免費的，有些則可能需要訂閱才能獲得相應服務。大部分這種資訊現在已經可以在 Web 上找到了，但是 XML Web Service 可以使編程訪問更簡單，也更可靠。

以 XML Web Service 方式提供現有應用程式，可以構建新的、更強大的應用程式，並利用 XML Web Service 作為構造塊。例如，使用者可以開發一個採購應用程式，以自動擷取來自不同供應商的價格資訊，從而使使用者可以選擇供應商，提交訂單，然後跟蹤貨物的運輸，直至收到貨物。而供應商的應用程式除了在 Web 上提供服務外，還可以使用 XML Web Service 檢查客戶的信用、收取貨款，並與貨運公司辦理貨運手續。

將來，某些最有趣的 XML Web Service 所支援的應用程式還可以利用 Web 完成目前無法完成的任務。例如，日曆服務就是 Microsoft .NET My Services（英文）項目即將支援的服務之一。如果您的牙醫和機械師通過這一 XML Web Service 提供其排程，您就可以通過網路與他們安排約會；如果您願意，他們也可以直接在您的日曆上約定清潔和日常保養的日期。不難想象，只要能夠對 Web 進行編程，您就可以建立數以百計的應用程式。

有關 XML Web Service 及其可以構建的應用程式的詳細資料，請參閱 MSDN Web 服務（英文）首頁。

SOAP

Soap 是 XML Web Service 的通訊協定。當把 SOAP 描述為一種通訊協定時，多數人都會想到 DCOM 或 CORBA，並且會問“SOAP 如何啟用物件？”或“SOAP 使用什麼樣的命名服務？”等問題。雖然 SOAP 實現方案可能會包含上述內容，但 SOAP 標準並未對其進行規定。SOAP 一種規範，用來定義訊息的 XML 格式 - 這是規範中所必需的部分。包含在一對 SOAP 元素中的、結構正確的 XML 段就是 SOAP 訊息。這是不是很簡單？

SOAP 規範的其他部分介紹如何將程式資料表示為 XML，以及如何使用 SOAP 進行遠端程序呼叫 (RPC)。這些可選的規範部分用於實現 RPC 形式的應用程式，其中用戶端將發出一條 SOAP 訊息（包含可調用函數，以及要傳送到該函數的參數），然後伺服器將返回包含函數執行結果的訊息。目前，多數 SOAP 實現方案都支援 RPC 應用程式，這是因為習慣於開發 COM 或 CORBA 應用程式的編程人員熟悉 RPC 形式。SOAP 還支援文檔形式的應用程式，在這類應用程式中，SOAP 訊息只是 XML 文檔的一個封裝。文檔形式的 SOAP 應用程式非常靈活，許多新的 XML Web Service 都利用這一特點來構建使用 RPC 難以實現的服務。

SOAP 規範的最後一個可選部分定義了包含 SOAP 訊息的 HTTP 訊息的樣式。此 HTTP 綁定非常重要，因為幾乎所有當前的 OS（以及許多以前的 OS）都支援 HTTP。HTTP 綁定雖然是可選的，但幾乎所有 SOAP 實現方案都支援 HTTP 綁定，因為它是 SOAP 的唯一標準協議。由於這一原因，人們通常誤認為 SOAP 必須使用 HTTP。其實，有些實現方案也支援 MSMQ、MQ 系列、SMTP 或 TCP/IP 傳輸，但由於 HTTP 非常普遍，幾乎所有當前的 XML Web Service 都使用它。由於 HTTP 是 Web 的核心協議，因此大多數組織的網路基礎結構都支援 HTTP，並且員工已經瞭解了如何對其進行管理。如今，已經建立了用於 HTTP 的安全保護、監視和Server Load Balancer的基礎結構。

開始使用 SOAP 時，最容易混淆的是 SOAP 規範及其許多實現方案之間的差異。多數使用 SOAP 的使用者並不直接編寫 SOAP 訊息，而是使用 SOAP 工具包來建立和分析 SOAP 訊息。這些工具包通常將函數調用從某種語言轉換為 SOAP 訊息。例如，Microsoft SOAP Toolkit 2.0 將 COM 函數調用轉換為 SOAP，而 Apache Toolkit 將 JAVA 函數調用轉換為 SOAP。函數調用的類型和支援的參數的資料類型隨每個 SOAP 實現方案的不同而不同，因此適用於一個工具包的函數可能並不適用於另一個工具包。這並不是 SOAP 的限制，而是所使用的特定實現方案的限制。

到目前為止，SOAP 最令人信服的特徵是它可以在許多不同的軟體和硬體平台上實現。這意味著 SOAP 可用於連結企業內部和外部的不同系統。過去曾試過多種方法以提出一個可用於系統整合的通用通訊協定，但它們都沒有象 SOAP 一樣獲得廣泛的認可。為什麼呢？因為與許多早期的協議相比，SOAP 更小巧，而且更易於實現。例如，DCE 和 CORBA 的實現需要數年時間，所以只發布了很少幾個實現方案。而 SOAP 可以利用現有的 XML 分析器和 HTTP 庫完成大部分艱苦的工作，因此 SOAP 實現方案在數月內便可完成。這就是為什麼現在已經有 70 多個 SOAP 實現方案的原因。當然，SOAP 並不具備 DCE 或 CORBA 的全部功能，雖然功能減少了，但由於其複雜程度大大降低了，因此 SOAP 更易於應用。

HTTP 的普及和 SOAP 的簡單性使您幾乎可以從任何環境調用它們，因此成為 XML Web Service 的理想基礎。有關 SOAP 的詳細資料，請參閱 MSDN SOAP（英文）首頁。

安全性如何？

通常，剛接觸 SOAP 的使用者提出的第一個問題就是 SOAP 如何解決安全性問題。在其早期開發階段，SOAP 被看作是基於 HTTP 的協議，所以認為 HTTP 的安全性對於 SOAP 已經足夠了。畢竟目前有數以千計的 Web 應用程式都在使用 HTTP 安全性，所以這對於 SOAP 確實已經足夠。因此，當前的 SOAP 標準假定安全性屬於傳輸問題，而並不作為安全性問題處理。

當 SOAP 延伸模組至更為通用的協議，並運行於眾多傳輸之上時，安全性問題就變得突出了。例如，HTTP 提供若干種方法對進行 SOAP 調用的使用者進行身分識別驗證，但是當訊息從 HTTP 路由到 SMTP 傳輸時，怎樣傳播該身份標識呢？SOAP 是作為構造塊協議進行設計的，所以幸運的是，已經有了相應的規範以基於 SOAP 為 Web 服務提供額外的安全保護功能。WS-Security 規範（英文）定義了一套完整的加密系統，而 WS-License 規範（英文）定義了相應的技術，以保證調用者的身份標識，並確保只有授權使用者才可以使用 Web 服務。

WSDL

WSDL (Web Services Description Language) 表示 Web 服務說明語言。在本文中，我們可以認為 WSDL 檔案是一個 XML 文檔，用於說明一組 SOAP 訊息以及如何交換這些訊息。換句話說，WSDL 對於 SOAP 的作用就象 IDL 對於 CORBA 或 COM 的作用。由於 WSDL 是 XML 文檔，因此很容易進行閱讀和編輯；但大多數情況下，它由軟體產生和使用。

要查看 WSDL 的值，可以假設您要調用由您的一位業務夥伴提供的 SOAP 方法。您可以要求對方提供一些 SOAP 訊息樣本，然後編寫您的應用程式以產生並使用與樣本類似的訊息，但這樣很容易出錯。例如，您可能看到一個 2837 的客戶 ID，並假設它為整數，而實際上它是一個字串。WSDL 通過明確的標記法指定請求訊息必須包含的內容以及響應訊息的樣式。

WSDL 檔案用於說明訊息格式的標記法以 XML 結構描述標準為基礎，這意味著它與程式設計語言無關，而且以標準為基礎，因此適用於說明可從不同平台、以不同程式設計語言訪問的 XML Web Service 介面。除說明訊息內容外，WSDL 還定義了服務的位置，以及使用什麼通訊協定與服務進行通訊。也就是說，WSDL 檔案定義了編寫使用 XML Web Service 的程式所需的全部內容。有幾種工具可以讀取 WSDL 檔案，並產生與 XML Web Service 通訊所需的代碼。其中一些最強大的工具可在 Microsoft Visual Studio .NET 中找到。

當前，許多 SOAP 工具包都包括從現有程式介面產生 WSDL 檔案的工具，但卻幾乎沒有直接用於編寫 WSDL 的工具，而且 WSDL 的工具支援也很不完整。但不久就會出現編寫 WSDL 檔案的工具，接著還會有組建代理程式和存根的工具（與 COM IDL 工具很相似），這些工具將成為多數 SOAP 實現方案的一部分。到那時，WSDL 將成為建立 XML Web Service 的 SOAP 介面的首選方法。

這裡有一個非常好的 WSDL 說明（英文），您還可以在 http://www.w3.org/TR/wsdl（英文）找到 WSDL 規範。

UDDI

通用發現、說明和整合 (UDDI) 是 Web 服務的黃頁。與傳統黃頁一樣，您可以搜尋提供所需服務的公司，閱讀以瞭解所提供的服務，然後與某人聯絡以獲得更多資訊。當然，您也可以提供 Web 服務而不在 UDDI 中註冊，就象在地下室開展業務，依靠的是口頭吆喝；但是如果您希望拓展市場，則需要 UDDI 以便能被客戶發現。

UDDI 目錄條目是介紹所提供的業務和服務的 XML 檔案。UDDI 目錄條目包括三個部分。“白頁”介紹提供服務的公司：名稱、地址、連絡方式等等；“黃頁”包括基於標準分類法（例如 North American Industry Classification System 和 Standard Industrial Classification）的行業類別；“綠頁”詳細介紹了訪問服務的介面，以便使用者能夠編寫應用程式以使用 Web 服務。服務的定義是通過一個稱為類型模型（或 tModel）的 UDDI 文檔來完成的。多數情況下，tModel 包含一個 WSDL 檔案，用於說明訪問 XML Web Service 的 SOAP 介面，但是 tModel 非常靈活，可以說明幾乎所有類型的服務。

UDDI 目錄還包含若干種方法，可用於搜尋構建您的應用程式所需的服務。例如，您可以搜尋特定地理位置的服務提供者或者搜尋特定的業務類型。之後，UDDI 目錄將提供資訊、連絡方式、連結和技術資料，以便您確定能滿足需要的服務。

UDDI 允許您尋找提供所需的 Web 服務的公司。如果您已經知道要與誰進行業務合作，但尚不瞭解它還能提供哪些服務，這時該如何處理呢？WS-Inspection 規範（英文）允許您瀏覽特定伺服器上提供的 XML Web Service 的集合，從中尋找所需的服務。

有關 UDDI 的詳細資料，請訪問 http://www.uddi.org/about.html（英文）。

其他內容

到現在為止，我們已經討論了如何與 XML Web Service 通訊 (SOAP)，XML Web Service 是怎樣進行說明的 (WSDL)，以及如何尋找 XML Web Service (UDDI)。這些內容構成了一套基本規範，為應用程式的整合和彙總提供了基礎。根據這些基本規範，公司可以構建實際的解決方案，並從中獲益。

為實現 XML Web Service，我們已經做了許多工作，但仍有大量工作需要完成。今天，人們已經使用 XML Web Service 取得了成功，但對於開發人員來說，仍有許多環節需要完善。例如，安全性、運營管理、交易處理以及可靠的訊息傳遞等。Global XML Web Services Architecture 將通過以下方式協助 XML Web Service 進入下一個發展階段：提供一個一致的通用模型，以模組化和可擴充的方式向 XML Web Service 添加新的進階功能。

上面提到的安全模組（WS-Security [英文] 和 WS-License [英文]）就是 Global Web Services Architecture 規範的一部分。運營管理的需要（例如在多個伺服器之間路由訊息，以及動態配置這些伺服器以便進行處理）也是 Global Web Services Architecture 的一部分，它們是通過 WS-Routing 規範（英文）和 WS-Referral 規範（英文）來實現的。隨著 Global Web Services Architecture 的發展，還將進一步介紹滿足上述需要以及其他需要的規範。

詳細資料，請參閱 Global XML Web Service Architecture（英文）。