This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Web Services for Low-End Communication

Stefan Tilkov,

I was about to write something really nasty about the Devices Profile for Web Services — after all, isn’t it obvious that it cannot possibly be a good idea to use the world’s fattest protocol for communication with or between devices?

Then I thought a bit more about the time when I started programming for real — using C++ at that time, when the veterans in the company told me that C++ is always going to be too slow for anything serious. A few years later, it was great that Java had JNI to bridge to C for the critical stuff. Remember when people said Java just might be usable on the client, but for your server, you will still need the ultra-fast C++? I remember discussions about CORBA/IIOP being totally inefficient for high performance communications, OO-style get/set methods inappropriate for real work …

Don’t get me wrong: Performance matters, and it matters a lot. But a performance advantage alone is not going to save a technology or programming paradigm from becoming obsolete — if it were, we’d all be programming our communication interfaces using assembly language.

My prediction is that in a few years, all communication — whether it’s local (in process or interprocess), in a Personal/Local Area Network, inside company boundaries or crossing oceans — is going to be SOAP/XML over something like HTTP by default, with a lot of optimized alternatives the parties are going to agree on during communication setup.

On May 13, 2004 9:13 AM, Hartmut Wilms said:

Hi Stefan!

“My prediction is that in a few years, all communication — whether it’s local (in process or interprocess), in a Personal/Local Area Network, inside company boundaries or crossing oceans — is going to be SOAP/XML over something like HTTP by default, with a lot of optimized alternatives the parties are going to agree on during communication setup.”

Sounds good to me, but I think that we’ve got a long road to travel until then and have to cope with some petty obstacles (no good tool support) and frantic arm waving heretics (“And what about performance?”).

I was pondering about the whole “performance” thing, while coding some boring but required stuff. I started with “well, at least the idea of logic implemented in the middle tier is a realistic idea today” up to “why bother trying to accomplish scalability on the server level, when the best scalability is reached with the thousand well equipped client machines accessing my server (using the middle tier merely for scaling data access)…?”. To make things worse I was wondering if the loosely coupled approach is much more difficult to grasp than the tightly coupled object-oriented appoach, at least today. After all we’re experienced OOA/OOD experts and an OOA/D model is easier to understand than a pile of XML documents exchanged by services … Maybe I’ve just get used to the “new” notation.

As you might have noticed already, I need some insightful advice in order to get on the right track, again ;-).