Web Things, by Mark Baker

Congratulations to Werner Vogels and his group on having their proposal for (amoungst other things) emulating the Internet accepted for funding! Werner writes;

The philosophy behind the testbed is to use a small high performance cluster (4 nodes) with 20 Fast Ethernet interfaces and an internal Gigabit ethernet interconnect to emulate the core of the Internet (or what ever topology you want to emulate). These FE interfaces are connected to a number of switches that provide the connection to all the end nodes. We make extensive use of VLANs to emulate the AD connections, and last mile connectivity. The goal is to run eventually with a 1000 physical nodes, the current first phase proposal was for 252 nodes. Each node has 3 ethernet connections, and we use software to emulate 3 end-nodes at each physical node. The experiments run the real software that you would eventually deploy, no simulated stuff.

Which sounds very cool from a technical POV. But if you want to emulate the whole Internet, try selling off those nodes to independantly owned and operated profit centers that are competitive with each other. Now that’s emulation (or is it simulation?). 8-)

So says George Colony, the CEO of Forrester.

The Web is dead and will be replaced by an executable architecture

Bunk.

Sam writes;

Mark Baker is upset because SOAP permits usages which are not, in his and many people’s opinion, well architected. Usages such as RPC. While many of Mark’s arguments resonate with me, he tends to throw the baby out with the bathwater. He might as well say that Python is not a good language for building REST systems because it can also be used for RPC.

I realize my position is far from typical, and appears inconsistent at times, but I thought I’d been pretty clear about it at least. Oh well. Ok, so let me get it all out, and describe what I believe – and what I don’t – about REST and SOAP;

I believe SOAP is a valuable and useful technology.

I believe the Web, and in particular the subset that follows the constraints of the REST architectural style, is a fundamental breakthrough in the evolution of large scale distributed systems, that will continue to effect how most systems, both human and machine-targetted, are built for the foreseeable future.

I believe SOAP can provide value outside the constraints of REST, but I also believe that its predominant value, by far, is when used within the constraints of REST.

I believe that using SOAP within the constraints of REST does not mean that HTTP (or Waka) has to be used.

I believe that using SOAP as a means for extending underlying application protocols, is the most valuable thing it can be used for.

I believe that using SOAP as a framework from which to build new application protocols has some value, so long as those new protocols are built on transport protocols and not tunneled over other application protocols.

I believe SOAP will fail to see significant use on the Internet because the predominant use of SOAP today is to tunnel new application protocols over existing application protocols, and to encourage an explosion in per-service application protocols, not a unification of application protocols as REST does via generalization.

P.S. I’ll believe it when I see it. 8-)

A funny addendum from Sam on the topic of concurrent updates with REST;

Obviously, Clemens hasn’t heard about the expires header. All you have to do is predict with 100% accuracy when the next POST or DELETE request is going to come in, and all caches will remain perfectly in synch.

It is just a SMOP.

Heh, exactly. Some might call this a bug, I call it a feature. There is no requirement in REST that all layers have a consistent view of the state of a resource, as to do so would be to reduce scalability. It’s basically just recognizing that perfect data consistency in the face of latency and trust boundaries, is impossible. The best one can do (addendum; well close to it) is to make explicit, at the time the representation is transferred, the expectations about the durability of the data. As I mentioned previously, architectural styles that transfer serialized objects (the whole object, not just the state) can address the issue of latency, by moving the encapsulating code along with the data. But this is done at the cost of visibility, which means that it likely won’t cross trust boundaries.