下面是修改Total值之后的测试流程：

  1.首先重复上面在AZURE平台上创建工作流实例的步骤，以便生成新的实例ID供客户端config文件更新节点配置。
   
  2.将client的运行代码从800改为1400,然后顺序启动上面的service,client应用，这时我们还是会看到之前运行的service端和client端的运行界面，只是这次服务端在客户端提提交请求之后，并未马上返回打印结果，而是运行了cloudDelay活动，这时如果我们访问azure平台上的相关工作流页面时，会看到下面的结果azure_run_flow.gif

  即当前工作流实例正在运行，我们需要等待1分钟之后，再刷新该页面时，会看到当前实例已运行完成azure_workflow_complate.gif

  好了，到现在为止，整个开发和运行测试流程就介绍的差不多了。

  因为手头的资料不多，而我还有的一些疑问还是没有最终得到解答。下面我将它们罗列出来，如果大家感兴趣或有这方面的经验，不妨与我联系或在回复中进行讨论。

  1.例子中的SERVICE端如果能够被布署在多台服务器上，当client端post请求时，当前会通过哪台机器上的服务来处理？我猜测的一种可能应该是service bus会通过一些网络路由算法（如最短路径算法）来分配相应的服务机来处理相应请求。但如果是这样，是否还应该包括负载均衡方面的考虑呢？ 必定每台机器的处理能力有限，任务多了就要排队，如果一味还是”最短路径“的话，会让service bus中的某一个服务结点不堪负。

  2.目前的测试可以让azure平台上的某一工作流在某一条件下被触发执行（上传中的total<=1000）.但工作流的持久化就在azure上吗？这样的话，如果azure平台出现问题，正在运行的实例可能会将执行在一半的工作流“回滚”，以免出现数据被脏读的情况吗？另外如果企业想将被执行失败的工作流按“自己的方式”进行处理又应该如何去做呢？

  3.在biztalk中其扮演的角色是ESB（企业服务总线），而Azure Service Bus目前而言应该是一个ISB(Internet 服务总线)。如果与ISG是ESB的一种实现方式的话，那在ESB中的消息类型与ISB中的消息类型又是否为一脉相承呢，在SDK中我看到了这样一段代码（出现在了AzureServicesKit\Labs\IntroServiceBus\Ex04-RESTSample中）：

  而该Message类型为abstract类型（位置System.ServiceModel.Channels名空间），这个类型又与在BIZTALK Server上配置于数据库中的message表中的消息数据是怎样一个关系呢。以前曾在网上看到有篇文章说azure会将shartpoint逐步在云中加以实现，如果是这样的话那biztalk是否将来会与AZURE平台产生某种更深层次的关联吗？