Behind the firewall, nobody can hear you scream.

In the recent blogstorm about SOAP/REST a theme is emerging. SOAP
proponents point out that SOAP is a great success behind firewalls -
enterprise applications and all that. Therefore SOAP is a great
success.

Hmmm. I do not doubt for one second that SOAP is being used
extensively behind firewalls but my personal experience has been
that:

1. Behind firewalls, SOAP is the bright shiny new RMI/CORBA/DCOM. It
is used as an Object Invocation/RPC mechanism. SOAP proponents keep
pointing out that you do not have to use SOAP that way. True, but 99
times out of 100, that is how I see it being used behind firewalls. If
it walks like a duck, etc.

2. Behind firewalls, network-related "ilities" can be swept under the
carpet given enough money and end-to-end control. Given given that you
have end-to-end ownership of the system, you can control network
latency and control network availability. Given enough money, you can
"upgrade" applications with super-duper fast processors and disks and
bandwidth to be able to survive in the temporally coupled, distributed
systems world that comes with Object Invocation/RPC-style SOAP.

3. Behind firewalls, you can get around interoperability problems by
the simple expedient of putting the same SOAP stack on all end-points.

4. Behind firewalls, IT folk quite rightly and quite understandably
keep their SOAP problems to themselves and they keep Cap Exp and TCO
to themselves. "Success" stories are the only type of stories the
private sector admits to. This is totally understandable but can skew
the perceptions of what is really going on.

So, how does all this relate to my opposition to SOAP and the
particular spin on SOA that is so prevalent at the moment?

1. SOAP is not being used the way its advocates now say it can and
should be used e.g. one-way, asynch, unreliable messaging with stuff
like reliablility etc. layered on top with WS-*. Is this a retrievable
situation? Will it be possible to move the perception of the "brand"
to one way, asynchronous, message-centric thinking which is necessary
for SOAP to be of any real benefit in this world? I don't
know. Personally I think there is too much history, too many "oh but
you don't have to do it that way" turnarounds, too much cruft, too
little help for non-specialists to guide them to a good design.

2-4. On the Internet, or on Intranets, you cannot control the
"ilities" and you cannot dictate technology stacks to the
end-points. Consequently, the Internet/Intranet is a great environment
for developing distributed systems technology that is both cost
effective and highly interoperable. Is it coincidental that CORBA was
a great success behind firewalls and DOA on the internet? I don't
think so.

We keep hearing the SOAP is a great success behind firewalls in
"enterprise class" applications. Maybe, just maybe, "Enterprise
class", in this context, means folk with money to throw at the
problem. Folk with end-to-end control who can design away the network,
the latency, unreliability, all that stuff through money, diktat and
imprimatur.

It is no great surprise to me that SOAP can be made to work - for a
given definition of "work" - in that sort of Enterprise Class
environment.

Behind the firewall, nobody can hear you scream and nobody can see
your wallet bleed.