微軟.NET戰略和ASP.NET簡介(2)

asp.net|微軟|戰略 1.1.2.3  MicroSoft .NET 的基本模組

?    網路服務一覽

       通常說來，一個網路服務只是一個作為服務――通過Internet標準此服務能與其它
網路服務整合在一起――發行的簡單的應用程式。換句話說，它是可通過URL定位的自動將資訊返回到需要它的用戶端那裡的一種資源。網路服務一個重要的特點是客戶不需要知道一種服務是怎樣實現的。在本節中，我將向你解釋網路及網路服務如何把基於組件技術的最好的方面結合在一起的，並且介紹與網路服務通訊所需的基本架構。
同組件一樣，網路服務提供“黑匣子”函數，它可以被再次作用而不用關心此服務是怎樣實現的。網路服務提供被稱為契約的精確定義的介面，此介面描繪了所提供的服務。開發人員可以將遠程服務、本地服務和定置程式碼群組合在一起而整合應用程式。例如，某公司可以使用如下服務組建一線上商店：微軟護照（原文：Passport）服務以驗證使用者身份，第三方個人化服務以使網頁匹配每一個使用者的參數，信用卡處理服務，銷售稅服務，對每個運輸公司的包裹Tracing Service，連結公司內部庫存管理程式的內部目錄服務，以及少量定置代碼以使他們的商店能脫穎而出。
然而，網路服務與現在的組件技術不同，它不使用需要在伺服器和客戶機有明確的、同類型基本構架的具體的物件模型協議，例如DCOM、 RMI或 IIOP 。儘管與具體組件技術緊密結合的實現在一個受控的環境中能很好地被接受，但它們在網路環境中變得不切實際。因為一個整合商業程式的參與者會發生變化，隨著時間的推移，技術也在變化，所以在所有參與者間確保一個單一的、統一的體系架構就變得十分困難。網路服務採取了另外一種途徑，它使用普便存在的網路通訊協定和資料格式，如HTTP和XML，進行通訊。支援這些網路標準的任何系統都支援網路服務。
而且，網路服務契約描述的是以術語報文形式提供的服務，這些服務是由網路服務產生和接受的，而不是描述服務是如何?的。通過把重點放在報文上，網路服務模板就完全對語言、平台和對象模板一無所知。 用任何一套程式設計語言、物件模型和平台的完全特性集，都可實現網路服務。網路 服務可在任何平台被用任何語言所實現的應用程式使用。只要用於解釋服務容量、報文序列和所期望協議的契約得到認同，那麼所實現的網路服務及網路服務使用者就可相互不同，而不會影響會話另一端的應用程式。
網路服務模板對最小體系架構的要求很低，以確保網路服務在使用任何技術和程式設計語言的平台上實現和訪問。對網路服務互用性的解決可只依靠網路標準。然而，為了使應用程式更容易使用網路服務，簡單地同意通過標準網路通訊協定就可以訪問網路服務是不夠的。當網路服務和網路服使用者依靠標準的方式表示資料和命令、表示網路服務契約 、算出網路服務所提供的容量時，網路服務才容易使用。
XML是定義一個標準的、可擴充的用於提供命令和典型資料的語言明顯的一種選擇。雖然為表示命令和典型資料可以定義使用其它技巧（比如編碼為一種查詢字串）的規則，但XML被專門設計為描述資料的標準元語言。簡單對象存取協議（SOAP）是以一種可擴充的方式使用XML表示資料和命令的工業標準。網路服務可選擇用SOAP決定報文的格式。
XML是網路服務契約的一種使能技術。服務契約語言 (SCL)是記錄網路服務契約的XML文法。由於SCL是基於XML的，所以對開發人員和開發工具來說，容易產生、解釋契約。關於SCL細則的草案很快會出台（注意：現在的SOAP Toolkit for Visual Studio 6.0支援稱為SDL的SCL的早期版本）。
Disco 規範為服務提供者發布網路 服務契約和相應的機制描述了一個標準方式，這將使開發人員或開發工具可找到契約文獻。當你讀到這裡時， Disco規範的草案應出台了。
象SOAP， SCL和Disco這樣的標準有助於開發人員，因為它們不需要明白和實現所使用的每一個網路服務的訪問方式。支援這些標準的更好的、已充分測試的、高效能的體系架構將由開發平台提供，這會大大簡化整個開發過程。

?    MicroSoft .NET Framework

MicroSoft .NET架構的目的是使你更容易建立網路應用程式和網路服務。圖2 顯示了MicroSoft .NET架構的體系。建立在作業系統最上層的服務，是管理運行時代碼需求的common language runtime，這些代碼可以用任何現代程式設計語言所寫。Runtime提供了許多服務，這些服務有助於簡化代碼開發和應用程式的開發同時也將提高應用程式的可靠性。.NET Framework包括一套可被開發人員用於任何程式設計語言的類庫。在此之上是許多應用程式模板，這些模板特定地為開發網路站台和網路服務提供進階組件和服務。

?    Common Language Runtime

