Nick Malik 的文章“仲裁在SOA 中的价值”引发了一起有趣的讨论。在关于这个主题的第一篇博客帖子中，他问道：“如果消息不能被仲裁，那它还是面向服务的吗? ”。
Malik 认为仲裁能力是任何 SOA 的关键益处之一，“能够拦截从 A 点到 B 点去的消息，并对那条消息做出反应而不通知那个管道的任意一方”。以他的观点，仲裁以技术中立的方式共同工作，它要求“我可以用一套完全不同的技术系统替换系统 A，并且只要消息是一致的就不影响系统 B”。
按照 Nick Malik 所说，“SOA 是用于企业应用集成的架构”。仲裁通过它的替换原则支持集成。通过比较架构性的仲裁和面向对象设计中的工厂模式，Malik 解释了这一观点，并引用了 Liskov 替换原则：
能够增加仲裁，为我带来了一些相当特别的便利。就像在 OO 设计中，工厂给与我 Liskov 替换原则的便利，在消息传递设计中，仲裁为我带来了替换的便利。仲裁能够观察到从一个贸易伙伴传递到另一个贸易伙伴的消息，并基于消息的内容采取行动（假设我已经正确地获取了它）。
Udi Dahan 并不同意 Malik 的 EAI 话语，以及他关于通过仲裁编排服务的想法：
尽管我非常同意 Nick 所说的 OO 仲裁是依赖注入变种的观点，以及在消息传递方面扩大那些相同的概念是正确的做法，我还是对仲裁领域中的编排有疑问。这些“战术变化”需要在顶层（即业务级服务策略）的上下文中完成。这意味着所有逻辑应归入一个服务。服务间的“网络”只是一个“哑”网络，没有任何业务逻辑，只剩下技术能力，如知道将消息路由到哪个物理服务器去。
JohnCJ 在 Malik 博客帖子的评论中表达了对于仲裁价值的看法，认为仲裁不应该被视为面向服务的通用需求。他认为：
- “要求仲裁会鼓励消息携带更多的上下文信息”。
- “除了请求 - 响应和发布 - 订阅，仲裁使消息交换模式极大地复杂化了”。
- “仲裁要求仲裁系统对于它所拦截的消息的语义至少有些理解”。
在再论仲裁的价值中，Nick Malik 就这些观点一一做出了回应。他指出上下文的信息并不会使消息膨胀，而是“为了表示我们在企业EAI 场景中所传递的中立规范的业务文档，从而必须增加单条消息大小的这个做法，只是取得业务敏捷性的小小代价”。关于第二个争论，Malik 给出了一个非常好的类比：Joe 是银行职员，他拿着他的休假申请表去找他的老板并等待批准。他的老板只是这个申请到达最终接收人那儿整个过程中的众多仲裁者之一。Joe 并不知道也不关心这些仲裁中的任何一个。他只关心结果——他的申请是否被批准。批准过程可以在任一步被修改而不改变这一过程的业务语义。因此，Malik 认为“几乎所有有价值的长运行事务都必须能够仲裁，这是为了让它们可以被组合、被再组合，以及被编排”。最后，他认为共享消息的语义需要依赖仲裁功能。在任何情况下，他都把那个点声明为“风险，而不是成本。它是在任何项目中都会出现的风险。在定义良好的SOA 基础设施中，这个风险比起我们试图通过在3 个计算机系统中输入数据来组合一个手工业务过程要低得多”。
Nick Malik 总结说：在他的观点中，仲裁并不是所有服务都必须的，但是“它是被设计交付可组合性（即业务敏捷性）的面向服务架构所必需的”。
查看英文原文： On Intermediation in SOA 。 - - - - - -
译者简介：胡键，自 2000 年西安交通大学硕士毕业后一直从事软件开发。2002 年开始使用 Java，在项目开发中经常采用 OpenSource 工具，如 Ant、Maven、Hibernate、Struts 等，目前正在研究信息集成方面的规范和技术。可以通过 jianhgreat AT hotmail.com 与他联系，或访问博客： http://foxgem.javaeye.com/ 。与 InfoQ 中文站分享内容，请邮件至 china-editorial@infoq.com 。
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论