Ask YC: How big of a failure is SOAP? | Hacker News Reader

Ask YC: How big of a failure is SOAP?

4 pointschriszf30 comments

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?

View on HN

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...

"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?

"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.

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.

"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"

To my knowledge, there is no "built-in" way to specify if a number should be parsed as an int or a float in JSON. The idea that one of JSON's strengths is it "is constrained to a sensible subset" is a naive view. Yes it is a strength if you are only using dynamic languages, which is valid given the nature of most of the projects talked about on YC. However, enterprise projects are usually loaded with formal specifications, UML diagrams, and usually use languages with static typing. A mixture perfect for SOAP.

"you don't end up having to replicate complex classes in multiple different languages"

SOAP and almost every SOAP stack have been designed to prevent this. Almost every SOAP stack has a tool with naming similar to wsdl2java, wsdl2perl, etc.,. Again, narrowly looking at SOAP without understanding the associated technologies, mostly WSDL and XSD, the technology as a whole cannot be effectively evaluated. I don't expect any of the Web 2.0 AJAX guys to understand the benefits of an implementation with such a formalized specification or broad scope. However, SOAP was created to fit the needs of large enterprises trying to interop with other large enterprises. It covers a huge scope and various edge cases. JSON covers a very narrow scope. The original post talked of SOAP as a dead technology. It isn't. Is it the best for AJAX style web services? Maybe not. Don't simply disregard it as a viable solution in all cases though.

Yes, people use the transport layer agnostic aspect of SOAP. The first SOAP service I implemented used SMTP. It worked very well for sending messages to offline clients. SMTP provided queuing and storage of messages until a client came online and requested it.

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

Indeed, my experience of SOAP seems to be data transfer overheads often totalling several hundred percent of the data transferred. This always seems to me to be wrong on principle.

I don't think I've ever seen an instance of SOAP used appropriately, and I'm finding it hard to think of even a theoretical example where it would be a good idea. Maybe I'm not the target audience, but it seems to me the code, object size and data transmission overheads are almost never made up by any advantage SOAP offers. I think I'd consider ASN.1's XML encoding before I ever considered sending a SOAP message somewhere. At least then you could translate it to DER for efficiency.

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

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.

Okay I'm pretty lazy:

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

Here's some ruby snippets that I used to build http://forecaster.ws

http://pastie.org/198820

Yes, SOAP is not always the right solution. It adds extra overhead, which is the price you pay for having the tools validate and map the message to objects automatically for you. It's your call weather that's worth it or not.

In many applications (mostly enterprise), the extra overhead is well worth it because of the time it saves the developers. With .NET for example, you simply add the tag "[webmethod]" before the declaration of your method, and it becomes available over the Web. And if you're building the client, you simply point your tool to the URL of the service, and it immediately pulls the declaration of all methods along with their documentation if available, and also provides autocomplete and compile time validation on those remote methods. So, most developers don't even know about SOAP and never see a SOAP message. It's all done behind the scenes. If you're using a tool that doesn't have good support for it, though, then you're going to have a hard time with it.

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.

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.

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.

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.

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.

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.

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.

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

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

What is 'HL7 V3' ?

I assume: http://en.wikipedia.org/wiki/HL7

I just attended an SVJUG meeting where Mark Hansen explained REST web services. http://tech.groups.yahoo.com/group/svjug-announce/message/20... According to him, REST services are suitable for building mashups where the client is a web browser and tight interface specifications aren't necessary. SOAP services are more suitable for EAI where you need high reliability and tight specification of interfaces. Makes sense.

i'm not sure that I agree that REST and SOAP are really in conflict. it may not be common, but there's no reason you couldn't use SOAP as a transport for REST-based services. the real conflict is between REST systems which may or may not use SOAP and RPC systems which may or may not use SOAP.

i do, however, agree that for most people, SOAP and RPC style services are pretty much synonymous.

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.

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.

Have you looked at wsdl2java? http://ws.apache.org/axis/java/user-guide.html#WSDL2JavaBuil...

wsdl2java has worked really well for any WSDL I've ever had to work against (consuming fairly rich both Java and .Net web services from Java).

Note that there's been a fair bit of resistance to Axis2, with a lot of people preferring to stay on 1. I believe they changed the entire team from 1 to 2.

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

http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-...

Reply on news.ycombinator.com