“服务封装业务功能”与“服务可以组合成业务流程”

Question

最近，我正在阅读 2 本书，并且遇到了以下陈述

向 Michele Leroux 学习 WCF：

服务封装业务功能

Service orientented architecture in real world:

服务可以组装（或“组合”）到业务流程中

松耦合 系统导致松散耦合的业务流程，[...]。服务及其 关联的接口必须保持稳定，使它们能够重新配置或重新聚合到 满足企业不断变化的需求

在现实世界中阅读 SOA，我了解到我应该将我的独立（最初无用）服务从业务上下文中抽象出来，然后组合和编排，然后做一些有用的事情，创建业务层并满足业务需求.

然后，阅读Learning WCF让我想到我应该让我的业务层满足特定需求，然后将其公开为服务（当然以非平台特定格式）

目前，我正在制作我的业务层，然后通过定义明确的接口公开它的一些公共方法，但我喜欢制作更多独立服务并组合起来制作业务层的想法。

我想听听经验丰富的 SOA 开发人员的意见，哪些方法最适合获得 SOA 的好处，为什么？

我对这个话题感到困惑。示例和开源项目会有很大帮助。

Answer 1

对我来说，服务的概念是封装与业务相关的功能。但是，这与业务流程不同。通常需要将单独的业务功能组合成更大的单元来表示整个业务流程。例如，进行销售将需要收款、运送产品、计算销售佣金。所有这些都是离散的业务功能，可以建模为服务，但它们必须组合起来才能代表整个业务流程

但是，业务流程往往运行时间相对较长（超过单个请求的网络超时时间），因此需要以某种方式维护业务流程的状态 - 这是 Workflow 和 Biztalk 可以为聚会。

Answer 2

在 Thomas Erl 的书中，他将服务分为“实体服务”和“任务服务”，“实体服务”是与一个实体相关的细粒度、与业务流程无关的服务，通常用于组合/编排中，而“任务服务”则是课程——粒度化，通常涉及多个实体，包含更多业务逻辑，对业务流程有一定了解，不适合重用/组合。

因此，一个业务流程既可以在一个大的任务服务中实现，也可以通过将多个实体服务组合成一个组合来实现。

“任务服务”听起来像是 Michelle Leroux 的服务愿景，而现实世界中的 SOA 则更像是“实体服务”愿景。

在 Erl 的 SOA 愿景中，两种类型的服务可以并存。实体服务是首选目标 - 这些可以更轻松地重用和组合并提高业务敏捷性。但在某些情况下，这可能不合适，任务服务会是更好的解决方案 - 性能需求和封装遗留代码就是两个例子。