在數據架構規劃前進行XML消息的設計

2019-11-17 04:38:29

字體：大中小

來源：轉載

供稿：網友

本文假定你對Visual Studio.NET和xml技術都比較熟悉摘要

Web服務是利用XML消息來傳遞數據的技術。假如你要設計一個數據庫結構，你大概不會讓你的工具去自動的完成，而是要手工的進行調整來保證最高的效率，作者在這篇文章中認為，設計Web服務也是一樣的。你需要首先了解Web服務會返回什么樣的數據，然后再用這樣的數據結構來設計出最有效率的消息格式。你將從這篇文章中學習到如何決定有效的消息結構，并且根據這一結構來創建相關的Web服務。沒有經驗的開發者在開發Web服務時，經常跳過設計這一重要的第一步，他們從給工程添加Web引用開始，然后再給服務中添加相應的Web方法。雖然這種方法比較簡便，卻不是創建真正用于業務的Web服務的好辦法，因為這樣的話就忽略了Web服務消息結構的設計。在這篇文章中，我會向大家解釋為什么這種常規的辦法不適合重要的開發，然后會教給大家用Visual Studio® .NET設計Web服務的更好辦法。

對你的數據有把握

當編寫面向數據的應用時，如何去創建數據庫結構呢？你是不是會先設計出類程序然后再讓你的集成開發環境幫你自動創建數據庫結構，還是你會親自手動創建標準化的，完整的和高效的數據庫結構？一般情況下你都會選擇手動的來創建數據庫結構。即使你是利用了可視化的數據結構設計器，而不是使用數據定義語言（DDL）來進行設計，你依然對數據結構的設計有良好的控制。 Web服務的目標就是在恰當的時候提供恰當的數據。當客戶端調用Web服務時，XML格式的消息被用于發送請求和返回結果。當編寫Web服務和相應的客戶端程序時，你主要就是針對這些消息格式編程，應用程序真正關心的就是這些消息中承載的數據。既然如此，為什么要先設計出Web服務的類和方法，然后再用工具自動的生成消息的數據結構？你應該先設計出消息的數據結構，然后再根據這一結構來設計Web服務，就像你在設計數據庫結構時一樣。

消息，而不是方法

優先考慮消息是一個進步，例如，某個Web服務接收地區編碼，然后返回當地的天氣情況，習慣了面向對象的方法，你會自然而然的就設計出GetWeather方法來獲取字符參數，然后返回一個CurrentWeather對象的實例。（參見示例1）這種方法不是很好，因為你設計的這些方法和對象僅對你這個Web服務有意義，使用這個Web服務的程序對你設計的CurrentWeather類卻一無所知，例如類成員所表示的具體意義。事實上，客戶程序僅僅知道它接收了一個名叫CurrentWeather的XML架構（XSD）復雜類型，當你訪問Web服務的WSDL說明（形如weatherservice.asmx?wsdl）時會自動的創建這一XSD類型的定義，客戶端工具就會根據自身的情況將這一XSD類型映射成為數據結構。例如，SOAP工具會把CurrentWeather實例映射成為IXMLDOMNodeList接口的XML節點。.NET Framework通常會把這個XSD類型轉換成為本地類型，從而帶來很多麻煩，例如，增加了對示例1中Web服務引用的.net應用會根據CurrentWeather的XSD類型自動生成一個名叫CurrentWeather的類：public class CurrentWeather{ public string Conditions; public string IconUrl; public Single Humidity; public Single Barometer; public float FahrenheitTemperature;} 對那些不知道這一Web服務功能的人來說，第一個問題就是“CelsiusTemperature屬性哪里去了，為什么FahrenheitTemperature是一個域而不是屬性”？答案就是，只有服務內CurrentWeather類的公共，可讀寫的成員會被.NET Framework自動序列化成為XML，因為CelsiusTemperature是只讀的，它就沒有被序列化，也就不能在客戶端的CurrentWeather類中體現出來，而且，自動生成的客戶端類只包含公共域，而不是屬性。客戶端程序僅僅知道有名叫CurrentWeather的XSD類型，但XSD類型并沒有區分屬性和域，對于客戶端來講都只是數據。從這個角度看，你會覺得Web服務有著很嚴重的局限性，不能夠讓客戶端得到服務所返回對象的實例。這其實并不是Web服務的局限，而只是你不能把Web服務看成是獲取遠程對象（就像DCOM一樣）的手段的原因。
設計天氣服務的更好辦法是從定義消息開始。例如，你定義了WeatherRequest消息，包含有地區編碼和包含有當地天氣情況的CurrentWeather消息。示例2就體現了示例的請求和返回消息，可以作為你設計Web服務的起點。現在，由于Web服務和客戶端的開發者都有可以理解這一Web服務的WeatherRequest消息和CurrentWeather消息，他們就不再會被一些實現細節所困惑了，例如只讀成員和屬性等。

