This first user track session is a panel, once again moderated by Michael Coté of Redmonk with John Davies, Technical Director and Head of Research at Iona, Eugene Ciurana of Leapfrog, John Rowell, CTO of OpSource, and John Gardner, Principal Consultant at MomentumSI. My take away from this is that Mule, perhaps open source in general, allows a company to better balance their risk as they test out the potential rewards while implementing tactically against strategic goals. A great metric from Eugene is that the most wait time he has ever had with Mule for a support issue is 90 minutes from opening a ticket to getting some sort of answer, and this is what keeps selling him on Mule vs proprietary solutions. Cost is a factor in ROI, and Mule wins out on not just initial costs but also costs less in need for training, on-going support, consulting, and maintenance; but beyond this, the flexibility of Mule and ability to integrate it with the infrastructure, and the openness not just of the code but in the company and personnel also adds to the return, as does the "cool" factor.
Having now seen Coté moderate two panels now, I have to say that he's one of the better moderators I've seen.
The second session is "A Quantum Leap in Ease of Use: Introducing Mule IDE 2.0". First let me say that having a nice, GUI IDE will help with the ROI perception, in that it is often the perception that development can be quicker and more efficient if done in a nice, pretty GUI. I happen to disagree, but I'm old and like CLI and typing more than clicking. Let's see what these guy's say. Yep, yep, yep… they're showing a pretty drag-and-drop GUI configuration editor. I took the one-day training at last year's MuleCon, and found that configuration through editing XML files to be very easy, and to help with understanding what Mule was doing. There was a contingent of attendees who complained that they didn't have their Tibco Wizard. This should help placate that contingent. Ah, the Mule IDE 2 is pre-alpha, though you can get it on the Forge. The release is expected to be in 2008Q3. The demonstration of the Mule IDE 2.0 plugin for Eclipse looks good; in addition to the GUI, one can still see the underlying XML.
John Davies, Technical Director and Head of Research of Iona spoke on Financial Messaging in Mule. The concept of losing a message in an investment is literally unthinkable. One interesting tidbit is that MS Excel is the only MS products one finds in an investment bank. John went over the front/middle/back office requirements, and the place where Mule is found is in the middle where XML is heavily used, usually over MQ & JMS. Using Artix, Mule, and GigaSpaces on an Azul box, provides essentially linear scaling and throughput is so high, performance is so great, that the need for transactions and supporting transactional relational databases is eliminated, thus increased performance allows increasing performance even more.
Could you expand a bit more about how the “so great performance” alleviates the need for transactions?
Are we talking about cluster-durable vs. database-durable?
I just finished speaking to John about this. Here’s the basics. In a clustered environment, write the transactions as an XML blob to memory, using something like GigaSpaces and index it with something like MAPS. When necessary, convenient, practical, or whatever other criteria makes sense for you, persist the XML Blob by writing to disk. The banks are using openSolaris, so the file system is ZFS, which branches changes much like subversion, thus keeping an history of any changes and ensuring that the history is maintained. By cutting out the database and the huge overhead of the ORM layer, the performance increase is amazing. This is very broad brush. You can get more details by John Davies and sorting through the 137,000 results. ;-)
In answer to the question above, it’s quite complex but in essence because we get such high performance from in-memory “databases", we can start to serialise many of the transactions. Things that used to take 20 minutes now take a second or two and can usually be serialised. Transactions are not alleviated all together but we can vastly reduce the number of transactions and the impact of them on the data, this helps to further increase performance.