通过

云形标计算

构建分布式应用程序使用.NET 服务

Aaron Skonnard

本文基于.NET 服务的预发布版本。如更改，恕所有信息。

本文讨论：

  • 了解.NET 服务
  • Confi guring.NET 访问控制服务
  • 通过.NET 服务总线通信
  • 生成一个群 workfl Ow
 本文涉及以下技术：
azure 服务平台.NET 服务

内容

.NET 服务
什么是.NET 服务中？
创建.NET 服务解决方案
安装.NET 服务 SDK
在.NET 访问控制服务
配置服务
.NET 服务总线
通过.NET 服务总线通信
.NET 工作流服务
生成群工作流

在 2008 专业开发人员会议 (PDC) 在 Los Angeles Microsoft 宣布雄心勃勃新群将展开下一次的几年的计算策略。Microsoft 群平台正式称为在 Azure Services 平台，便于移动到群使用相同的工具和 API，它们已经熟悉其应用程序 （或混合的部分） 的.NET 开发人员。

Windows Azure 展示了 Microsoft 群平台的基础。将 Windows Azure 视为在基于 Windows 的群的操作系统。它在运行.NET 应用程序和整个世界上将数据存储在 Microsoft 数据中心提供与高度可缩放的执行环境。构建 Windows Azure 上的应用程序可以 shield 您许多在应用程序允许您将主要精力放而在开发和您的业务昂贵和麻烦的基础结构方面。

Microsoft 提供了几个基于 Windows Azure Foundation 中包括.NET 服务、 SQL 服务、 Live 服务、 SharePoint Services，等服务。组合这些服务使用 Windows Azure Foundation 形成完整的 Azure 服务平台 （请参见 图 1 ）。这些服务的每个包含多个单个服务可以在应用程序中选择时调用的。Microsoft 是积极地构建在应用不同使用者面向程序如 Windows Live、 Microsoft Office Live、 Microsoft Exchange 联机、 Microsoft SharePoint 联机，Azure 服务平台上以及其他人。您有机会执行相同，利用任何 Azure 服务提供值给您。

fig01.gif

图 1 </a0>-Azure 服务平台

本文的其余我将深入讨论在基于 11 月 / 12 月 2008 CTP 版本下的 Azure Services 平台内在.NET 服务提供。可以看到在 图 1 ，则这是仅一小段更广泛的群平台策略，但这是.NET 开发人员向群移动的特定兴趣之一。

.NET 服务

如果您认为自己 Microsoft 连接系统的开发人员使用 （如 Windows Communication Foundation (WCF)、 Windows Workflow Foundation (WF) 和 BizTalk Server 的技术，将要支付到.NET 服务的特别注意。这是您关心的技术的大多数 Azure 服务平台的显示位置。（很有趣要注意 incubation 项目的原始名称是"BizTalk 服务"。 正式的名称-.NET 服务已公布在随 Windows Azure PDC)

如果您愿意可以将 Windows Azure 看作"Windows 在您可以视为.NET 服务"在 Microsoft.NET Framework 在"。 今天，.NET 开发人员利用大量.NET Framework 构建针对 Windows 平台的应用程序。.NET Framework 提供许多的应用程序所需的公共构造块，从而使其易于获取这些设置和运行快速。在.NET 服务发挥了类似作用在 Azure Services 平台，从而使其更易于编写基于云模型的应用程序一些常见构建基块。

尽管在的相似性还有.NET Framework 和.NET 服务一个显著区别。虽然.NET Framework 提供了构建基块.NET 程序集的形式，.NET 服务将提供托管服务的形式构建基块 Microsoft 数据中心内运行。当使用.NET 服务，还有您的内部部署的逻辑和运行在该.NET 服务之间具有清晰边界。就工作来撰写到您的业务解决方案的这些服务。Microsoft 都将承载、 管理，和维护您的应用程序所依赖的托管的服务。

您计划对.NET 服务通过集成单个服务它提供。虽然的名为".NET"服务，但您实际上不必使用.NET 来完成此，您可以与集成.NET 服务通过标准的 SOAP 和 REST 等它公开的接口。Microsoft 提供了优化了.NET 开发体验一个.NET 服务 SDK，甚至 Java 和拼音 SDK 可从社区。

什么是.NET 服务中？

