I see lots of SOA books surrounding Java and have always had the subliminal notion that Java is the “right” language for robust/enterprisey SOA, even though I know what SOA involves and that it is perfectly possible using other languages & frameworks.
What exclusive traits Java has that other languages/platforms don’t, that makes it so popular for SOAs?
4
What exclusive traits Java has that other languages/platforms don’t, that makes it so popular for SOAs?
There’s nothing much in Java itself that makes it especially suitable for SOAs. Sure, it offers garbage collection and dynamic code loading and the like, and they’re all useful, but they’re hardly unique features of Java.
What did make a difference though was the Enterprise Bean specification (which evolved into EJB and JEE). That was basically an adaptation of concepts that had been around for quite a long while in the big-iron space (transaction monitors, that sort of thing) to an OO model, together with the addition of statefulness so that certain types of models were a lot easier to express. The interesting thing is that EJB was a multi-vendor effort; yes, Sun promoted it a lot, but there were many commercial vendors that did implementations of it in their products quite early in the spec’s lifecycle. That encouraged a lot of adoption; expertise in Java-based transaction monitors had suddenly become a nice transferrable skill.
Once that base had been established, it grew (e.g., with excellent SOAP tooling support, which superseded the use of CORBA in a lot of deployments) and that’s really cemented Java in place. The thing that keeps Java as the king of the SOA space for now is the huge ecosystem of third-party libraries that make it easy to work in the area provided you use Java (or one of the other JVM-based languages, like Groovy or Scala). It’s entirely possible to have such libraries in other languages, other environments — I’d expect C# and .NET to do fairly well on this metric — but you typically have to write a much larger fraction of the support layer yourself, and some of that is both tricky and boring to do well; leveraging Java makes a lot of sense if it is keeping you able to focus on the application’s business logic and not the support framework.
In short, Java’s good for SOA for you because it’s good for SOA for many other people (and yes, that’s self-reinforcing and sounds tautologous); it’s the network effects.
1
Java was (and still is) simply the most popular language for the kind of application where the SOA concept is most attractive, i.e. heterogenous distributed and integrated systems with constantly shifting requirements aka “enterprise applications”. So everyone was already using Java for such systems before SOA became a buzzword in exactly the same area.
As for the reason Java got so popular in that area, there’s a lot of things that probably contributed: platform-independance, excellent cross-version compatibility, Sun’s marketing budget and previous presence in the market (via Solaris and hardware), the focus on standardized APIs, being the first garbage collected and VM-based language to offer acceptable performance…
6
Simply because many of the first systems that were being connected using SOA techniques were in already built in Java. There’s nothing inherit in Java that makes it a superior language for SOA solutions.
Some might argue that it’s rich ecosystem of BDD/TDD frameworks and community around that helped build more robust SOA solutions, but then again I’ve seen plenty of terrible ones :-).
In short SOA is an architectural design pattern that is language agnostic.
3
It’s just everyone else is doing SOA without explicitly naming it so, without strict formalizing etc. People build RESTful services and back-end using message queues without mentioning “SOA” even once. The keywords are rather “loose coupling” or “web services”.
On the other hand it seems, that in Java world there’s a need for buzzword (or rather buzz-acronym) for everything, every design pattern, every architecture etc. Thus so many books where Java and SOA are mentioned together.
Java IDEs and annotations make it easy to create web services. So anyone who wants to learn about SOA and web services tends to run into a lot of Java-based tutorials (likely where your “subliminal notion” came from), and anyone who wants to get their feet wet with some simple service implementation gets quick gratification from experimenting with Java. I don’t think that Java is “better” than other languages at SOA, but it’s arguably easier to get started using SOA with Java.