对于 The Open Group for SOA 提供的可用作企业示例的引用架构，我有些困惑。
问题 1:在该引用架构中，有一个服务层向外界公开服务。标准文档指出，您可以在此服务层中拥有流程服务，该服务层实现了一些可以作为服务访问的功能流程。还可以在服务层中组合使用其他服务的服务。但是，还有一个业务流程层，据我了解，它主要是通过从服务层编排不同的服务来实现业务流程。业务流程层中的业务流程与服务层中的流程服务有何不同？
问题 2:是否有任何论据来决定您是否应该提供使用多个不同服务的组合服务: 1. 在服务层中，通过为组合服务提供自己的接口(interface)，同时使用服务层内的其他服务？ 2. 作为业务流程层中的业务流程 3.通过在消费者层处理它。
最佳答案
回答 1):
一般来说，业务流程层中的流程与组织中的业务流程密切对应，而流程服务则实现更多“技术”的任务组合。
- 理论上，在理想场景中，业务流程应由业务用户在业务分析师的帮助下通过 GUI 自行创建和修改，而服务层流程则由技术人员实现。
- 另一个区别是，这些业务流程通常包含手动步骤，人们必须手动执行某些操作、做出主观决定或确认/批准流程的继续。
- 业务流程组合了业务服务，而服务级别流程则组合了往往连接到多个后端系统以完成任务的服务。 示例:以订单履行业务流程为例:您可能有一个业务流程，要求客户支持代理在发送订单进行履行之前调用客户进行确认 - 这是一个手动步骤，将成为该流程的一部分。然后，在开始履行后，可能会启动一个名为“评估客户忠诚度级别”的服务层流程。因此，业务流程将执行“履行客户订单”等流程，而技术性更强的服务流程将执行“将该客户的信用评级与我们商业智能商店中的当前中值进行比较”等流程 - 因此需要多次调用到多个后端系统。
回答 2):
这是一个需要上下文的区别，并且通常需要经验才能做出正确的选择，但这是我的两点意见。
如果您拥有适当的业务流程管理解决方案并且组织使用它，那么请务必在此层中实现任何业务流程。对于最终用户(您的企业)来说，这更加灵活且易于理解。
如果您需要实现一个必须从多个系统收集/修改数据的技术流程，那么可以在服务层实现它。当然，您可以尝试在服务层中实现业务流程(我在实践中有时也看到过这种情况)。但请记住，与真正的业务流程管理解决方案中的工具集相比，您的工具集会有些有限。您还将在服务层中拥有一些业务流程，并在业务流程层中拥有一些业务流程，当在某些时候拥有真正的 BPM 时，这可能不是很方便。因此，这实际上取决于面向服务的架构的成熟度。
一般来说，我会尽量避免在消费者中实现流程。它使您的设计与消费者系统耦合，因此您在将来的某个时间点将无法轻松替换它。此外，业务流程管理层(和服务层)都具有更好的开箱即用的监控、日志记录等手段。话虽如此，长期维护和问题调查不会像消费者应用程序那样痛苦。
关于architecture - 有关 SOA 引用架构的问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26958839/