如果考虑将需要将您的应用程序到群平台，有几个常见的要求您将最可能遇到。首先，您需要一种描述和打包您的业务流程或工作流，以便可以被执行并管理群。第二个，您将需要一种基于云模型的工作流和内部部署应用程序，之间通信的方法遍历任何防火墙或网络地址转换 (NAT) 设备的方式可能的。第三个，需要一种安全的通信和控制访问各种基于云模型资源的方法。

大多数群应用程序需要处理至少一个这些要求。如果您有自己生成这种类型的基础结构，它极大地将更改整个价值主张。这些是精确地在区域的.NET 服务重点 11 月 / 12 月 2008 CTP 版本中。

具体来说，.NET 服务满足通过三个各个构建基块服务这些群基础结构需求：.NET 工作流服务，在.NET 服务总线和.NET 访问控制服务 （请参阅图 2有关详细信息）。

图 2.NET 服务组件
服务 说明
.NET 工作流服务 此组件提供了用于承载和管理 Azure 服务平台的 WF 工作流基础结构。它还用于部署、 管理，和跟踪运行工作流实例提供群为中心的活动和工具。
.NET 服务总线 此组件提供中继服务，使跨组织边界建立到群的连接。此关键基础结构允许基于云模型工作流与内部部署的应用程序通过遍历防火墙和 NAT 设备。
.NET 访问控制服务 此组件提供了的基于声明的访问控制机制，在使用 WS-Security 的功能所撰写的。它还满足包括与 Active Directory 和 Windows Live ID。 标识提供者互操作性的大多数群方案中固有的联盟要求

.NET 服务总线依赖于.NET 访问控制服务控制对中继发件人和侦听器服务的访问。这意味着所有发件人和侦听程序必须首先获取令牌从.NET 访问控制服务才能使用.NET 服务总线。.NET 工作流服务与.NET 服务总线，以使其可以传输邮件通过中继服务集成启用各种基于云模型的工作流中的有趣通信方案。共同这些服务将用于构建应用程序在提供出色的开发结构。

创建.NET 服务解决方案

您可以开始使用.NET 服务之前，您需要访问在azure 服务平台门户并创建一个解决方案。本文基于 11 月 / 12 月 2008 CTP 版本中，在创建.NET 服务解决方案之前，将需要一个邀请标记。您可以获取一个邀请标记按照在"尝试现在"在 Azure Services 平台 Portal.Windows Azure 上的链接并.NET 服务需要不同的邀请令牌，请确保您请求一个.NET 服务标记过。一旦批准，您将收到您的.NET 服务邀请令牌，通过电子邮件。

一旦您已收到的邀请代码，您可以浏览到在门户中的.NET 服务区域，并创建新的解决方案。您必须输入一个有效的邀请代码并指定一个解决方案的名称，然后它将提供一个新的.NET 服务解决方案并提供解决方案的密码。(解决方案名称用作用户名进行身份验证)。

提供的过程将会要求您登录使用一个 Windows Live ID (WLID)，因此新的解决方案可以与您的帐户相关联。多个解决方案可以与一个单一的 WLID，但每个解决方案需要一个唯一的邀请代码今天。到门户登录使用您 WLID 时您将看到您在"解决我方案"在页面的右侧下列出的解决方案的所有。选择特定的解决方案时, 它可管理的.NET 服务的特定解决方案中的不同方面一个网页 （请参见 图 3 ）。

fig03.gif

图 3 管理解决方案

解决方案基本上是管理不同的.NET 服务资产一个顶级容器。例如，它的.NET 服务的总线终结点，您的.NET 工作流服务类型和实例和.NET 访问控件服务身份标识容器，并声明转换规则。

安装.NET 服务 SDK

此外需要下载并安装.NET 服务 SDK 还可以获取从 Azure 服务平台门户。当您安装 SDK 时，它将添加多个.NET 程序集您的计算机和使其更易于以编程方式集成.NET 服务一些 Visual Studio 加载。

可以在安装目录默认情况下位于 \ Program Files\Microsoft.NET Services SDK 中找到新的程序集。密钥集包括 Microsoft.ServiceBus.dll、 Microsoft.Workflow.activities.dll，和 Microsoft.AccessControl.Management.dll。安装目录也包含说明如何使用每个服务和主要功能由每个服务提供的示例。请务必查看各种示例，当您开始您的过程。

