IJTC conference - Spring, Grails, Camel, Netbeans and STP

I attended the Irish Java Technology Conference last week in Dublin. It took place in the Cineworld complex in Parnell St. which was very convenient and comfortable. The venue did throw up some unexpected surprises such as the "Saw 4" double-bill with "Spring 2.5" and the Netbeans session which was billed as "Atonement" (alas Kiera Knightely was not in attendance). As always when attending Java conferences the first stand that I saw walking in the door was Microsofts! Go figure...

But I digress.

Spring 2.5

The Spring 2.5 session was delivered by David Syers of Interface 21. It is clear that this release is a SEAM defense mechanism - In 2.5 Interface21 has made a lot of it's configuration available as Java annotations - I guess this is to counter the argument that nobody wants to program in XML. David was at pains to show us how little XML you need to write to support Spring 2.5. For me I am not clear why 2 configuration mechanisms are required or beneficial. It seems to me that having 2 mechanisms just makes it more difficult to sync up and fails to properly support the separation of concerns between the developer and the configuration management people.

The second thing that struck me as intriguing was the hints that were given about OSGI and Glassfish. It looks to me that Interface21 are looking to provide a stack of their own so that Jboss, BEA and co. dont continue to eat their support lunch....

GRAILS

In order to broaden my horizons I attended the GRAILS session delivered by Guillame Laforge. I know I should have attended the JPA and DALI session but it did not sound like it was going to be too much fun so GRAILS it was....There are 3 schools of thought on the subject of GRAILS/Groovy versus Ruby/RAILS - one school passionately supports GRAILS because of it's Java-like syntax; others prefer RUBY and the majority dont really care - I am one of the majority. GRAILS looks quite nice but Guy failed to convince me that it was anything more than an interesting technology project - I was waiting to hear that site X was using GRAILs and was getting 1 million hits a day or that customer Y had converted 200 developers to use GRAILS but it never came. I wonder whether, in such a noisy market space without a major backer, we will ever hear such things?

Netbeans

The Netbeans & Glassfish session after lunch was heavy on NetBeans and light on Glassfish which was a shame. The latest iteration of Netbeans looks like a competent piece of work but I am an Eclipse bigot so I found it difficult to get worked up about their improved syntax highlighting capabilities and mobility development capabilities. It is like these guys come from a curious, parallel world where train tracks are narrow-guage.

Camel

One of the most interesting sessions from my perspective was the talk by James Strachan on Apache Camel. James is quite an entertaining speaker and delivered an interesting pitch for Camel. Cape Clear provides many of the capabilities which Camel offers so it was good from my perspective to see how they had approached the issue of integration patterns.

Camel itself is not an ESB per-se, it is a component of an ESB which provides a subset of the capabilities of Cape Clear's assemblies. Camel is aligned closely with the Enterprise Integration Patterns written by Hohpe and Woolf http://www.enterpriseintegrationpatterns.com. The book is a nice catalog of high-level integration patterns.

My take aways from this session are that:

1. One of the key messages that came out of the session was how Java-centric the Camel solution is - Strachan went so far as to articulate the view that coding in XML was a fundamentally bad idea. He went on to cast aspersions on graphical tools also. His clear preference was that integration logic should be written in Java. Given that I have worked with highly skilled Java developers for many years now I was not too surprised to hear this - many good developers shy away from tooling, seeing it as compromising their style or the power of the underlying framework - hence the longevity of vi and emacs I suppose. However it is important to note that all developers are not middleware experts and have no wish to be. Indeed the enterprises they work for want their developers to spend as little time and effort as possible on middleware plumbing. They need and demand tools which will enable them to get at least 80% of patterns done without having to understand the middleware architecture, it's threading model, it's support for configurable expression languages etc. Most people express their requirements in a declarative way- I have data at A that needs to get to B, on it's way I need to perform transformation, validation, logging etc. (indeed the EIP book itself does this) . However Camel has taken a very Java centric approach and I think this increases it's complexity unnecessarily.
2. Camel presents transports as nice-simple looking endpoint URIs in Java. However configuration of these transports may not be as simple as it seems. There appears to me to be a potential disconnection between the Camel processors and the Camel Components in terms of configuration. In the presentation processors use endpoints which can be configured using Spring within Camel. However it would appear that many of the component implementations are inherited from ServiceMix and these properties will need to be set presumably within the ServiceMix container configuration? When you have multiple XML configurations to use a transport then the pretty looking URI is hiding a lot of complexity under the hood.
3. Some of the pattern implementations look a little short on credibility - take the aggregator pattern for example the "aggregator" pattern does not seem to have the concept of a store - so in essence one must have access to all of the messages which require aggregation or must hold aggregations in memory for the configurable timeout period. This will clearly not work in a scalable way. Likewise as regards clustering - if you are looking to aggregate 2 messages and they turn up on different servers you gotta problem.

To summarise Camel is clearly a worthy set of widgets and they will work for very simple applications without Enterprise requirements. I would say that this is a project to watch - the ideas behind the implementation are sound but it still needs a good deal of work to be useful for Enterprise apps.

Eclipse STP

The last session I attended was the session on the Eclipse STP - This project has been around for well over a year now and it still does not appear to have a central focus. It's projects include a BPMN editor, BPEL2Java converter, STP Core and SOA Systems projects. This appears to me to be a collection of bits and pieces which dont hang together to do things that are either new or useful. It appears that they are removing the SCA core contribution from IBM and replacing it with (what they call) the Intermediate Model which I understand to be an intersection of the JBI and SCA models. The future plans look more interesting - they have several new contributions - a Policy editor, an Enterprise Integration Designer and and SCA composite designer which are all currently being integrated. These look good but I cannot help thinking that this project would be better off trying to do one thing well rather than adding yet more breadth to their offering.

Just finally to congratulate the IJTC on their organisation of the event - it was very useful, worthwhile and well run.