運行語言(runtime)調入並運行用任何運行感知程式設計語言所寫的代碼。以運行為目標的代碼被稱為受控（managed ）代碼，受控代碼代碼只是意味著在內部可執行代碼與運行自身間存在已定義好的合作契約。對於象產生對象、調用方法等這樣的任務，被委託給了運行語言，這使得在運行語言能為可執行代碼增加額外的服務。
運行語言以交叉語言整合、自描述組件、簡單配製和版本化及整合安全服務為特點。
運行語言使用一種新的能表達大部分現代程式設計語言語義的一般型別系統，一般型別系統定義了一套標準類型及產生新標準的規則。運行語言知道怎樣產生、執行這些類型。編譯器和解譯器使用運行語言服務定義類型、管理對象、進行方法調用，而不是使用工具或特定於語言的方法。
類型系統的主要設計目的是使多種語言能深度整合。用一種語言所寫的代碼能繼承用另一種語言所寫的類的實現，用一種語言所寫的代碼拋出的異常能被用另一種語言寫的代碼捕獲，象調試和剖析之類的操作會在完全封閉下工作，而不用考慮代碼所用的語言。這就意味著編寫可重用類庫的開發人員，不再需要為每一種程式設計語言或編譯器產生一個版本，並且使用類庫的開發人員不再受到為他們使用的程式設計語言開發的庫的限制。
自描述組件――現在MicroSoft .NET架構上已成為可能――簡化了開發和配製，並提高了系統的可靠性。許多由運行語言提供的服務是由中繼資料及用於補充可執行代碼的資訊所驅動。因為所有的資訊都儲存在一起，只有可執行檔（代碼）才被稱為自描述組件。
自描述組件的一個主要優點是，使用它們並不需要其它檔案。類的定義不需要單獨的標頭檔；通過檢查中繼資料對類的定義可以從組件自身獲得。跨語言或過程邊界訪問組件並不需要各自的IDL檔案、類型檔案或proxy/stubs；所必需的資訊已存在於中繼資料之中。為識別開發人員請示的服務屬性，並不需要展開各自的配製資訊。 最主要的是，由於中繼資料是在編譯過程中由原始碼產生，並與可執行代碼儲存在一起，它將永遠和可執行部分同步。
除了改善對單個組件的配製，Microsft .NET架構定義了一個應用程式配製模板，以解決定置應用程式安裝和DLL版本化（通常被稱為“DLL Hell”）這一複雜過程的問題，運行語言提供了支援這個模板的服務。
Microsft .NET架構 引入了組合體的概念。一個組合體是一組資源和類型，並包括有關這些資源和類型的中繼資料，也就是被作為一個單元配製的。中繼資料被稱為組合體的名單，它包含象類型和資源表之類能被組合體外看得見的資訊，這個名單也包括有關從屬關係之類的資訊，例如組合體建立時的版本號碼。開發人員可以指定版本原則，以指示運行語言是否裝入系統上已安裝的依賴於組合體的最新版本，裝入一指定版本，或在編譯時間使用的版本。
某軟體組件的多個拷貝總可以存在於同樣的作業系統上，然而，通常說來，只有其中的一個拷貝能被作業系統註冊、調入記憶體、執行。對系統來說，定位和調入記憶體的策略是全域性。.NET Framework Common Language Runtime 增加了所必須的體系架構以支援管理組件定位和調入的每個應用程式策略，這通常被稱為並行配製。
組合體可以被一個應用程式私人，或被多個應用程式共用。一個組合體的多個版本可以同時配製在同一台機器上。應用程式配製資訊定義了到何處去尋找組合體，這樣runtime就能為同時啟動並執行兩個不同的應用程式裝入同一組合體的不同版本。這就消除了由組件版本的不相容性引起的問題，提高了系統整體的穩定性。如果必要，如果必要，管理員可以為配製時刻的組合體增加配製資訊，例如一個不同的版本原則，但是編譯時間提供的原始資訊永遠不會丟失。
因為組合體是自描述的，所以並不需要在系統上進行顯式註冊。應用程式的配製簡單到只需將檔案拷貝到目錄中既可（如果為了使應用程式能夠運行，必須安裝未經組織過的組件的話，情況會稍微複雜一點）。配製資訊儲存在可被任何文字編輯器編輯的XML檔案中。
最後，運行語言也提供完整的、普遍深入的安全服務，以確保未經授權的使用者不能訪問機器上的資源，並且代碼不會執行未經允許的動作。這就提高了系統整體的安全性可靠性。 由於運行語言用於裝入代碼、產生對象、執行方法調用，所以當受控代碼裝入記憶體、執行時，運行語言能進行安全檢查，強化安全性原則。
Microsft .NET架構不僅規定代碼訪問安全，還規定基於角色的安全。通過代碼訪問安全機制，開發人員能為應用程式指定完成工作所必需的許可權。例如，代碼或許需要寫檔案或訪問環境變數的權力。這類資訊和有關代碼標誌的資訊一起儲存在配製級上的。當代碼裝入記憶體及執行方法調用時，運行語言驗證是否能給予代碼所要求的許可權。如果不能，將記錄一條安全衝突資訊。給予許可權的策略，這被稱為信任策略，是由系統管理員建立的，並且是建立在關於代碼的證據基礎之上，比如：代碼是誰發布的，是從什麼地方獲得的，以及在組合體中找到的代碼標誌和它要求的許可權。開發人員可以指定他們顯然不需要的許可權，以防止其它人惡意使用他們的代碼。如果所需要的許可權依賴直到運行時刻才會知道的資訊，那麼就可寫入綱鄰性的安全檢查。
除了代碼訪問安全，運行語言還支援基於角色的安全。基於角色的安全建立同代碼訪問安全一樣的權限範本，只是這些許可權是建立在使用者的身份之上，而不是建立在代碼的標誌之上。角色表明了使用者所屬的類，並且可以在開發和配製階段定義。給予許可權的策略被分配到每個預定義的角色。在運行時刻，使用者的身份被確定，代碼將代表這個身份運行。運行語言決定使用者是哪個角色的成員，然後給予基於這個角色的許可權。
在查看Microsft .NET架構的可程式化模板前，先看一下它所提供的服務。

