On the structure of services

Continuing on my previous post on “SOA Testing”, I wanted to discuss the structure of a service before getting into how unit testing could be used. First of all, I’m going to assume that you are designing large-scale, coarse-grained, autonomous, business-level services rather than dinky little address lookup services. In this case, the business logic of your service would most probably take the form of a Domain Model, a la Evans DDD. If you don’t think that you have enough meat in the service to warrant a domain model, you almost definitely don’t have enough meat for a whole service.

I will not get into how you can unit test a domain model, since that topic’s already been covered elsewhere, but it is worth mentioning that if you haven’t unit tested your domain model, trying to unit test your service is just wasted effort.

Alright then – getting back to the structure of a service. Since a service communicates via messages/messaging (preferably asynchronous), the service needs something to handle the different message types it receives. These are its Message Handlers. A service will have (in most cases) a single message handler class for each message type it can receive. (Remember that a service can receive and handle messages that are owned/defined by other services – for instance if it subscribes for those events.)

There is also the issue of what a message is – or rather, a message schema. A schema has two parts to it, one logical, and the other physical. The difference between the two is that the same logical schema can have an XML based physical manifestation, or a binary one, or a simple CSV/text based representation. While we may choose to use XML to represent our schema in a web services environment, most platforms eventually transform this representation into several classes, usually one class for each message type (inheritance and all that garbage aside). These platform level transformations belong in the bus. Message handler classes should only be aware of the logical schema represented in the platform those classes are implemented in. For example, the class that handles new order messages may be defined like so:

public class NewOrderMessageHandler : IMessageHandler
{
public void Handle(NewOrderMessage message) { … }
}

Notice how the class is dependent upon the platform specific representation of the message. The description “platform specific” doesn’t do the issue justice, since the “NewOrderMessage” class is just a “POJO” – a class that depends on nothing else but the specific runtime. The NewOrderMessage contains all the Integers, Doubles, Strings, etc that make up the order information. The business logic that understands the meaning of all the data in the message, as well as how to interact with the domain model in order to validate and process all parts of the order would be defined in the “Handle” method above.

So, since all the “Service Logic” is contained in message handlers, if you wanted to unit test a service, you would just go about unit testing its message handlers. And for all the zealots out there, no, you don’t have to test the transformation from XML to the platform specific classes. It adds no value.

Just to sum up, and my next podcast (#4) will go into more detail, message handlers are the “Service Layer” (aka Application layer) of DDD. It would be perfectly alright to call them in-process directly in a non-distributed hosted environment. This makes message handlers very suited for the in-process kinds of unit tests that are in such wide-spread use.

In my next post, I’ll describe how the message handlers get wired into the bus in such a way that leaves them independent of all the XMLy goo.

Posted by Udi Dahan at 03:08 PM  Permalink