在最近一篇博文中 JP Morgenthal 解释了概括的 SOA 实施是：
标识、合并、编排并治理一组业务功能或能力。
Morgenthal 从解释 SOA 中的服务的确切含义开始：
很多东西都可以被称为服务，这是 SOA 问题产生的地方所在。我认为在 SOA 环境中使用的“服务”这个单词暗指了特定的含义，它过滤了大部分不适用的服务定义……SOA 是一个用于标识和描绘特定域内的业务功能边界的架构方法。域可以是一个组织单元，也可以是整个企业。不论是哪个域，如果在该域中有交互，那么该域中就很可能包含不止一个业务单元才完成这些交互……非常简单，SOA 就是用来标识域目标，后将产生的业务功能编排成流程从而实现业务目标。划定必要的业务功能边界并由他们实 现目标，SOA 还要合并这些业务功能以确保没有冗余，然
接着他解释了虽然很多媒体的噱头让很多人认为 SOA 非常复杂并且需要昂贵的软件和资源，而实际上它就是将功能分解使之与业务对齐：
……拿一个特定的域，看看我们如何将它切分成一组协同工作的服务。例如，“园林美化”服务和“护根”服务之间就有很好的协作，你同意吗？它 们是独立的服务，但是他们之间存在着我们称之为松耦合的关系。即它们为了完成某个任务而合作，而后各行其道。的确，对一个域进行分析并将它分解成一组服务的工作是一种策略技术，它需要执行者的经验，然而划定边界和并围绕这些边界开展治理工作却可以由现有的管理去完成。
在 SOA 中所有的服务都被实现成软件，但是在这种情况下更重要的是每一个服务都代表了一个真实的业务功能。软件实现只是将这些功能执行自动化的 一种方式：
……因为它是在软件中实现的，而不是通过其自身实现的。这是他们所代表的角色。这些服务让业务降低了复杂性，使得他们合在一起实现业务目标而且是以敏捷而灵活的方式完成的。此外，虽然他们不依赖于其他服务而提供业务价值，但是我们可以很容易地看到他们可以有效地协作……
Morgenthal 继续解释他对 SOA 的理解并分析了与 SOA 相关的两个典型话题——软件即服务（SaaS）和基于组件的软件开发。在他看来 SaaS 不算是真正的 SOA 服务，因为：
SaaS 满足了我们定义服务的一个准则——我们通过付费用去使用服务而并不想拥有服务。然而，大多数 SaaS 只是租用的软件。在租用后，你依然要负责将自己的数据集成到 SaaS 应用中，你还要负责配置表单和工作流。对我来说，SaaS 不具备服务的其他特点。
Morgenthal 认为，很多执行者在谈及 SOA 时，实际说的是基于组件的开发。在他看来，当人们使用 SOA 来描述构建软件系统的方法时确实是这样的。但是 ，但有人开始谈到平台服务或工具服务时：
……这些谈论明显地说明了谈论的话题已经降级到软件设计方法论而已经脱离了 SOA 的范畴……不存在“工具”服务这样的东西，它只是软件组件 ……软件提供的的业务服务可以不需要工具服务的存在而存在。结果方案也许不像设计的那么模块化，也许并没有服务提供者以及期望的敏捷和灵活度，但是，如果你决定不建立工具服务和而直接把业务逻辑实现在软件里面，对服务的消费者没什么坏影响。
Morgenthal 的博文很好地定义了 SOA 的基础，同时仍然提醒着我们，SOA 关注的是架构和业务及 IT 的对齐，而不是软件设设计方法论或提供商工具。
查看英文原文： SOA in a Nutshell
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论