最近，我正在阅读2本书，我发现了以下陈述
从Michele Leroux学习WCF：
服务封装业务功能
Service orientented architecture in real world：
服务可以组装（或组合）到业务流程中
松耦合 系统导致业务流程松散耦合[...]。服务和他们的 关联的接口必须保持稳定，使其能够重新配置或重新聚合 满足不断变化的商务需求
在现实世界中阅读SOA，我理解我想要从业务环境中提取我的独立（最初无用）服务，然后编写和编排然后做一些有用的事情，创建业务层并满足业务需求
然后，阅读学习WCF 让我认为我应该让我的业务层满足特定需求，然后将其作为服务公开（当然是以非平台特定格式）
目前，我正在创建我的业务层，然后通过定义良好的接口公开它的一些公共方法，但我喜欢创建更多独立服务的想法，然后编写构建业务层。
我想听听有经验的SOA开发人员，这些方法中哪些方法可以获得SOA的优势以及为什么？
我对这个话题感到困惑。示例和开源项目将会有很大帮助。
答案 0 :(得分：3)
对我而言，服务的概念是封装与业务相关的功能。但是，这与业务流程不同。通常需要将单独的业务功能组合成更大的单元来表示整个业务流程。例如，进行销售需要付款，发货，计算销售佣金。所有这些都是可以建模为服务的独立业务功能，但它们必须被组合以表示整个业务流程
但是，业务流程往往运行时间相对较长（超过单个请求的网络超时），因此需要维护业务流程的状态 - 这是Workflow和Biztalk可以为其带来的事情之一。方。
答案 1 :(得分：1)
在Thomas Erl的书中，他将服务分类为“实体服务”，这些服务是细粒度的，与一个实体相关的业务流程无关服务，通常用于作曲/编排，以及“任务服务”，它们是课程 - 粒度，通常涉及多个实体，包含更多的业务逻辑，对业务流程有一定的了解，不适合重用/组合。
因此，业务流程既可以在一个大型任务服务中实现，也可以通过将多个实体服务组合到一个组合中来实现。
'任务服务'听起来像Michelle Leroux的服务愿景，而真实世界中的SOA更多的是“实体服务”愿景。
在Erl的SOA愿景中，两种类型的服务可以并存。实体服务是首选目标 - 这些目标可以更轻松地重复使用和组合，并提高业务灵活性。但在某些情况下，这可能不合适，任务服务将是一个更好的解决方案 - 性能要求和封装遗留代码是两个例子。