Azure Services Platform Step by Step

Azure，这个简单优美的单词，从2008年11月28日开始，被赋予了另所有程序员心潮澎湃的意义。对，她就是庞大的微软帝国的一次豪赌。

　　Azure,全程Azure Services Platform。主页是Http://www. 。这是很新很新的玩意儿，目前不管是在国内还是国外，都很少有人研究它。

　　Azure是啥？简单的说，Azure services Platform是一个基于微软数据中心的Internet云端服务平台，为我们提供了一个实时操作系统和一系列的开发、存储、数据存储、Hosting等服务。更简单地说：Azure就是传说中的云计算，是微软实现云计算的平台。

　　上一段内容比较概括和振奋人心。相信很多人和我一样，一直听说“云计算”，但是从来都不知道云计算到底为何物。"云计算"这一概念性的东西，被媒体炒作得跟当年的"Web 2.0"一样热。终于，Azure这一亲切的平台带我们很轻松地去体验"云计算"的云里雾里。对，亲切。因为Azure和其他几乎所有的微软技术一样，有一个莫大的好处：上手非常容易。

　　对于我们这些早已习惯和熟悉Visual Studio各种开发的dev来说，我们很容易就会爱上Azure.官方也说了：Get Started Quickly Using Your Existing Skills. 也就是说，你根本不需要学习更多的知识，就可以通过Azure开发各种云端应用，体验“云计算”。

　　也许几句话根本介绍不完。确实，我也是看了好几天Whitepaper,SDK和Forum才完全了解了Azure的结构和技术。先允许我用几句“小农意识”的话来概括Azure的好处吧：使用Azure，你再也不用到处去找支持ASP.NET的虚拟主机来放置Web Application和Web Services了，因为Windows Azure提供“云里雾里”的HOSTING，比普通的虚拟主机更强大；你再也不用去寻找盗版SQL Server 200X和数据库服务器了，因为在SQL Services里提供了RESTful的数据存储，方便到家；你再也不用为你服务器的稳定性烦恼，因为你的云端应用都部署在Azure上，使用微软的infrastructure，稳定性与安全性由微软帝国来保证……

怎么样？很不错吧？哈哈，其实这才是Azure的皮毛，我只提到了Azure最基本最容易理解的几个服务而已。想要深入了解？继续关注我Blog吧，我会在接下来的几个月对Azure进行全面研究和解析，并且制作一些完整的应用程序。

　　好，现在你对Azure有一点基本的认识了，让我们继续。

　　　　1.Azure platform包括4个部分：Windows Azure,.NET Services,SQL Services,以及微软早就提供出来的Live Services.很显然，另大多数人激动的只有前3个。4个部分都包括很多具体的服务，我们在以后会一一介绍。

　　2.你所开发的应用程序，可以被多种客户端使用。

　　3.你所开发的应用程序，可以放在你自己的服务器，也可以通过Windows Azure提供的服务，部署在云端。不管你的程序在“平地”还是在“云端”，它们都可以调用Azure Platform提供的其他各种服务。

　　了解Azure的基本结构后，如何进行学习？

　　首先，你需要到官方网站http://去申请内测资格。地址http://www.microsoft.com/azure/register.mspx

　　说明一下，不然很多人可能会confused.如上文说的，Azure包括Windows Azure,.NET Services,SQL Services,Live Services4块。不知道微软怎么想的，它把Windows Azure和Live Services的dev portal放在了一起，地址是http://lx.azure.microsoft.com/ 。而.NET Services和SQL Services的dev portal放在了另一个地方：http://portal.ex.azure.microsoft.com/ .在申请内测资格（invitation code或token）的时候不用区别，只需要申请一次就可以了。但是微软在发放invitation code的时候，会对于以上两个不同的portal分别发放。

　可以参考一下国外的一篇博客Setting Up the Windows Azure Services Platform。不过作者只收到了SQL Services+.NET Services的invitation code.

　　一定要强调的是，等邀请码是很需要耐心的。看看老外写的这篇文章：Waiting for Windows Azure Tokens? seems many are in the same boat ..　

　　所以，填写资料的时候一定要认真……如果有不明白直接给Sriram Krishnan 发邮件，他自称"I work for the Windows Azure team and I'm the token/invitation master in sorts”，我拿到token之前就骚扰过他……([e-mail])

　　然后，你需要下载以下官方学习资源：

　　官方的资料比较多，以下两个最重要。

　　Introducing the Azure™ Services Platform:这是一个30多页的pdf文件，对Azure进行了全面的介绍（不涉及技术）。

　　Azure Services Training Kit - PDC Preview：这是官方的教程，色香味俱全。也是目前能够找到的唯一教程。（我google几天了，目前真的没有其他第3方教程了。）

接下来，当然是SDK:

　　Windows Azure SDK

　　Windows Azure Tools for Microsoft Visual Studio

　　Microsoft .NET Services SDK

　　Microsoft SQL Data Services SDK

　　Live Framework Documentation and Resources

　　这里需要再次说明一下：对于Azure platform的4个部分，都有不同的SDK和工具。其中只有Windows Azure稍微特殊一点，需要Vista或windows2008操作系统。

　　Then,开发：

　　Azure的开发过程与普通.NET的开发过程没啥区别：

　　使用Visual Studio开发 - 开发中使用Azure的各种服务 - 发布- 登陆dev portal部署到“云”里

　　以后我慢慢讲。

 

在上一篇里我已经提过了，有了SQL Services，作为一般的中小型应用程序开发，你完全可以忘掉SQL Server 200X的存在。有这么神奇吗？现在流牛木马就来详细地了解SQL Services是何方神圣。

