views:

61

answers:

1

I'm starting to design a new version of one of my company's telecommunications products, and to provide load balancing and scalability I was considering some kind of (.NET open source) ESB. I'm hoping to boost the throughput of the system by avoiding relational databases and use (perhaps) non-transactional queues feeding into distributed in-memory caches (Velocity or memcached for example).

I've never used an architecture like this for a real-time system, and I'm worried that what I gain in simplicity of day-to-day development, I lose in throughput (which for this app is hyper-critical).

I've only played about with NServiceBus, so I have no idea whether it (or its brethren) is suitable as a foundation for real-time no-sql apps. What do you think?

How should I judge these products? Should I buy a commercial app instead, avoid ESB like the plague, or use some other approach?

+2  A: 

Andrew,

When talking about throughput, parallel message-based architectures tend to work very well. NServiceBus specifically has scaled to very high levels, and when used in conjunction with non-locking persistent stores, can perform tremendously.

When you say real-time, obviously you're not talking about hard real-time here - as you're still on Windows, and even then not programming in C/C++. In other words, it sounds like the main goal is throughput rather than low latency. I think you'll find that ESBs can work out very well for you.

Udi Dahan
Hi Udi, True, it's not real-time in the sense of requiring 100% predictable timing from all levels of the system, but messages coming in must be transported from the dialer hardware through to the users' machines within a fixed number of milliseconds, otherwise they are worthless (a weaker definition of real-time). In that sense we need both to reduce individual message latency as much as possible, but also to allow the system to handle many simultaneous messages. We also need to hang a lot of other non-real time systems off of that message flow.
Andrew Matthews
There is Rhino.Esb too - I wonder if that fairs well in comparison to NServiceBus?
cvista
The design of Rhino.Esb was based to a large extent on that of NServiceBus - so I'd assume the performance and throughput should be comparable.
Udi Dahan