SOA服务组合实际上在实践中有效吗？

SOA主要服务设计原则之一是服务可组合性原则（https://en.wikipedia.org/wiki/Service_composability_principle）。

这个想法是，通过使用现有服务作为构建模块来组合新服务，可以迅速开发新服务。类似于实现新方法时如何调用对象的现有方法。这就是SOA可以大大提高生产力的地方。

实际上有人真的这样做吗？我已经在书面文本中看到了无休止的重复，但是我自己还没有在现实世界中工作的经验。本书的大部分内容都没有提及事务处理，这在我看来是实现可组合服务的最大障碍。

首先，在组成任何非平凡的服务之前，您确实确实需要解决交易问题。当然，如果该示例具有服务“ findCurrentTime（）”和“ writeLogMessage（）”，则很容易不必担心事务，但是在具有诸如“ depositMoney（）”和“ withdrawMoney（）”之类的真实示例时则不必担心。

我知道两个选择：

1. 使用WS-Atomic Transaction或类似工具实施真实交易
2. 实施基于补偿的解决方案，使用“ cancelA（）”或类似方法补偿对A的调用，如果对B的调用失败

这两个问题似乎都非常棘手/对我来说几乎无法使用：

• WS-原子交易
  • 一个很大的复杂性，大多数的建议，我发现只是警告“疼痛的屁股，不这样做”
  • 支持是有限的，例如，如果您使用开源ESB，则主要替代产品ServiceMix，Mule或WSO2不支持它
• 赔偿金
  • 对我来说，实施赔偿处理似乎很复杂。如果服务A成功并且我们从未从服务B得到答案并且不知道它是失败还是成功，我们该怎么办？手动处理这种逻辑（作为合成服务的实现者）使我想裂开手腕-这是某些工具应该为我完成的工作！
  • 我也看不到如何在非平凡的服务中使用补偿方法。假设您的服务A是“ depositMoney（）”，并且成功，其他一些操作很快将钱转移到其他地方，然后我们收到“ compensateDepositMoney（）”，我们现在该怎么办？好像一大罐蠕虫。

在我看来，服务组合是SOA的一项基本原则，如果您不能（方便地）组合服务，那么您真的无法获得SOA的好处。现实是什么？90％的SOA用户在没有实际服务组合的情况下使用“ crispled SOA”？还是大多数用户实际上使用服务组合，而我却夸大了它的难度？

简短的回答是！

我已经在几个大型金融组织中看到了这一点，并且效果很好。

事务问题很复杂，但通常由（昂贵的）中间件处理，例如Oracles WebLogic EAI或IBM Websphere ESB。

是的，可以使其在实践中起作用。但是，它可能不是最佳方法，并且可能被更多地用作默认选项。在我看来，随着组织发展其IT来自动化更大的任务，SOA作为一种集成遗留系统的方式而变得流行。如果可以重新使用旧版系统，可能会很混乱，但值得这么做。如果您有幸开始一个绿地项目，那么在认为这是最好的方法之前，应考虑其他方法。

为了回答您的一些更具体的问题...

您可以使用交易：

1. WS-TX是PITA，我会避免使用它。
2. 您的所有服务都可能在单个应用程序服务器上运行，在这种情况下，您可以通过XA事务将它们全部覆盖。这就是发明诸如应用程序服务器之类的原因。

考虑基于补偿的方法：

仅在发生故障时才需要考虑补偿措施。服务组合工具是否具有可以控制的标志，该标志可以在第一次运行工作流步骤时清除，但会在后续调用时设置？就像JMS中可能的重发标志一样。然后，您可以使用所谓的1.5阶段提交，这基本上意味着如果清除了标志，则继续进行，但是如果设置了标志，则首先进行调用以检查状态是否已更新并且需要再次进行。您仍然指出，这仍然需要手动进行错误处理，并且可能很复杂，甚至不可能。

在某些情况下无关紧要：

这是最终一致的方法。假设一个服务发送电子邮件。如果服务组合失败并重新启动，则会再次发送电子邮件。对于接收者来说，这有点烦人，但是他们可能意识到它是重复的，并且一切都可以继续进行而不会造成太大问题。

您还可以保留已发送电子邮件的日志，并在设置该标志时使用它来删除重复数据，这样就只发送一次电子邮件。

您可以使用异步消息传递将事务分解为较小的部分：

考虑一个事务性的JMS队列。您的服务协调员可以更新其状态，并在单个Tx中将消息发布到队列中。下游服务可以删除消息，并在单个Tx中更新其状态。现在，您正在多个工作单元中协调服务，但是每个都是原子的。如果发生任何故障并且必须重新启动就没有问题。

这仍然意味着您正在数据库和JMS队列上进行XA事务，但是使用最后一个资源来避免XA的全部开销仍然很有效。

或者，您可以使用此模式，但要对数据库和JMS进行1.5阶段提交。或者，您可以在没有事务的情况下运行JMS，但可以通过集群使其更加可靠。

异步消息传递还可以帮助解耦系统，因为生产者和消费者之间可以变得更加独立，从而减少了整个系统中的耦合量，并使其更加灵活。当涉及具有多种服务的大型组织时，这种去耦非常重要。

不，这是一个神话。设计服务体系结构时，这是错误的意图。有很多问题：

1. 非常紧密的耦合。如果一项服务被更改，则需要测试整个系统。
2. 此类服务的粒度非常细，因此内部通信很多。
3. 由于细粒度，因此提供了许多服务。系统越来越难以理解，查询也越来越难以追踪。
4. 实体服务的封装不完善：此处没有检查任何业务规则，此逻辑在操作服务中。因此，任何服务都可以调用任何实体服务，并使用其接口中存在的通用更新查询来更新其数据。这类实体服务通常被称为以数据为中心的-与以流程为中心，以行为为中心的服务相反。
5. 这些服务之间通信的天生本质是同步的。因此，选择的传输方式可能是http。因此，我稍后会谈到它的所有缺点。

还有更多错误的方法来处理服务体系结构。所以要小心。