现实世界的 Windows Azure：Davide Bedin讲述aKite零售管理解决方案
作为现实世界Windows Azure系列的一部分，我和DEDIN商店系统首席技术官Davide Bedin交谈了有关该公司采取的基于Windows Azure发布aKite零售管理解决方案的长期策略。这里是他所说的：
David Ingham: 告诉我们有关你公司和你们提供给客户的aKite服务的情况？
Davide Bedin: BEDIN 商店系统，总部位于意大利的 Cornuda, Treviso, 有超过20年的发展销售点（POS）和针对零售商的店内系统方面的经验。在使用微软技术为小规模到大规模的零售商，独立商店，连锁店提供解决方案方面，我们已经获得了国际先驱的信誉。
aKite 是一个设计在Windows Azure上的软件即服务解决方案的销售点和店内的软件。aKite零售Web服务托管在Windows Azure上，通过连接总部和其他外部web服务商店，它可以保存和分析数据。
两个智能客户应用程序，POS.net用于前台存储操作，SHOP.net用于后面办公任务。工作以对等方式进行断开连接和合作，这是作为通常未充分使用的服务器会变成一个故障单点和不必要能源消耗的关键优势。
aKite从商店中删除了其复杂性，使得零售商的生活更简单。当无资本投资也是必须时和一对一收费，aKite也提供了经济效益。部署工作是很简单的------在几分钟之内，ClickOnce允许坏电脑替换或者是打开新存储方式安装。
DI ：你试图解决使用基于消息的体系结构的主要挑战是什么？
DB ： 第一个挑战是在承载在Windows Azure上的智能客户端和销售Web服务之间的数据同步。价格表的更新的实在例子是需要从Web服务到智能客户端的事件通知。小规模时这并不难，但aKite支持很多的中等大小的连锁店和一些非常大的很多家店，所以分发这样通知的聚合任务是真正的挑战。aKite提供了零售商提前做好准备此类更新的能力，但仍然要求尽可能快的更新到客户端。也有一家零售商需要进行更新但涉及到数百家商店这样的情况。传统的解决方法是让客户进行密集轮询式更新。这种技术明显的劣势是占用web服务上的资源。提供一种高效推送到客户，并允许应用程序专注于其核心工作，Windows Azure Service Bus更为合适。
在获得使用Service Bus进行同步的经验后，我们学到更多关于其优雅和潜力。我们看到它可以大大帮助弥补aKite零售web服务的组件之间异步消息传递：这里的目标是找到减少存储信息数据库加载的一个解决方案，以及提高恢复能力和可靠性。
DI ： Service Bus怎么帮助解决这些技术难题？
DB ： 一般情况下，Service Bus允许我们只专注于aKite的业务逻辑，以减轻事件通知和消息处理。对于同步方案，通过Service Bus减少了60%的来自客户端的aKite零售web服务调用。在发送和处理通知方面，我们也看到了性能改进。
对于客户端到服务器的连接以及构成零售web服务的组件，Service Bus，使得我们能够创建松散耦合的架构。我们可以专注于信息的业务内容，而不是它们的交付。组件简单的发送信息到Service Bus队列和主题，而不需要知道组件最终会处理它。这种松散耦和允许我们能够创造性的将不同的方案组合在一起，会让我们轻松地应对未来新的突发情况。例如，应需要，创建一个新的服务组件以新的方式处理服务器事件，然后可以创建以筛选器匹配消息相关的新方案的新订阅。
我的观点是，在服务体系结构中引入Service Bus比只解决眼前的需要更有价值，它提供的“未来校对”，意味着我们能够以更丰富，更快的方式应对改变和演变。
DI ：你使用Service Bus构建实际上是为了构建怎样的通信场景？
DB ： 我们目前依赖Service Bus支持许多不同方案。如上所述，我们提供的第一种方案是运行在商店发送到数据更新通知和其他信息到aKite智能客户端。通知信息是发送到Service Bus topic。信息上的属性确定那个商店应当接收到通知。每一个客户有一个自己的主题的描述，通过筛选器确保只接收相关的信息。在响应aKite的任何服务组件发出的信号对应的事件，准备和更新通知会发生。这些事件会以信息方式发送到一个主题和相应的描述员工。
另一种情况下，每个前端商店POS.net客户通过Service Bus队列发送销售文档到aKite零售web服务。该队列帮助我们应对连锁店销售活动的突然，不可预见的变化。一些工作人员总是在监听队列进来的消息。队列的负载调配属性意味着加载的峰值和谷值---队列的长度增长和交接。 整体负载应当持续增加，然后更多工作人员可以添加进来，共享工作。
另一个使用Service Bus消息处理模式的是零售Web服务。POS.net 客户端的一个销售文档通过几个不同的步骤成为后端处理的一部分，后端处理需要大量的计算或需要广泛与数据库的交互。每一步都有工作者角色执行，角色之间的通信是通过Service Bus topic完成的。每个工作者角色监听一些描述，每个描述包含针对于一些一整个连锁店或大连锁店，商店的一个子集的数据。在完成其工作时，每个处理步骤将消息发送到主题并传递文档到下一步。不同的工作角色都能够在不同的工作者实例之间动态、 自动拆分整体工作负载。这样能够很灵活并且体系结构能适当缩放处理系统负荷。
DI ： 你觉得使用Service Bus的开发体验如何 ？
Service Bus对象模型是很清晰的，示例和覆盖很多可能的用例文档描述了使用方案。使Service Bus直接进入Windows Azure客户端库是一个额外的简化。在Windows Azure 客户端类库中拥有Service Bus提供给我们额外的便利。
我们是Service Bus的早期用户，通常新兴技术的情况是，起初没有太多的支持工具可用。Service Bus Explorer工具的到来已经是并将继续是探索，调试和测试Service Bus的极其重要的工具。
DI ：你有向终端客户推出你的解决方案（服务）吗？
有，Service Bus现在支持每个aKite用户。我们不断地推出新功能并不断地做出改进，每位新老客户、大客户或小客户都将从不断完善的产品中获益。