Service Oriented Applications (SOA) Application architecture (part 2)
In a previous
blog post I described the general SOA architecture. I finished after describing the two basic message types we needed to send around the system. These where:
- Fire and forget notification messages to multiple endpoints.
- Request and response messages to a single end point.
Now that we know about the kind messages we need to take a look at how to get those around the system.
In the case of fire and forget messages we have a number of choices:
- Send to message to a message pool where every service of the application receives every message. This is very simple to implement using a drop directory, database table or some similar system. However this approach lacks in scalability because each endpoint has to open every message, check the message type and decide what if anything to do with it. When the system gets larger in size with more services and is used more and more the number of messages increase and every service gets busier and busier opening messages that it probably has no interest in at all.
- Create a message loop/pipe line. This approach is also relatively simple to implement and is similar to a token ring network. Each service just has to be aware of one inbound and one outbound queue, read all messages from the inbound queue, optionally do something with it and then send it to the outbound queue. Again the downside is that every service has to open and look at the message limiting its scalability. One additional downside is that if a single service is down all messages stop there and the other services further down the pipeline won’t receive any events until the stopped service is running again.
- A central routing application. I think this is the best way to go. In this case each service sends its messages to the routing application. Next the routing application looks at the message type and compares that to a list of interested endpoints and forwards it to those services. Now this is typically something that BizTalk does very well, not really a surprise as that is what BizTalk was designed to do. Besides just forwarding messages BizTalk has additional capabilities in transforming the message itself, something that is really handy if one of the existing services is replaced by another one. A scenario where it is likely that the new service is designed around a different message format.
We also need to route the Request/Response type of messages. In this case we are talking about an endpoint to single endpoint message. Again we want to make sure that services are unaware of each other. Basically we have the same options as above but in this case we also need to route the response back to the sender. Again the central routing application is the most appropriate kind of routing style.
Now there is one problem and that is that BizTalk is expensive, actually very expensive. Depending on the kind of application it might be enough to create a small application that just looks at XML messages dropped in a specific input queue and copies them to input queues for specific services. Again these can be simple directory drops where each service looks at or something more advanced like MSMQ or SQL Server Service Broker. A central routing application like this isn’t all that complex to develop, been there done that, and can be quite enough for a simple SOA application. Additionally an application like this can be reused in the next SOA application provided that the routing is specified in the same way or is done in a configurable way. If full scale transformations and multiple communication types are required things get more interesting and BizTalk is probably a good way to go because the amount of work and support required would be more expensive than the BizTalk route.
If you want a quick start, just go with the central drop directory and drop all messages there and have all services read from them. Just make sure you define two different directory settings for each service, an inbound and outbound, that simply point to the same directory. This way it is a breeze to add a central routing service and have each setting point to a different directory.
That leaves us with the message itself and how to add both the routing information and its payload in a reusable format, something I will cover in a
next blog entry.