In my post on Guerilla SOA, a reader posted the question as to whether we could use DNS as our means of routing messages between endpoints. The point that was made was that we could define a different host name for each endpoint, and then if we needed to physically move an endpoint we could simply update the DNS entry and messages would still be routed correctly.
Although this point is valid, DNS doesn't give us the power and granularity of routing we require in an SOA environment.
Firstly, DNS will only help us route a message to a physical machine. An endpoint address contains more than just the host name. For example:
net.msmq://policy-service.myorg.com/private/policy_requests
Here we have the transport being specified (net.msmq), as well as the queue name (/private/policy_requests). If we were to change the either of these details, updating our DNS record would be insufficient for our service consumers to continue communicating with our service.
Moreover with this approach, we still have the same coupling discussed in my last post. If we restructure our service contract such that our messages now need to be routed to different endpoints, we would need to update our service consumers.
So although DNS does abstract physical host addresses, we get better decoupling from a more powerful routing mechanism.
Monday, March 31, 2008
Can DNS be my Message Router?
Subscribe to:
Post Comments (Atom)
2 comments:
"If we restructure our service contract such that our messages now need to be routed to different endpoints, we would need to update our service consumers."
True, DNS doesn't solve this problem, but if we use HTTP as our message transport then it can: 301 Moved Permanently.
And we don't need centralized configuration to achieve this.
Very true. This is a nice feature of HTTP. However with SOA we want to be transport agnostic, so I wouldn't recommend this approach. +1 for REST though. :)
This approach would add some complication to the endpoint implementations however. When we move a message to another endpoint, the previous endpoint would have to still have to recognise the old message and know where it went in order to be able to give the 301 response.
Post a Comment