　　在大多数情况下，Web应用程序都需要依赖另一个数据库服务器。这个数据库服务需要专业的IT人士来维护。在你部署应用程序之前，你需要考虑太多：这个数据服务器有足够的容量么？性能怎么样?稳定和安全?负载？还有其他太多太多未知的因素…

　　按照云计算的基本概念，解决以上问题，我们需要Cloud-based data platform，即把数据服务都放在云端，依靠强大的云端操作系统和平台硬件来处理。对了。SQL Data Services(SDS)就是这样一种基于"云"的数据平台。

　　什么是SDS?

　　SDS是一个面向internet的强大database，提供强壮、安全、灵活数据库服务。SDS提供SOAP和REST两种标准接口，与传统编程语言脱离，让使用任何语言的coder都可以轻易地操作它。

　　为什么要使用SDS？

　　Flexibility and scale，Business-ready reliability and security，Developer agility

　　SDS在Azure Services Platform中的地位：

　　SDS是Azure四大模块之一，在云端为天上地下的应用程序提供数据服务，也为其他的Azure Services模块提供数据服务。

　　图片看不清楚？请点击这里查看原图（大图）。

　　SDS支持的数据类型

　　SDS支持 String（字符串）, Decimal（十进制数）, Boolean, DateTime, and Binary 几种基本的数据类型，还支持一种叫BLOB（binary large object ）数据类型，允许你存储任何格式的内容。

　　申请地址：

　　http://go.microsoft.com/?linkid=9373222

　　Dev Portal

　　http://portal.ex.azure.microsoft.com

　　ACE模型

　　终于进入重点了。在使用SDS之前，你必须了解SDS的ACE(Authority,Container,Entity)模型。Authority是最高level的对象。一个Authority包含了多个Container,一个Container包含多个Entity.如下图

　　我们可以把Authoriy想象成SQL Server中一个数据库实例(SQL Server instance)。那么，Container就好比实例中的多个相互独立的数据库了。而Entity就相当于一条记录。这样类比只是一个直观的概念，其实ACE模型和关系数据库是有区别的。

　　如果要准确类比的话，Container可以等同于关系数据库中的一个独立database，也可以等同于一个table。Entity是一条数据记录没错，但是Entity的是任意的，不需要像关系数据库里那样，在一个table里有一个特定的结构定义。大家看上图可以注意到，一个Container可以包含多种结构不同的Entity。

　　举个实际例子，如上图所示，我们可以创建一个叫做"food"的Authority，其下包括名为"fruit"和"vegetable"两个Container.　 Container["fruit"]中包括3个实体，分别是"apple1","apple2","pear1".注意，这里我们假设五角星代表pear，三角形代表apple。这样，在这个　 Container["fruit"]就包括了两种类型的三个Entity。同样，在Container["vegetable"]中，我们假设圆形是白菜cabbage，方形是西红柿tomato，我们又有了"tomato1","tomato2" ,"cabbage1"三个entity，它们也属于两种不同类型。。

　　呵呵，根传统的instance-database-tabale-row的模型很不一样吧？不要紧，现在先记住基本的结构就好了，在下一节，你会有机会动手把玩一下它们。

　　编程模型

　　每个Authority都对应特定的URI。比如一个叫做food的Authority，它的HTTP地址就是https://food.data.database./v1 ,可以直接在浏览器中打开（在浏览器zhogn1直接打开，等同于执行HTTP的GET方法）

　　有了Authority的URI，你会发现，Container和Entity的URI也很容易找到了。格式如下：

　　https://food.data.database./v1/<container-id>

　　 如https://food.data.database./v1/fruit/

　　https://food.data.database./v1/<container-id>/<entity-id>

　　 如https://food.data.database./v1/fruit/apple1

　　SDS的编程模型，CRUD，说白了就是对以上这些URI的HTTP操作。下表是一个HTTP Verb到SDS Operation的映射

HTTP Verb	SDS Operation
GET	Fetch,Query,（即Select）
POST	Create，(即Insert）
PUT	Update
DELETE	Delete

 

　　好了，这一节到此结束。：） 下一节我会通过一个小工具来玩转SDS的全部功能。

 

SDS其实是很友善、很好玩的。这一节我们不会使用任何的编程语言, 流牛木马将带领大家，仅靠SDK里的一个叫做SSDS Explorer小工具来玩转SDS，熟悉和实现上一篇讲述的一些内容。很有趣的哦~

　　在申请Azure后，经过耐心漫长地等待，你会收到一封叫做“Do Not Delete! Invitation Code to Microsoft .NET Services and Microsoft SQL Services”的邮件。

　　终于开始了！从邮件中复制出Invitation Code，打开http://portal.ex.azure.microsoft.com/，激活你的SDS

　　图片看不清楚？请点击这里查看原图（大图）。　

　　激活后，点击右上角的Get Started

　　进入SDS,然后创建一个新的Solution。注意:一个invitation code只能创建一个Solution.

　　然后就来到了.NET SERVICES和SQL SERVICES的管理界面

　

　　点击顶部的Solution Credentials,修改solution的密码。改成一个自己好记的吧:)

　

　　好了，现在你已经有了自己好记的Solution名和密码了。

　　下载SDS的SDK http://www.microsoft.com/downloads/details.aspx?FamilyId=0B1FA5C6-EC9D-440B-939E-481DD05F2627&displaylang=en

　　安装SDK.

　　打开安装目录下的SSDS Explorer

　

　　在这里我们先复习一下上一篇讲的ACE模型。

　

