ESBs improve SOA testability

In my latest podcast I tried to describe the value that the bus architectural pattern can bring a distributed system. You can also find a link there to a detailed analysis of the API of a bus, and how well Microsoft latest communications platform (WCF, formerly known as Indigo) fits in with that API. What isn't immediately apparent is how the use of a bus can affect how you test a service.

The important thing to note about using a bus in such a fashion is that your application logic is entirely decoupled from technology. Just as important is that modeling of the message handler as the primary abstraction for encapsulating that application logic. In a supporting role, we find the message schema is a group of “plain old {your language here} objects” and independent of the XML representation on the wire.

In this design, we do not even require a bus in order to test our application. By encapsulating the application logic behind message handlers, we are now able to write application level tests just as if they were unit tests, and even run them using the same infrastructure (xUnit).

The result is striking. By isolating the message handling logic from communications details (like HTTP), we make it easier to write tests. This, in turn, results in more, higher quality tests that run faster – decreasing the time programmers need to wait for feedback.

Shorter timelines. Higher quality. Technological independence.

What’s the catch?

Well, this paradigm of messages and message handlers get muddled when multiple services handle the same kinds of messages – not to mention it introduces implicit dependencies between those services. The answer is: just don’t do that. There’s no reason two Autonomous Services should share the same schema. Since each Autonomous Service provides unique business value, there should be no overlap. In the cases where it appears there must be, the answer most often lies in switching to asynchronous communication.

The case where two Autonomous Services appear to share part of a schema most often occurs when you want data to pass from one to the other. One way to do this is to have those common messages be, indeed, common. Another, better, way is to have the consuming service subscribe to those messages published by the producing service. I’ve found this event-based, pub/sub pattern to best maintain the autonomy of each of the services.

So, there’s no real catch, if you get your boundaries right.
[Posted here as well.]

Posted by Udi Dahan at 05:13 PM  Permalink