這篇博客對在云計算解決方案中操作數據進行總覽性的介紹。

概覽

對于絕大多數解決方案而言，數據都是至關重要的一部分。在云計算里面，絕大多數現成的建議都可以直接拿來用。但是云計算也有其獨特之處。這篇博客將討論以下兩個用例：

• 將你存放在云中的數據發布至全世界
• 在云端的項目中使用你本地的數據。

通用的建議

無論是哪種用例，這些建議都是通用的。

選擇一個拓撲

在SOA的世界中，最重要的一個概念就是契約（contract）。在云計算的世界中，有關通信的最重要的概念也是契約。當一個契約被很多云計算解決方案使用之時，我們就可以把它稱作一個拓撲了。

現在我們只討論數據通信。如果你選擇了微軟的解決方案，我們推薦你使用Open Data Protocol (OData)。OData是基于諸如HTTP和AtomPub的國際標準創建的，它提供了一個跨平臺的數據通信的方案。如果你云端的程序使用OData來發布數據，這個世界上的任何一個程序，只要是支持OData標準，就都能享用你的數據。同理，你云端的程序也能使用OData來訪問你本機的數據。

很多目前的微軟產品已經在應用OData了。例如：windows Azure Table Storage，Dallas，SharePoint 2010，SQL Server 2008 R2，等等。

如果你打算使用其他的拓撲，有必要仔細思考它們的可伸縮性，有多少人在使用它們，等等。

選擇一門技術

既然拓撲已選定，下一步就是選擇一門技術來實現這個拓撲了。

如果你選擇了微軟的解決方案，我們推薦你使用WCF來處理所有程序間的通信。針對數據通信，WCF Data Services自然是最好的選擇。

首先，WCF Data Services是WCF服務，所以你可以使用所有現有的WCF知識。其次，WCF Data Services已經實現了OData拓撲，于是你可以致力于你的數據格式在你的程序中的表示，而不是AtomPub/JSON這些真正在網絡上傳遞的數據格式。再有，WCF Data Services致力于數據傳輸，而不是數據存儲。你的數據可以存放在任何位置：本地的數據庫，云端的數據庫，外部的web services，xml文件，等等。無論數據是怎么來的，你都可以用同樣的方式來發布/使用它們。

如果你選擇了其他技術，有必要仔細考慮使用該技術的需要花費多少精力來完成你的解決方案，該技術能否提供將來的解決方案擴展，等等。

接下來我們來看看微軟的產品如何幫助你們完成上述兩個用例。

將你存放在云中的數據發布至全世界

許多云計算解決方案都不是孤立的，它們需要和外部世界交互。說到數據，你很可能直接了當的反應出來DaaS (Data as a Service，數據即服務)。

云計算的數據可以存放在許多地方，而且數據本身也是非常多樣化的。本文將致力于討論結構化的數據（例如xml），以及關系型數據（例如關系數據庫）。當前微軟提供了兩大產品用于在云中存放數據。

• Windows Azure Table Storage：用于存儲結構化數據。使用動態架構 (dynamic schema)。
• SQL Azure：用于存儲關系型數據。使用靜態架構(fixed schema)。

下面這張表格比較了靜態架構和動態架構各自的優勢。

針對你具體的場景，請選擇一個合適的數據存儲方式。通常來說，如果你的服務對外部世界開放了寫的權限（允許外部世界更新數據），動態架構是一個比較好的選擇，因為第三方的程序很有可能需要適當的修改你提供的數據結構。然而目前Windows Azure Table Storage還有一些局限性，它并未實現OData所有的功能，再加上關系模型已經有了好幾十年的經驗，你的開發人員也很可能非常熟悉關系模型，所以如果對你而言使用動態架構成本太高，請選擇靜態架構。

無論你選擇了何種架構，OData和WCF Data Services都能起到非常大的作用。

