世界上最大的 SOA

SOA 和 mashup - 两种驱动更快/更廉价服务开发的架构模式。它们都被用于构建可复用的服务 - 但是它们之间有哪些区别呢？

SOA 其实是一套由

​​9 大设计原则​​组成用于构建高可复用服务的设计方法。如果我们根据这 9 大设计原则来对 mashup 进行评估的话，结果会怎样呢？

√ 服务协同

mashup 常常是基于诸如 XML、HTTP、REST、Web Services、RSS 以及 Atom 等标准的，所以它们的协同程度是比较高的。

与遗留系统的互操作性也是可能的。SOA 解决方案常常会使用企业消息总线 (ESB) 来促进协同性 - 一个 mashup 没有任何理由不去使用 ESB 同样的方式。

× 标准服务契约

大多数 mashup 缺乏一个 SOA 服务所期望的明确的服务契约。

× 服务松耦合

mashup 订阅者被紧密地和 mashup 发布者耦合在一起。只有当 mashup 通过 web service WSDL 或类似契约发布的时候是例外，但这是很少见的。

√ 服务抽象

通过将自己的业务与外部世界隐藏起来，大多数 mashup 能够满足这一标准。

√ 服务复用

现今部署的大多数 mashup 都用于大规模消费并且是高可复用的。

√ 服务自治

mashup 一般会具有对其所封装业务逻辑的控制权。

× 服务无状态

很多 mashup 存储请求某个数据库中的特定数据。大多数时候该 mashup 自己直接访问数据源。

× 服务发现

由于 mashup 通常会缺乏一个明确的服务契约，一般是不可被发现的。

√ 服务组合

互联网 mashup 通常被设计用于多种用途。它们通常提供细颗粒的功能点，在大多数场景下是可以进行组合的。

mashup = SOA？

根据 SOA 设计原则进行评估，大多数互联网 mashup 能够得到 9 分里的 5 分。当今公开部署的 mashup 很少会考虑到 SOA 服务化治理。

mashup 和 SOA 能否进行融合？

mashup 由一些互联网公司所提供的非正式 API 所演变而来。SOA 是一套被用于构建企业级解决方案的较为严谨的设计原则。

对于两者的融合是有一些迹象。将 mashup 应用于企业级的兴趣呈现出一个上升的趋势。这将驱动 mashup 标准化的提升。而关于对 mashup 制定标准化、可发现服务契约的兴趣也呈现出一个上升的趋势。

如果对于向 mashup 提供 SOA 设计原则有一个推动力的话 - 互联网可能会变成一个超大型的 SOA。

原文链接：

​​The World's Biggest SOA​​，发布日期：2011 年 2 月 4 日。

作者简介

Anna Mar 是一名拥有 18 年以上金融领域经验的首席架构师，当前就职于东京的一家电信公司。