（网络）服务依赖关系问题

比方说，我们有一个电子商务系统，它有两个独立的系统：库存管理系统（IMS）和订单管理系统（OMS）。假设IMS提供围绕库存的信息（getItem，getItemQuantities等），并且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) 
}

您可以轻松地找出一个简单的数据库表结构来实现上述。

作为一个用例，考虑一个客户端将一个项目添加到订单中。此请求需要OMS进行多个服务/数据库调用：

验证orderId（可选，可将此责任传递给数据库）。
呼叫到IMS，以验证传入的itemId存在（必填由于DIFF DB）
呼叫到IMS，以验证库存对传入的数量（由于requred把分差DB）
插入新记录插入到表（必填）

从性能的角度来看，这是否有意义？你能想出更好的方法吗？

[编辑]：作为后续，在用户请求OMS订单细节的情况下，只能返回订单ID，并且每个含有的itemId，数量和小计orderLineItems的列表。客户实际上也希望项目的名称和描述。是通过IMS向客户撤回名称/描述还是由OMS负责？

来源

2009-09-11 djunforgetable

这可以在单个服务调用中完成，这可以使单个数据库调用存储过程。

来源

2009-09-11 00:47:32

这个问题表明这两个系统是分开的。此外，使用存储过程通过在数据库层引入紧耦合来打破SOA的主要目标（尽管这不是问题中提到的问题）。 – 2009-09-11 01:00:55

我用一个存储过程作为如何在低级别实现数据层的例子，来反击关于需要多个数据库操作的建议。 – 2009-09-11 03:11:53

从perfromance的角度来看，我会这样做

验证orderId的服务。

一种名为ValidatePlaceInDetails这确实既验证传入的itemId存在和验证库存对传入的数量

一种用于将新记录插入到表服务。

，我们通过合并2和3

来源

2009-09-13 02:56:59 shivaspk

因此，我们基本上将验证直至订单管理服务。你会实现围绕执行验证逻辑的方法调用的Aspects吗？或者你认为addItemToCart操作应该知道验证要求吗？我会倾向于后者，但我希望看到你（和其他人）的想法:) 但似乎在任何情况下，OMS实际上是一个*复合*网络服务？ – djunforgetable 2009-09-14 21:30:02

我看到你所描述的系统，比一个事实，即它们是独立的其他任何问题减少服务呼叫。

但是，如果我们想象，这不能被任何不同的做法和你担心性能，你总是可以实现某种缓存，以减少数据库查询的数量和顺序的全部内容存储在缓存也是如此。缓存的问题在于，在您提交订单时，需要执行一项新的更昂贵的数据库操作，以检查订购商品是否实际存货，或者只是丢弃不可用的商品。

对于可能的缓存解决方案，请看memcached。

来源

2009-09-16 19:06:05

他们分开的原因很简单，只要oms失败，商店就不会停下来。用户仍然可以访问该网站并浏览，只是无法做出任何订单... – djunforgetable 2009-10-12 22:45:03

由于这是一个SOA问题，我很好奇你为什么要在你的应用程序和webservices之间创建如此强大的依赖关系。

为什么不使用ESB，现在有一些开源的ESB，它可以使您只需调用带有订单信息的ESB，并且响应将是错误或订单号以及您需要的任何其他信息。

你抽象出所有其他的东西，因为它是照顾我在ESB中的规则。

一个ESB我与实验是：https://open-esb.dev.java.net/

的好处是，你可以换出web服务，数据库或添加新的规则，而无需更改应用程序中的任何代码。

如果您的应用程序已分发，这非常有用。

理想情况下，您可以提供一些服务质量要求，因此VIP的订单可以比普通人更快，新用户可以更快更快地完成前两次，这样他们可以看到有多快你的系统是。

在ESB中添加性能会受到影响，但有一些优势，例如松散耦合，可以弥补这一点，因为现在您已经与ESB Web服务的wsdl之外的任何更改隔离了。

来源

2009-09-22 00:10:29

我只会向IMS发出一个请求，请求检查项目X是否实际存在。如果它不是一个有效的项目，IMS应返回一些结果代码，说明我请求了一个无效的项目。这样你就可以省去一次往返IMS的旅程。如果我请求的商品数量不足，我希望另一个结果代码说明。

来源

2009-10-01 07:03:53

忘了SOA一会儿。

您有两个独立的系统和至少一个需要对它们进行一致更新的常见操作。

您不仅需要考虑检查库存，而且还需要考虑减少库存，并且大概只有在订单行的增加时才是正确的。

你打算如何确保一致性？我们可以设计各种方法（2PC交易，或记录保留，或补偿交易，或乐观的批量对账工作），但在我看来SOA或不是Web服务，或者我们仍然不需要解决这些问题。

很明显，为了提高效率，我们希望减少系统部件之间通信的次数，以实现用水量功能。因此，已经提出了“检查和做”的模式。然而，至少在其原始形式中，这样的模式往往不适应失败路径。

这可能是最好的想出几个短路。例如，当订单行被添加时，我们实际上并不检查库存。（可能UI已经显示了库存，因此已经进行了比较近期的检查）因此，我们在订单最终放置时检查库存，然后告诉用户“不能这样做”或“您可能需要等待一两个星期的一些点，你想继续“。

随着狡猾，我们可以使许多操作只更新一个后端系统的任何一个服务调用。

来源

2009-10-16 16:27:02 djna

（网络）服务依赖关系问题

回答

相关问题