This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: ESBs improve SOA testability
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
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.
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.
Previous Topic
