例如，我们有一个简单的电子商务系统，有两个独立的系统：库存管理系统（IMS）和订单管理系统（OMS）。假设ims提供有关库存的信息（getitem、getitemquantity等），oms提供订购服务（startorder、additemtoorder、finalizeorder等）
这两个系统使用不同的后端实现为web服务。在OMS中，假设一个简单的模型，如：
public class Order {
private int orderId;
private List LineItem;
...
}
public class LineItem {
private int orderId;
private int itemId;
private int quantity;
private int subTotal;
....
}
在ims中，假设模型如下：
public class Category {
private int catId;
private List Item;
...
}
public class Item {
private int itemId;
.... (other attributes)
}
您可以很容易地找出一个简单的db表结构来实现上述功能。
作为一个用例，考虑一个客户机向订单添加一个项目。此请求要求OMS进行多个服务/数据库调用：
orderid的验证（可选，可以将此职责传递给数据库）。
调用IMS来验证ITEMID中传递的（由于DIFB需要的）
调用IMS根据传入数量验证库存（由于差异数据库而需要）
在表中插入新记录（必需）
从性能的角度看这有意义吗？你能想出更好的办法吗？
[编辑]：作为后续操作，当用户向OMS询问订单详细信息时，它只能返回OrderID和OrderLineitems列表，每个列表都包含itemID、Quantity和Subtotal。客户实际上也需要物品的名称和描述。是否有责任（通过IMS）将姓名/描述转发给客户，或OMS对此负责？
最佳答案
暂时忘记soa。
您有两个独立的系统和至少一个公共操作，它们都需要一致的更新。
您不仅需要考虑检查库存，还需要考虑减少库存，而且可能只有在添加订单行起作用的情况下才是正确的。
你将如何确保这种一致性？我们可以设计各种方法（2PC事务，或记录预订，或补偿事务，或乐观地处理批量对账），但在我看来，不管是不是，Web服务，我们仍然需要解决这些问题。
显然，为了提高效率，我们希望减少传递reuisite功能所需的系统各部分之间的通信次数。因此，人们提出了“检查并做”的模式。然而，这样的模式，至少在其原始形式下，往往无法处理故障路径。
最好能想出一些短路的办法。例如，在添加订单行时，我们实际上不检查库存。（可能用户界面已经显示了库存，所以已经进行了较新的检查）因此，我们在最终下订单时检查库存，然后告诉用户“做不到”或“您可能需要等待一两周才能完成一些任务，是否继续”。
通过巧妙的操作，我们可以使许多操作只为任何一次服务调用更新一个后端系统。