Enterprise.Even saying the word can send shivers down the spine of the ‘enlightened’ developer. It can conjure up thoughts of gargantuan XML configuration files tied down with lashings of buzz, pomp and sales patter. Of documentation and usage so verbose that the eyestrain is almost palpable from the mear tonguing of the term. However, sometimes, on rare occasion, our gut is wrong and our reaction foolish because out there in ‘enterprise’ land are some truly fabulous nuggets of software. In this posting I will be looking at one such ‘diamond in the rough’ and seeing how we can exploit it in rubyland.Distribution. In the sense of networks within software systems, distribution has near boundless uses; session sharing, shared processing, file access, logistics, analytics, etc., however its implementation is non-trivial. It is, in fact, a bloody hard problem to solve requiring schemes for; networking, fail-over, discovery, clustering, events, backups, locking and more besides. Its therefore not surprising that few technologies exist in the ruby community to allow for truly distributed sharing of data, clustering if you will. Nor is it particularly surprising that there isn’t really a potent technology for realtime event broadcast and node synchronisation or for distributed locking. All of these problems can of course be solved through the use of transactional databases, transactions and a strong dose of hack but it simply doesn’t have to be this way. This difficult!Money, Money, Money.Within the world of the enterprise, distribution is big business (puntastic.) It is required for a plethora of business problems from ensuring your bank balance is consistent through to updating the stock in your local supermarket. You see enterprise is massive, there systems scale is truly vast, often intercontinental, and so it is paramount that systems can communicate efficiently, easily and reliably. The fiscal leverage of such organisations has provided an ideal excuse for some seriously sharp minds to pit there wits agains the problem and luckily for the rest of us, the results are ripe for the picking. Exploit.Hazelcast is one such solution. An open source clustering and highly scalable data distribution platform which is:Lightning-fast; thousands of operations/sec Fail-safe; no losing data after crashes. Dynamically scales as new servers added. Super-easy to use; include a single jar. Waaaait a second! ‘include a single jar’ Surely these be the words of the mad?! Ah yes, Java, the undisputed king of the enterprise world. The conservatives choice. Verbosity to ruby’s terseness, static to it’s dynamic, rain to it’s DRY. However again we sometimes forget that in spite of it’s failings within the eyes of the rubiest it holds advantage for many application. It’s hugely fast, portable and, in this case probably most importantly, the enterprises love it. Furthermore, for us it’s hereditary Java genes are too our advantage.On walks JRuby.Due to the nigh insurmountable work of Charles Nutter, Thomas Enebo, Ola Bini and Nick Sieger along with there team we have direct access to Java libraries and thus to a plethora of usefulness. Sometimes I think we forget how lucky we are, the ruby community, to have such awesome people simplifying our lives, anyway, thats quite enough arse kissing. So, on with the show: What you see above is a fully distributed hash. It has redundancy, consistency and a smorgasbord of other features all built in and with about 6 lines of ruby we can use it. Download it, run it a couple of times from different terminals and you will see that for each new terminal the system finds and connects with the others and appends it’s own hello message to the hash (you will see the hash growing.) Close an instance and then open another, the hash will remain along with the destroyed nodes entry. Tell me that isn’t cool! How about a fully distributed process queue? Sure the example is stupid and there is a million better ways of passing through a function than with a string and eval but for a second ignore the stupidity and look at the potential. A full distributed, falt tolerant job queue in 12 overly verbose and crappy lines of ruby! Potentially the worlds worst chat program but again, distributed, tolerant and broadcast/event enabled. In this example, as the rest, I have provided nothing more than a naive example using strings to broadcast messages however there is no reason that the strings are no objects of more value. We could be passing currency objects or error messages, instances of Person (everyones favorite model) or even binary data. The Lowdown.You are tasked with the job of creating a POS system for a local shop. Nothing fancy is needed, you construct a little interface in HTML, hook it up to a sinatra app running in the back office which records purchases to a database and interacts with some given merchant account and all is well. The shop takes off, expands to 3 stores and suddenly needs a distributed solution. This is still possible with what we have however assuming we now have some stock of goods in a warehouse which is shared amongst the stores it may become cumbersome having stocks updated only when an action is taken on the POS. Imagine how nice it would be to have the stock updated on screen as alterations occur? Ajax/Web-socket + broadcast and your done. You still have your simple system but now it has a new feature and it’s cost practically nothing and is utterly, enterprise, resilient. This is your traditional enterprise problem domain but with a coat of Ruby simplicity painted on top.Or. Want to round-robin load distribute your server hits but need your sessions to be sticky to the user? Database? Or… simply place the session data onto the distributed hash and you suddenly have no single point of failure! Server dies, all your sessions remain. How about sending emails? Queue them up and have multiple systems take care of delivery without so much as a smidgin of work for you.Basically.There are a million more features to hazlecast which I haven’t mentioned and doubtless the whole experience could be made yet more loverly with a little gem which wrapped up the little ugliness left over (and in fact it has by some inspired by this little scribling) but the point is this: Go check out the Java landscape, see what you can find and get it out there. Don’t be afraid of the BIG Java Enterprise with all it’s buzz because although there is bloat out there, there is stuff which can blow you away. Java