领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Michael Poulin炮轰SoaML
作者 胡键 发布于 2009年6月10日
SoaML是一种服务建模语言，其目的是为了简化服务建模，InfoQ已于今年年初报道了其草案的发布。最近，Michael Poulin撰写了由两部分组成的文章：“SoaML什么都是，就是不是SOA（SoaML is about everything but SOA）”（1 2），对其进行了批评。
我现在知道SoaML一词中的“SOA”为何要写成如此不同寻常的形式了。我的看法是，SoaML规范的作者们对其努力工作的结果感到惭愧；他们知道SoaML并不是面向服务的，而且也不是一个完整的架构建模语言，因为它并没有建模架构的全部实体，而只是关注它们之间的关系（这些关系是很重要，但是这还不够）。
Michael Poulin质疑了在SoaML规范中再重新定义SOA/服务的必要性，因为在他看来，既然规范已经引用了OASIS SOA的参考架构，那么为何不直接使用OASIS SOA的相关定义呢？此外，对于SoaML规范的SOA/服务定义，他也认为存在着明显问题：
- 服务为什么只能通过一个接口提供（SoaML：‘一个定义良好的接口’用的是单数）？
- 服务为什么对未明确定义的‘群体’是可用的，而不是把它（‘社区’）换成广泛的服务消费者？如果‘群体’一词背后意指服务的广泛使用，为何这要比在不同的执行上下文中由（不属于任一群体的）相同消费者广泛地重用服务更重要？
……
- 为什么参与者（SoaML：‘如果参与者提供服务，那它就是一个服务提供者；如果参与者使用服务，那它就是服务消费者——一个消费者既可能提供服务，也可能消费服务。’）是SoaML中的主要角色？如果SoaML讲的是面向服务架构的话，服务到哪里去了？
他认为，SoaML强调参与者着实令人感到困惑，因为它显得“消费者和服务提供者之间的关系”要比“消费者和服务本身之间的关系”更为重要。而实际情况是：在SOA环境中，消费者和服务之间的交互是通过它与服务提供者协商的契约来完成的。一旦契约确定，消费者就不再关心服务提供者，只关心业务功能和服务结果，服务提供者则起到辅助支持作用。他猜测该规范这样做的目的是想将服务契约的重要性置于服务接口之上，后者常常在技术术语中指代契约。但是，Michael Poulin认为SoaML仍然低估了服务契约的重要性，因为根据OASIS SOA标准，服务契约的基础是服务描述，即某个特定服务的定义，在SoaML中完全找不到这部分内容。因此，他在文中用黑体写道：
对我而言，SoaML是一个以角色/参与者为中心的模型，不是一个以服务为中心的模型。
而且他表示，这绝非他个人的主观论断，宣告“参与者服务架构”存在的恰恰是SoaML规范本身。
我之所以说是‘宣告’是因为这个‘架构’是通过一个例子而非定义来解释的；你自己就能看出来：“一旦把一个参与者‘分解’，它可以包含针对其他也同样提供和使用服务的参与者的角色。用这种方式，该服务架构就可以由这种‘供应链’开始……并且下钻至企业中实现这种‘供应链’的角色。这样一个参与者的服务架构就可以被建模成一个包含<<participant>>和<<servicesArchitecture>>原型的组合组件。”
Michael Poulin表达了对<<servicesArchitecture>>一词的不解，同时认为把参与者分解成角色未必就能导出服务的使用。在他看来，SoaML搞的就是一种权力、责任和义务的结构，以该结构而非业务需求作为企业服务架构的基础将有损于面向服务的精神。
文章第2部分，在对Cory Casanave的关于SoaML的幻灯片进行一番批驳之后，Michael Poulin又将话题拉回了SoaML规范。他指出，SoaML规范将服务契约作为服务接口的一部分完全是一种不符合OASIS SOA成果的表现，尽管前者口口声声要试图利用后者的现有成果。在OASIS的标准中，服务契约的位置是在服务接口之上。
虽然提出了诸多批评，但在文章的末尾，Michael Poulin还是表示出了对出现SoaML的欢迎。他把这一动作视为制订厂商中立的SOA建模标准的开端，并表示如果对规范能进行相应修订，他将更加高兴。
胡键 热心开源技术，《开源技术选型手册》作者，《SOA实践指南》译者。目前致力于Groovy/Grails的研究和推广。
没有回复
关注此讨论 回复