Hi Michi - yes, it's been a while, but as always, ...

2005-06-25T10:07:00.000+01:00

Hi Michi - yes, it's been a while, but as always, it's good to talk to you.

So, I couldn't agree with you more: interoperability doesn't mean XML and it could have been done using binary (for example, there was a push for ASN.1 many years back that, if successful, could have made a big difference today).

When I said: But you pay a heavy price for this kind of interoperability The important word in that sentence is this, which really means: SOAP over HTTP and universally adopted by everyone. If we'd been successful in persuading everyone to adopt CORBA (and I think we came pretty close), then I still believe things today would be different. But we didn't and as an industry we have to suffer the consequences. With any luck, given quite a few years, the binary evolution of SOAP that I mentioned, might actually result in something more akin to CORBA or DCOM - and yes, it's frustrating that people keep forgetting history ;-)

BTW, I think that SOAP is over used in many situations because people see that they want to ship XML around and immediately consider it as the best way of doing it. Hey, if all you want to do is exchange XML as an application-level exchange, then do it at the application and use something like CORBA, RMI, or ICE and put the overhead where it belongs: at the application.

So hopefully we're not in disagreement. I definitely believe that binary interoperability is possible. But I don't think it's going to happen this year, next year or in the forseeable future. That's not because of technical drawbacks, but just because of how long it took to get to this point with SOAP (and probably how certain vendors were pushed into it in the first place). Because we are using SOAP, we as an industry have to pay a price. But maybe that price isn't such a bad thing given what it gets us?

Hi Mark, long time no talk ;-)Thanks for your thou...

2005-06-25T00:01:00.000+01:00

Hi Mark, long time no talk ;-)

Thanks for your thoughful comments. I agree with much that you say. But there is one point I keep tripping over:

But you pay a heavy price for this kind of interoperability.

People repeat this like a mantra over and over. There seems to be some assumption that, in order to be nteroperable, a protocol can't use binary. This is a completely incorrect statement, and there is plenty of precedent to prove that statement incorrect. Just think of the whole internet suite of protocols (many of which are binary) that interoperate just fine (not mention TCP/IP itself). Just because CORBA has interoperability problems does not mean that binary protocols have interoperability problems. CORBA's interoperability problems stem from poor protocol design, unnecessary complexity, and sheer incompetence. If you look at the Ice protocol, you'll find that it does everything CORBA does, yet in ways that are very simple (and, as a side-effect of the simplicity, are efficient as well). Having a third party interoperate with the Ice protocol is trivial (and has been implemented without difficulty in the past).

If people want to ship XML documents around and build document-centric applications, by all means, let them do that. But why did we have to standardize on a transport infrastructure that uses technology singularly ill-suited to the job? Let's face it: the choice of XML as an encoding has historical and political reasons. The XML craze of the late nineties and early twothousands was responsible for that, not any technical consideration. Basically, if it was XML, it sold, regardless of whether XML was suitable technology or not. So, we end up getting stuck with this idiotic transport, and then people come up with bandaids in an attempt to make this poor choice more palatable and, in the process, without even realizing it, make things even worse. We could have just as easily standardized on an efficient binary transport and saved ourselves all the grief. (But, of course, at the time, that would have been a much harder sale.)

So, we repeat history, and the world yet again gets stuck with a business solution and a standard that rest on a technical foundation of sand. And, as always, reality will eventually catch up with us, and we'll throw the entire SOAP/XML nonsense away in favor of something better. But, this industry being what it is, we won't do that until after we've spent billions of dollars. And then, we'll have a new generation of people who, like their predecessors, will ignore the lessons of the past and reinvent a wheel with lots of corners, and the cycle will repeat itself. ("I've never designed a distributed computing infrastructure before but, heck, how hard can it possibly be?")

Distributed objects are a good idea. CORBA was one attempt at building an infrastructure for that. CORBA failed to become a ubiquitous infrastructure because of technical deficiencies, vendor bickering (MS versus the rest of the world), vendor greed (IBM asking $100,000 at one point for a CORBA license), and unnecessary complexity. What is the industry's reaction? It goes and concludes that distributed objects are bad, invents a completely new thing that is inferior at both the conceptual and technology levels, and throws out the baby with the bath water. And then proudly writes papers about its achievements, such as 7ms latency...

We really could have the best of both worlds, XML and binary protocols, if we only bothered to stop and think about it, and were willing to learn from the lessons of the past. But I'm not holding my breath...

Cheers,

Michi.

Comments on Mark Little's WebLog: SOAP: slow or fast?

Hi Michi - yes, it's been a while, but as always, ...

Hi Mark, long time no talk ;-)Thanks for your thou...