领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
移动SOA的门柱
作者 Boris Lublinsky 译者 胡键 发布于 2008年11月2日
John Evdemon在其最新的一篇帖子展示了针对SOA，业界进行定义、重定义和自相矛盾的尝试。这些定义五花八门，无章可循。
首先是关于松耦合的大体定义：
随着Web服务和SOA的来临，我们正试图创建耦合更松的架构和系统。松耦合系统提供了许多好处，包括：支持运行时迟绑定或动态绑定到其它组件，可以化解组件结构中的差异，安全模型、协议和语义，从而对易变性进行了抽象。
接着，重用占据了舞台中央：
软件重用的核心思想并不是什么新东西，即从最初已经创建出的组件中获取更多价值。在SOA之前，由于组织内业务单位之间缺乏集中控制和沟通，导致相同的解决方案一再重复发明。为了确保组织内各业务单位不创建重复服务，SOA干系人，如业务分析师和架构师，应该能够以一种广为人知和系统的方法来寻找现有服务并评估它们是否能够重用。
业界最后发现真正的重用实在是太复杂了并且并不是总能实现：
创建可重用服务要求对未来进行预测……服务创建者怎么可能准确地猜到未来应用的需求？“车到山前必有路”的想法非常难以实现真正的重用。加上，鼓励所创建组件可被其他小组重用的组织，即使有，也不多。
接着，它谈到了业务流程的松耦合：
硬连接流程应该是一种罪恶，我们要坚决地抵制它……松耦合将迫使我们反思业务活动的方方面面……它将对我们管理业务操作的方式产生深远影响。厚重的流程手册留下了对我们硬连接业务操作方式的遗嘱。预先指定全部活动的详细细节，然后监测所有活动来清除任何不符合标准的变化。尽可能地加固操作。松耦合业务流程的运转方式完全不同。
当SOA无能为力之时，事件驱动架构（EDA）成了（一个更流行的）SOA替补。：
EDA交付了SOA只是承诺却没有做到的松耦合。它并非同步的“命令并控制”类型的模式，而是其反面：异步的“发布并订阅”类型的模式。发布者和订阅者完全不知道对方的存在；在某种程度上，组件是松耦合的：它们只共享了消息的语义。
接下来，它谈到了业务/IT的对齐：
自从发迹于面向对象设计和基于组件的软件开发方法论，SOA已经进入了理想的崇高领域。随着故事的发展，SOA不单单是为重振IT而设计的了；它还成了能改变IT所服务于的业务的魔弹。
并且，最终它发现SOA跟技术没有任何瓜葛：
太令人震惊了；SOA似乎是第一个对技术没要求的技术。大厂商们告诫说，只要你坚持走有SOA特色的架构基本路线不动摇，在技术上不管你做什么都没关系。
这些定义明显的不一致似乎是来自于以下几个因素：
- 和任何架构一样，SOA相当复杂且涉及多个关注点。随着SOA实现经验的增加，架构师和开发者都发现，他们在实现中需要开始考虑更多的事情。这并非真的移动了门柱，而是意识到“操场”的真正尺寸。
- 相比起正确定义他们确实要做的东西，人们往往更关心变得“时髦”。考虑当前的SOA流行程度，许多东西被人为的拉入SOA领域并非是因为它们真的就属于那儿，而是因为术语引起了CEO/CIO的注意。这并非真的移动了门柱，而是使用流行词汇来引起管理层的更多注意。
- 人们往往把SOA架构和SOA平台/实现混为一谈。尽管SOA架构没有改变，但是平台/实现的门柱却总是在往更好地支持客户需求的方向移动。
查看英文原文：Moving the SOA Goalposts
译者 胡键 热心开源技术，《开源技术选型手册》作者，《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。
没有回复
关注此讨论 回复