
The S stands for Simple - 10ren
http://72.249.21.88/nonintersecting/2006/11/15/the-s-stands-for-simple/
======
uriel
The server seems to be back online, but in case it goes down again (or changes
IP or whatever), I have mirrored it here:

<http://harmful.cat-v.org/software/xml/soap/simple>

------
sketerpot
Did anybody else hear the SOAP Guy's lines in a voice that sounds like a cross
between a used car salesman and Foghorn Leghorn?

Also, I like Google's protocol buffers library. It's straightforward, fast,
has really nice bindings for C++, Java, and Python, and we know it's stable
because it's what Google uses for most of its internal RPC stuff.

<http://code.google.com/p/protobuf/>

~~~
sgk284
Yea, but the PB library doesn't actually handle sending requests over the
network, etc... It literally just encodes data. If you like protocol buffers,
check out Thrift. Thrift was designed based off of protocol buffers, but
handles everything from end to end. <http://incubator.apache.org/thrift/>

~~~
houseabsolute
To be more specific, the protocol buffer library provides an interface for
transport, but not the transport layer itself.

------
seldo
I have to say that SOAP didn't even seem like a good idea at the time.

~~~
blasdel
Dave Winer: Menace, or Monster?

------
psadauskas
Its been my experience that anything with Simple or Lightweight as one of the
letters in the acronym is usually anything but.

~~~
dflock
In the same way that the old communist states often had both 'democratic' and
'republic' in their over-long official names.

Hmm, LDAP. I'd hate to meet HDAP.

~~~
samuel
LDAP is "Lightweight" only when compared with X.500..

------
csytan
Using the Q & A style to introduce a topic works really well. I hope more
people start writing like this.

~~~
mnemonik
If you like this you should read The Little Schemer (if you haven't yet, that
is) it is written in dialogue/question-answer format. Very Socratic method. I
can't recommend the rest of the series; I haven't read them yet. The Little
Schemer is excellent though.

------
10ren
Interoperability is a vitally important but hard problem. CORBA and then SOAP
have been thoroughly adopted, then widely condemned.

What's next?

~~~
JulianMorrison
JSON in HTTP GET/POST. It's more of a nuisance, but it forces you to face the
network issues head-on, and code that reads JSON can't afford to make
assumptions, so it ends up less brittle.

~~~
InclinedPlane
Not just JSON and HTTP but specifically REST w/ JSON. There's a lot to be said
for such a model.

~~~
garnet7
What's the difference between "JSON in GET/POST" and "REST with JSON"?

~~~
JulianMorrison
In one, you are essentially doing RPC: here's the input, do the operation and
give me an output. In the other, you are remotely manipulating "documents".
Even a command to act consists of emplacing a "request" and being redirected
to a "response". You navigate between "documents" by following URLs in links.

To be honest, I like REST for CRUD of things that are natural resources, but I
think it's wasted extra work for operations that are natural RPCs.

~~~
garnet7
Ah thanks. Just plain JSON RPC sounds simplest to me.

------
papaf
I'm sure I've had this conversation in real life :-) My one experience with
SOAP was trying to get a perl client library working with a Java server --
they weren't compatible with each other. In the end I used ethereal with a
Java client and dumped the request which I could then replay through perl. In
fact, I would go as far to say SOAP is the least fun protocol that I've ever
used (including an undocumented one).

~~~
zaphar
My one SOAP exerience was similar but I ended up using LWP and creating my own
serializer then they upgraded from .net 1.1 to .net 2.0 and it all broke
again. I hated SOAP from then on.

------
three14
If you know that you're only going to be using the Microsoft stack, and you
actually do get to use the tools that cover all this up, do you still end up
regretting that there's SOAP under all of it?

I've just found myself working on a project like that for the first time, and
saw this, and started wondering.

~~~
steve_g
If both ends of the communication are on the Microsoft stack, setting up SOAP
webservices is straightforward. The tools basically take care of everything.
In our case, we have a customer who exposed an ASP.NET webservice that we
consume (data flows in both directions). Our production apps use VB.NET to hit
the webservice, but I was able to easily write a python client for testing (by
handrolling the SOAP messages).

My intuition is that SOAP starts becoming unpleasant if you have lots of
parties involved and/or multiple platforms. We haven't hit that wall.

~~~
flatline
Well, yeah, except you used to be able to throw up an endpoint as an asmx file
and it just sort of worked. Now you are guided to create a separate WCF
application. So you get a book on WCF and start reading. You create a "hello,
world" app but it takes three days of playing with the config file and reading
half of MSDN to get it to work. Now that you know all kinds of stuff about
message and service contracts, you can't do things like pull the raw HTTP
headers because it's not necessarily bound to HTTP (who's using those other
protocols, again?) And, you can't latch on to just any point in the request
handling because it may be any sort of request. Another week with MSDN and
you've finally gotten something kind of close to what you want, which involves
running with aspNetCompatibility and might as well just have been an asmx
endpoint, and which would have taken about half a day's work with the old
toolkit.

Not that I would know from personal experience.

------
robbed
I'm working on some SOAP stuff at work. I think it was a ploy to make me want
to quit.

------
StrawberryFrog
A few notes The "SOAP Guy" sounds rather like a straw man to me. I'd like to
hear what a real soap guy has to say. Though I don't know if there is such a
guy any more. Soap is just a transport format. Any WCF
([http://en.wikipedia.org/wiki/Windows_Communication_Foundatio...](http://en.wikipedia.org/wiki/Windows_Communication_Foundation))
guys around?

We use WFC between .Net programs, and once you connect to the right endpoint,
it pretty much just works. You may have a look at the generated WSDL to see if
it's sensible, but for the most part, it _is_ "just plumbing. You don’t need
to see it."

We're not stupid enough to try to get WCF and SOAP to interop with other
languages, though. We'd probably look at using ActiveMQ, or XML and URLs for
that kind of job.

Also the statement that "no one actually uses these other transports" is not
true - we use TCP transport in some cases, and it's not that unusual.

There are parts - large parts - of the spec (see the WS-* stuff, e.g.
[http://en.wikipedia.org/wiki/List_of_Web_service_specificati...](http://en.wikipedia.org/wiki/List_of_Web_service_specifications#Messaging_Specification))
which very few people use or care about, which would probably make full-
blooded interop with other stacks very hard. It's sad that we didn't get there
yet, but I'm glad that we've got what we do have.

In some cases REST is better. Even MS knows this. See
<http://msdn.microsoft.com/en-us/data/bb931106.aspx>

~~~
StrawberryFrog
And another thing: the article complains that 1) SOAP sucks and 2) It keeps
changing.

There's some merit to both those charges, but change is a legitimate response
to something not being right yet. What's the alternative?

Not sure why I'm getting downvotes. Its possible that I'm wrong, but it's a
more substantial answer than most comments on this topic. I'd like to hear
your point of view. Or are only "LOL I agree soap sucks" comments encouraged?

------
mgrouchy
I can identify with this totally. This was my life like 4 months ago before I
started at the startup I am working at now.

Trying to write these schemas by hand IS hell, but putting blind trust in your
toolbox is possibly even worse.

