Ross Mason, the Mule head-honcho, tried his best to combat the increasingly hostile AV equipment while promoting Mule2’s integration with Spring2, the former not yet GA’d. His moaning of how hard the team is working to get Mule2 out was in direct contradiction with the entire weekend he spent gambling away at The Venetian – yeah Ross, I saw you near the slots over the weekend. So Mule2’s approach is something called “The Hollywood Principal” which means “Don’t call us, we’ll call you” – damned if I know what that means. Mule is the latest to create their own Spring XML namespace and from the examples, it didn’t seemed terribly hard to get an ESB going.
Mule’s also proud that you don’t have to mention class names in your Spring config files anymore which is seen as a big plus? Not sure if that’s really the case since there will be a tight binding somewhere else and you’ll just be jumping through another hoop to get Spring to work. Of course, no talk is complete this year without a mention of OSGi and this one was no exception. Turns out an OSGi container will do hot deployment of Mule endpoints, services, transformers and anything else you dream up. Not a bad talk, would be better if his audio worked.
The guy sure is proud that the Mule IDE doesn’t overwrite your code changes once you go from code-view to design-view. Is that really something so special that you have to point it out? And one more thing, stop showing the donkey from Shrek and pretending it’s a mule – it’s not a mule, it’s a donkey! I was going to download Mule to test it out, may as well do it once it’s got the Spring2 stuff in it. Also, stop wasting your time on Drag’n Drop features for the IDE, that’s stupidness.
Mark Richards seems like a guy who could talk for 16 hours straight without any water or oxygen. When this talk ended I felt a lot better because I finally saw some people who were as confused as me about what an ESB is and what it does and doesn’t do. Instead of defining what an ESB is, Richards first proved that nobody really knows what it is by whipping out three different but widely accepted definitions of an ESB through “Buzzword Bingo” which I loved. Instead, he tried to solve the problem of how to deploy a distributed environment and offered point-to-point solutions using JMS Queues and Adapters which ended up solving the problem but required additional work such as wrapping the messaging protocol etc. So even if we supply a good level of abstraction, we’re still bound to a contract and if the application changes, so must the client. The answer to this problem? An ESB.
Service Locational Transparency and enterprise wide security seem to be the two major benefits of having an ESB, both of which are currently undoable using point-to-point techniques and plain old web services. It was a great talk by Mark Richards who was nice enough to dumb it down to code examples when talking about SLT, consistent service access and implementation decoupling.
The talk was titled The Enterprise Service Bus: Do We Really Need it? and Richards seemed to answer, Yes, unless you’re a wannabe architect working on one pathetic system. The need for an ESB seems directly proportional to the number of different transport methods and disparate systems your services are being provided from. If you’re doing POWS (Plain Old Web Services) on a single cluster, it’s definitely overkill. If you’re managed to get yourself tangled up in queues, web services and RMI, I say go for it.
Rod Johnson pitched Adrian Colyer’s talk on Spring’s OSGi integration and I bit. It’s surprising that an idea so old and good is only now being realized and accepted. I raise me hand when I say I had little clue of what OSGi was until this conference except that Eclipse’s plugin system was based on it. Lots of talk about visibility, versioning and operational control coming through a British accent makes you feel warm and fuzzy but let’s face it, we’re years away from OSGi actually being adopted in the mainstream. No matter how hard Spring tries to “osgi” their modules, they’ll still have to wait for the likes of commons-lang to comply with OSGi before somebody can actually build a true OSGi based system.
So the idea of having more than one version of a module in the same JVM seems to excite everybody but I’m wondering if that really is a good thing? What does it say about your application if it’s dependent on spring-jdbc 1.2.8and spring-jdbc 2.0? Sounds to me you’re using OSGi to cover up some pretty crappy software design and decisions. Colyer had a good, concise and short-scoped talk on OSGi and anybody who didn’t know what it was before they entered the room, had a damned good idea when they left it. These Interface21 guys don’t seem so bad in person as they do on the forums.
Random Notes: Lost around 15 bucks, Cirque Du Soleil is overrated, Gondola rides are for posers, 10 dollars for a drink at The V is robbery