世界上最大的 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
Anna Mar 是一名拥有 18 年以上金融领域经验的首席架构师,当前就职于东京的一家电信公司。
posted @ 2017-04-13 09:31  Defonds  阅读(30)  评论(0编辑  收藏  举报