Why use SOAP over JSON and custom data format in an "ENTERPRISE" application?

Question

Hi all,

I work in a medium size financial company where all our applications talk to each other using SOAP and we only use JSON for AJAX requests from web sites.

Recently in a new project planning session, someone asked me why do we have to use SOAP for inter-application communication? Why not use JSON or even custom data format? In my heart I felt these alternatives are not "Enterprise-ready" but actually I couldn't think of a very compelling answer as to why they are bad.

The only two advantages of SOAP I can think of are tooling and security.

Modern IDEs such as Visual Studio have built-in utility to generate classes from WSDL definitions, which you don't get if you use JSON or custom data format. In terms of security, SOAP has well-defined security standards that are not available in other data format standards.

What do you think? do you use JSON as the data exchange format between applications?

Answer 1

The reason for JSON is simplicity. It's easy to read, easy to understand, has little overhead, and has implementations in just about every language.

To call something "enterprise" capable is a bit crazy, IMHO. It's just a data exchange format. Whether it's SOAP, XML, JSON, whatever, it's just a communication format.

Tooling is nice, I admit; auto-generated classes are great. But on the other hand, you get a lot of flexibility when you manage your classes by hand, and generally, it's not that difficult to do.

Security is a non-issue in my mind. Your data format should have (again, IMHO) nothing to do with your security. That needs to be at a different level entirely. While SOAP has some security extensions, etc, I think for the most part, they just provide a lot of unnecessary complexity. Ever tried reading some of the specs for the WS-Security? Yikes. How about just using JSON+HTTPS - easy, everyone supports it, and it works like a champ....

Now, that's not to say it's the right solution to every problem, but if you're just looking for data interchange, I'm sold.

Personally, I love JSON as a format, and use it all the time.

Answer 2

JSON does entail more effort that SOAP XML, but it typically produces much smaller packets, and is therefore more scalable. It is also (in my subjective opinion) vastly easier to read, while debugging, sniffing the wire, etc.

Answer 3

IMHO, there is one big reason everyone sticks with SOAP instead of using JSON. With every JSON setup, you're always coming up with your own data structure for each project. I don't mean how the data is encoded and passed, but how the data format is defined, the data model.

SOAP has an industry mature way of specifying that data will be in the form Cart is a collection of Products and each product can have these attributes, etc. A well put together WSDL document really has this nailed. Heck, it's a W3C specification.

JSON has similar ways of specifying this data structure. A JavaScript class comes to mind as the most common way of doing this. A JavaScript class isn't really a data structure in any kind of agnostic, well established, widely used way. Heck, JavaScript really only executes in one environment, the browser.

In short, SOAP as a way of specifying the data structure in a maturely formatted document (WSDL). JSON doesn't.

Answer 4

One major reason has nothing to do with technical reasons.

A lot of "enterprise" systems are being sold to big stuffy "enterprise" clients. The client demands SOAP and that's what they get.

What are their reasons? Sometimes it is very pragmatic: their team is familiar with SOAP and they have many existing SOAP services (and this team would maintain the product after it is delivered). Sometimes it's not: they read it in some article and they have their minds made up.