面向服务架构已经成为企业软件开发的主流实践之一。但是，根据 Dan North 的说法， SOA 的实施已经被软件厂商提供的众多工具制约，而这些厂商的兴趣是“强调 SOA 的复杂性，然后提供一个及时地和可盈利的解决方案。”最终结果是，许多 SOA 架构师的决定被技术考虑所驱使，而不是将注意力集中在核心业务场景的映射和建模上，而后者正是 SOA 方法的本质。
在他的文章中，Dan North展示了如何以“技术不可知”的方法去设计 SOA 。为了“去掉任何对计算机或现代技术的引用”，他选择使用一个休假预约过程的例子，因为它“发生在一个上世纪 50 年代的公司”。在这个业务场景中，一个雇员 Bob 办理他的休假预约，该预约必须被人事部门批准。Dan North 按部就班地举例说明了如何基于彻底的业务过程映射去识别 SOA 需求：
按 SOA 的术语来说，人事部门是一个服务提供者。它的服务之一就是安排年假。Bob 是一个客户端或服务的消费者。休假申请单描述了一个服务契约。那么，填好的单子就是一个异步消息——Bob 并不会暂停他的活动而去等待请求的回应；相反，他会继续进行他的日常工作。
内部的邮件就是一次消息的传输——在这种情况下是一次不可靠的传输。幸运的是，Bob 有一个错误处理协议，即超时。一周之后，他的日历通知他去给人事部门打电话。打电话是一次同步交互——他实时的在电话旁边。他接着实施了一个错误修正策略，那就是重新发送消息。
在讨论错误处理策略的同时，North 甚至提供了更多通过业务过程建模定义 SOA 需求的例子。如果有人在休假批准前更新了休假记录以减少离开的天数，接着请求丢失了——就 Bob 的例子来说——这会导致记录的不一致。理解这种情形会驱使我们得出结论“休假预约必须是事务型的”。一个请求也可能会因为某些业务原因失败，如津贴用光了、签名丢失等等。用 SOA 的话来说，这被称为“语义”或“业务规则”。在这个情况下，应该给关心返回结果的人发回一个失败原因的响应。用类似的方式，North 展示了业务上下文是如何为关联响应、服务可用性、安全或服务变革去定义 SOA 需求的。
按照 North 的说法，保持对真正业务问题的关注可以“将’是什么’从’如何做’之中剥离开来”：
事实上，一个真正的面向服务架构应该只有在业务中有直接对等物的服务；否则，它们就不可能被建模成一个业务过程。
抽象技术概念，如“数据服务”或“复制服务”，就业务来说没有任何意义。（可能有提供公共技术功能的共享模块或库，但是这些不应该被实现为服务或被称为是服务。）
同时，North 还声称如果事实上就存在有 2 个单独的领域，那么架构师就应该避免定义一个统一的领域模型。例如，对于 Bob 和人事部门负责批准休假请求的职员来说，“假期”并不意味着是同一事物。就前者来说，它关系到“棕榈树”和“在海滩上散步”；而对于后者，它涉及“围绕当时预约的业务过程”。North 认为这两个领域都应该被描述，尽管“假期”应该被作为“将每个服务背后的所有更细粒度的领域模型结合在一起”的业务概念。它不仅将会更好地反映现实，而且就架构来说也具有优势：
这些服务契约接下来按照企业级别的业务概念去表示，如休假或分发或销售订单，这再次将服务消费者从服务提供者解耦出来，使得它们可用独立的发展，同时也能以一种公共语言进行通信。
Dan North 充分认识到通过业务过程建模来定义 SOA“只是实现充分发挥 SOA 作用的第一步”。然而，关注业务问题有助于“理解服务的目的，并独立于技术问题去研究业务复杂性”。这种方式，SOA 需求的定义不会受技术决定的限制，它总是可以“按照已建模的业务过程被映射回可识别的业务价值”。
查看英文原文： Technology-agnostic approach to Service Oriented Architecture: back to the essence of SOA?
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论