Thursday, March 26, 2009

Muscle meets Might

Just saw the article on Red Hat Adds Muscle to Apache CXF. Hurrah! This is a great thumbs up and vote of confidence for the great work that has been done by the Apache CXF community. Bringing in this muscle, and combining it with the might of the many committers of the CXF project, lead by fusesource.com's Dan Kulp, is going to establish CXF further as the de facto implementation for open-source web services.

The new JMS flow in ServiceMix 4

I wandered down to the hotel bar last night and bumped into Guillaume Nodet; we got chatting about the new support for JMS flows in ServiceMix 4. I've written about JMS / JCA flows in a previous blog entry, arguing that, if not correctly configured, they can lead to far too much distribution and a consequent impact on performance. Back then, I argued that using explicit JMS queues - through ActiveMQ or whatever JMS broker you want - can provide just as effective a mechanism for distribution, message persistence, reliability and location transparency.

The latest stuff in SMX4 introduces some new stuff that makes me feel a lot happier about the concept of implementing the NMR with a JMS flow. First, if you want a JBI endpoint to be clustered, you have to explicitly mark it as clustered. This I like, as it gives the developer/designer back control of where the distribution points are in a flow. Second, the JBI flow now uses a single distributed queue for clustering. Previously in ServiceMix 3 a seperate queue was created for each JBI endpoint using the JMS flow; the new approach means less queues and less threads required to support the JMS flow. Different JBI endpoints will listen off the "NMR" queue using optimized message selectors to ensure that messages get consumed by the correct target services. Third, you can now optimize the JBI messaging layer to omit the use of JBI DONE messages: so, if you're implementing a one-way interaction over the JMS flow, you don't end up having to deal with an DONE that you simply don't need. Finally, Guillaume has made a cleaner separation between the JMS flow and the underlying JMS transport. So, you can use ActiveMQ if you want, or, alternatively, plug in another JMS broker to handle your JBI traffic.

I'm looking forward to playing with this, and perhaps documenting these new features. One clear point is that if you've made use of JMS flows in your architecture for ServiceMix 3, then you'll have that same support in ServiceMix 4, with just a little tweaking of configuration.

Good work, Guillaume! And, thanks again for the sandwich!

Wednesday, March 25, 2009

HamsterJam, ApacheCon, and building businesses out of Apache Software License

Just thought I'd check in from ApacheCon EU 2009 in Amsterdam. This definitely one of the most engaging conferences I've had the good fortune to attend. Yesterday I gave a one day workshop on building web- and RESTful services using Apache CXF, showing also how to plug in the JMS transport into CXF so that you can do XML/JMS or SOAP/JMS from JAX-WS code. I was blessed with a really good audience, which made for a fun day. Had an interesting scrape though: throughout the day my MacBookPro kept on 'freezing' out of the blue! Not the kind of thing you want when you're doing live-coding: took me eight hours to figure that this was happening because I'd left my bluetooth mouse on in my bag, and it was periodically taking control of my machine whenever it could make a connection. Ouch!

Today I broke with my usual tradition of doing technical talks to join the business track, where I got to follow up after a great panel discussion with my own talk, Adopting Open Source in the Enterprise (follow the link to pick up PDF of the slides). I also really enjoyed Paul Fremantle's talk on building business out of Apache Software License, which agreed with my own observations on the need for ASL-based business to give real business value in terms of their support, services, training and consulting. In my own talk I had talked about Ricardo's Law of Competitive Advantage, and how organizations will support themselves in their adoption of open-source unless a vendor - like Progress with FUSE - can demonstrate that they can provide that support cheaper, better, faster than the organization can do themselves. For me, a vendor offering services around Apache-licensed community software acts as a 'mountain guide', helping users to get most value out of the commons code while minimizing risk.

Right now I'm in a talk by Andreas Gies (a colleague from Progress) who has such great experience in adoption open source for distributed team development. He's a Maven committer, and, in my eyes, an absolute legend. Go Andreas, Go!

Tuesday, March 10, 2009

On the question of 'ServiceMix vs Camel'

There was an interesting discussion on the ServiceMix users list on how to choose between implementing integration solutions using ServiceMix or camel; thought I'd post my contribution to that discussion here. ServiceMix should really be thought of as a container, that facilitates the deployment of JBI-based integration solutions and Camel-based solutions for enterprise integration. And, of course, ServiceMix 4 is an OSGi container, which extends the concept of what can be deployed - JBI service assemblies, spring configuration, OSGi bundles, etc.

The question really becomes "Should I use the ServiceMix JBI components (-eip, -file, -ftp, etc.) or should I just use camel components?" I think the decision around this will depend on whether the JBI architecture forms an important underpinning of your solution: if so, then it makes sense to use the JBI components. If, however, you have no desire to go down the pure JBI route, then you can choose to adopt either a pure Camel or a more blended approach.

As Chris Custine and Jean-Baptiste have both pointed out, Camel integrates very effectively with JBI, so you can get the best of both worlds. You might find that the JBI servicemix-ftp component is more robust than the camel-ftp component, and choose to use the former as part of a Camel route. Or, you might prefer the servicemix-eip Aggregator's persistence of state over that of the aggregator in Camel.

So: my advice is, in a nutshell, move forward embracing a blend of both JBI and camel components, and, consider 'ServiceMix' to be a container for both.