Infoq之前报道，微软已经发布了 Azure 服务平台的新 CTP 版，它是：
……微软提供了许多以云为基础和云感知应用所需要的关键构建单元，它们是微软托管的、高伸缩、面向开发者的服务集合。和.NET 框架提供了大幅提高开发者生产效率的高级类库很相似，.NET 服务可以让开发者更关注应用逻辑，而不是去为构建和部署基于云的基础设施服务而烦心。
Azure .Net 服务的核心是服务总线，它：
……提供了人们所熟知的企业服务总线应用模式，并且有助于解决在跨网络，安全以及企业边界的 Internet 环境中实现该模式时所产生的若干难题。
正如 Clemens Vasters 所言，2009 年 3 月份 CTP最大的改变是加入了服务总线路由和队列：
……我们已经着手向服务总线加入持久的、系统固有的消息传递元件，这些元件的存在和运行完全独立于任何从其他系统插入到服务总线中的监听器。这意味着，服务总线可以作为一个“推 - 拉”模式的传输中介；也可以用作发布 / 订阅消息的分发工具，从而可以加速或者优化网络上的消息传输。或者，也可以用它来实现如下的消息分发场景，该场景中一些消息的目的地存在 Web 服务，依赖服务总线的转发才能交付给某些接收者。
服务总线路由和队列的实现得利于服务总线命名空间的一个改变：
服务总线命名空间的核心是一个联邦、分层的服务注册表，其结构由 “项目” 决定并拥有。服务总线命名空间与“经典”服务注册系统（如 DNS、UDDI、LDAP）的区别在于，在服务总线命名空间中服务或消息元件（通常）不仅被注册表引用，而且被直接投影到注册表中，因此，你可以使用相似或者相同的编程接口在统一的命名空间中访问注册表以及那些被投影的服务和消息元件……服务总线的“联邦”体现在服务或者消息元件可以被注册到“任何位置”的共享命名空间。例如，一个 URI 的路径部分代表一组来自 Web Farm 或集群数据库的相对紧密的同位资源，而权限部分（直接或间接）代表着目标集群。
Clemens Vasters解释道：
消息元件和服务总线命名空间之间关联的建立是通过如下方式实现的，给项目中的服务总线层级取一个名字……给这个名字赋一个角色……理论上，所有服务总线命名空间中的名字可以没有角色而独自存在。因此，当我给一个名字赋上一个角色时，我并没有创建名字，名字本身已经存在，只是隐藏了……任何名字都可以充当系统支持的任意角色。目前，当你简单将一个外部引用（如一个 URI 或者 WS-Address 端口的引用）跟注册表中的一个名字关联起来时，这个名字就会有一个“元数据”的角色。当 WCF 监听器在服务总线上使用一个名字进行侦听时，这个名字就会被赋上“连接点”角色。此外，我们还有两类新角色“路由”和“队列”。
他如此定义路由和队列：
路由是一个发布 / 订阅的消息分发元件，它把消息“推”向订阅者并且获取流进路由器的消息。而队列是一个容器，它保存消息，直到（消息的）消费者从队列中“拉”走消息。我们显式支持一个路由向另一个路由订阅消息，也支持队列向路由订阅消息。如此组合的结果也必然会比任何一个单独的元件具有更强大的能力。我们把这些能力称为“元件”是因为他们明确地支持组合。
队列的能力是由队列策略定义的，策略一定程度上类似于典型的JMS 队列的策略，并且可以通过WS* 和 Rest API 来访问和管理策略。
微软认为：.NET 服务总线是 ESB 模式的一种实现，近年来越来越流行，因为它简化了多个服务之间的连接管理。简化管理的一个途径是提供了发布 / 订阅架构，这为整个企业提供了更加松散的耦合。在.NET 服务 2009 年 3 月版的 CTP 中，通过服务总线路由和队列而引入的队列支持，使该愿景向现实又迈进了一步。
查看英文原文： Service Bus Routers And Queues .Net Services March 2009 CTP
译者简介： 马国耀，2007 年毕业于北京大学信息技术学院，硕士学位。他感兴趣的技术领域是 SOA，ESB，J2EE，Java 编程，开源项目等。业余时间爱好五子棋，围棋，获中国棋院授予的五子棋初段段位。他热情乐观，愿与天下各路豪杰结为朋友，可以通过 maguoyao (at) gmail.com 联系到他。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论