领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
.Net服务2009年3月CTP：服务总线路由和队列
作者 Boris Lublinsky 译者 马国耀 发布于 2009年4月24日
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联系到他。
译者 马国耀 关注企业级应用开发与架构，有多年SOA项目实施和咨询经验，专注于SOA及云计算的融合。
没有回复
关注此讨论 回复