

Ask YC: How big of a failure is SOAP? - chriszf

I'm trying to do something involving a web service that's only offered via SOAP (naturally, it's a microsoft technology: Mappoint). I remember hearing a lot of hype about interoperability and web services and remote whatever and integration way back when. But now, as I'm working on this thing, I find that Java support for SOAP is questionable at best, and poorly documented to boot.  Python's support has a passable interface, hiding all the setup with its powerful metaprogramming facilities. Now, if only it worked correctly. I couldn't even bring myself to look at Ruby support. Naturally, C# and VB.net support SOAP almost natively. So how about it folks? Is this another technology resigned to the rogues gallery?
======
jlujan
SOAP was engineered by enterprise companies for enterprise applications. It
came form the same thought train as COM/DCOM, CORBA, etc.,. It is still a
major player in the enterprise world. You wont see many B2B apps that don't
use SOAP or some other XML payload. I have used SOAP extensively in PHP and
C#, together even. The support is there for it if you look. Java actually has
good support for SOAP, if not the best (<http://java.sun.com/webservices/>
<http://ws.apache.org/axis/>).

Most of the haters on SOAP and other thick WS technologies are people trying
to do simple AJAX type message transfers. SOAP is a little heavy for that. But
when you try passing messages between multiple systems in multiple languages,
it becomes the obvious solution. As far as the following response goes...
"allow me to put it this way: 1k of text to get a 2 or 3 digit temperature
from a weather service." SOAP stacks will automatically parse that 2-3 digit
number into the correct data type for the platform/language you are using. Now
say instead of a 2-3 digit number you passed an entire object or data
structure. Would it be easier to role your own parser or have the SOAP stack
automatically marshal it for you?

Added to this, when you use the full set of SOAP technologies including WSDL
and XSD, you also have data validation and to some extent, documentation. This
is what JSON and the likes lack. If you provide a WSDL I can look at it and
usually use a tool to automatically generate all the data types and interfaces
needed (ie. wsdl in .Net). You point me at a JSON interface and I have no such
luxury. I wont know what data to expect until you write documentation for it.
Further neither of us would know if each others messages were valid without
some kind of custom validator.

Also SOAP is transport layer agnostic. If you use HTTP you can take advantage
of any compression the underlying platform supports. Apache's Axis and Perl's
SOAP::Lite both support HTTP compression in their SOAP stacks. I am aware of
ways to enable it in .Net as well.

Advances in computing power and network resources are making SOAP a more
viable option, not less. It comes down to using the right tool for the job and
REST is viable in some applications, but SOAP is as well. SOAP's life span
will be at least as long as COM or CORBA. They haven't completely died yet
either...

~~~
simonw
"SOAP stacks will automatically parse that 2-3 digit number into the correct
data type for the platform/language you are using."

JSON stacks not only do that, but they do it better because the set of
available data structures in JSON is constrained to a sensible subset - you
don't end up having to replicate complex classes in multiple different
languages just to get a chunk of data from one place to another.

Has anyone in the history of computing ever really taken advantage of the
"transport layer agnostic" aspect of SOAP?

~~~
johnyzee
"Has anyone in the history of computing ever really taken advantage of the
"transport layer agnostic" aspect of SOAP?"

At my current enterprise gig, SOAP messages are passed via MQ. This provides
for additional facilities (transactions, message persistance) that SOAP in
itself does not offer.

~~~
smhinsey
we do a lot of stuff with soap over queues (msmq in our case, but same
difference) as well. as i've been interviewing people, i've observed that
stuff like this is really rare, so not many people have actually stopped to
think about what you could do with something like WS-Addressing and a queue
based bus.

however, i totally agree with most of the rational critiques of the WS-* stack
- it's gotten way too complicated and in my view simplicity has been
sacrificed at the altar of XML Schema.

------
mattdennewitz
allow me to put it this way: 1k of text to get a 2 or 3 digit temperature from
a weather service.

~~~
breck
As a matter of fact I'm running into this _exact_ problem right now. RSS,
SOAP, XML, why can't I just:

wget
[http://weather.com/api?field=temperature&zip=02142](http://weather.com/api?field=temperature&zip=02142)

and get back a file consisting of "52" or something similarly simple.

Currently I have to get a 1k+ file and create a parser for it. I can't even
find a really simple format that would allow me to use prebuilt XML parsers.
If anyone knows of a dead simple API for temperature, precipitation, etc., I
will upmod you at least once.

~~~
breck
Okay I'm pretty lazy:

<http://developer.yahoo.com/weather/>

------
paulgb
I've been working with XML-RPC (predecessor to SOAP) over the past few days
and it's much less painful than SOAP. It only takes a couple lines of (python)
code to get a client running functions on a remote server, without having to
know what is going on below.

------
allertonm
Java does have a pretty good SOAP stack, namely Axis.

The claim of early SOAP advocates was that it would enable more loosely
coupled, 'be liberal what you accept and conservative about what you generate'
type services, especially when compared to older technologies like CORBA.

Unfortunately, the approach taken to this was to add more and more metadata,
and the outcome has been, well, lousy interop because implementations disagree
over the metadata. The standards and the stacks have been designed and tested
based on hypothetical use cases rather than having arisen out of real world
uses and I think we all know how well that approach works out.

It actually turns out that there are some things that SOAP is good for - for
example, you want to create a service that can only be called with digitally
signed, timestamped requests from known clients you trust, well, you can do
that with SOAP pretty easily compared to rolling your own. But unless you are
doing B2B, it's unlikely you have any need to do that - and even if you did
you will probably find yourself mandating a particular stack for both client
and server to make it work. So much for loose coupling - SOAP ironically turns
out to be great for _tightly coupled_ SOA.

------
neilk
Paul Prescod has written some very thoughtful articles on REST versus SOAP.
See:

    
    
      http://www.prescod.net/rest/ 
    

in particular:

    
    
      http://www.prescod.net/rest/rest_vs_soap_overview/
    

SOAP is indeed on the way out but not quite for the reasons most people say.
It's not just due to the overhead, or even the incompatibilities. These are
symptoms of the fact that it's solving the wrong problem. SOAP is a way to
tear your program apart and put half of it on one machine and half of it on
another. REST is a design strategy that requires the absolute minimum of
coordination, thus it scales somewhat better, like the web itself.

That said, magical RPC-injection protocols like SOAP often work really well
for quick and dirty apps within a single organization.

------
j2d2
I've used SOAP at work with great success. We map sql select queries from the
input XML and use the web service simply as a language independent (text-
based), read-only database (we only allow select). The XML let's us control
all queries run on the database and provides more than enough flexibility for
generating a flexible where clause for filtering.

The platform independence is huge for obvious reasons. The XML based querying
is huge because now the data model is totally hidden from our users. We just
work from what they're asking for.

------
andrewf
Interoperability is a mess. From the server side, no matter how long you chip
away at it, there always seems to be another client library, or another
version of a client library, that will bork.

However, provided your server can talk to it at all, Microsoft's toolchain
works really, really well for anybody writing a client. If you are providing a
web service and want .NET developers to be interested, you owe it to yourself
and them to provide a SOAP interface.

------
simonw
Huge, epic fail. I work with some extremely smart developers. When ever a task
involving SOAP comes up, faces drop around the room. RESTful APIs (be they XML
or JSON, the latter often preferable) are far, far easier to consume.

I don't have a link, but I remember hearing Jeff Barr from Amazon Web Services
claim that the services they provided in both REST and SOAP saw an order of
magnitude traffic to the REST interface.

------
kogir
I can't speak to java's support for consuming web services, but I've written
plenty of code that consumes java web services from .net. So far most of the
problems I've encountered were the result of the partner (using java)
publishing an invalid or incorrect wsdl. A little hand editing is all it takes
to generate functioning proxy classes.

------
eisokant
My personal preference is REST and I hope SOAP will slowly disappear because
I've never felt comfortable using it.

~~~
nradov
REST is fine for trivial applications. Now try using it send a large HL7 V3
message. :-(

~~~
st3fan
What is 'HL7 V3' ?

~~~
DougBTX
I assume: <http://en.wikipedia.org/wiki/HL7>

------
nradov
Java for soap is quite extensive and generally works extremely well. We have
used it in many places with good results. The only major problem is, as you
discovered, trying to deal with discrepancies when calling complex services
designed specifically for .NET.

~~~
chriszf
I don't suppose you have specific recommendations as far as this goes? I'm
lost in a sea of libraries and options. As I mentioned, I'm trying to work
against the MapPoint webservice, but I've had no luck in creating even the
most basic client with axis2 against their wsdl.

~~~
jlujan
Have you looked at wsdl2java? [http://ws.apache.org/axis/java/user-
guide.html#WSDL2JavaBuil...](http://ws.apache.org/axis/java/user-
guide.html#WSDL2JavaBuildingStubsSkeletonsAndDataTypesFromWSDL)

------
st3fan
We are using a simple alternative that we call 'Query Style calls with JSON
Responses' ... <http://code.google.com/p/polarrose-wsf/>

------
ken
[http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...](http://wanderingbarque.com/nonintersecting/2006/11/15/the-
s-stands-for-simple/)