剛才已經說過，WCF Data Services可以使用任意的數據源。它默認就提供了兩種數據提供者：ADO.NET Entity Framework (EDM)和LINQ to SQL (L2S)。如果你使用的是這兩種數據源，通常只需要寫一小部分代碼即可完成一個項目。如果你選擇SQL Azure存放數據，你就可以使用EDM和L2S做數據源。

如果你使用了其它數據源，（例如Windows Azure Table Storage），你需要將你的數據模型轉換成WCF Data Services理解的模型。如果你的數據是只讀的，這個過程就很簡單，因為你只需要寫一個很普通的類來表示你的數據結構。如果你需要完整的CRUD功能，就必須實現IUpdatable這個接口。這被稱作“Reflection provider for WCF Data Services”。在更高級的場合中，你還可以使用“Custom Data Service Providers”。詳細信息可以參考http://msdn.microsoft.com/en-us/library/dd672591(VS.100).ASPx。

Windows Azure Table Storage本身也是使用OData拓撲，所以你可能會試圖讓你的客戶直接訪問你的數據源。但是在絕大多數的場合下，請不要這樣做。你必須竭盡全力保護你的storage賬號的key（把它想象成你的密碼）。如果你將自己的密碼給與一個受你信任的用戶使他/她能直接訪問你的Table Storage，而他/她濫用了這份權限，到最后，使你必須支付你的storage賬號的費用。我們推薦用戶將數據和業務邏輯封裝成服務，使用WCF Data Services就是完成這一任務的很好選擇。

你可以從All-In-One Code Framework (Azure).zip 中下載一個示例，它演示了如何使用WCF Data Services將存放在Windows Azure Table Storage中的數據發布至全世界。示例的名稱是：CSAzureTableStorageWCFDS/VBAzureTableStorageWCFDS該示例也提供了一個Silverlight客戶端用于測試服務。

在云端的項目中使用你本地的數據

另一個常見的場景就是在云端的項目中使用你本地的數據了。絕大多數場合下，這些數據都使用了靜態架構存儲于關系型數據庫中（例如SQL Server），所以你通常不會考慮如何存儲數據。在這個場景中，你更關心的是可連接性以及安全性。

很多公司都有防火墻和NAT。很難找到一臺機體，既可以自interNET訪問，又擁有一個固定的IP地址，所以要在云端的程序直接連本地數據庫也就很難了。權限控制也是一個問題。云端的程序并不在你的公司的局域網中，和數據庫不在同一個域里，要使用集成Windows驗證是不可能的，而federated驗證目前還沒有針對數據庫提供很好的解決方案。

為了解決第一個問題，微軟提供了Windows Azure platform AppFabric Service Bus。Service Bus就好比你本機服務和云端程序之間的橋梁，本地服務對于Service Bus而言其實是一個客戶端，所以即使本地服務器位于NAT之后，它還是可以和Service Bus交流。Service Bus會把你云端程序發送的消息傳達給你本地的服務。

Service Bus同時支持TCP和HTTP。大多數防火墻至少是允許outbounding連接通過80/443端口的，而這也正是Service Bus的最低需求。這樣一來，Service Bus便可以穿越NAT和防火墻。

安全是一個很復雜的話題，本文不準備詳細探討。但是有必要指出，Windows Azure platform AppFabric Access Control在很多場合下都是很有幫助的，而且它默認就和Service Bus集成。

當然，OData和WCF Data Services在這個用例中也很有幫助。

你可以從All-In-One Code Framework (Azure).zip 中下載一個示例，它演示了如何使用Service Bus和WCF Data Services在云端程序訪問本地的SQL Server數據。項目名稱是：CSAzureServiceBusWCFDS/VBAzureServiceBusWCFDS。這個項目也提供了一個ASP.NET客戶端用于測試服務。你可以很輕松的將這個客戶段轉換成一個Windows Azure的Web Role，真正的在云端進行測試。

NET技術：云計算和數據，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。