　　我们的操作顺序也是根据这一模型来的。

　　首先要建立一个Authority，然后在它下面建立不同的Container，最后再在Container下建立多个同类型或者不同类型的Entity。

　　还是上一篇的例子，与上图对照，我们可以创建一个叫做"food"的Authority，其下包括名为"fruit"和"vegetable"两个Container.　 Container["fruit"]中包括3个实体，分别是"apple1","apple2","pear1".注意，这里我们假设五角星代表pear，三角形代表apple。这样，在这个　 Container["fruit"]就包括了两种类型的三个Entity。同样，在Container["vegetable"]中，我们假设圆形是白菜cabbage，方形是西红柿tomato，我们又有了"tomato1","tomato2" ,"cabbage1"三个entity，它们也属于两种不同类型。。

　　接着我们在复习一下基本操作与HTTP Verb的映射表

HTTP Verb	SDS Operation
GET	Fetch,Query 查询
POST	Create　 新建
PUT	Update 修改
DELETE	Delete　 删除

　　好了，够了，开工！进入SSDE Explorer！！

　　图片看不清楚？请点击这里查看原图（大图）。

　　第一步当然是创建Authority.直接点击右边的 按钮

　　此时文本框里会出现这样一段

　　在<s:Id>与</s:Id>中间输入Authority的名字，我这了就叫做food了。输入完成后点击 (因为根据上面的映射表，“新建”操作对应的HTTP Verb是"POST")

　　此时可能会弹出Credentials对话框，输入刚刚设置的Solution名字和密码即可。

　　如果操作成功，底部的状态框会出现 。如果出现的是 ，说明操作有误，请根据错误提示进行更改。

　　操作成功后，顶部的地址栏会变成

　　对了，这就是这个Authority的URI了。上一篇里说了，对这个Authority的所有操作，其实就是对这个URI的HTTP操作。

　　现在我们来建立两个叫做"fruit"和"vegetable"的Container

　　点击 ，在<s:Id>和</s:Id>中输入"fruit",此时文本框如下图

　　点击 ，状态栏变成。

　　地址栏里显示的URI是https://food.data.database./v1/fruit，对了，这就是"fruit"这个Container的URI

　　现在就是在fruit中加入具体的Entity了。(vegetable类似，略)。

　　我们假设fruit中有两种Entity，

　　一种是Apple，包括的属性如下：

属性名	Weight	Color	Availability	RecordDate
类型	Decimal	String	Boolean	DateTime

　　另一种是Pear,包括的属性如下

属性名	Weight	IsPopular	ProducingArea
类型	Decimal	Boolean	String

　　现在我们来添加第一个Apple: "apple1"

　　由于我们是要在fruit这个container中插入Entity,所以操作时请保持URI为https://food.data.database./v1/fruit

　　点击右边的

　　将默认的<Entity />标签对的名字改为<Apple />

　　在<s:Id/>标签对中输入"apple1"

　　点击右边的属性区，依次添加属性。属性名就是节点标签名字，请注意更改。

　　描述属性的节点内有一个叫做"xsi:type"的attribute,表示当前节点的类型。

　　如<Weight xsi:type="x:decimal">1.2</Weight >，定义了一个叫做Weight的String属性，它的值是1.2。

　　apple1的最终外观如下：

　　同样的方法我们可以添加apple2

　

　　再添加Pear类型的pear1

　

　　呵呵，这样就添加完了。如果这个时候我想修改 apple1呢？只需要在地址栏中输入https://food.data.database./v1/fruit/apple1，点击 ，修改好后再点击 即可。（PUT对应UPDATE操作） 删除呢？呵，一个硕大的 出现在底部，就不用我说了吧？

　　接下来我们就可以使用LINQ来玩弄它了！

　　基本语法如下

　　from e in entities [where condition] order by [property] select e

　　运算符和布尔操作符

　

　　比如，我们现在可以在地址栏中输入https://food.data.database./v1/

　　在查询框中输入from e in entities where e.Id=="fruit" select e，点击

　　此时文本框中就会出现fruit这个Container的内容。简单吧？

　　让我们循序渐进：

　　地址栏输入https://food.data.database./v1/fruit

　　查询框输入from e in entities where e.Kind=="Apple" select e，点击，此时文本框中就会展示出apple1和apple2的内容。

　　再来。

　　执行查询from e in entities where e.Kind=="Apple" && e["Color"]=="Red" select e

　　则只能看到apple2的内容，因为只有apple2的"Color"等于"Red"

　　读者走到这里可能有疑问了。为什么是e.Kind和e["Color"]呢？到底是用"."还是用"[]"呢？解释一下，对于Entity的元数据属性(metadata property)，需要使用".",如e.Id,e.Kind;对于普通属性，则使用"[]",如e["Color"]

　　读者可以继续练习更多：

　　from e in entities where e.Kind=="Apple" && (e["Color"]!="Red"||e["Color"]!="Blue") select e　 （使用括号）

　　from e in entities where e.Kind=="Apple" && (e["Weight"]>=4) select e (使用表达式)

　　from e in entities where (e["Weight"]>=4) select e（多种Kind的Entity可以混合在一起查询）

　　from e in entities where e["RecordDate"]>="2008-12-15" select e（使用日期）

　　from e in entities select e （取得所有Entity）

　　from e in entities where e.Id>"pea" select e (字符串使用比较符号)

　　注意： 同一个Kind的Entity可以包含的不同的属性(不推荐)。比如我们可以把apple1中的<Availability />属性删除掉，完全没有影响。可以执行以下查询进行测试

