“完全解耦是极其困难和昂贵的，否则就是不可能的，”Ron Schmelzer 如是说到，他是 ZapThink 的高级 SOA 分析师。一般人们都认为：系统要么是松耦合的，要么不是。在这篇最近的帖子中，Schmelzer 炮轰了这个信仰。尽管松耦合的重要性得到认识已经有些时日了，但是围绕这个帖子展开的对话却收集了一些有趣的讨论。
Schmelzer 如此描述松耦合的 7 个维度：
- 实现
- 服务契约
- 服务策略
- 过程
- 数据模式
- 基础设施
- 语义级别
这个报告是这样说明松耦合实现级别的：
所有 SOA 的实现必须在实现级别是松耦合的，但是显然这并不足以保证达到业务期望的那种完全的松耦合。
服务契约提到了使用服务描述框架的好处：
服务描述框架（SDF）……是一种技术中立的服务契约模板。以那种方式，新的服务契约并不是简单地替代旧的契约。除非给服务消费者提供一个转换路径，否则旧契约就永远不会被弃用。
延迟绑定的问题也被提了出来：
在这个舞台上 [可能] 的最佳实践就是使用一种延迟绑定的方法，该方法利用了运行时注册和基于契约的绑定，这样抽象了特定于服务消费者的绑定，并使服务契约变更照成的影响不致于蔓延开来。
直到我们解决跨 Web 的无缝互操作问题之前（主要是 XML 到对象数据绑定引起的问题），由涉及产生和实现动态客户端代理的消费者来把运行时绑定到服务只不过就是一次视觉探索（VisionQuest）！在当前那些确实“利用运行时注册和基于契约的绑定”的环境中，唯一可行的运行时办法只限于动态绑定到不同的 SOAP 端点（它能在注册中使用一个运行时的查找得到），当且仅当已经在潜在的生产者和消费者之间的 Web 代码中完成了上述的互操作测试。
报告将服务策略与服务契约这样联系起来：
公司指望服务可变性在处理策略变更的方法与它们处理服务契约变更的方式一样：延迟绑定、启用服务仲裁、基于注册和治理。
业务过程的处理是类似的：
通过在元数据中定义过程并使用服务契约暴露这些过程（作为服务暴露，服务组合时采用递归方式），可以把过程实现从服务消费者中抽象出来。
第一次提到对数据模式进行不同的处理：
模式是服务数据互操作能力的关键。但是，当模式发生变化时情况会怎样呢？解决问题的一个关键就在于将信息和模式按照服务元数据相同的管理方式进行管理。数据模式被视为元数据的一种形式，并且异常管理、转换、服务仲裁和数据服务全部都是数据结构松耦合的关键。
现在，再一次回头看看服务契约中说的——“模式和服务契约没有什么不同”。
报告认为，尽管从基础设施观点来看，松耦合可能很容易定义，但是极少有厂商提供这种灵活性：
[这] 意味着在任何时间，公司都可以改变他们的基础设施，而无需重新构建所有的服务消费者和提供者。
最后的解决方案是在语义级别描述的——动态服务定义，其中“服务接口的定义必须基于服务请求者的上下文改变。结果是，服务可以在调用之间改变它们的契约”。这种宽松的语法看起来会和 REST 模型一起工作得很好，但是与 WS 标准结合的效果在现阶段是未知的。
Nicholas Gall 在他的分析中增加了松耦合的另一个方面：
这个列表遗漏了松耦合最重要的一个方面：普遍性。如果我和唯一的另一合作伙伴采用了世界上最动态的可重新配置的中间件架构，那么他和我就紧密的彼此联系到一起了。试想我们两人设计出了 WS-* 的自家变种，姑且称之为 WS-Silo。那么，我们之间可以在一端进行随意的变更，而不会破坏另一端。但是，我们不能和其他的任何人进行互操作。
尽管在怎样达到松耦合上并没有获得一个广泛认同，但是在众多人的意见中，它的目标是一致的——通过将系统变得彼此来降低改变它们的成本。
查看英文原文： 7 Degrees of SOA Coupling
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论