微軟最新卓越工程師：Anders Hejlsberg 的演講

作者： 發表日期：2003年3月17日 主持: 女士們，先生們，請歡迎最卓越的工程師：Anders Hejlsberg (掌聲) Anders Hejlsberg: 謝謝。在開始今天的題目之前，我想先帶大家回顧一下歷史，從早期的計算到現在我們到了何種狀態。我相信如果我們回頭看一下電腦與分佈式套用，你將看到每十年左右都會有變化。回到70年代，你知道，幾乎所有的計算都執行在一台伺服器上，她被放在後面的房間裡，然後前台有傻瓜中斷以合適的協議與它相連。 到了80年代，你會發現，套用的重心開始轉移到客戶端，文件伺服器只是提供文件的分類存儲。很多計算不是在伺服器上實現的，而是在客戶端實現的。 現在到了90年代，網際網路的時代，套用的重心由轉到了伺服器端。網際網路就好像是一個舊的IBM的3270終端，只是你會聯結多個網站而不是一個放在房間後面的伺服器。當然，HTML是一個更豐富的協議。 現在，人們開始談論也許現在該轉向另一個時代，趨向於客戶端，在這一個點到點的計算時代。但事實上，我們相信現在是一個最終走向平衡的時代。我們將同時計算放在伺服器端，也會放在客戶端。我們將依然會做很多是在伺服器端，先我們現在一樣，同時我們也會利用技術的革命，比如手寫體識別技術與語音識別技術，將套用放在客戶端。 換句話講，我們將擁有兩種最佳的計算世界。這也是一個理由，我們相信會有一種更豐富的協議，一個構架，允許我們擁有兩端智能的套用，那就是XML與 Web 服務。 關於XML Web服務的一件事，當然，是一個自然的轉移，讓我們來看.NET：是一個在何時何地都可以訪問的信息。但不管你問誰，它都是一組分佈式的計算，一個分佈式的套用，一組連接的套用。並且我們相信，XML與web服務將成為這些分佈式套用的連接架構。當然，隨著這自然變化，將帶來一組工具的變化。 讓我們來看，我們現在在哪裡。是一些有歷史意義的一些工具，從幾十年前的本文模式的套用，到圖形界面的套用，到現在領導網際網路的一些工具。還有今天我們要談到的有創新意義的一組工具.NET 框架與Visual studio.NET. 當我們發佈Visual studio 6.0，那已經是三年半，四年以前，我們知道我們新增了一組極好的工具，可以使客戶新增很好的套用，但我們知道我們可以在開發工具方面可以做得更好。 例如，我們意識到新增分佈式的套用於連接這是套用非常複雜。如果讓我們來看那些新增分佈式套用與連接分佈式套用的技術，而且我們至今還再用者的技術：DCOM, Corba, IIOP, RMI. 我們知道那是一組字串串，但非常難開發與維護。我們知道我們可以做得更好。 我們也知道我們有很多很難的編程模型，與很多很難的編程語言難以集成。你知道，我們有Visual Basic與C ,ASP等等。我們知道我們的面向對像系統，COM, 在許多方面不夠豐富來新增今天人們想新增的套用。COM不能夠支持一些關鍵的面向對象的的概念，例如繼承與多態，同時我們知道，COM太複雜了。COM是一個非常低層的二進制標準。你不得不自己做很多整理工作，例如擔心結果，與增加refs, release, GUIDs等等。 同時，我們與W3C聯盟一起在XML的標準之上的工作中，看到一些網際網路上跳躍式的發展，並知道將有一組新的套用將在此基礎上建立。 但看看所有眼前的事實，我們不可能只是通過修改一下COM，DNA就能有革命性的創新。我們知道，我們需要新增一個新的平台。 這個平台就是.NET 框架。她是一個內裝支持XML web服務，統一我們所有編程模型，並能大大簡化開發，提供了一個強大的，持久的，安全的執行環境，支持多種編程語言，並最終允許我們將原有投入精力寫的程式碼得以集成。 現在，在我結識如何構建這一框架，以及詳細介紹之前，來讓我給你們看一下這個框架的示意圖。 她開始於底層的操作系統，在操作系統之上，我們叫他「通用執行時」(common language runtime) .這是一組組件，在平常的工作中看不到。她提供了所有核心的服務比如類庫載入，編輯，意外處理，垃圾收集，安全性，等等，等等。所以它是一個黑盒子，讓你可以在.NET世界裡執行程式碼。 在通用執行時上面是一組類庫，開始於基類庫，它提供一組最通用的功能比如：文件輸入輸出，串處理，例如訪問TCPIP等等。 在這之上，我們有ADO.NET，這是下一代的支持XML web 服務的ADO版本，我們的XML堆(stack)開始於一個低端的XML parser, 通過一個與W3C DOM相容的XML 文件模型工作，並且也支持X-PATH於一組其它的XML標準。 在類庫上面有兩個框架。我們有伺服器端的框架和客戶端的框架。在伺服器端，我們有ASP.NET, 我們的套用伺服器，Web forms, 那是一個在ASP.NET裡寫表單的編程模型。她支持Web服務與移動網際網路工具集，並且允許你為移動設備新增UI. 在客戶端，我們有Windows Forms, 你可以把它當作把Visual Basic 表單與MFC放在一起的一種革新。你可以在Windows表單世界裡，將最優化的兩種特徵兼顧。 再往上，我們可以看到叫做通用語言規範，它是一個標準，是所有的語言必須支持一個最小的功能集合，以便於所有語言可以執行在.NET通用執行時上。 並且我們提供了支持這種通用語言規範的四種語言：Visual Basic, C , C# 與 J#. 但實業界的合作夥伴正在新增，你知道，到目前，我們已經有超過20種的語言支持通用執行時。 最終，當然，支持所有功能特性的是Visual studio.NET. 那麼現在來看一下我們如何新增這一開發工具以及何種動力產生了這一框架。 談到這裡，讓我們看一下我們為什麼會有這麼多的複雜的編程模型，糾其原因，其實都是一個歷史程序，讓我們來看我們如何編寫Windows套用的。讓我們回溯到10或甚至15年，寫一個Windows套用，實際上只有一種方式來做。你會啟動你的C便一起。你可能會：include Windows. H. 你會翻開書，你會寫Win cross與Windows 消息處理器。那些都非常複雜，並且沒有工作效率。 然後，隨著時間的推移，我們看到一些不同的編程模型。例如，Visual Basic 開創了一種快速開發方式，利用表單來設計程序，用這種方式，你知道，可以從一個工具面版上拖放「控制」放到一個表單中。然後你可以寫一些時間處理器，使得程式碼都放在後台。 但C 就走了另外一條道路，利用MSC與ATL. 這裡我們用一些不同的範例，如Sub classing. 當然，這樣使你更輕大，並可以更好的表示，但他當然沒有Visual Basic使用起來容易。 最近，隨著網際網路的發展，我們看到一整套新的編程模式的崛起，圍繞在伺服器端執行的HTML頁面，與ASP編程模型。 然後你一定會想像，我們會繼續下去，並且將有一種新的編程模型來寫Web服務，與一種新的編程模型來寫移動UI, 但是有一個不幸的事實。一個是你不經意間選項的編程模型會決定你選項編程語言。 例如，如果你想到MSC, 如果你是一個VB的編程人員，並且有一些MSC或ATL你想使用。她不只是一種簡單的可能。反之，VB表單只能從Visual Basic中得到。如果你想寫一些HTML 頁後面的程式碼，你只能用描述語言。 另外一個問題時，每種不同的編程模型，都對通用的問題有著不一樣的解決方案。例如， 在不同的編程模型中，對於文件的輸入輸出，就有不同的處理方式。 現在，.NET 框架所作的事情，就是統一這些編程模型，提供一種一致API，不管你所用的語言，也不管你用了何種編程模型。 現在，我來講以下.NET框架的另外一個目標是大大簡化編程。在這裡，.NET框架提供了很多方式，我不能夠例數所有的方式，但我放了一些重要的在這張幻燈片中。 首先，我認為.NET框架所作的是提高了抽像層。如果你今天來看COM, 他是一個非常低級的二進制標準。我不知道你們是否作過C 與COM的編程，它是可怕的。你知道，你不得不處理H結果與GUIDs與增加refs與release, 直是到處都有豐富的機會來藏有bugs. 正向我所說的，COM在今天來看，並不足夠豐富。她不支持核心的面向對象的概念。 .NET框架是你遠離這些麻煩，它只是完全自動的去處理這些事情，讓你可以從雜物中解脫出來，並集中思想到運算規則上。 另外一個問題是，.NET框架是如何統一編程系統的。在.NET框架中，每件事都可以看作是一個對象。甚至一個INT也可以看作是一個對象，或一個float. 沒有變量；所有都是對象。所以就沒有在Visual basic中在變量與對像中的二分法。將會有一個字串串綁定在整個平台，並且所有字串資料都是Uni-Code. 最後，這一平台提供了面向對象的編程或軟體組件的編程方式。例如屬性內容，方法，事件都是.NET框架中的第一級的結構。所以他不像如果你用C 來寫一個Active X 控件，你不得不用一些巨集來定義屬性內容，以及事件等等，這些所有的支持都內裝在.NET框架的開發語言中。 另外一點是：組織這些API的方式。過去人們用Win32API, 實際上是一個巨大的扁平的API. 那裡根本沒有任何組織。我們對這些30000個入口最好的辦法就是按照字母排序，但請看在.NET框架中，所有一切都被邏輯化的組織明且命名。所以如果你看到一些關於輸入輸出的東西，就可以去看System IO，然後你會找到叫」文件「的類庫，所以它可以很容易的帶你到你想要的地方。 另外一種方法來看是否我們簡化了編程，就看一下我們以前如何寫程式碼，現在又是如何寫程式碼。這裡是一些我喜歡的，一些例子，使用Windows API來產生Windows. 你首先使用Creat.windows.ex然後把它送給至少12個參數。然後你需要更新一下視窗，來顯示一下螢幕上的狀態。 對比一下你所做的，把它放在.NET框架中。你產生一個表單。你用了Caption,然後你顯示出來。 現在，你所做的許多都是一個VB程序員會做的事。「我們已經這樣做了好幾年. 到底有什麼新鮮花樣？「 我認為有幾個新的地方，對比今天的VB編程方式。首先，今天的VB,為了讓你容易得拿到APIs. 一些人不得不事先打包API把它變成COM APIs. 這也是為什麼VB有些滯後。通常，當新的API出來，他們首先是由C的編程方式產生，然後VB 工作人員再把它打包成容易使用的API. 第二個問題，當然，一旦這些APIs被打包，你就不能真的與其他人說相同的語言，因為別人在一個低級別的API上並且一些我的文件不能用，一些東西不能夠打包，因此你不得不丟到這些，或者那些，你喜歡的功能。 但我認為也許最重要的事我們-微軟將如何編輯這些API. 他不會是一些低級別的官樣文章。我們將把抽像層向上移，使新的API容易使用，程序員只需要關注於所要做的事情，也就是說不需要完全懂得所有的API才能夠寫最簡單的應用程式。 我認為另外一個重要的事情就是.NET框架提供了一個功能強大的持久地執行環境。在.NET框架中，所有對象都是自動地執行垃圾收集與記憶體管理。 現在，事實上，在COM與.NET框架中，記憶體管理是完全不同的。在COM中也有自動的記憶體管理。但它是用一個叫做reference counting的方法來處理，用這種方法來計數代表每個對象的reference的數量。如果沒有遇到一個難題，到目前為止他工作的非常好。這是一個循環reference的問題。如果你有兩個對象，每個都有一個reference指向對方， 而對於記憶體管理來講，這些對象就始終是活的，然而沒有其他reference他們並且你產生了一些記憶體島，永遠不會被收集。 .NET框架使用不同的技術來實現記憶體管理，叫標記(mark)與清掃（Sweep）, 我不打算將太多細節他是如何工作，但最根本的他完全解決了reference counting的問題。 另外一個提供強大執行環境的關鍵是意外處理。你已經熟悉了在VB中的「on error go to」,它確實是提供了一些少量的結構化的錯誤處理。但仍然有些錯誤處理會更複雜，當一個錯誤出現在.NET 框架中，每個意外處理都會帶有一個錯誤描述信息。你可以獲得一個錯誤信息堆棧，並能精確知道什麼出了錯，並錯在哪裡。 在.NET框架中也許最重要的錯誤處理就是強制性的處理。 如果你們看一下，傳統的Windows API是如何工作的，所有語言是如何工作的，比如C, C 等等，錯誤處理總是一個隨意的事情。一個API也許可以返回一個錯誤程式碼或一個結果程式碼來說明這個API是工作還是不工作，但除非你會寫一些程式碼來檢測這些錯的結果，你知道，否則任何事都不會發生。事實上，你的套用將會處於混沌狀態，然後三個或四個API使用會啟動，因為一個空指針或者你沒有任何想法如何結束。 不只是意外處理。如果一個意外處理發生了，如果你的套用沒有處理這個意外，然後你的套用就會關掉。他們會有序的關掉，並提醒你，你有豐富的時間去解開現有的狀況等等，但我們最終不會陷入混沌，這樣就會減少很多bugs. 類型安全是另外一個帶來強大的原因。在.NET框架中不會有不安全的類型表。你不會產生某一個類型的指針指向另外一個類型，執行引擎會簡單的拒絕她。不可能有位啟始化的變量。你不可能索引，超出他的邊界的數列等等。 一個關鍵的功能就是我們的零衝擊安裝功能。這時，事實上是我喜歡的功能之一。在.NET框架中，絕對不需要為了執行而註冊的說法。你可以產生一個子目錄，把套用拖到哪裡，執行他，當執行結束，你就可以刪除目錄，不管你在什麼電腦上執行，都不會留下痕跡。 （歡呼，鼓掌） 這不是說你的套用不能共享信息。我們也支持另外一個模式，當我們安裝進一個global assembly cache, 正如我們所說的，然後套用可以共享類庫。 另外一個關鍵，我認為，在.NET框架中的革新是Side-by side執行，這允許你可以在相同套用利在你的電腦上執行與安裝不同的版本程式碼。你可以有套用版本1.0，套用版本2.0 並且你可以並行執行他們。你甚至可以在相同的工作中執行從這些套用中出來的對象。 這也就意味著，你不再有哪些DLL hell問題，當你安裝一個新版本的DLL, 你的套用在從前的時候會因為它而終止。 而替代它的是，在.NET框架中，你的套用將繼續會根據版本而執行。所以，正像我所說的，你可以有一些資料庫支持的庫版本1.0，1.1 與2.0, 各種不同的套用可以繼續使用不同的版本，因此預設情況下當你在機器中安裝了新的撓τ茫仍j撓τ靡膊換嶂卸稀?br /> 所以.NET框架是一個多語言的平台。從最初我們設計這一平台，我們就知道我們想要在這一平台上支持多種語言。對我們最重要的不是讓人們只學一種語言，而是讓他們可以利用以前他們已經知道的編程語言經驗，並且已經編寫的程式碼。 另外一個關鍵，.NET框架中所支持的語言都是一流的。我提到過一些早期的事實，API不能用於今天的VB如果他沒有第一時間打包成一個COM對象。這在.NET框架張絕對不成問題。任何API發佈到.NET框架中，都可以立即被VB或任何在這一平台上實現的編程語言來使用。 事實上，我們的集成能力已經遠超過我們現在所看到的。例如，你可以用一種語言寫一個類， 從另外一個語言中繼承，並且從第三種語言例示。這種集成能力可以如此之深。 當然，它也意味著你可以高度整合這些開發工具。你實際上只需要一個集成的開發環境，一個Debugger來使用這些多語言。 現在我們提供了5種語言：VB, C , C#, J# 與JavaScript 或者Jscript. 但是在業界，學術界，有很多其他語言被開發，以及正在開發，包括一些語言如：Cobo, Fortran 與APL. 現在，我曾經提到.NET框架允許你高度的集成存在的程式碼。因為你的所有語言都新增在這一公共的基礎之上，叫做.NET框架的公共基礎之上。你可以看到.NET框架在語言之間的集成能力是比我們以往所見的任何架構都強。 其實在性能上，能力上，在這一平台上寫一個Visual Basic或C#或Jscript 或任何其他這一平台支持的語言都沒有太多差別。 但是在現實世界裡，只是語言的互操作是不夠的。當然，有很多程式碼不是為.NET框架寫的，我們也希望能夠完全的利用上，所以.NET框架提供了在DLL之間的互操作性，在DLL中的程式碼，通過一個叫做 P 使用, 來實現DLL與COM或OLE自動對象的互操作。事實上，任何你在.NET框架中寫的程式碼都可以在框架之外看作是一個COM對象，反之亦然，任何COM對象，可以自動輸入到.NET 框架中，被看作是一個類放在哪裡。 然後最終，我們通過XML和SOAP，我們提供了可能是最好的，最靈活的方式來在異類的系統中集成。 所以有很多互操作簡單的內裝在裡面，因為我們相信摩爾定律－－至少在我的思想中，摩爾定律已經離我們很遠。我們會如何以用Gigaherz的CPU與512 megabytes的記憶體？回溯以前６４K或640k的記憶體，你也許每次都會感到困難，也許要花六個月來寫一個程序來利用所有的機器容量。你已經遠離那個時代。但今天，你不會與要這樣的問題，我的意思是，客戶期望越來越多的容量，好像用不完的容量，我們不得不找到方法來利用以前已經寫過的程式碼。 所以，我轉移一下話題，來談一些web service. 關於web service的革命，我認為我們正在當中，Visual studio.NET與.NET框架，會將起重要作用。 在我們做演示之前，我想講幾張幻燈片來解釋一下我所認為的web service. 實際上簡單得像可以認為它是一個花生殼，如果HTML是使人與機器可以交互溝通的話，XML與SOAP就是關於機器與機器的溝通機制。更精確些，它是一個相同的結構。 現在我來講一下，傳統的分佈式計算，是如何利用DCOM, Corba, RMI等等來連接套用。 那什麼是web service來提供的更好的技術來寫這些分佈式的套用。 我認為有三個關鍵的因素。首先，XML web service充分利用了Web. 他們有著與新增HTML套用相同的架構。所有在網路上傳遞的一切都是通過HTTP協議。所有都一樣。唯一改變的就是web service 替代了傳遞HTML, 你在HTTP基礎上傳遞XML. 當然，這樣就給我們很好的機會可以利用以前的web 套用，使原來的web 套用變成web service 也許只需要簡單的增加幾行程式碼，或一頁程式碼在網站上。 第二件事情是，web service可以使你真的可以在異構系統集成。任何種類的套用結構都必須支持的異構系統環境的集成。你不需要要求套用的兩端都執行在相同的OS上。你甚至於不需要套用的兩端都用相同的中間件。有了web service, 你的套用的一端可能是在.NET框架上，套用的另一端可能是執行在Apache server上，執行著perl script，但輸出XML的資料格式。 最後一件事，我認為web service允許你新增真正的可擴展的套用。再次，讓我們看一下傳統的分佈式套用技術。他們都用了所謂遠端使用的技術如：DCOM, Corba等等，他們真的使得這個世界看起來像是面向對象。她正好是一些對像執行在這台電腦上，一些對像執行在另外一台電腦上。但是這個架構只有在內部處理通訊，在一台電腦上，或在一個本機的內部網路中，它可以執行得很好。但當你開始擴展你的套用時，比如你的客戶端在舊金山，而你的伺服器在紐約，你就會出問題。因為在這種舊的技術中，它基本上是，試圖隱藏一個事實，你的套用不能夠足夠分佈，當分佈的距離分佈到無限的網路上時，就會出問題。當你提出一個使用，但需要等很久，你不得不持續保持呼叫狀態，但這真者的會傷害到可靠性，因為你不可能fail over. 而且你也不能做一些饒舌的溝通當你在使用一個對像時，對方回話後然後離開。「噢，謝謝」「噢，別客氣」等等。當你在一台電腦上這所有一切都會很好，，但是當你要對東海岸對話時，你真的需要瞭解對方的狀況時，光速就會出現問題,。 現在，對比XML web service, 有很好的證據存在著，它可以擴展到任何你以前達不到的地方。因為我們已經今天在HTML上看到了很好的擴展。正如我所說的，我們改變的只是傳遞的東西，從前是HTML, 現在是XML. 但所有的架構都一樣。我們知道如何擴展，我們知道它可以擴展。 所以什麼是web service的基礎？當然，它起源於唯一的有網際網路提供的通訊，在這一通訊機制上，我們存儲通用的由XML提供的資料結構，XML可用來傳遞任何資料。 現在，在XML之上我們有很多變化了的協議，我們有XSD來描述類型。我們有SOPA來描述交互或web service的使用。我們有WSDL, web service 描述語言來描述web service. 我們有發現協議。 在這之上，我們有web service的黃頁，註冊的服務叫做UDDI. 現在，最關鍵的就是我們有簡單的開放的標準，並且有廣泛的業界支持。這些都不是微軟制定的標準，這些標準是我們與業界合作夥伴以及與標準組織如W3C合作新增的 所以一個web service 是如何工作的？讓我來舉例，假設我是一個web service的消費者，我想使用web service. 首先，我會找到我想要得web service. 我不得不在web service 世界裡去尋找。我可以有幾種方法。我或者到UDDI去找，或者到特定的業務區域裡去尋找。這些特定的區域支持特定的schema，資料按各種方法排序。但通常，我會的得到一個連接，一個web service描述語言文件，告訴我關於我所找到的web service. 或者我也可以直接找到我要找的web service的組織，說我已經知道他們的網址，並且獲得了disco我的文件或一個發現我的文件，它基本上是一個目錄，所有的web service都在這一位址上。 另外一個狀況是，我最終找到一個WSDL文件或者一個Web service描述語言，或者我找到了一個連接，這個連接可以讓我找到WSDL文件。通過這個文件，我可以知道如何與Web service通訊，最後一步就是利用基於XML的SOAP協議來與這個服務對話。 現在，在幻燈片最上面的三個步驟是設計時步驟，如果你願意，沒有任何步驟在執行時發生。只有最後一步是在執行發生。但所有以上三步都完全支持Visual studio. 我可以從Visual studio中找到UDDI的註冊處。我可以獲得Discovery(發現)文件或者一個WSDL文件，並且Visual studio自動為我產生web service的代理服務。以便於我只需要簡單的使用一個方法，帶來一些參數，然後所有的基礎結構的事情被自動處理了。 這也就是什麼是web service. 現在，我們來看一下，.NET帶來了什麼？如果來看一下你是如何開發套用的，有一些概念在你的開發程序中一直是通用的。你的套用趨向於處理資料。並且趨向於結構化這些資料。你的套用完成一些服務，例如，套用的功能，有一個政策是關於套用是如何使用的。 現在，讓我們來看一下web 上已存在的標準，或者存在的，或者即將出現的。資料可以描述成XML. Schemas可以描述成XSD. 服務可以描述成WSD，使用可以使用SOAP協議來實現。 但當你寫程式碼時，你真的不知道XML與XSD等等。你知道更多的是關於的資料，與你的對象。對於你的Schema你可以把它看成是這些對象的類。對於你的服務，也就是你的套用的方法，或者是你的套用的功能，也就是說，使用就好像是使用這些方法。 然而，.NET框架的價值就是給你提供這些概念的雙向映射，這些概念就是你作為一個程序員已經知道的概念，與今天現在在網際網路上已經存在的概念。 所以.NET框架可以把，例如，任何對象，自動轉換成XML，反之亦然，它可以把XML再轉回成對象。另外，它可以把一個類，產生一個XSD結構的Schema，相反它也可以把一個XSD的Schema轉換成類。 所以基本是，.NET框架可以讓你是用你已經適應的編程術語，框架自己回去處理與網際網路結構的映射。 為了說得更清楚些，這了讓我給大家演示一下，web service是什麼樣的。比如說，我寫一個訂單處理的類，它有一個提交訂單的方法。並且提交訂單會帶來一個購買訂單的對象。為了把這個轉成一個web service, 我實際上不需要修改程式碼的任何部分，我只需要給這個程式碼家一個屬性內容，一個 Web method 的屬性內容，它告訴系統，請把這個方法發佈到網際網路上。 現在，我也許實際上想再多加些程式碼，比如控制這個XML 可以跨越有線網路，所以我可以給我的購買訂單加一些屬性內容，來指定當這個對象轉換成XML時，請把它放到XML的命名空間。對我的對象的每一個域，我可以指定我是否讓他映射到XML屬性內容或到XML元素。 但是這裡關鍵的是，我可以寫一些程式碼像現在這樣，我也可以用另一種語言來寫他，例如，這裡我是用C#來寫Web service的，我可以在客戶端用VB的程式碼來使用他。當我做了一個新的購買訂單後， 我可以讓他把東西寄給我，然後把帳單寄給Bill，並且要今天做，然後提交訂單。 來看看，當我做這些時，.NET框架中會發生什麼，它把這個使用轉換成SOAP格式化的XML, 傳遞SOAP信封，把它嵌在對像中透過網路傳遞到web 伺服器。在web 伺服器端，也就是說，重新新增這個對象，完成工作，把已經轉換為XML的結果發回來，回來之後，變成對象，再返回給我的客戶端。所有這些都是自動的。 事實上，讓我們來看一個小的演示。 現在你可以看到這個平台的一些令人不可置信的功能。下面15分鐘我將作一些有關.NET的事情。首先， 我將新增一些web service. 然後我將用我的瀏覽器測試這個web service. 然後我會給這個web service加一些資料訪問邏輯。最後我要新增一個豐富的客戶端，一個web service的客戶前台。最後我要實施這個豐富的客戶端套用。 讓我們開始。只是先讓你們看看，這裡絕對沒有魔術或者字串串放在這裡，我將用我最喜歡的編輯器，Visual Notepad, 然後，盡量簡單的寫幾行程式碼。現在我啟動我的書寫板，然後寫個Web service的程序在這。 現在我們開始寫web service. 我喜歡用一下C#， 然後我把這個類叫做「my service」 現在，我寫一個頭，告訴ASP.NET， 這個文件包括一個web service. 剩下的文件就簡單得像一個通常的C#文件。這裡我可以說，用一下system.web.servcie 然後我可以寫我的類：publice.class.my.service. 然後我產生一個方法，這個方法是將兩個整數相加，然後返回給我結果。這實際上就是我的web service的全部程式碼。 現在，我唯一需要做的事就是，我需要告訴系統請把這個方法作為一個web service 發佈出去，為了做到這一點，在我剛才的時候已經說過，只是簡單的在這個方法上加一個web method. 現在我們存起來，並把它叫做demo.asmx. 現在讓我們啟動瀏覽器。然我來試試，點擊這個web service. 所以我要到localhost/demo/demo.asmx 然後只需要退後，看看什麼發生了。 首先，當我點擊web 頁面，ASP.NET每次都會首先看一下這是不是第一次我點擊這個web 頁面，它是否編譯成IL. 現在發生了什麼，首先，我寫的類，自動被ASP.NET編譯。第二件事，ASP.NET注意到我是從一個瀏覽器端訪問的，是從一個web service的客戶端訪問的。然後她會為這個web service自動產生一個測試頁。現在來看一下測試頁。有一個add method在這裡，我只需要直接使用這個add method, 通過輕輕點擊，然後測試頁就會讓我輸入兩個參數，X與Y. 所以讓我來輸入32 和10，然後我們使用這個方法，這是這個方法就執行了。她計算的結果是42， 然後他自動被作為XML傳遞後來。 所以web service 很像一個簡單的花生殼。 現在讓我再回到這個測試頁。你會注意到不僅ASP.NET自動彈出這個測試頁。並且他還會在我的web service 上做一些分析。來看一看他是否遵守所有網際網路上的標準。然後他發現，我沒有把web service放到一個XML的命名空間，如果我是一個習慣良好的開發人員應該做這些。接下來，它會建議我應該修正我的程式碼。然後我說好吧，我只需要拷貝貼上一點更正就可以了。所以我只是抓取他，然後返回我的web service.然後我貼上，使得這個web service放到一個命名空間。 現在，現實是通過網際網路來做一個簡單的數學運算是很沒效率的一件事—在大多數情況下，人們可能是通過網際網路來取一些資料。但是當我來看人們是如何在他們的套用中來新增資料邏輯時，我會發現她好像來源於兩種不同的學校。一種模式是，你會把你的資料當成一個對象。你會有一個客戶對象，一個訂單對像等等。你從資料庫中獲得對象，然後你給你的對象產生一個實例，然後你把資料放在那裡，然後你在上面操作。 另一種模式，你只是簡單的存放這些資料在他的表格中。你知道，今天，它就是記錄集。在ADO.NET中它叫做資料集。但基本上，你會認為它是一筐資料。 下面我要演示我們是如何將兩種模式都支持的很好。先讓我們來看一下把新增資料訪問看成是對象的方式。然後，事實上，在我的web service裡，我會新增一個資料庫連接，然後我把它叫做web service. 然後我把它作為一個對象。 接下來，首先我會貼上一些東西，省得我來寫所有的程式碼，一個叫做聯繫人的類，包括一個名字，位址，與電話號碼。然後我產生一個web service. 它可以返回一個聯繫人的列表， 我只是把它貼上上來。 現在，當然，在現實世界中，你不會只是簡單的使用這些對象。他們會產生一個資料庫。我只是想顯示，web service能夠返回一個結構化的資料，並且可以操作他。這裡你看到我通過我的使用方法，可以返回一個聯繫人的陣列的對象。 讓我們來試，並且存一下。然後我們回到我們的測試頁，我們只是簡單重新整理一下測試頁。然後你看到發生了兩件事。首先，ASP.NET發現我的web service文件修改過了，所以他重新編譯。她產生了一個新的測試頁。在新的測試頁裡，原來在底端提示的錯誤信息沒有了，因為我修正了丟失了的命名空間，我現在有一個連接，這個連接是到一個我寫的附加的方法。Get contacts 方法。然後我試著點擊這個連接，因為沒有參數，它只是讓我簡單的點擊使用按鈕。 這裡你可以看到結果已經被格式成很好的XML. 請注意這裡，我絕對是什麼都沒做，它就將聯繫人的對象轉換成一個XML, 這裡他是一個聯繫人的陣列，在這個陣列裡，每個聯繫人都有名字，位址，電話號碼。所有這些都是自動完成的。 曾經有些人與我爭論，他們希望這個聯繫人的資料庫，每一個聯繫人不要通過XML元素來傳遞，最好使用XMl屬性內容來傳遞。 現在，我們回去，然後加一些指示在這裡，來控制產生XML的形式。為了做到這一點，我首先使用：system.xml.serialization 然後在我的對象的域上加一些屬性內容，實際上我們是把XML域轉換成屬性內容，而不是元素。在名字上做這些，然後我們做其他的， 我們只需要拷貝，然後貼上，然後我們把這個對象的位址域轉換成adder屬性內容，然後把電話域轉換成ID屬性內容。 然後我們存起來。我們回到測試頁，然後我們重新整理我們的web service的結果，它將重新使用web service. 新的格式出現了。這時，你發現XML的格式奇跡般的從使用屬性內容，轉換成了元素。所以你可以看到這個工具給了你超強的控制能力。 現在，另外一個傳遞資料的方法，或者是套用操作資料的方法，只是產生和返回一個完全的記錄集，它基本上反映了一個sql 查詢的結果，我們當然也可以在web service裡實現。事實上，只需要回去，再讓我家一些邏輯在這裡。首先，我將加幾個使用子句，然後輸入進來資料命名空間。然後我們抓一些方法進來，貼上在這裡。這是一個小的方法叫「get data」,它使用一個查詢字串串。然後她產生一個連接。她為這個連接產生一個適配器。然後她產生一個新的資料集，然後用執行的結果填充他。 然後我們存起來。然後回到我們的web service. 我們將再次重新整理這個測試頁。你發現他又一次編譯了。我們看到「get data「的方法，然後我們使用他。然後，當然，它需要我們填寫查詢字串串。然後我們敲入字串串。 我們寫：say select * from customers,然後我們安執行鍵。 現在，我們看到的是sql 查詢返回的一個XML格式的查詢結果。事實上，如果你往下看這裡，你會看到每個表的項，比如說有 客戶ID 與名字等等。但在這個XML的開始處有一個描述，描述這些資料的格式。所以這些資料不僅包括實際的紀錄， 他也包括一個描述，描述這些紀錄的意義。以便於客戶端套用理解如何顯示這些資料。 然後我們來試一下，新增一個客戶端的套用來使用這個web service. 所以我們關上所有的視窗，然後我們啟動Visual studio. 讓我們產生一個自己的項目。我們將產生一個Visual basic的windows表單套用。然後我們叫他客戶端。然後我們的windows表單設計器出現在這裡，然後我們試著來做一個客戶端的套用來使用我們的web service. 並將資料顯示在柵格裡。所以我們抓取資料柵格，把它放在我們的表單上。我們在抓一個按鈕過來。把它放在我們的表單的小面的角上，試著弄得更整齊一些。好了。 現在，為了使用這個web service, 首先我們加一個引用。在我先前提到過。Visual studio自動完成這些步驟，比如說輸入web service的描述文件，並且給web service提供一個代理。所以我們只需要簡單的點擊右鍵然後說「add web reference」 在這，我們只是點擊我們的web service. localhost/demo/demo.asmx 這裡，我們再看一下。服務做好了。我們只是加了一個引用並輸入他們。 現在我們可以寫一些按鈕後台的程式碼，這裡我們寫：「dim S as new local host.」 因為我沒有改變命名空間，我所引用的命名空間，依然是本機的命名空間。現在你可以看到web service上完成的語句。你可以看到my service對象，存放在本機的命名空間上。這正是我剛才寫的服務。所以我只是定義他為一個對象。 現在我可引用我的web service. 然後我所做的是「data grid one.data source」。所以通過我的get data 方法從web service上得到我的資料柵格。現在你可以看到我的任務完成了。她知道要去取一個聯繫人，一個get data的方法在哪裡。實際上，她知道當我點擊取資料，它會讓我輸入一個查詢字串串，所以我輸入select * from customers, 然後我會取出第一個表，從資料集裡出來的第一個表。不像一個記錄集， 他提出來的是多個表。我們只是選項第一個返回。 所以兩行程式碼來使用這個web service. 讓我們試一下，執行這個套用。當你按擊這個按鈕。這個結果作為xml格式返回，並且把資料放到了資料柵格裡。 現在，當然，你的工作不僅是寫一個豐富的客戶套用，你還得實施這個豐富的客戶套用。我們可以讓你很容易的在.NET框架上實施這些套用。實際上，你可以通過在一個web 頁上的一個連接來開發你的豐富的客戶端套用，我來演示以下如何做到這一點。 首先，我到我的項目裡。到我的屬性內容裡。然後我改變我的build輸出路徑，是網站的根路徑。所以當我新增時，Visual studio將一個exe拖進我所新增的web伺服器的根路徑。 所以我們新增， 然後我們再回到visual notepad， 我們將寫一些HTML的頁，連線到豐富的客戶端套用。所以我們啟動HTML頁。我們把它叫做H1. 以便於我們容易的叫他。然後我們說「點擊「然後我們產生一個H 引用到Client.exe, 他坐在web伺服器的根目錄下，所以點擊這裡，執行這個聰明的客戶端套用。我們把它關上，然後我們存出它，我們就叫他啟動HTML. 現在讓我們來啟動瀏覽器，然後點擊這個頁，我們到 localhost/demo/start.html. 在這裡，你看到一個web 頁，我剛才所寫的，連線到我的客戶端套用。所以當我點擊這裡時，所有這些都發生在同一台機器。但當我點擊這裡，我實際上是下在套用到我本機的機器。在網際網路下載快取區來執行他。 這時套用在執行，我可以點擊這個按鈕。然後他可以與web service對話。 現在你會問：「好吧，那安全性又是怎麼樣的？」 實際上，套用是執行在一個沙盒中，他保護你的使用你的web service，而不是來自於相同URL的其他web service. 他不能夠在磁牒上產生文件，等等，有一個整套的邊界在哪裡。為了顯示這一特性，我把它關上，然後回到Visual studio 然後，我來試圖在我的套用中加多幾個按鈕。然後我來寫一個事件處理器來試圖做些壞事。我們不打算做得太壞，所以我們只是在這個伺服器的根目錄下產生一個文件。所以我們只是簡單得說 system.IO.file.create 然後我們試圖產生一個log.txt在根目錄下。 我們build一下，然後會產生一個新的exe在我們的web服務的根目錄下。我們回來，啟動我們的web頁面。我們再次連接，他會下載一個新的可執行文件。你可以看到我們有了一個新的拷貝，因為我們有兩個按鈕。我依然使用這個web service. 但當我試圖在根目錄下產生一個文件，我得到了一個違反安全的警告。你看到，他說套用試圖要做些。。。。等等，這是安全政策所不允許的。 現在，有趣的事情是，我可以繼續執行，因為它都是通過意外處理來處理的。只是每次當套用試圖做些壞事時，他都會被停止。 所以在下面的15分鐘裡，讓我們快速回顧一下，.NET提供給了伺服器端，客戶端等等的功能。 事實上，.NET的核心原則是客戶端，伺服器端，服務端都可執政的政策。正像.NET框架為開發套用提供了核心的結構，目的就是這個方向，Visual studio.Net也是一樣，提供了完全的開發經驗。 在客戶端，比如說，Visual studio.NET允許你產生多種不同的客戶端套用，例如Windows,表單，正像你們剛才看到的，web 表單，或者是利用移動網際網路工具來產生前端的移動設備的套用。 在伺服器端，我們提供了為伺服器端快速的套用開發。 正如你們所用到的客戶端套用開發的技術：通過簡單的從工具版上抓取控件， 然後把他們拖放到表單上，現在伺服器端也可以做這樣的事情，比如抓去一個時間日誌，或消息貯列，放到一個商務邏輯設計器，然後用可視化的方式來新增你的商務邏輯。 我們在Visual studio裡有相當豐富的資料訪問能力。我們集成了資料設計器，查詢新增器，等等，來完善對.NET企業伺服器的支持。 並且，當然，你還看到了visual studio.NET對web service的支持，從web service的整個生命週期，從發現，使用，產生，註冊與實施。 現在，給大家近距離得看一下visual studio.NET， 我介紹一下Rob copelan 他是visual basic.NET的產品經理。 Rob Copeland: 早上好。你們今天早上已經看到了很多很好的東西。你們已經看到了用visual studio.NET以及.NET框架新增的一些套用。並且Anders 已經帶你們大致瀏覽了一下框架的強大功能，並且如何利用這些豐富的功能來新增套用。 我今天會花幾分鐘來看一下，Visual studio.NET 是如何簡單的開發那些套用。 我將啟動開發環境，並產生一個新的項目。所以我點擊新項目。然後她允許我選項我想要產生什麼樣的項目。 現在，我說，我想產生一個web service，然後返回一些關於書的信息。所以我點擊asp.net web service.然後我想，我將使用這個書的服務，然後我點擊okay. Visual studio現在將連接web 伺服器，為我產生一個套用的根目錄， 把那個文件放在那裡，然後我需要為了產生這個web service, 我開啟設計視圖。 現在，這個設計視圖是visual studio.NET的新功能。她可以讓我很容易的使用那些我正在開發的一些組件與淚。她與我們平常使用表單，拖拉拽方式很相似，拖拉一個組件，設定他的屬性內容，處理他的事件，不需要寫那些所有管道性的程式碼。我可以集中精力在我的商務邏輯上，我想要的程式碼由web service自動實現。 現在，Anders給你們演示了如何簡單的用XML格式從web service上產生資料，返回資料。 我會演示一個類似的程序，我將使用一些在visual studio開發環境中一些豐富的工具。 我將介紹一個visual Studio.NET的新功能，叫做服務瀏覽器。這個服務瀏覽器是一個很好的方法來從伺服器端取得資源，然後在此基礎上來編程。在這個例子中，有兩件事。當我有了資料連接，我就可以訪問SQL servers.以及其他類型的資料庫，我現在有一個服務列表，現在我只有一個在那裡，那就是我自己的機器，但我可以在裡面加其他的。 我想做的事情就是，當有些人使用我的web service時，我可以從SQL server上取資料，然後返回結果。 所以如果我展開這個節點，我會看到一個資料庫透視圖。以及連線與存儲程序。如果我擴展這個表，這有一個書的表。這是一個我想用到web service裡的表。我可以拖拉拽的方式，拖到設計界面。Visual studio.NETE會自動產生組件，這些組件是我所需要的，從SQL server中取出的資料。 在這個例子中，他產生了兩個組件：一個連接，他允許我連線到SQL server 然後在那裡執行指令，它叫做資料適配器。一個資料適配器就是用來做這些事情，他把資料從SQL server中取出，然後把它放在我想要的表單中，然後放在一個資料激勵。Anders剛剛提到過這個概念。 現在，正如我所說的，這在很多方面都很像表單，除了它真的是一個我所工作的類之外。 但它與表單相似之處，就是我點擊這個組件， 然後來到屬性內容視窗並給他們設置屬性內容。所以，例如，也許我不想讓我的web service叫做service 1。 他只需要簡單的來到屬性內容視窗來更改他的名字。我叫他書服務。 在預設情況下，我所產生的資料適配器，會返回所有資料。我真的不想要那麼多紀錄。我想讓一些人能夠告訴我需要有關書的什麼信息。 所以我回到屬性內容視窗，我可以點擊配置資料適配器連接，然後他會帶我到一個嚮導，嚮導會帶我做這些。她問我什麼適配器我想要。這裡只有一個，所以我就選項這個預設的。現在她問我我想怎樣更新我的資料，以及如何從我的SQL server取資料。按照預設方式，我選項SQL 語句，但我將選項產生一個存儲程序以便於我可以依賴於SQL server, 並且我可以得到更好的性能與可擴展性。並且Visual Studio.NET自動為我產生存儲程序。 當我點擊「下一個」，我們可以看到磨人的選項語句，嚮導想讓我們用它，然而他會返回所有記錄，但我真的不像這樣。所以，我可以快速點擊查詢產生器，開啟他，ISBN是我想要的，客戶將會拿ISBN來查詢，然後我會基於所給的ISBN來返回資料。所以我到標準域m