SOS

A couple of you have contacted me for the code for this post, you should now be able to download it here.

Apologies I didnt make it available sooner.

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.

Just back from some great days in Stockholm, at a SOA conference there. Great event, great people - at the end of the event the organisers asked me to prepare an executive summary, which I'm attaching inline below. In a nutshell: SOA is maturing nicely, but EDA and REST have a big part to play in SOA solutions.

The "SOA for the Services Industry" conference took place this year in Stockholm, bringing together battle-hardened SOA practitioners, industry visionaries and solution providers, under the banner theme "Beyond the Introduction: Managing SOA for a Decade". The event lived up to its promise of bringing to bear the idealism and purity of the SOA architectural vision with on-the-ground experience and real-life use-cases. IONA Technologies was delighted to sponsor and chair this event.

A recurring theme that emerged throughout the presentations, panel discussion and conversations throughout the event was that "SOA is just part of the solution". Many of the case studies, drawn from the airline, financial services and telecom industries, showed that while a SOA-based architecture formed the backbone of their thinking, Event Driven Architecture (EDA) also formed a key role. One delegate captured this succinctly, saying "our business is event-driven ". Gartner's proposal for a "SOA 2.0", which emerged mid-last year amidst much debate and mixed acceptance, declares EDA to be a key differentiator from its predecessor; however, some delegates felt that EDA is already a de facto part of existing SOA solutions. Case studies showed also that the principals behind REST architecture, as defined in Roy Fielding's thesis, are also immensely important in designing distributed scalable systems.

Delegates found some agreement on the idea that SOA does not always have to be an enterprise endeavor - the principals and technologies behind SOA can be applied at an application or project level to good benefit. In fact, one delegate was keen to point out that the feudal nature of his organization meant that any attempt to impose an enterprise-wide methodology was simply doomed to fail for political reasons alone. By applying SOA principals in the small there was a greater change of building a groundswell and ultimate acceptance. Applying all elements of SOA architecture, from services creation and deployment right through to orchestration and choreography, just "for the sake of it", is clearly misguided; one delegate went as far as to say "It's almost better to have no SOA at all, than a badly done SOA".

The use of SOA as a business facilitator, supporting and easing mergers, acquisitions and outsourcing programmes was demonstrated in a number of presentations in the telecoms and airline sectors. The importance of governance and organizational training in achieving SOA success was also stressed. All were agreed that SOA is perhaps now far more a people problem than a technical problem: aligning an organization to understand and capitalize on SOA, or rather, aligning a SOA to facilitate and support an organization’s DNA, may be the greatest challenge.

And, in the long term, remember that a SOA is "not just for Christmas": SOA practitioners must consider the cost of ongoing deployment, evolution and maintenance of SOA systems. Planning for success requires strategic thinking around version control, ownership and scaling is crucial for success in the long term.

The event was organized by Inoventa; for more information on the event, and to download conference materials, go to http://www.inoventa.com/