Michael Poulin 炮轰 SoaML

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 规范本身。

我之所以说是‘宣告’是因为这个‘架构’是通过一个例子而非定义来解释的；你自己就能看出来：“一旦把一个参与者‘分解’，它可以包含针对其他也同样提供和使用服务的参与者的角色。用这种方式，该服务架构就可以由这种‘供应链’开始……并且下钻至企业中实现这种‘供应链’的角色。这样一个参与者的服务架构就可以被建模成一个包含 <> 和 <> 原型的组合组件。”

Michael Poulin 表达了对 <> 一词的不解，同时认为把参与者分解成角色未必就能导出服务的使用。在他看来，SoaML 搞的就是一种权力、责任和义务的结构，以该结构而非业务需求作为企业服务架构的基础将有损于面向服务的精神。

文章第 2 部分，在对 Cory Casanave 的关于 SoaML 的幻灯片进行一番批驳之后，Michael Poulin 又将话题拉回了 SoaML 规范。他指出，SoaML 规范将服务契约作为服务接口的一部分完全是一种不符合 OASIS SOA 成果的表现，尽管前者口口声声要试图利用后者的现有成果。在 OASIS 的标准中，服务契约的位置是在服务接口之上。

虽然提出了诸多批评，但在文章的末尾，Michael Poulin 还是表示出了对出现 SoaML 的欢迎。他把这一动作视为制订厂商中立的 SOA 建模标准的开端，并表示如果对规范能进行相应修订，他将更加高兴。