TSS Java Symposium Review Part 2: Spring2 + <anything> = cool; ESBs exposed; OSGi love

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


2 thoughts on “TSS Java Symposium Review Part 2: Spring2 + <anything> = cool; ESBs exposed; OSGi love

  1. Neil Bartlett

    I think you’re wrong about mainstream OSGi being years away. To take your example: Spring doesn’t have to wait for commons-lang to “comply with OSGi”. They just add a few lines of metadata into the MANIFEST.MF of commons-lang.jar and, hey presto, commons-lang now complies with OSGi. In fact this has already been done for a very wide range of existing open source libraries, and the results are stored in a Maven-like repository.

    Thousands of developers are already building “true OSGi based systems”. Anybody who develops for WebSphere application server today is building a true OSGi based system. Anybody who uses Eclipse is using a true OSGi based system. Anybody who uses anything that came out of BEA recently is using OSGi – they’re basing all their new development on it (not yet their most famous product, WebLogic Server, but maybe soon). Anybody who runs the new version of Lotus Notes when it comes out will be using a true OSGi system. Anybody who drives a BMW 7 Series car is using a true OSGi system – the onboard entertainment system is based on it. Need I go on? 😉

    As for two versions of the same thing side by side, you’re right that it’s not necessarily desirable. The thing is, sometimes it’s unavoidable. If you’re using two or more third-party libraries in your application then sooner or later you’re going to get a problem where one of those libraries needs (say) Log4J version 1.3 and another one needs Log4J version 1.4. Ideal you would just get everybody up to the same version, but that just isn’t always possible. In standard Java you have no choice but to go with Log4J version 1.4 and hope that the guy who wanted 1.3 doesn’t break. OSGi simply gives you more options.

  2. Alex Blewitt

    If you want to read up about BEA’s mSA framework, based on OSGi and what all products (inc Weblogic) are going to use going forwards, here’s a URL which explains a little about it:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s