　　from e in entities where e["Availability"]==false　 && e.Kind=="Apple" select e

　　怎么样？很简单很有趣吧？

　　“赤手空拳”与SDS“肉搏"到此为止。在下一篇中，我们将使用C#语言，对以上所有的操作进行编程实现，敬请关注。

 

在上一篇中，我们通过SSDS Explorer详细了解了SDS的工作和操作流程。

　　这一篇，我们会详细讲解如何使用程序员的方法来操作SDS。

　　SDS提供SOAP和REST两种接口，这里我们是用REST+C#的方法来讲解。SOAP与之殊途同归，请有兴趣的同学自己查阅MSDN。

　　闲话少说，下面我们以创建Authority为例，给出REST操作SDS的“万能框架”：

public　　 string　 CreateAuthority()
　　　　　　 {
　　　　　　　　　　 //步骤一（蓝色部分）：通过某种方式，构造要发送到服务的XML数据。显然，这一部分只有在POST方法和PUT方法时才会有，对于GET方法和DELETE方法则不需要。下面示例的是一个创建Authority的XML
　　　　　　　 　　 const string AuthorityTemplate =
　　　　　　　　　　　　　　　　　　　　 @"<s:Authority xmlns:s='http://schemas.microsoft.com/sitka/2008/03/'>
　　　　　　　　　　　　　　　　　　　　　　 <s:Id>{0}</s:Id>
　　　　　　　　　　　　　　　　　　　　 </s:Authority>";

　　　　　　　　　　 if (String.IsNullOrEmpty(ServiceUri))
　　　　　　　　　　 {
　　　　　　　　　　　　　　 throw new ArgumentOutOfRangeException("ServiceUri");
　　　　　　　　　　 }

　　　　　　　　　　 string authorityUri = null;
　　　　　　　　　　 try
　　　　　　　　　　 {
　　　　　　　　　　　　　　 string requestPayload = string.Format(AuthorityTemplate, authorityId);
　　　　　　　　　　　　　 //步骤二：建立用以传送数据的HttpWebRequest对象
　　　　　　　　　　　 　 HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(ServiceUri);
　　　　　　　　　　　　　 //步骤三：将用户名和密码放置在HttpWebRequest对象的Credentials中
　　　　　　　　　　　　　　 request.Credentials = new NetworkCredential(userName, password);

　　　　　　　　　　　　　 //步骤四（：设置Http方法。HTTP方法与数据操作方法的对照： POST=create; PUT=update; DELETE=delete; GET=retrieve 。在这个例子中，我们需要create，所以选择POST方法。
　　　　　　　　　　　　 　 request.Method = "POST";

　　　　　　　　　　 　 //步骤五（蓝色部分）：传送数据到服务器。显然，这一部分只有在POST方法和PUT方法时才会有，对于GET方法和DELETE方法则不需要。

　　　　　　　　　　　　　　 UTF8Encoding encoding = new UTF8Encoding();
　　　　　　　　　　　　　　 request.ContentLength = encoding.GetByteCount(requestPayload);
　　　　　　　　　　　　　　 request.ContentType = XmlContentType;

　　　　　　　　　　　　　　 // 传送数据
　　　　　　　　　　　　　　 using (Stream reqStm = request.GetRequestStream())
　　　　　　　　　　　　　　 {
　　　　　　　　　　　　　　　　　　 reqStm.Write(encoding.GetBytes(requestPayload), 0, encoding.GetByteCount(requestPayload));
　　　　　　　　　　　　　　 } 　　　　　　　　　　　　
　　　　　　　　　 //步骤六 ：获取服务器响应，根据服务器的相应获取操作结果　　　
　　　　　　 HttpWebResponse response = (HttpWebResponse)request.GetResponse();
　　　　　　　　　　　　　　 if (response.StatusCode != HttpStatusCode.Created)
　　　　　　　　　　　　　　 {
　　　　　　　　　　　　　　　　　　 Console.WriteLine("Failed to create authority");
　　　　　　　　　　　　　　 }
　　　　　　　　　　　　　　 authorityUri = "https://" + authorityId + ".data.database./v1/";
　　　　　　　　　　 }
　　　　　　　　　　 catch (WebException ex)
　　　　　　　　　　 {
　　　　　　　　　　　　　　 Console.Error.WriteLine(ex);
　　　　　　　　　　　　　　 HttpWebResponse response = ex.Response as HttpWebResponse;
　　　　　　　　　　　　　　 if (response != null)
　　　　　　　　　　　　　　 {
　　　　　　　　　　　　　　　　　　 string errorMsg = ReadResponse(response);
　　　　　　　　　　　　　　　　　　 Console.WriteLine(string.Format("Error: {0}", errorMsg));
　　　　　　　　　　　　　　　　　　 Console.WriteLine("Unexpected status code returned: {0} ", response.StatusCode);
　　　　　　　　　　　　　　 }
　　　　　　　　　　 }

　　　　　　　　　　 return authorityUri;
　　　　　　 }

很简单吧？ 所有的操作与这个“万能框架”相似。例如，我们稍微做一些改动，就可以得到下面这样一个删除Entity的函数：

