从SOAP / WS-API更新/写入调用中分离GUI的好方法是什么？

Question

假设我们有一些配置GUI，它以当前形式使用直接数据库事务以一致的方式为多个可配置组件提交新配置。

现在让我们将数据（DB）的东西移到一些SOAP / WS API之后。 GUI不再具有直接的DB访问权限。必须保留事务行为，但API NOT 应设计为explcitly容纳GUI表单提交。实际上，我甚至不知道新GUI将如何工作或如何构建用户输入。因此，我需要在API服务器端提供类似WS-AtomicTransaction的内容。但是，（至少）有两个警告：

• GUI是用PHP编写的：我认为PHP中没有任何WS-Transaction支持。
• 我不希望在等待其他客户端请求时在服务器端保持数据库事务处于打开状态。

我能想到的解决方案：

• 使用Camel's aggregation。但是，这会使事情变得更加复杂，至少有两种方式：
  • 您不能在同一事务内的后续调用中使用新插入行的数据库行ID。您需要使用某种符号反向引用，因为在处理聚合消息时，客户端和服务器之间不会进行通信。
  • 电话回复不会立竿见影（或者对每一个电话的立即和单独回复只会是某种存根，即除了“您的信息已附加到TX xyz”之外不包含任何有用信息 - 如果这在Camel聚合案例中是完全可能的。）
• 上一个解决方案的两个缺点让我想到了请求批处理，其中可能的WS标准提供了在批处理事务中的后续调用中引用调用结果的方法。有没有这样的东西可用？甚至可能作为PHP客户端？
• 尝试通过仔细使用行级锁等来消除数据库中的锁争用。但是，在插入新元素时，我的猜测通常是页面和索引页需要被数据库锁定。
• 可能是一些使用乐观锁定的服务器端持久层？但同样，如果数据库写入被推迟到提交（不知道是否可能），那么在最终提交之前不会将任何数据库ID返回给客户端。

你想到了什么？

Answer 1

交易是一种强大的工具，我们很容易进入一种思维模式，在这种模式中，我们将每一个问题视为我们用这个大锤击中的钉子。我可以提到你的困惑因为我自己经历过这种困惑。不幸的是，我没有比你更好的建议，而不是考虑事务而是原子API调用。

当我考虑交易时，我的思维模式通常是这样的：

• 启动交易
• 阅读（根据需要重复）
• 更新（根据需要重复）
• 提交/回滚

需要一些时间才能意识到我们过度使用这种模式。实际的冲突是罕见的，还有许多其他方法来处理它们。这是API中常用的一个

• 读取并向客户端发送数据（原子API调用）
• 更新数据（在客户端上）
• 将原始+更新发送回服务器（原子API调用）
  • 启动事务（在服务器上）
  • 阅读
  • 与来自客户的原件进行比较
  • 如果不相同，则返回错误（客户端应重试）
  • 如果相同，请更新
  • commit

最后六点是API调用实现的一部分。

Ferenc Mihaly http://theamiableapi.com