格式化消息的設計

現在你已經創建了樣例的請求和返回消息，你需要把這些消息的設計格式化，以便Visual Studio .NET等開發工具可以理解這些設計，并且提供更加強大的開發功能，如客戶代理生成。

你需要去創建一個XML架構來描繪你的請求和返回消息，從而格式化這些消息的設計。雖然你可以用很多種的工具甚至文本編輯器來生成這些XML架構文件，我還是建議你使用Visual Studio的XML架構編輯器。使用XML架構編輯器，啟動Visual Studio并且選擇菜單：新建文件 XML架構。設計器有一個專門的工具箱面板，里面包含有XML架構的組件，例如元素聲明和類型定義等，想聲明WeatherRequest一類的元素，只需要把元素（Element）圖標從工具箱中拖到設計界面上就可以了。每個元素都包含有兩個必須設置的主要屬性：元素的名稱和數據類型，當你設置元素的數據類型時，你可以從XSD內置的類型中選擇，也可以自定義類型。例如，WeatherRequest就是內置的字符串類型（WeatherRequest元素包含字符串），而CurrentWeather則是包含有其他元素的自定義類型。對類型進行定義，然后再聲明這些類型的具體元素，這和你在編程時所作的工作非常類似：先定義類（例如CurrentWeather類），然后就成為你工程里的一個新的類型。隨后你就可以對這些類聲明變量了，就像示例1中的cw變量。 XML架構設計器使聲明新的類型變得輕易，通過在CurrentWeather元素的界面內增添行的方式就可以定義新的CurrentWeather類型。就如示例3展示的那樣，CurrentWeather元素包含有未命名的類型，這個類型包含有Conditions，IconUrl，Humidity，Barometer，FahrenheitTemperature和CelsiusTemperature元素。在數據架構規劃前進行XML消息的設計（圖二）

示例3：Visual Studio XML架構設計器到此為止就還有最后一步來完成消息的設計，你要為XML架構設置targetNamespace屬性，來唯一的標識你的Web服務或應用程序，就像在示例3種屬性窗口中的設置一樣。這是一個良好的習慣，但它不是必須的，以致于很多開發者都忽略了這重要的一步。如過你需要對XML架構進行深入的工作，你可以通過點擊示例3中底部的XML附簽，來切換到XML視圖。它展現了整個XML架構的源文件，你可以根據需要對它進行深入的編輯，就像示例4那樣。示例4：消息架構

完成界面的定義

示例4中的XML架構充分描述了請求和返回消息的數據定義，但消息還有很多其他方面的信息需要被用一種正式的，機器可讀的方式所描述出來。例如消息是否使用了SOAP遠程調用？消息是怎樣被編碼的？為了提供這些方面的信息，你可以創建Web服務描述語言（WSDL）文件。現在Visual Studio .NET里還沒有內置的WSDL設計器，不過有第三方的產品可以提供圖形用戶界面的WSDL設計器，而且WSDL是符合XML語法的，你可以用任何的XML或者是文本編輯器來創建WSDL文件。由于需要提供大量的特性，所以WSDL語法會有一些復雜，但實際上你只會用到其中很小的一部份，你最好建立一個WSDL模板文件（類似示例5中的那樣），然后在其基礎上修改，來滿足你的需要。示例6展示了為天氣服務定制的WSDL模板文件，我修改了請求與返回消息中的部分信息，指向在ServiceMessages架構中設計的WeatherRequest和CurrentWeather元素，還把操作命名為GetWeather，把綁定命名為WeatherInterface。這些命名都會在你的代碼中分別作為Web方法名稱和綁定名稱，所以盡量使名稱有良好含義。到此為止就完成了設計的工作，你現在預備好了Web服務界面的正式設計，包括每個請求和返回消息中的應用程序數據的定義。接下來服務的開發者就應該開始實現這些接口的功能，客戶端的開發者也要進行相應的編程了。清注重，客戶端的開發者不需要等到服務開發完成后才能開始開發工作，這意味著你可以通過讓兩種開發同時進行來節省時間。

接口的實現