public　　 string　 DeleteEntity(string entityId)
　　　　　　 {
//由于删除是HTTP中的Delete操作，所以无步骤一和步骤五

string EntityUri = string.Format("https://{0}.data.database./v1/{1}/{2}",
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 authorityId, containerId, entityId);
　　　　　　　　 try
　　　　　　　　 {
//步骤二： WebRequest request = HttpWebRequest.Create(EntityUri);
//步骤三： request.Credentials = new NetworkCredential(userName, password);
//步骤四： request.Method = "DELETE";　　　　　　　　　　　　
//步骤六：using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
　　　　　　　　　　　　 {
　　　　　　　　　　　　　　　　 if (response.StatusCode != HttpStatusCode.OK)
　　　　　　　　　　　　　　　　 {
　　　　　　　　　　　　　　　　　　　　 Console.WriteLine("Failed to delete the entity resource.");
　　　　　　　　　　　　　　　　 }
　　　　　　　　　　　　 }
　　　　　　　　 }
　　　　　　　　 catch (WebException ex)
　　　　　　　　 {
　　　　　　　　　　　　 string errorMsg = ex.Message;
　　　　　　　　　　　　 Console.WriteLine("Deletion failed: {0}", errorMsg);

　　　　　　　　　　　　 if (ex.Response != null)
　　　　　　　　　　　　 {
　　　　　　　　　　　　　　　　 using (HttpWebResponse response = ex.Response as HttpWebResponse)
　　　　　　　　　　　　　　　　 {
　　　　　　　　　　　　　　　　　　　　　　　　 Console.WriteLine("Unexpected status code returned: {0}", response.StatusCode);
　　　　　　　　　　　　　　　　 }
　　　　　　　　　　　　 }
　　　　　　　　 }
}

　UPDATE的操作和"万能框架"中Create的方法基本雷同，唯一区别是在步骤4的地方，将"POST"改为"PUT"。比如以下这个函数：

　　读取数据就不用说了吧？呵呵。。那太容易了，就连把URI直接输入浏览器都可以。不过作为编程来说，其实就是在上面给出的DeleteEntity（）函数的代码中，步骤四的HTTP方法由DELETE改为GET，再大到HttpWebResponse 中去获取你想要获取的内容。

　　至此，数据库的四种操作（CRUD,Create,Read,Update,Delete）我们都已经讲过了。对，就是这么容易。

　　由于时间关系，我只在附件内写出了Authority,Container,Entity三种结构的Create操作。相信读者看完这篇文章后，自己改写成其他操作并非难事。

　　我正把SDS应用到我目前的项目之中。如果大家有兴趣的话，我争取过段时间提取一部分功能，做成Demo供大家参考。

 

在云端运行应用程序、存储和处理数据只是云计算的一部分。我们还想搭建云端服务(cloud-based services)。云端服务当然和普通的服务不同了，需要更多的管理和约束。.NET Services就是为填平这一空白存在的。例如，当今热门的"分布式应用程序"，如果使用到.NET Services提供的一些功能，就会变得很容易。本节主要从Overview的角度来介绍.NET Service。

　　 .NET Services在Azure Services Platform中的位置如下图所示。

　　

　　图片看不清楚？请点击这里查看原图（大图）。

　　 .NET Services首先是Services，我们可以在portal里对它们进行配置和管理，同时在程序里使用他。另外，和SQL Services一样，.NET Services不仅可以被云端程序使用，普通的应用程序也可以使用它。

　　 .NET Services包括三个部分：Access Control,Service Bus,Workflow。在接下来的几节中我们会介绍。本节只做概要介绍。

　　 Access Control :随着应用程序越来越复杂，角色越来越多，控制用户的access权限变得很重要。不仅单纯是网站页面的浏览权限问题，在各种服务中也需要，比如WCF服务。主流的解决反感是让用户提供token,应用程序根据token去判断权限。Access Control就是提供这样一种服务。她规定了自己的一种基于token规则。配置用户权限、识别token判断用户权限这些事再也不需要程序员自己来做了！Access Control会帮你完成得很好！

　　 Service Bus:　 这个功能太好解释了。"Service Bus"，顾名思义，就是把"Service"放在"Bus"里。事实也是这样，Service Bus就是把Web Service的EndPoint封装在一起，方便客户段使用者发现可以使用的Web Service，这就是Service Bus的主要功能。此外，Service Bus还有一牛x功能:网络地址转换和穿防火墙——以后有机会再慢慢说。

　　 Workflow :Workflow相信很多做.net开发的朋友已经再熟悉不过了。.NET Services提供的Workflow服务很容易理解：就是把平时大家用的本地WF逻辑运行在云端。这倒是一个非常实用的服务。

　　 清楚了吧？呵呵，其实Azure这一整套平台提供的都是"思想大于技术"的东西，不增加程序的负担，让开发者使用已有的技术体验到云计算带来的好处。

　　 在接下来的几节，我们还会通过讲解SDK里Samples的方式来带领大家快速了解.NET Services的各个部分，都非常容易，短时间内就可以掌握。

 

本节通过简短的语言讲解Microsoft .NET Services (Dec 2008 CTP) SDK里的实例，向大家展示Service Bus的入门知识。

　　 没有安装Microsoft .NET Services (Dec 2008 CTP) SDK的朋友直接直接下载本文附件使用。

　　使用实例：

　　 首先，打开Microsoft .NET Services (Dec 2008 CTP) SDKSamplesServiceBusGettingStartedEchoCS35 目录下的Visual Studio解决方案EchoSample.sln

　　图片看不清楚？请点击这里查看原图（大图）。

　　 在Service项目上点击右键，启用新实例。

　　 输入方案的用户名和密码。（在http://portal.ex.azure.microsoft.com中设置的）验证成功后控制台会给出一个类似"sb://servicebus./services/sixsix/EchoService”的URI。

　　图片看不清楚？请点击这里查看原图（大图）。

然后再启用一个客户端(Client)的调试实例。同样要求输入Solution名和密码。

