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

Question

最近，我读了两本书，我看到了下面的陈述

向Michele Leroux学习WCF：

服务封装业务功能

http://www.enterprisearchitecture.ir/downloads/books/ServiceOrientedArchitectureInTheRealWorld.pdf

服务可以组装(或-composed‖)到业务流程中。

­

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

在现实世界中阅读SOA时，我明白我应该将独立的(最初无用的)服务从业务上下文中抽象出来，然后编写和编排一些有用的东西，创建业务层并满足业务需求。

然后，阅读学习WCF让我认为我应该让我的业务层满足特定的需求，然后将它作为一个服务(当然，以非平台特定的格式)公开。

目前，我正在创建我的业务层，然后通过定义良好的接口公开它的一些公共方法，但是我喜欢这样的想法，即创建更独立的服务，然后进行组合来创建业务层。

我希望从经验丰富的SOA开发人员那里了解到，，这些方法中有哪些是获取SOA好处的理想方法，以及为什么是

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

Answer 1

在Thomas Erl的著作中，他将服务划分为“实体服务”，这些服务是细粒度的、与一个实体相关的业务流程无关的服务，经常用于组合/编排，以及“Task Services”，这些服务是过程粒度的，通常涉及多个实体，包含更多的业务逻辑，对业务流程有一定的了解，不适合重用/组合。

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

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

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

Answer 2

对我来说，服务的理念是封装与业务相关的功能。但是，这与业务流程是不一样的。通常，需要将业务功能的各个部分组合成更大的单元来表示整个业务流程。例如，销售将需要支付，运输产品，计算销售佣金。所有这些都是业务功能的离散部分，可以建模为服务，但必须由它们组成来表示整个业务流程。

然而，业务流程的运行时间往往相对较长(超过单个请求的网络超时时间)，因此业务流程的状态需要得到维护--这是Workflow和Biztalk可以为各方带来的事情之一。