.NET框架與XML：Web服務的未來之道
應用程序開發技術正發生著一次質的飛躍，從根本上大幅度提高開發人員的生產效率，它開啟了一道通向全新概念的應用程序的大門。
在過去，開發人員一直通過集成本地系統服務來構建應用程序。在這種模式下，開發人員可以訪問豐富的開發資源并能嚴格控制應用程序的行為。
如今，開發人員在很大程度上已掙脫了這種模式的束縛，致力于構建具有復雜結構的n層系統，這種系統能將網絡中各處的眾多的應用程序進行集成，并大大提升應用程序的價值。這樣，開發人員便可集中精力挖掘軟件獨特的商業價值，而不必日夜為如何構建基本結構傷腦筋了。令人欣喜的局面將應運而生：軟件投放市場的時間大大縮短、開發人員的編程效率明顯提高，最為根本的是開發出質量上乘的軟件。
我們正在進入一個嶄新的計算時代，一個互聯網時代，其核心技術是“可擴展標記語言”，即XML。XML創建出可供任何人從任何地方訪問和使用的功能強大的應用程序。它極大地擴展了應用程序的功能，并實現了軟件的不間斷傳輸。在這種大環境中，軟件已不完全是指那些從CD進行安裝的程序，而是已經演變成了一種服務：類似于調用者的ID驗證或按觀看次數進行收費的電視，人們可通過通信媒體預定此類服務。
這一切，是通過將緊密耦合的、高效的n層計算技術與面向消息的、松散耦合的Web概念相結合來實現的。我們將這種計算風格稱為Web服務，它的出現標志著人類已經邁入應用程序開發技術的新紀元。Web服務是一種應用程序，它可以使用標準的互聯網協議，像超文本傳輸協議(HTTP)和XML，將功能綱領性地體現在互聯網和企業內部網上。可將Web服務視作Web上的組件編程。
從理論上講，開發人員可通過調用Web應用編程接口(API)（就像調用本地服務一樣），將Web服務集成到應用程序中，不同的是Web API調用可通過互聯網發送給位于遠程系統中的某一服務。例如，Microsoft Passport服務使得開發人員能夠對某應用程序進行驗證。通過Passport服務編程，開發人員可以充分利用Passport的基本結構，通過運行Passport來維護用戶數據庫，以確保它的正常運行、定期備份等等。
.NET框架與XML之松散耦合
在某個網絡中分發應用程序邏輯，并不是一個全新的概念，在Web中分發并集成應用程序邏輯才是一個嶄新的概念。
從前，分布式的應用程序邏輯需要使用分布式的對象模型，諸如：微軟的分布式組件對象模型(DCOM)、對象管理集團的公用對象請求代理程序體系結構(CORBA)或Sun的遠程方法調用(RMI)。通過使用這種基本結構，開發人員仍可擁有使用本地模型所提供的豐富資源和精確性，并可將服務置于遠程系統中。
這些系統有一個共同的缺陷，那就是它們無法擴展到互聯網上：它們要求服務客戶端與系統提供的服務本身之間必須進行緊密耦合，即要求一個同類基本結構。這樣的系統往往十分脆弱：如果一端的執行機制發生變化，那么另一端便會崩潰。例如，如果服務器應用程序的接口發生更改，那么客戶端便會崩潰。
要求提供緊密耦合的基本結構，無可厚非，許多應用程序均是基于這種系統構建而成的。但是，當各個公司需要相互合作、或信息技術提供商擴大業務范圍時，便很難實現單一而統一的基本結構。您根本無法保證您希望與之進行遠程通信的管道的另一端，具備所有您需要的基本結構：對于它使用的操作系統、對象模型或編程語言，您可能一無所知。
相反，Web服務彼此是松散偶合的。連接中的任何一方均可更改執行機制，卻不影響應用程序的正常運行。從技術角度講，人們已轉向使用一種基于消息的異步技術來實現高可靠性的系統性能，通過使用諸如HTTP、簡單郵件傳輸協議(SMTP)以及至為重要的XML來實現統一的連接。
消息傳遞系統將通信的基本單元打包成自我描述型的數據包（又稱作消息），并將其放到網絡纜線中。消息傳遞系統與分布式對象系統之間的本質區別在于：要求發送方辨識接收方的基本結構的程度有所不同。在分布式系統中，發送方需對接收方的情況作出種種猜測：應用程序是如何激活或拆包的，調用的是什么樣的界面，等等。
另一方面，消息傳遞系統會在纜線格式級上創建合同。發送方既不需考慮消息被接收后的情況，也不需考慮接發雙方之間的通信情況，唯一需要考慮的是接收方是否能辯識發送的消息內容。
在纜線格式級上創建合同的優勢不言而喻。例如，接收方可在任何時刻進行更改，而不會干擾發送方的消息發送，只要它仍可辯識原有消息的內容。另外，發送方無需任何特殊的軟件即可與接收方通信：只要它發出正確格式的消息，接收方就可以響應。
.NET框架與XML之纜線級的XML：SOAP
實現Web服務的異類基本結構以及在整個Web中實現Web服務的關鍵，是實現支持簡單數據描述格式的技術。這種格式就是XML。Web服務必須使用XML來完成三件事情：基本的纜線格式、服務描述以及“服務發現”。
SOAP：在通信的***級別，系統需要使用同一語言。特別，作為通信雙方的應用程序需要遵守同一套通信規則：如何表示不同的數據類型（例如：是整數還是數組），以及如何表示命令（即：需要對數據進行何種操作）。另外，在必要的時候應用程序還需對該語言適當的擴展。簡單對象訪問協議(SOAP)是XML的實施工具，它提供了一套公共規則集，該規則集說明了如何表示并擴展數據和命令。
Web服務描述語言(WSDL)。雙方應用程序在得到了如何表示數據類型和命令的規則后，需要對所接收的特定數據和命令進行有效的描述。僅僅說已接收到整數是不夠的；比如，在接收到兩個整數后，應用程序必須明確表述它可以對這兩個整數執行乘法運算操作。Web服務描述語言(WSDL)是一種XML語法，開發人員和開發工具可使用它來表述Web服務的具體功能。
“SOAP發現”：在***層，還需制定一套如何定位服務描述的規則：默認情況下，用戶或工具能在什么地方找到服務的功能描述？依據“SOAP發現”規格說明中提供的規則集，用戶或開發工具可以自動找到服務的SCL描述。
一旦實現了這三種功能層，開發人員便可容易地找到Web服務，將它例示成一個對象后再集成進應用程序中，繼而構建出一個具有豐富功能的基本結構。這樣，得到的應用程序便能與Web服務進行反向通信了。
.NET框架與XML之.NET框架：Web服務引擎
很顯然，許多基本結構都需實現上述進程對開發人員和用戶的透明化。.NET框架提供此基本結構。從.NET框架角度看，所有組件都可以是Web服務，而Web服務也僅是一種組件。實際上，.NET框架提取出微軟組件對象模型(COM)的精華，將它們與松散耦合計算的精華有機地結合在一起，生成了強大、高效的Web組件系統：簡化程序員的“管道”操作、深入地集成了安全性，引進了基于互聯網的操作系統，極大地改善應用程序的可靠性和可擴展性。
.NET框架包含三個主要部分：公共語言運行時、具有多層次結構的統一的類庫集合和高級版“活動服務器頁面”（又名ASP+）
公共語言運行時
此名稱不能準確反映它的全部功能。實際上，公共語言運行時在組件的開發過程中以及軟件的運行過程中，都扮演著非常重要的角色。在組件運行過程中，運行時負責管理內存分配、啟動或取消線程和進程、實施安全性策略、同時滿足當前組件對其它組件的需求。在開發階段，運行時的作用有些變化：與現今的COM相比，運行時的自動化程度大為提高（比如可自動執行內存管理），因而開發人員的工作變得非常輕松。尤其是，映射功能將使代碼編寫量銳減，這些代碼是開發人員在將業務邏輯轉化成可復用的組件進行編程時所需的。
對編程語言而言，運行時這個概念并不新奇：實際上每種編程語言都有自己的運行時。Visual Basic?開發系統具有最為明顯的運行時（名為VBRUN），Visual C++?跟Visual FoxPro?、Jscript?、SmallTalk、Perl、Python和Java一樣，有一個運行時MSVCRT。NET框架的關鍵作用是它提供了一個跨編程語言的統一的編程環境，這也是它能獨樹一幟的根本原因所在。
統一的編程類
.NET框架中的類為開發人員提供了一個統一的、面向對象的、層次化的、可擴展的類庫集(API)。現今，C++開發人員使用的是微軟基礎類庫，Java開發人員使用的是Windows?基礎類庫，而Visual Basic用戶使用的又是Visual Basic API集。簡而言之，.NET框架統一了微軟當前各種不同的框架。這樣，開發人員不再需要學習多種框架就能順利編程。遠不止于此的是，通過創建一個公共的跨編程語言的API集，.NET框架可實現跨語言繼承性、錯誤處理功能和調試功能。實際上，從Jscript到C++的所有編程語言，都是相互等同的，開發人員可以自由選擇理想的編程語言。
高級版“活動服務器頁面”(ASP+)
ASP+是使用 .NET框架提供的類庫構建而成的，它提供了一個Web應用程序模型，該模型由一組控件和一個基本結構組成。有了它，Web應用程序的構建變得非常容易。開發人員可以直接使用ASP+控件集，該控件集封裝了公共的、用于超文本標識語言(HTML)用戶界面的各種小組件（諸如文本框、下拉菜單等等）。實際上，這些控件運行在Web服務器上，它們將用戶界面轉換成HTML格式后再發送給瀏覽器。在服務器上，控件負責將面向對象的編程模型呈現給Web開發人員，這種編程模型能提供面向對象的編程技術擁有的豐富功能。ASP+還提供一些基本結構服務（諸如會話狀態管理和進程循環），這些服務進一步減少了開發人員要編寫的代碼量，并使應用程序的可靠性得到了大幅度提高。ASP+還允許開發人員將軟件作為一項服務進行傳送。通過使用ASP+ Web服務功能，ASP+開發人員只需進行簡單的業務邏輯編程，而由ASP+基本結構負責通過SOAP傳送服務。
盡管ASP+還未正式發行，但它已在改進應用程序功能方面創造出令人難以置信的奇跡：在現有基于ASP的應用程序性能基礎上，性能優化了三倍之多，更為激動人心的是生產效率再度攀升。
.NET框架的核心要素
.NET框架有幾個要素值得一提。首先是它的安全系統和配置系統。這兩個系統協同工作，有力地遏止了運行不安全代碼的可能性，并大幅度減少了號稱“DLL Hell”的對應用程序進行配置時所面臨的挑戰。
安全系統是一個高度細化、基于事實的系統，它賦予開發人員和管理員多種代碼處理權限（而不僅僅是“on”或“off”）。將來，還會根據代碼本身的核心要素來決定如何實施上述權限。
例如，當.NET框架應用程序被下載到某一系統中時，它會申請一組權限（諸如對臨時目錄的寫入權限）。運行時將收集有關應用程序的事實信息（諸如：它是從何處下載的、是否用了有效簽名、甚至它訪問系統的準確程度），并按管理策略決定是否允許應用程序運行。運行時甚至還可告之應用程序它無法授權申請的所有權限，并允許應用程序自行決定是否繼續運行。
有這種安全系統作保障，許多應用程序配置問題便會迎刃而解。開發人員和管理員（最終是用戶）所面臨的***挑戰之一是版本的管理問題。如果在您新裝了某個應用程序之后，一切都限于癱瘓狀態，而在這之前系統一直運行得非常良好，那么***的可能是新安裝的應用程序重寫了一些共享庫，并極有可能修正了現有應用程序正使用的程序錯誤。這種情況出現的頻率很高，以致人們將它稱為：“DLL Hell”。
.NET框架擁有的幾項高級功能可以徹底消除“DLL Hell”現象。首先，它有一個非常強大的內部命名系統，能夠有效地防止兩個庫因互相重名而被錯當為對方的情況發生。除此之外，它還提供一項被稱作“并行”配置的新功能。如果前例中新安裝的應用程序確實重寫了共享庫，現有應用程序可對該庫進行修復。等現有應用程序再次啟動時，它會檢查所有的共享文件。如果發現文件被更改，同時這些更改又是不兼容的，則它可以請求運行時提取一個它可以使用的版本。得益于強大的安全系統，運行時可以安全地執行該操作，這樣應用程序就完成了本身的修復工作。
.NET框架與XML：結論
人們總是喜歡不厭其煩地發表諸如“互聯網改變了一切”的陳詞濫調。同樣地，在談論互聯網給人類帶來的影響時，總是情不自禁地使用廣告式的夸張語，以表達對互聯網的推崇。不過，互聯網的確徹底改變了應用程序的開發模式和配置方式。將傳輸軟件演變成一種服務還有待人們的共同努力，XML是實現這個夢想的重要手段。.NET框架是微軟開發人員戰略的核心內容，它旨在幫助開發人員輕松地構建、配置和運行Web服務。
【編輯推薦】