如果您启动 Visual Studio 时，您还会注意到新项目模板称为 CloudSequentialWorkflow （在下 CloudWorkflow 项目类型）。使用此项目模板来创建要承载.NET 工作流服务中的 WF 工作流。SDK 还会安装更易于将您的工作流部署到.NET 工作流服务一个 Visual Studio 加载项。

很有趣要注意.NET 服务的实现实际上派生 fromWCF 和.NET Framework 3.5 中的 WF。.NET 服务 SDK 就能够基于该 Synergy 为了让使用者开发人员的体验尽可能为简单那些已经熟悉 WCF 和 WF 编程模型。如果您在该 camp，编程.NET 服务的机制会感到很自然要。最后的主要是一项学习.NET 服务总线） 一些新 WCF 绑定 (、 配置这些的绑定和了解.NET 工作流服务） 的某些新的活动。

在将其余的部分我将请快速查看每个服务中，并遍历使用每个的示例。结束，应该感到熟悉如何开始您自己。

在.NET 访问控制服务

我们先来看.NET 访问控制服务。在过去的几年 Microsoft 已向因素身份验证和授权决定出您的应用程序并到可以安全专家集中维护的外部服务允许您的基于声明的标识模型的移动。在这种模型下安全专家控制对用户进行身份验证，并发出有关用户声明的过程。您的应用程序只需信任提供该服务的声明然后根据这些声明 （避免身份验证） 做出决定。

使用基于声明的标识模型时, 用户提供其标识为声明一组应用程序。声明是有关用户的只是声明，也可以是任何内容 （如名称、 一个电子邮件地址或反馈分级。声明是由一个知道如何将用户和其属性 （可能是从企业目录） 进行身份验证的标识提供者提供的。客户端应用程序以透明方式使用颁发机构获得这些声明，并向该应用程序中显示它们。

Microsoft.NET 访问控制服务是便于 Azure 服务平台意识到此模型在集中式基于云模型服务。目前，.NET 访问控制服务可以作为一个标识提供者 （通过验证通过设置过程期间分配的解决方案凭据的用户） 但这不真正它是为了执行。它旨在主要依赖于现有的身份提供程序 （如 WLID 和"Geneva Server 安全性令牌服务或支持标准的联合身份验证协议的任何标识提供者。这使得 Single Sign-on 自然的结果。

.NET 访问控制的主要职责服务是提供一组对您的应用程序有用的声明。这通常表示为一组的输出声明具有到您的应用程序的含义的转换 （来自如 WLID 或"Geneva Server 一个标识提供者） 的输入的声明。可以将其视为在一个可配置的声明转换引擎。

配置服务

您配置.NET 访问控制服务通过管理门户提供特定的解决方案中 （请参见 图 4 ）。这是可以配置确定如何它会发出声明为用户知道有关或的转换来自其他提供程序的声明的规则。

fig04.gif

图 4 .NET 访问控制服务管理门户

而不是配置我自己的一个示例服务，我将向您展示如何.NET 访问控制服务配置为.NET 服务总线。如果您单击高级按钮管理门户中，您看到的解决方案名称表示不同的作用域的所有者的下拉。作用域是声明转换规则的集合。当我为我的帐户选择服务总线解决方案时，它显示作用的域

http://servicebus.Windows。net / 服务 / pluralsight /

使用.NET 服务总线时, 您将配置此服务总线范围用作该基本 URI （您将进行自定义您的帐户的） 的终结点。每个解决方案提供了一组.NET 服务总线和.NET 工作流服务的访问控制规则的预配置。

如果单击管理，您可以检查规则配置为在特定范围内的列表 （请参见 图 5 ）。在这个特别的示例有查找包含 pluralsight 值的传入用户名声明的两个规则。一个生成发送一个输出声明，并另生成侦听的一个输出声明。.NET 服务总线开发以查找这些声明来控制对其终结点命名空间的访问。提供发送声明的任何用户能够将消息发送到范围 URI，并提供了侦听声明的任何用户将允许在作用域 URI 创建一个侦听。如果我删除生成将发送令牌的规则，pluralsight 帐户将再也无法发送通过.NET 服务消息总线此范围内，将只能侦听。

fig05.gif

图 5 Confi guring 规则的一个作用域

很容易将类似的支持添加到您自己的服务。您只需定义新的作用域在管理门户中的 URI，然后定义所需生成声明的规则期望您 Service.within 服务逻辑，您需要编写代码来检查传入的声明，使授权决策基于有何种声明和它们所包含。WCF 和新的"Geneva 框架使这通过其基于声明的编程模型。请有关完整的示例参阅该.NET 访问控件服务入门示例 SDK 中。

.NET 服务总线

.NET 服务总线的主要重点是提供在具挑战性由于到不断这样的常见的防火墙的 Internet 作用域和限制在大多数环境中的入站的通信的 NAT 设备的双向连接。.NET 服务总线完成这通过提供在提供必需的网络遍历逻辑的集中式的中继服务 （请参见 图 6 ）。

fig06.gif

图 6 .NET 服务总线中继

中继使得发件人与接收端通过聚合地址。接收方连接到通过一个出站端口中继，并创建双向套接字的指定它要侦听的聚合地址的通信。然后，发件人可以传输接收方指定相同的聚合地址中继邮件。当中继收到消息时, 它将邮件将相应的侦听器 （或侦听程序在多播的情况下） 共享相同的聚合地址的。中继传输消息接收方通过双向套接字已在这意味着任何入站的端口所需的接收器的位置。这会说明原因机制的工作方式通过防火墙和 NAT 设备 （如典型的聊天应用程序）。

.NET 服务总线支持多种邮件样式包括单向、 请求响应和甚至发布的订阅。它支持 HTTP 和 TCP 通信，根据您是关心互操作性和性能。中继甚至可用于一种模式协商基于端口的预测算法的两个对等机器节点之间的直接 TCP 连接。绕过中继允许更高的吞吐量传输较大的邮件时。总体，.NET 服务总线提供了极灵活地适应各种今天的最常见的通信方案。

了解如何构造为您的.NET 服务总线终结点 URI 重要的。当您提供一个的基于 TCP 端点时，就需要构建您的地址，如下所示：

sb://servicebus.windows.net/services/{solution}/{name}/{name}/...

当您提供基于的 HTTP 地址时，http 时只需替换 sb 协议方案。请注意您指定您的解决方案名称作为地址的一部分以将端点分开所使用的.NET 服务总线整个其他解决方案。这是被用作.NET 访问控制服务配置中的 URI 范围在同一个地址。在解决方案名称之后，您可以指定您想为您的终结点使用任何 URI 名称层次结构的完全控制。

发件人和接收器需要显示发送或收听到.NET 服务总线 (从.NET 访问控制服务获得） 的声明中才发送或在特定的地址上侦听。由于.NET 服务总线具有信任关系与.NET 访问控制服务，就能够读取该安全令牌，它颁发的并处理这些声明。没有这些的声明不能使用中继 （除非特定终结点已被配置以允许可能的匿名发送）。

与.NET 服务总线中继集成最简单的方法是随 SDK 提供的新 WCF 中继绑定。没有大多数内置的 WCF HTTP / TCP 绑定 （参见 图 7 ） 的等效的中继绑定。还有几个新的没有 NetOneWayRelayBinding （对于严格的单向 traversals) 和 NetEventRelayBinding （对于单向多播方案，通常用于发布 / 订阅） 一个清除副本的。当而不是标准绑定使用中继绑定、 基本的 WCF 信道组件负责与.NET 访问控制服务，并在后台中继通信和您的代码甚至可能需要更改。

图 7 WCF 中继绑定
标准的 WCF 绑定 等效的中继绑定
BasicHttpBinding BasicHttpRelayBinding
WebHttpBinding WebHttpRelayBinding
WSHttpBinding WSHttpRelayBinding
WS2007HttpBinding WS2007HttpRelayBinding
WSHttpContextBinding WSHttpRelayContextBinding
WS2007HttpFederationBinding WS2007HttpRelayFederationBinding
NetTcpBinding NetTcpRelayBinding
NetTcpContextBinding NetTcpRelayContextBinding
N/A NetOnewayRelayBinding
N/A NetEventRelayBinding

.NET 服务总线还提供了源的子组件的形式的服务注册表。在解决方案通过标准的 HTTP GET 请求的基本地址提供此订阅源。源将自动包含的所有活动的侦听器终结点 （特定的解决方案中的信息。

通过.NET 服务总线通信

现在让我们遍历通过使用发布 / 订阅模型在.NET 服务总线进行通信的完整示例。首先，假设我有以下服务约定：

[ServiceContract(Namespace = "")]
public interface ITweetNotifier {
  [OperationContract(IsOneWay = true, 
    Action = "urn:DisplayTweet")]
  void DisplayTweet(string status);
}

假设我有承载服务 （称为 TweetNotifierApp） 只是打印传入的状态文本，向控制台窗口的应用程序，没什么特别之它。

我可以将主机应用程序通过.NET 服务总线侦听定义终结点使用中继绑定配置。 因为我想要实现发布 / 订阅 （可能为多个侦听器），我将需要使用该 NetEventRelayBinding，如 图 8 所示。

图 8 NetEventRelayBinding

<configuration>
  <system.serviceModel>
    <behaviors>
      <endpointBehaviors>
        <behavior name="Default">
          <transportClientEndpointBehavior 
            credentialType="UserNamePassword">
            <clientCredentials>
              <userNamePassword 
                userName="pluralsight" 
                password="{password}"/>
            </clientCredentials>
          </transportClientEndpointBehavior>
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
      <service name="TweetServiceLibrary.TweetService">
       <endpoint address="sb://servicebus.windows.net/services/pluralsight/tweet"
            behaviorConfiguration="Default" 
            binding="netEventRelayBinding"
            bindingConfiguration="" 
            contract="TweetServiceLibrary.ITweetNotifier" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

请注意，我还使用指示 WCF 将发送到.NET 何种凭据访问验证并获取所需的.NET 服务总线声明的控制服务的特殊情况。 将要替换用户名和密码使用您自己的凭据如果您尝试运行此示例。

当我运行宿主应用程序时，WCF 托管基础结构自动通过.NET 访问控制服务的身份验证，获取声明，然后打开到.NET 服务总线的出站端口并注册指定的地址上的侦听程序。 此时，本地托管的服务就可以接收通过.NET 服务总线在指定的地址上中继的邮件。 我还可以浏览到解决方案，此时可以访问源的服务注册表的基址，并且任何活动的侦听器端点将显示源中。

现在我可以编写客户端应用程序通过相同的聚合地址上的.NET 服务总线发送邮件。 此处的我的客户端程序如下所示：

static void Main(string[] args) {
  ChannelFactory<ITweetNotifier> cf = 
    new ChannelFactory<ITweetNotifier>("tweetService");
  ITweetNotifier tweetNotifier = cf.CreateChannel();

  Console.WriteLine("Enter a status update: ");
  string status = Console.ReadLine();
  while (!status.Equals("")) {
    tweetNotifier.DisplayTweet(status);
    status = Console.ReadLine();
  }
}

客户端配置文件需要看起来就像主机配置文件。仅在终结点定义需要 <client> 部分中的显示。除此之外，它应该查看有关相同，包括在 <transportclientendpointbehavior> 客户端端点上配置。

使用此位置，我可以运行跟客户端应用程序的单个实例宿主应用程序的多个实例并我查看的所有邮件中继在一个多址广播方式 （请参见 图 9 ）。中继即使在宿主应用程序位于防火墙或 NAT 设备。

fig09.gif

图 9 运行.NET 服务总线演示

这是支持的.NET 服务总线的许多可能的通信方案的一个示例。有关更多的示例请参阅.NET Services SDK 中提供不同的.NET 服务总线示例。

.NET 工作流服务

向群移动计算工作流将一种简单的方法用于协调复杂服务交互复合群解决方案中生成。

.NET 工作流服务为提供了可伸缩宿主环境运行和管理在 WF 工作流。因为宿主环境基于窗口 Azure，就能够根据，缩放，因为正在使用 WF 运行时，将工作流实例不固定到特定的服务器它们能够将从一个服务器移动到另一个 （在 Windows Azure） 的执行的每个情节。.NET 工作流服务依赖于一个 WF 持久性服务，利用 Microsoft SQL 服务要保存正在运行的工作流的状态并确保恢复能力的。

您构建群使用 Visual Studio 及相同工作流设计器已始终使用的工作流。您最终创建 XAML 工作流和规则文件。这些 XML 文件然后部署到.NET 工作流服务，可用于创建工作流实例。

.NET 服务 SDK 包含用于创建一个 SequentialCloudWorkflow 标准 SequentialWorkflow 模板的专用的版本的项目模板。定义要在运行的工作流时, 还有限制您可以使用工作流中的活动。可以使用仅在 WF 文章活动库中活动的子集，以及一套新的自定义的群活动作为.NET Services SDK 的一部分提供的 （请参见 图 10 ）。这些群活动使您可以发送、 接收，并处理消息，但一下今天。更多的活动将被添加在将来增强您的基于云模型工作流的功能的版本。

图 10 群工作流活动
活动 说明
CloudHttpReceive 收到 HTTP 请求发送到工作流实例的特定 URL
CloudHttpSend 调用指定的 URL 上的 HTTP GET 或 POST 操作，并获得响应
CloudServiceBusSend 将消息发送到.NET ServiceBus 上的特定终结点
CloudXPathRead 读取指定的输入 XML 文档中的数据
CloudXPathUpdate 设置指定输入 XML 文档中的数据
CloudDelay 等待指定的时间范围

与其他服务一样.NET 工作流服务附带的管理门户管理工作流类型和实例。.NET 服务 SDK 还附带了客户端管理 API，允许您以编程方式完成相同的事情。

fig11.gif

图 11 完成的工作流设计

生成群工作流

若要查看.NET 工作流服务的工作方式，让我们构建使用公用的 Twitter 源，并将最新的项发送给所有已订阅的 TweetNotifierApp 实例通过.NET 服务总线的工作流。

首先我需要做的是 Visual Studio 2008 中创建一个新的 CloudSequentialWorkflow 项目。我将调用它 MonitorTwitterFeed。到目前为止您应该看到传统 WF 设计器。如果您展开活动工具箱，您看到活动，您要允许使用受限制的的集。

我需要使用一段连续轮询公用 Twitter 的活动源每隔 60 秒。因此首先我将 While 活动到工作流设计表面，然后指定的条件是声明性规则条件。本示例用于，我制作条件始终返回"True。 接下来，我将一系列活动拖到 While 活动定义的我要重复的步骤顺序。

现在，我想要这样我将一个 CloudDelay 活动拖到系列，并指定超时值的 00:01:00 延迟 60 的秒。我需要检索公用的 Twitter 源使用的 HTTP GET 请求，以便将右下方 CloudDelay 活动一个 CloudHttpSend 活动并正确配置 （设置方法 GET 和 http://twitter.com/statuses/public\_timeline.xml URL）。

接下来，我需要最新状态项读取该源所做可能通过 CloudXPathRead 活动的顶部。后置于此顺序，我绑 InXml 属性定到上一个活动的响应属性中。我也设置状态的状态 / 文本指定 XPath 表达式 InXPathExpression。

接下来，我需要生成将发送到通过.NET 服务总线 TweetNotifierApp 相应的 XML 消息。我可以完成此操作通过 CloudXPathUpdate 活动。目标服务需要一条消息，如下所示：

<displaytweet> <text> 此处显示状态 </text> </displaytweet>

因此后放置到序列 CloudXPathUpdate 活动，我需要 InXml 属性中输入 XML，使用"/ DisplayTweet 文本"进行 InXPathExpression。我还需要将 InNewValue 绑定到上一活动 OutReadValue 属性。这实质上告诉活动如何构造一个新的 XML 文档通过 XML 模板中插入一个输入的值 （最新状态）。

最后，我需要指示发送该邮件通过.NET 服务总线工作流。这是其中 CloudServiceBusSend 活动有。之后将放它序列的末尾，我设置操作为 urn: DisplayTweet、 为多址广播，ConnectionMode 和 sb://servicebus.Windows 地址。net / 服务 / pluralsight / tweet。我定 Body 属性绑定到上一活动 OutXml 属性时。在位置与，工作流已完成。为生成的工作流设计的一个完整 Visual 参见 图 11 。

右键现在，来部署和测试工作流，我只需单击工作流设计表面，然后选择部署工作流。我输入您的解决方案凭据，然后按部署和运行。加载项会将您的 XAML 定义上载到.NET 工作流服务，并启动它的一个实例。也就可以上载管理门户上的窗体通过手动在 XAML 定义。

您已经部署工作流后，您可以浏览到管理门户，并查看工作流类型和正在运行的实例。如果有任何实例运行的 TweetNotifierApp，您看到的 Twitter 邮件显示每隔 60 秒。

Aaron Skonnard 是 Pluralsight，提供同时教师指导和点播 Microsoft 开发人员课程培训提供商的创始人之一。这些日期 Aaron 花费大部分时间录制 Pluralsight 点播 ！课程重点群计算、 Windows Azure，WCF 和 REST 等。Aaron 编写、 说，和向世界各地的专业开发人员讲授的年。您可以 brian.noyespluralsight.com/Aaron.