　　图片看不清楚？请点击这里查看原图（大图）。

　　 此时客户端已经已经连上服务端的服务了。

　　 相信大家通过解决方案名都已经知道这个服务的作用了，很简单，就是客户段输入字符串到服务端，服务端向客户端传回同样的字符串。

　　图片看不清楚？请点击这里查看原图（大图）。

　　通过实例看Service Bus有啥用：

　　 显然，这个实例中使用的服务是网络编程中最基础的Echo服务。我们使用了Username/Password的验证方式。

　　 读者可以尝试关掉服务端。你会发现，客户端没有任何变化，只是不能再调用服务，不能得到echo而已。这说明Service Bus其实起了一个桥接作用。服务端程序无论运行在怎样的网络环境下，无论是在NAT之内还是公共环境，也不在乎这个服务的IP如何更改，甚至服务处于防火墙后面，客户端对其的定位依赖于Service Bus提供的统一URI，Service Bus为服务提供了注册与地址解析。在本例中，Echo服务的地址始终是"sb://servicebus./services/sixsix/EchoService/”，该服务的实际网络环境和地理位置，对客户机是完全透明的。这是上一节提到的，Service Bus的一个实用的牛X功能。

　　 另外，此时如果你打开http://servicebus./services/{your solution name}/，可以看到Service Bus把你Solution下的都以Atom 1.0 Feed的格式装在了"Bus"中（只显示当前可以使用的服务，也就是说，如果你关掉了服务端程序，就不会看到内容）。下面截图了显示了http://servicebus./services/sixsix/ 。"sixsix"是我的Solution名。目前这个Solution下只有1个echoservice。

　　

　　图片看不清楚？请点击这里查看原图（大图）。

　　明白Service Bus的使用方法和目的后，编程操作是很容易的。请自行查看代码。

 

最近有朋友问我：Windows Azure是不是一个微软官方提供的ASP.NET应用程序虚拟主机？

　　他的具体理解是这样的：Windows Azure提供了对ASP.NET应用程序的托管，并且，“云计算”离我们那么近，只要把ASP.NET应用程序部署到Window Azure 上，以前的ASP.NET应用程序就变成“云应用”了！

　　怎么说好呢？这种理解完全是受当今社会混乱的.NET虚拟主机市场逼出来的。Windows Azure作为Azure Services Platform的一号服务，如果你仅仅只用他来存放你已经过时的ASP.NET应用程序，那简直是杀鸡用牛刀、暴殄天物。

　　那么，Windows Azure应该怎么用？它到底比一般的虚拟主机牛在哪儿？那还的从Windows Azure的服务架构说起。

　　Roles(角色):

　　先说说角色问题吧，非常重要。不理解Windows Azure关于Role的概念，是没办法懂得微软煞费苦心的”云”的。

　　部署到Windows Azure上的程序扮演着以下两种角色：Web Role和Worker Role。

　　 Web Role：顾名思义，就是提供Web服务的角色。简单地说，Web Role就是ASP.NET Applicantion，是你本地ASP.NET Application的云端版本！支持HTTP/HTTPS协议，还能提供WCF服务。

　　 Worker Role：在后台运行的应用程序。它可以在后台访问任何网络资源、数据源并进行操作。它从来不在大庭广众前露面（不开放外部访问接口)，它接到命令后会毫无怨言地依次执行（Queue service里的消息队列能引导它的工作），它就像一个默默无闻的无私奉献者。可以拿Windows系统服务跟它类比，一旦启动，一直在后台运行。很爽吧？ 这个功能值得重视，大伙们看清楚了，这可是一般的虚拟主机无法提供的哦～ 就连Google引以为豪的云平台Google App Engine，至今已经更新了许多许多次，也从来没有考虑过让一段程序在后台长期运行！

这个Workder Role颇具有“云”的概念：一直在云端悄悄运行，地面上的人看不到它，但却不能没有它。

　　 所以，“云计算”并不是说只要你把“计算”放在“云”上就可以，而且彻底地让“计算”在“云”上运行。它包括以下几层含义：在云上——不需要本地服务器；云很大——计算量可以很大；无论在哪里，一抬头就是云——云平台上的应用无论在哪里、使用何种设备都能使用；躲在云里——它的计算过程无论有多复杂，地面上的使用者不需要看到它。

　　Role的附件

　　 Web Role和Worker Role这两个小朋友也是带了家属一起加入到Windows Azure这个大家庭的，它们暂时包括：

　　把Local Storage作为缓存使用

　　标准的Event Streams记录日志、发出警告

　　健康报告

　　 呵呵，这些也是普通的虚拟主机无法有的吧？ “云主机”的功能是非常强大的，配套是非常完善的！

　　服务定义（Service Definition）

　　 程序生活在Windows Azure这个新环境里往往会感到纳闷，会怀疑人生：我到底是Web Role还是Worker Role呢？

　　 这就需要我们来帮助它们了。

　　 Windows Azure使用了一类后缀.csdef的文件来定义服务。包括：这个服务到底似乎Web Role还是Worker Role？使用HTTp还是HTTPS ? 哪里去找Local Storage这个亲家来帮忙？诸如此类的信息。

　　图片看不清楚？请点击这里查看原图（大图）。

　　服务配置（Service Configuration）

　　 Web Role和Worder Role这两个小朋友在得到关于职业规划的答复后，又产生了对职业生涯方面的疑问：具体应该怎么做呢？

　　 这就需要用到服务配置了。顾名思义，就是对具体服务的具体配置了。我们采用.cscfg为后缀的文件来保存它们。它担当着与ASP.NET中的Web.Config文件类似的任务，且任务更重。　　　　

