September 07, 2006
Asynchronous communication at odds with reliability?
This week I'm finally going to get around to a question that's been sitting in my inbox for a while. Jason asks about SOA, asynchronous messaging, smart clients, and service reliability:
"Udi,
Thank you for your webcast on messaging and SOA and how they change everything. I’d listened to an ARCast on “asynchronous” requirements for autonomous services and was getting quite frustrated at how unusable that concept seemed to be. After listening to your webcast, however, some of my questions were cleared up. Your assertion that high throughput systems can most readily be achieved my using correlated messaging with queued message handlers and senders seems to be valid. I still have a couple of outstanding questions that I’m confident you can quickly answer. I’m just about ready to buy into the concept of correlated messaging as a requirement for SOA, but:
1 – Assuming that the end client (Smart Client) is using services through correlated messaging, and the services need to respond back, how do we bypass firewalls, etc. to get to the port on the client that will receive the message. Do we use a mechanism to ride back over the same ports that we received a request on?
2 – I’ve heard it stated multiple times that the idea is that you submit a request and whenever the service can get around to fulfilling it, you’ll get a response. This doesn’t seem to be a very reliable way to service users. What is your take?
Thank you for your time and the guidance you provide to so many."
Well Jason, thank you for your kind words and my apologies for this belated reply.
To your first question, there are two answers. The first answer is that "end clients" can very well be considered part of a service. I expounded on this topic a couple of posts ago and you can find it here. If the end client is not part of the service that it wants to communicate with, we can (again) take one of two views. The first is a technological perspective; how we keep a high-level asynchronous API yet use the underlying protocols in such a way that common infrastructure won't get in our way (i.e. firwalls).
One technical solution is first to have all clients communicate to/through a common gateway which, in turn, communicates with the target service. You may then be able to press the infrastructure guys to open a single port for the gateway, instead of N ports for all the client. Otherwise, given that the clients already are communicating asynchronously, you might be willing to have the gateway communicate synchronously with the service. I think that you're hearing that I don't think much of this technological perspective.
The architectural perspective would state that if the end clients don't belong to the target service, they probably belong to some other service. In which case, you'd maintain loosely coupled communication at the service level, while letting the end client communicate synchronously within their own service. When you're talking at the service level, you usually have the mandate for opening ports to support the enterprise standard of communication.
As for your second question, I over-exagerate the point I'm trying to make. In good network conditions, and when Murphy is on vacation, the service will be able to respond promptly to client requests. The issue I'm raising here is that things always go wrong, and at the worst of times, so design your systems for those worst cases, and then be pleasantly surprised most of the time. However, what you'll be avoiding is system-level race conditions - where system A is waiting for B, which is in turn waiting for C, which is waiting for A, but since all of A's threads are held up waiting for B, it doesn't have any threads available to answer C.
In good conditions, service reliability is just fine, although the more appropriate term would be service availability or the service level agreement (SLA) that the service could support. What we're doing here is improving system-wide robustness.
So, I hope that that answers your question Jason, and thanks for being so patient with the response :) To everybody else who has sent me an email and hasn't seen a response yet, don't worry, I haven't forgotten you! One of these days I'll have to quit my day job and do this full time. What do you think?
Posted by Udi Dahan at 05:38 PM Permalink
|