?    服務架構
在Common Language Runtime之上是服務架構，此架構提供能被任何現代程式設計語言調用的類。所有的類都遵循一套命名和設計方針，以大大減小開發人員的學習上的彎路。
架構套件括一套開發人員希望在標準語言庫中存在的基底類別庫，例如：集合、輸入/輸出，字串及資料類。另外，基底類別庫提供訪問作業系統服務如圖畫、網路、線程、全球化和加密的類。服務架構也包括資料訪問類庫，及開發工具，如調試和剖析服務，能夠使用的類。本文章沒有詳細討論所有的類，我將重點放在資料訪問類上，因為大多數網路服務需要對資料的訪問。當然，你可以在MicroSoft .NET Framework SDK中找到關於服務架構類庫的附加資訊。

?    資料訪問服務
幾乎所有的網路服務都需要查詢和更新永久性資料，不論是以簡單檔案，還是以相關資料庫，或是以其它的儲存類型存在。為了提供對資料的訪問，服務架構套件括ActiveX Data Objects+ (ADO.NET)類庫。如同名子所暗示地那樣，ADO.NET由ADO發展而來。ADO+被設計為基於網路的可擴充的應用程式和服務提供資料訪問服務。ADO.NET為串連的指標風格的資料訪問，同時也為更適合於把資料返回到用戶端應用程式的不需連線的資料範本提供高效能的APIs流，就象在以後介紹的那樣。
就象其餘幾個部分一樣，ADO.NET定義了那些連結資料倉儲、 對資料倉儲發送命令及從中擷取結果的類。這些類由受控資料提供者（managed data provider）實現。ADO+中連結和命令對象看上去和ADO中的是一樣的，並且一個名為DataReader的新類提供了通過高效能API流擷取結果的能力。DataReader在功能上同前向、唯讀ADO記錄集（Recordset）是等同的，但是DataReader被設計用來最小化記憶體中產生的對象的數量，以提高效能，避免垃圾積累。在.NET Framework中包含了針對MicroSoft SQL Server?的受控資料提供者以及可通過OLE DB訪問的任何資料倉儲。
ADO.NET的一個主要創新是引入了資料集（Dataset）。一個資料集是記憶體中提供資料關係圖的高速緩衝區。資料集對資料來源一無所知，它們可以由程式或通過從資料倉儲中調入資料而被產生、填充。不論資料從何處擷取，資料集都是通過使用同樣的程式模板而被操作的，並且它使用相同的潛在的資料緩衝區。使用.NET平台的開發人員能夠用資料集代替傳統ADO中不需連線的記錄集。
受控資料提供者為資料倉儲和資料集公開一名為DataSetCommand 的介面對象。Dataadpter 使用ADO.NET連結和命令以從資料倉儲中填充資料集，並把在資料集中發生的變化解析到資料倉儲中。
就象DataReaders 顯示了對於相關資料的有效流訪問一樣，XmlReaders 顯示了對XML資料的流訪問。開發人員使用DataNavigator 可以滾動和編輯記憶體中的XML文檔。DataNavigator在功能上和W3C Document Object Model (DOM)是一樣的，但它更有效，並提供了能很好映射關係資料表的對象模板。DataNavigator 支援Xpath文法以對資料流進行導航。ADO.NET為那些希望繼續使用DOM作為XML對象模板而不是使用更有效DataNavigator模板的開發人員提供了一個XMLDocument類。
由於所有的資料都可被看作XML，所以開發人員可以為任何資料使用轉換和確認服務。ADO.NET定義了一個消費DataNavigator、產生一個新的XmlReader的通用轉換體系。.NET Framework提供了一個支援W3C XSL Transformations (XSLT)細則的特殊轉換組件。ADO.NET同時提供了一使用XML簡圖確認XmlReader的確認引擎。ADO.NET支援通過DTDs， XSD或 XDR定義的簡圖。