　　图片看不清楚？请点击这里查看原图（大图）。

　　 好了，说了这么多，相信读者已经对Window Azure的服务架构有了一个清晰的了解了。千万不要再把Windows Azure当作一般的.NET虚拟主机来使了哦～微软知道后会很受伤的！

 

相信大家看完本套教程前7篇后，已经对Azure Services Platform已经有了一个比较全面的了解。现在我们一起动动手，以最最简单的留言板为例，使用Azure Services Platform中的的Windows Azure作为主机、SQL Data Services作为数据存储，来了解开发、部署Azure应用程序的全过程。

　　如果您的准备只是还不够充分，请先选择性地快速浏览以下几篇文章：

　　【准备知识0】INTRODUCING THE AZURE SERVICES PLATFORM

　　【准备知识1】忘掉SQL Server 200X——Introducing SQL Data Services(SDS)

　　【准备知识2】别把Windows Azure当虚拟主机使—理解Windows Azure服务架构

　　【准备知识3】赤手空拳玩转 SQL Data Services(SDS)

　　【准备知识4】SQL Data Services 编程基础

　　最终效果图如下：（也可通过http://ibm.查看网络版本)

　　开发过程：

　　1.启动本机Windows Azure SDK里的Development Fabric，打开本机的调试运行环境。

　　2.打开VS2008，新建Visual C# – Cloud Service – Web Cloud Service项目。本例非常简单，只需要使用Web Role。

　　关于Web Role和Worker Role的区别于联系，请参考【准备知识2】。

　　图片看不清楚？请点击这里查看原图（大图）。

　　新建项目后，解决方案中将出现GuestBook和GuestBook_WebRole两个项目。其中GuestBook是关于Roles的配置文件，在本例中可以不去理会它。本例主要操作的是GuestBook_WebRole项目，即一个ASP.NET网站项目。

　

　　3.打开SQL Data Services SDK里的SDS Explorer。配置好用户名、密码；新建Authority和Container。 具体操作过程请参考【准备知识3】。

　　图片看不清楚？请点击这里查看原图（大图）。　
 

　　图片看不清楚？请点击这里查看原图（大图）。

　　4.在这里，我们新建了名叫“guestbook”的Authority和一个叫做“1st”的Container。现在我们将它们配置到GuestBook_WebRole项目的web.config文件里面，以便程序读取。

　　5.在GuestBook_WebRole中新建CloudDataHelper类。里面写入对SQL Data Service的一些基本操作。详细代码见附件。

　　以下是读取配置文件和存储数据的函数示例。

　　6.在Default.aspx页中拖入几个控件和简单的逻辑代码。呵呵，这就不用我教了吧？详细内容同样包含在附件里。

　　7.F5进行Debug运行。如果运行成功的话，首页会出现在你的面前——就像调试传统的ASP.NET Web Application一样。同时，在Development Fabric里会出现一些相关的信息。

　　8.如果你已经对Debug的效果满意，那么就需要将我们的第一个“云端应用”部署到“云”上面去咯～

　　 在GuestBook项目上单击右键，选择Publish(发布)

　　如果发布成功，此时VS会弹出两个框在你面前：

　　包含发布文件的文件夹和Azure Services Developer Portal(需用LiveID登录)

　

　　图片看不清楚？请点击这里查看原图（大图）。　

　　9.在Azure Services Developer Portal里新建“Windows Azure”-“Hosted Services”项目。填写一些简单的信息。

　　如果你有关于Azure Services Developer Portal的疑问，请参考【准备知识0】.

　　图片看不清楚？请点击这里查看原图（大图）。

　　图片看不清楚？请点击这里查看原图（大图）。

　　10.介绍一下Hosted Service的主界面吧：如下图。每个Host在Windows Azure上的应用程序包括两种状态（或者理解为两个不同的部署平台）：Production和Staging. 简单地说，Production是正式部署的地方，Staging是放内部测试部署的备份服务器。

　　图片看不清楚？请点击这里查看原图（大图）。

　　11.我们先把我们的应用程序部署到Staging服务器上。点击上图中的Deploy按钮，进入以下界面。根据提示上传刚才Publish时生成的两个文件。

　　图片看不清楚？请点击这里查看原图（大图）。

　　12.在Staging服务器上Deploy成功后，点击下图中间的圆圈，将Staging服务器上的内容交换到Production服务器上，并点击”Run”按钮。注意：这两个过程都需要较长的等待。

　　图片看不清楚？请点击这里查看原图（大图）。

　　13.如果部署成功，你会看到类似下图的界面。当“WebRole”标识下出现绿色的小勾并带有”Started”字样，说明此时你已经可以在网络上访问你的“云应用程序”了。如http://ibm.

　　图片看不清楚？请点击这里查看原图（大图）。

 

在本系列的第一篇【Azure Services Platform Step by Step-第1篇】INTRODUCING THE AZURE SERVICES PLATFORM里就介绍过了，Azure Services Platform包括4个部分。其中，Windows Azure是支撑整个微软云平台(Azure Services Platform)的基础。换句话说，Windows Azure是“云平台的操作系统”,它提供了云平台最基本、最重要的服务。

　　图片看不清楚？请点击这里查看原图（大图）。

　　Windows Azure由两个重要部分构成：

　　虚拟化计算服务（提供基于VM主机。在上一篇里已经示范过它。）

　　各种数据存储服务。即本文要介绍的Windows Azure Storage。