你可以使用Microsoft® .NET Framework SDK中的wsdl.exe工具來實現一個Web服務的接口。這一命令行工具可以對WSDL文件進行操作，生成Web服務的stub類（實現了給定接口的類）或代理類（客戶端使用的類）。
例如，想要生成天氣服務接口的stub類，你可以運行wsdl.exe，后面加/server開關，傳遞給它接口的WSDL地址，如下面這樣：C:/> wsdl.exe /server /o:WeatherStub.cs http://localhost/MSDNMag/weatherinterface.wsdlMicrosoft (R) Web Services Description Language Utility[Microsoft (R) .NET Framework, Version 1.0.3705.0]Copyright (C) Microsoft Corporation 1998-2001. All rights reserved.Writing file 'WeatherStub.cs'. 默認的，wsdl.exe會生成C#代碼，假如你可以使用/language開關來選擇生成Visual Basic® .NET或javascript語言。在這個例子中，生成的WeatherStub.cs文件包含一個抽象的WeatherInterface類來實現天氣的接口。這個類包含一個GetWeather方法，它可以接受一個字符串參數，然后返回一個CurrentWeather的實例。CurrentWeather類是根據在XML架構中的CurrentWeather類型而生成的。開始實現服務代碼的時候，把WeatherInterface類加入到你的工程中，創建一個新的Web服務，然后把這個Web服務改成從WeatherInterface抽象類繼續，然后你就可以重寫基類的GetWeather方法，實現你的業務邏輯，就像示例7那樣。為了通過SOAP展現這個GetWeather方法，你需要加入一個WebMethod屬性，來明確這個GetWeather方法就是較早前在WeatherInterface.wsdl定義的那個GetWeather操作的具體實現。你還需要在返回的信息中加入一個Xml元素，添加一個SoapDocumentMethod屬性，并且把它的ParameterStyle屬性設置成為SoapParameterStyle.Bare。（請參見示例7）假如你使用Visual Basic .NET開發，你不用手動的添加這些屬性，當你從overrides菜單中選擇GetWeather 方法時，Visual Studio就會自動地把它們添加在你的代碼里。假如你編寫了Web服務，并且找到那個自動生成的WSDL文件，你會發現里面包含了很多的信息，這確實是個麻煩。首先，WSDL文件里面包含完整的WeatherInterface，其次，文件還包含了支持HTTP GET和HTTP POST協議的另外兩個接口。包含有完整的接口會影響單一接口多次實現的目標。所以你首先要從服務的WSDL文件中刪除那些接口的內容，然后確保它指向你先前創建的WeatherInterface.wsdl文件。想達到這一目的，你需要給Web服務本身增加一個WebServiceBinding屬性，指出服務實現的WSDL綁定（WeatherInterface綁定）的名稱，以及定義綁定的WSDL文件的地址。你還需要設定每個Web方法的SoapDocumentMethod屬性的綁定屬性，指出這些Web方法在綁定中定義的具體操作。示例8展示了經過這些修改的Web服務。最后，我建議你關閉服務的WSDL文件中綁定的HTTP GET和HTTP POST。假如是為某些特定的應用程序關閉這些協議，你只要編輯應用的Web.config文件，在system.web節中增加webServices節即可，如下所示：<webServices> <PRotocols> <remove name="HttpGet"/> <remove name="HttpPost"/> </protocols></webServices> 你也可以通過編輯machine.config文件來對整個計算機關閉以上的協議，從協議列表中刪除HttpGet和HttpPost即可。現在，當你創建了Web服務并且查看其WSDL文件時，你得到了一個簡潔的文件，僅僅引入了WeatherInterface.wsdl文件，并且添加了服務定義（參見示例9），你可以把服務定義也看成是WeatherInterface.wsdl中定義接口的非凡實現。

對界面編程

開發客戶端程序來實現天氣接口，你可以使用wsdl.exe，或者是在Visual Studio里添加Web引用來從接口生成代理類。

注重，當你生成這個類時，你需要指出WeatherInterface.wsdl，因為里面包含著接口信息，非凡當類中沒有實現這些接口的服務的地址時。因此，客戶端必須在設計時和運行時都設置這一地址。避免在客戶端代碼中寫死這個地址，你最好把它放置在你客戶端的配置文件中，在運行時動態讀取就可以了。以下就是WeatherInterface的客戶端代碼：Private Sub BTnWeather_Click( _ ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles btnWeather.Click Dim ws As New localhost.WeatherInterface() ws.Url = System.Configuration. _ ConfigurationSettings.AppSettings("ServiceUrl") Dim cw As localhost.CurrentWeather = _ ws.GetWeather("20171")End Sub

總結

Web服務是利用XML消息來傳遞數據的技術，所以編寫Web服務的時候尤其要精心的用XML架構和WSDL來設計消息的結構。當你從設計消息結構開始，而不是從編寫方法開始的時候，你的Web服務需要接收和返回何種類型的數據就變得比較清楚了。使用XSD和WSDL來設計消息結構，你可以創建一個標準的接口定義，讓Web服務的開發者去實現，同時客戶端的開發者也可以參照其來進行編程。下次你再開發Web服務的時候，請先用Visual Studio XML架構設計器來設計消息的結構吧。

上一篇：java的設計模式，學習心得總結

下一篇：“不完美”的VS 2005 Team System