This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: MEST infrastructure looking for a name
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.
After Savas has oh so gently prodded me (again) to continue writing about my MEST infrastructure, I thought that first of all I need a name for it. I'm waffling between the cute "MEST-up" and the ego-centric "UdiBus". Let me know what name you like.
Anyway, alpha testing has been going well. There are currently three configurations in which the product can be run: Client, DbService, and ComplexService. As for benchmarks, it's not really that interesting what happens in Client mode (it runs fast), but DbService and ComplexService are what matters. On my 2-year old hardward at home, DbService runs at around 45 messages per second (sustained) and ComplexService comes in around 100 messages per second (sustained) with the ability to handle bursts of around 600 messages in one second without adversely affecting latency.
Just so we all understand what's going on, the purpose of this product is to provide an infrastructure for developing robust distributed systems. This means that despite various environmental failures, no information will be lost and data consistency will not be compromised. These failures include network outages, server reboots at the worst of times... the usual suspects.
In DbService mode, the use of the DTC and transactional messages queues gives the required robustness characteristics, but adversely affects throughput. ComplexService mode splits message handling into a 2 phase process, the first in-memory with message sending tied to the original message receipt with queue level transactions, the second phase acting the same as the DbService. Of course, when handling new information coming into the service, Ids must be generated by phase one, and durably passed to phase 2 for persistence along with all the regular message data.
Finally, as a programming model I've based the infrastructure around 3 major elements:
IMessage which represents what messages look like - this being more of an envelope in that it has a header with all the relevant information, but the body isn't bundled into a separate part - it's just data on the message.
IMessageHandler represents that code which will run when the appropriate message arrives at the current service.
IServiceBus represents the API to the outside world - subscribe/unsubscribe, publish, send (with it's many variations...
Let's talk about send for a second:
you can just send a message and be done with it.
you can send a message to a specific service, regardless of whether you know if that service can understand the message.
you can send a message specifying the code that you want to run when a response arrives, or that the timeout you set has elapsed.
Timeout is an important part of any time-critical process. It can be as little as 1/10 of a second, or as much as several days.
Of course, a service may reject a message (send back the original message with the reject code set in the header) specifying why it did that, and have that information return to the sender. Conversely, a service may acknowledge that it has processed the message successfully.
The really interesting thing I learned (from one of the projects that this product is being used in) is how it looks to implement a broker style architecture with a bus style product.
Anyway, I'll be looking for beta testers in the coming weeks. Let me know if you're interested and what kind of system you're considering using it in. If you want to know more about features, or how it's built, drop me a line and I'll put up a post so that everyone will keep updated.
Previous Topic
