mercredi 29 juillet 2015

What pattern can I use for partial success when calling a method which calls a proxy to aggregate data from multiple endpoints?

As an example, suppose I have the following class:

public class FruitBasket {
    private List<Apple> apples;
    private List<Orange> oranges;
    // getters and setters...
}

Now suppose I also have a method somewhere which gets the FruitBasket.

public FruitBasket getFruitBasket() {
    //...
}

Now further suppose that the getFruitBasket method aggregates data from two different sources, which are accessed via a proxy. For example, there is a server AppleTree to get objects of type Apple, and a server OrangeTree to get objects of type Orange, and both are accessed via a proxy called OrchardGate. This is the reason why I want to write a single getFruitBasket method rather than getApples and getOranges, to minimise the latency when calling from my application to the OrchardGate.

In the case where Apple objects and Orange objects were retrieved successfully, there is no problem, I can just return the FruitBasket. In the case where there was a problem accessing or inside the OrchardGate, or in both the AppleTree and OrangeTree, I can also handle this by throwing a descendant of RuntimeException (or even Exception, if I add it to the getFruitBasket throws clause as appropriate).

However, what happens in the partial success case? What happens if I can access the AppleTree server fine, but I can't access the OrangeTree server due to some transport issue between the OrchardGate and OrangeTree?

As far as I can see there are only four options, and all are absolutely horrible:

  • I could throw an exception, meaning that even though the Apple objects were received successfully, the FruitBasket would not be returned due to the lack of Orange objects.
  • I could ignore the error and just return an empty list of Orange objects. This would mean that the client would not be able to see an error when looking for the Orange objects, instead it would just look as if no Orange objects existed on the OrangeTree server.
  • I could add a field to FruitBasket called errorCodes which contained a list of the errors encountered when accessing the FruitBasket. Then I could add an error code to that list called PATH_FLOODED to signify the error I had encountered. However, this field errorCodes does not belong on the FruitBasket domain object at all. This field is not relevant to a FruitBasket, but only in the transaction to retrieve the FruitBasket.
  • I could throw an exception, but attach the incomplete FruitBasket to the exception. This is also horrible because exceptions should only contain error information - they should not contain any fruit baskets.

I have described this problem in Java but I imagine this problem extends to multiple languages. I was quite surprised to not find a discussion of it already. Is there any standard pattern for writing methods which can return a partial success? Or anything I have missed?

Aucun commentaire:

Enregistrer un commentaire