I love working for IONA. Last week they sent me to the lovely city of Barcelona, to share a speaking slot at The ServerSide Java Symposium Europe. Met some great people there, and got to see some of the town too. Gotta love that Gothic Quarter... Anyway, for those that didn't make it and would like to know what's going on in the Java/Open Source/Developer landscape, read on...
The session I was speaking at was with Ted Neward, on "Pragmatic XML web services with CXF and .Net". Very pleased with the attendance, about 90-100 delegates. We covered code-first service design, .Net interoperability, RESTful services, scripting languages (DSLs) and JSON, Lots of interest afterwards, including around my WSDL Versioning Best Practice. All good - thanks Ted!
The SOA Industry Leaders panel session, with Oisin Hurley (IONA), Gregor Hohpe (Google) and Martin Fowler (ThoughtWorks), and chaired by Ted, was packed out. If I can sum up the prevailing theme in four words, then it's "Complexity Bad. Pragmatism Good". Stacks, technologies or even architectures that try to do everything are out; in their place pragmatic approaches, based on proven, readily available tools, are preferred. For example:
* There seems to be low interest in JEE and EJB3 - many are choosing to use Spring instead as a Java container. Developers, architects and their managers are voting with their downloads and using tools like Tomcat, Spring, Hibernate and a host of other staple open source frameworks to get the job done.
* There is serious disillusionment around WS-*. Martin Fowler refers to the extended suite of Web Services specifications antagonistically as "WS Death Star", raising questions about the validity and veracity of specs that are barely-implemented and infrequently used. For example: is WS-Transactions really necessary? Distributed transactions are hard enough as it is, why should doing it with web services make it any better? What about WS-Reliable Messaging? There are lots of applications out there where sending SOAP or XML over JMS is more than enough already: no WS-RM required! I'm a pragmatist at heart, and much of this kind of thought really does resonate with me, Still, I'm not keen to throw the baby out with the bath water: there's some good stuff in WS-*. I found myself musing at the conference about what a a tragedy it would be if we as an industry decide to bin WS-* and start all over again, only to run into the same problems (again) a few years down the line. Hmmm. Let me be clearer: if you're going to mock WS-*, then earn the right to do so first by suggesting a viable alternative.
* There are clear signs SOA fatigue in the community; to the point where people really don't care about the term any more. When the panel was asked "what is a service anyway?", they laughed nervously and tried to evade the question with nebulous answers. Ted probed further "Is a database a service?" (I actually do know the answer to that one …): when faced with the panel's answer "it depends", you're left thinking that if a service is all things to all people, then it's really not that meaningful a concept at all. But enough of this pedantry: the important thing is the unanimous agreement that it's more important to Use the Right Architectural Approach: be it REST, EDA, SEDA, SOA or whatever, than to apply the same architectural solution all the time. This plays perfectly to the strengths of ServiceMix, CXF, ActiveMQ and Camel: by supporting Enterprise Integration Patterns in general, these tools can be used to implement all these architectures.
* Even Java is getting something of a grilling when it comes to complexity. As a general purpose language, you can do whatever you like with Java; however, you sometimes end up having to write lots of code to provide additional support for design patterns used in your solution. Some modern scripting languages, for example Ruby, provide language features that innately support common patterns, resulting in less code. As a case in point, consider RabbitMQ, a fully fledged AMQP broker, written in less than 8000 lines of Erlang. I can't see Java disappearing any time soon, but I can see growth in alternative languages. It’s worth noting here that Camel itself provides a "Java DSL (Domain Specific Language"; by providing a language that innately supports numerous enterprise integration patterns, you can implement these patterns with much less code.
Google played a large role at the conference; I really enjoyed their presentation on GWT (Google Web Toolkit). Here's the GWT pitch: AJAX programmers today end up writing pretty complex code, typically relying on lots of cutting and pasting of existing examples in order to design their page. GWT allows you to design your browser-based GUI in Java using the GWT API; GWT tools then automatically converts your Java to appropriate JavaScript for your pages. You end up with a rich, compact, fast-download, JavaScript UI. This is very neat and I've enjoyed playing with it. One big implication of GWT is that if its successful then there's going to be a lot more JavaScript clients there. I've made the mistake in the past to assume that in a WS world, everything's a Java/C++ or .Net client: however, with lots of GWT client applications now in the offing, there will be a greater demand for RESTful services that return either JSON or raw XML. I'm glad that CXF is ahead of the curve here in its support for implementing these services.
And finally: the really, really interesting stuff at TSSJS has got to be the stuff people are doing with JavaSpaces. I've only flirted with it myself, but I'm fascinated at the ability to easily construct scalable, dynamic Grid applications using spaces. I'd like to put together a nice demo with John Davies (if I get the time) showing how to build a nice compute service. At the front end there'll be a nice, well behaved REST/WS interface. At the back? Well you won't have to worry about that: spaces will make it fly along.