My colleague Warren posted a thoughtful and comprehensive response to Craig McMurty’s piece on Jini and Indigo. I just wanted to point out another angle on one of Craig’s assertions.
Craig says, “In the years since Jini, though, we have learned a lot about how NOT to design those programming models, and those lessons suffuse Indigo”. Now from the Microsoft perspective, I’m sure that this is true. Over many years they had pushed a distributed programming model (under various names) that was inextricably tied to the Windows OS. (Yeah, I know about Mono – wake me up when it’s real.) I’m quite sure that their customers told them that this was a bad idea; I know that some of them have said to me, face to face, “We have to work with you, because Microsoft doesn’t understand decoupling and layering.” But because of their obsession that Windows was The One and Only True Platform, Microsoft decided – incorrectly – that the only solution was to move to a (relatively) platform-neutral approach. As a result we got the wholesale shift to WSDL and XML web services. But because Microsoft still believed in the old COM model, and didn’t want to give up any of the functionality, they were forced to layer tons of new protocols, starting with SOAP and ending with the WS-splat Tower of Babel. (And while some of these are open, not all of the schemas will be.)
What’s wrong with this picture? First, most customers weren’t asking for a new pile of stuff to learn! They simply wanted a distributed computing model that was decoupled from the OS and hardware platform, to give them some choice up and down the stack. And the technology to do that already exists: it’s called Java.
Short digression: I spent some of the last year talking to large IT organizations (not all Sun customers) about their distributed computing plans. One of the questions that I regularly raised was, “How are you planning to integrate your existing applications into your future architecture?” And the answer that I heard over and over again was, “We’re going to wrap them in Java.” Never “Wrap them with .NET”. (OK, one company was planning to implement a SOAP interface in Cobol, but…)
At the end of the day the idea of platform neutrality looks pretty lame anyway. The whole WS-splat mess has grown so complex that customers are going to be forced to treat it as another platform in its own right. And given the competitive sniping and politicking that seems to characterize these “standards”, it’s unclear if the result will be any less proprietary than before. The upshot is likely to be either (1) customers will focus on a small subset of the whole steaming pile (perhaps RESTful), or (2) they’ll shrug, push the button in Visual Studio, and treat it all as COM++, just another proprietary stack.
The Jini proposition is very simple. If you are developing in Java – and many people are – it makes sense to use Java as your distributed service model as well as your application platform. You avoid the problem of lossy mappings between different representations, you get end-to-end type safety, you don’t need to learn new languages, or exception models, or security frameworks. And as a bonus, you can use the best protocol for the job: you don’t have to reduce everything to the lowest denominator of XML.
We wouldn’t claim (most of us 🙂 that Jini was right for every case. Always mistrust sweeping generalisations! On the other hand, Craig seems to be doing exactly that: asserting that Indigo reflects the one true way. That’s utter nonsense. In fact it smacks of an Aesop’s Fable. Microsoft was assailed for coupling their programming model to a monopoly OS on a monopoly chip. Since they were incapable of distingishing between platform and OS, they were forced to go “platform neutral”, and wound up creating another platform (and a depressingly baroque one at that).
Java and Jini suggest a different approach: make the programming platform independent of the host OS and hardware. It meets many of the customers’ needs (as we’ve seen), and seems to represent a more elegant way of doing things. (And for those who argue that elegance is an inappropriate property, I recommend Samuel Florman’s wonderful book The Existential Pleasures of Engineering.)
[Hmmm. On re-reading this, let me draw your attention to the disclaimer at the top of the sidebar, for what it’s worth.]