Number 6 in your enterprise-y features list, management/statistics collection, is something we’re still tinkering with. Turns out grid management of our nodes across multiple physical machines is not a trivial problem to solve elegantly…

So far we’ve tried a few different implementations: Plain Java sockets, JMX, and a Terracotta based communications mechanism. Each has an important drawback which leaves a bad taste in my mouth. We’ve so far stuck with the TC based system because it doesn’t introduce a new moving part into our implementation and is sort of “the simplest thing which could possibly work.”

Maybe Mark or I will elaborate on them sometime. It’s an interesting and important topic. The bus system isn’t of much use unless you can easily deploy and manage nodes in the cluster… I am curious to understand how other systems tackle the problem.

The reason I follow your blog (and Terracotta, and Gridgain, and ActiveMQ, and HardOop, and … ) – is that IBM’m may have the right product for us, but, I can not wait for the day when we can kick them, and all other providers that want to dictate scaling strategy with byzantine licensing and muck up development and debugging with closed source drivers.

I come here not to point out that your falling short of some arbitrary standard, but to push us all ahead!

Anyway, thanks for the interesting posts as usual Mark. I follow perhaps 30 Java blogs in my reader, but always seem to be commenting here.

You (again, like last time) make excellent points.

You’re working in finance, which makes your requirements somewhat different than mine. For example, we don’t have a need for JTA and the like, which you mention in a previous post on my blog and again in your list above (#3).

TC provides persisent storage of messages in their disk cache. We would probably need to build in a little more functionality to assure that messages are not only delivered but also processed successfully through our system. TC clusters maps, so putting a message into some kind of holding bay until taken out later (upon successful completion) seems like a ridiculously easy feature to implement.

We’ve got multiple of everything. All consumers run in their own JVMs across the network. TC is the glue that binds them together. We’ve got multiple of each type of consumer.

TC has a network high-availability config option. This may be new from when you last looked at it.

We can put a lot of messages through our system, and processing those messages take longer than the overhead of bussing. But we’re in a different business that you are. Our processing is CPU intensive, so we’re limited by hardware. We can and will scale out our server farm horizontally to increase our throughput, but we’re also not writing a trading application. Our messages take several seconds to several minutes to process. We just need an easy way to distribute them all across the network for parallel processing. That’s what we built.

My very first blog article is titled “Horses for courses.” I think you and I are running different races, so our choice of tools will, naturally, be different.

I hope one day a fully open source message system will satisfy your reliability requirements. Until then, it sounds like IBM’s got the right product for you.

1. Guaranteed message delivery
2. No single point of failure
3. Some sort of true transactional semantics (i.e. Deliver all these messages or none)
4. High message count throughput
5. Large message size support
6. Management/Statistics collection

If you can accomplish all this in 92k, I am 100% on board. Trust me, we are tired of paying MQSeries licensing fees, and worrying about the reliability of ActiveMQ is not good for my blood pressure

Like the post relational solutions that are now looking to replace RDBMS systems (see http://www.vldb2007.org/program/slides/s1150-stonebraker.pdf) – the enterprise message bus could really use an out of the box rethink. I applaud any efforts towards this and still find Terracotta an interesting product. But, where does it fit into a production environment. Last time I looked it seemed to only offer hot/cold multi-node capability. How do you scale things up and out, etc..

Treating the network as a single VM is great, but hell, I worry about the data fidelity inside our single VM nodes as is. Additionally with our messaging bus I worry about network outages, VM bugs, memory limitations, disk space issues, the “oppps, I tripped over the power cable” factor, etc, etc, etc – With something like JMS (and specifically a JMS provider you can trust, but hopefully as more implementations mature, that will count everyone) I can be certain within a very high level of confidence that when I PUT, the message will come out the other end.. Be it sooner, or later. Maybe my thinking in all of this is just screwed so tightly to our current business needs and current toolchain.. I am willing to admit that.. Well, that’s why I am here, looking to you guys to think outside of all that, just don’t forgot about the basic needs in all the excitement.

Really though, I love following this stuff and please keep up the interesting work..

Again, its great to see your enthusiasm. Let’s try to talk some time soon. I want to help all these people understand what you have achieved. Like Dan says, there has to be a lower detail version of sharing what you have done than just open sourcing the source. For example, we could collaborate on a whitepaper that documents the architecture concepts, the interfaces, and the capabilities w/o the use case or the implementation.

As an example, I am working with the kind folks at http://www.getabby.com who have implemented SQL on top of Amazon SDB and while they have not shared anything yet, we plan to get together and make something generically available to the market (documents and source) without revealing a thing about getabby.com and their usage of this technology.

Very smart and lucid arguments as to why consider reinventing the wheel, BTW!

Kewl,

–Ari

As for JMS/ActiveMQ/etc a compelling reason to use a middleware server is to connect to applications which are out of your control or written in (possibly unknown) alien technologies. Which is why something AMQP-based like Apache Qpid is interesting. AMQP about an effective protocol, not an over-complex-broker-for-my-app. With AMQP you can send a message from Python to Erlang to C#, never mind JMS or ActiveMQ! That’s when brokers are useful.

Well done on the less is more front.