　　Windows Azure Storage可以让程序员存储他们想存储的任何数据。按照“云计算”的概念，数据一旦存储到“云”中，就永远不会丢失，程序员可以在任何时候、从任何终端和任何地方获取任意大小的数据。Windows Azure Storage正是继续遵循这一思想。

　　Windows Azure Storage由三个重要部分构成：

　　Windows Azure Blob：存储大型数据

　　Windows Azure Table:存储表数据。类似关系数据库中的数据表，但不同。

　　Windows Azure Queue:为异步工作提供分派消息服务。有点类似Windows系统自身的消息队列。

　　接下来我们来以此介绍这3个数据服务。

　　Windows Azure Blob

　　 刚才说过了，这个牛X的服务，就是用来存储大型的数据的。怎么样的数据算大型呢？文件！不知道你是否和笔者一样，刚看到这个服务时第一个反应就是：用它来做网络硬盘。: )

　　 Windows Azure Blob的数据模型非常简单，看一眼就不会忘记。我们真的大可以把它想象成云端的一个无限大的硬盘。它的结构如下图：

　　图片看不清楚？请点击这里查看原图（大图）。

　　 大家先别看“Block”部分。很一目了然吧？ 一起继续YY:　 如果Account是那块硬盘，Container就代表不同分区（可惜分区里没有文件夹概念），Blob就是分区根目录里不同的文件。那么上图的意思是：在我的那块叫做"sally”的硬盘里，有"pictures”和"movies”两个分区，"pictures”分区根目录里有"IMG001.JPG “”IMG002.JPG”这两个文件。

　　 这块云端的无限大硬盘在哪里呢？怎样才能找到它？也很简单，它仍然采用Azure的管理，使用REST的方式操作它。地址是：

　　 http://<account>.blob.core./<container>/<blobname>

　　 例如：http://maheshwar.blob.core./livesearchimages/AcacusDesert_EN-US1025081982.jpg （这是一张图片，点击链接可直接访问)

　　 现在可以继续解释上图中的“Block”了。既然是采用REST的方式，就是通过HTTP的方式，那么真正很大很大的文件，比如1G的电影，要直接传上去显然是一件非常困难的事。Block就是为解决这个问题而存在的。只要你心情好，你大可以把这个电影分割成1000个1M的Block来上传。Block对下载流程是透明的，下载者根本不知道也不用去知道它正在下载的文件被分成了多少个block。

（事实上笔者真的用它做自用的网络硬盘，从开发和使用角度来说都非常方便，以后有机会我整理一下代码与大家分享一下）。

　　Windows Azure Table

　　 这个服务是很多人心中的最爱。

　　 正在使用VS200X来开发简单ASP.NET应用程序的时候，你会许和很多人一样有以下两个重要习惯：使用关系数据库（如SQL Server）；数据库中的某些表直接对应程序里的实体类。你或许会使用代码生成工具，ORM工具，或者自己写三层架构来完成关系数据库to对象的映射。发现没，此时的你是多么希望能够直接将实体存入数据库当中啊!

　　 Windows Azure Table服务就是用来解决这个问题的。它可以直接将实体类、实体对象存入表格结构当中。它让太多的人感到欣喜。

　　 它比较类似传统关系数据库当中的表格，但是又有很大不同。先看下图的结构：

　　图片看不清楚？请点击这里查看原图（大图）。

　　 与你想的一样，它支持LINQ, REST。HTTP地址是　　　　　 http://<account>.table.core.

　　 这部分内容比较多，过几天我会单独使用一节的内容来做一个简单Demo讲解它的使用。

 

　　Windows Azure Queue

　　 Windows Azure Queue因为Windows Azure的服务架构而存在——这个一个需要消息队列的架构。

　　 我们在《【Azure Services Platform Step by Step-第7篇】别把Windows Azure当虚拟主机使——理解Windows Azure服务架构》里了解过，Windows Azure VM中是如何引入了Web Role和Worker Role这一非常创新的概念，从而脱离了普通虚拟主机，晋升为“云主机” : )

Windows Azure Queue最常见的一个应用就是作为Worker Role和Web Role之间通讯的消息队列。

　　 再举个例子。Web Role是前台卖牛肉面的，Worker Role是后台煮牛肉面的。顾客只能接触到Web Role这个店员，它收集不同顾客的需求，保持先来后到的顺序记录这些需求到一叠纸条上递给大厨Worker Roler。大厨Worker Role带着口罩，什么话也说不出来，他的工作就是按顺序完成纸条记录的任务。Windows Azure Queue就充当了这个“任务纸条”的作用。

　　 理解完了“牛肉面”的例子，再看看下图结合一下“云计算”的实际吧。是不是很容易理解呢？

　　图片看不清楚？请点击这里查看原图（大图）。

 

　　Windows Azure Table 与SQL Data Services 的重要不同之处：

　　 在实际开发中，这两者都是最常用的数据存储服务。

　　 博客园网友 montaque和老赵同志在《【Azure Services Platform Step by Step-第8篇】开发部署Azure留言板》一文的评论中一起讨论了Windows Azure Table和SQL Data Services的不同。

　　Windows Azure Table 旨在提供轻便快捷低成本的大规模存储数据，包含实体和属性。它不是关系数据库，所以不能提供类似SQL中joins的方法,也不能管理 foreign keys。

　　SQL Data Services旨在提供严谨的关系数据方法。

　　在当前的Azure版本中(Azure平台第一个版本，feasure还很不完善)，如果开发者对joins或foreign keys等关系数据库的功能需求较大，你可以选择SQL Data Services，反之建议使用开发更为快捷的Windows Azure Table。