(Web) Service Dependency Question

Question

Let's say for example we've got a SIMPLE eCommerce system, with two separate systems: an Inventory Management System (IMS) and an Order Management System (OMS). Assume IMS provides information around inventory (getItem, getItemQuantities etc) and OMS provides ordering services (startOrder, addItemToOrder, finalizeOrder etc)

These two systems are implemented as web services using different backends. In OMS, assume a simplistic model like:

public class Order {
    private int orderId;
    private List LineItem;
    ...
}

public class LineItem {
    private int orderId;
    private int itemId;
    private int quantity;
    private int subTotal;
    ....
}

In IMS, assume a model like:

public class Category {
    private int catId;
    private List Item;
    ...
}

public class Item {
    private int itemId;
    .... (other attributes)
}

You can easily figure out a simple db table structure to implement the above.

As one use case, consider a client adding an item to an order. This request requires OMS to make several service/database calls:

1. Validation of orderId (optional, can pass this responsibility to database).
2. Call to IMS to validate passed-in itemId exists (required due to diff DB)
3. Call to IMS to validate inventory against passed-in quantity (requred due to diff DB)
4. Insertion of new record into table (required)

Does this make sense from a performance perspective? Can you think of a better way?

---

[EDIT]: As a followup, in the case where a user asks OMS for order details, it can only return orderId, and a list of orderLineItems each containing an itemId, quantity and subTotal. The client actually wants the item's name and description as well. Is the resposibility of retreiving the name/description to the client (through IMS) or is OMS responsible for this?

Answer 1

Forget SOA for a moment.

You've got two independent systems and at least one common operation that requires consistent updates to them both.

You need to consider not only checking the inventory but also decrementing it, and presumably that's only correct if the addition of the order line works.

How are you going to ensure that consistency? We can devise all manner of approaches (2PC transactions, or record reservations, or compensating transactions, or optimistic work with batch reconciliations) but in my view SOA or not, Web Services or not we still need to solve those problems.

Clearly for efficiency we want to reduce the number of communications between parts of the system requied to deliver the reuisite function. Hence the pattern of "check and do" as has been proposed. However such patterns, at least in their raw form, tend not to cope with the failure paths.

It may be best to come up with a few short-circuits. For example, we don't actually check the inventory when the order line is added. (Probably the UI already displayed the inventory so a comparatively recent check was already made) So instead we check the inventory when the order is finally placed, and then tell the user either "couldn't do it" or "you may need to wait a week or two for some bits, do you want to proceed".

With cunning we can make many operations only update one backend system for any one service invocation.