3

I know that there are a lot of discussions already on SO about SOAP, bloat, XML, and alternative mechanisms like REST.

Here's the situation. A new team member is really talking up SOAP based upon the difficulty of implementing protocols by hand. He recommends gSOAP (project is all in C++.) He is stating things like WSDL cleaning up lots of messy hand coded C++.

Right now I am handling most networking with XML based text messages, and the expat XML library. So I have some programming effort (not much) associated with modifications to message formats or additions to parameter lists. At the sender end I package up an XML request and send it over a plain old TCP socket. At the receiver I parse the XML using DOM or SAX. Etc. It has worked fine so far. The XML messages are quite compact and average a couple of hundred characters, at most. And I understand every item in those messages.

We want one portion of the product (a server) to be accessible to web sites that are coded using PHP. That is partly driving this idea here, that a SOAP interface will be "easier" for script writers. Everyone on this project believes that SOAP is their salvation.

I see the introduction of a new large library like gSOAP as highly disruptive to the momentum of a mature project.

What I am wondering is if there is a different and more compact way of doing what SOAP gives us. And how to balance claims of gSOAP or other SOAP tools making development life easier against hard reality.

IE, I am being told that WSDL is better, easier, more workmanlike, etc than hand coding C++ using an XML library. That it puts the semantics of the C++ objects right into the declaration of the network messages. The thing is, many of the XML messages that I have defined don't map one for one to a single distinct object at the receiving end.

Or, it is possible that I am worrying about nothing.

But the reality as I scan messages here seems to contradict what I have been told locally.

Wannabe Tycoon
  • 307
  • 1
  • 3
  • 10
  • Can I say you are very concern about the overheads/bloating of SOAP? And trying to find out how can you implement SOAP without these drawbacks? – o.k.w Oct 17 '09 at 17:54
  • I never considered SOAP before this. The new guy on the team is recommending SOAP because of two apparent things: 1) he has worked with it and 2) he doesn't like the idea of hand coding XML code that tears strings apart and parses them into data values. – Wannabe Tycoon Oct 17 '09 at 17:58
  • If you want to open up a channel for others to consume, you do not have to use SOAP, but preferably something already out there and suits your needs. – o.k.w Oct 17 '09 at 18:02
  • I pretty much agree with you, especially since you already have a working non-SOAP system. But have you considered not parsing the strings but expressing *all* the structure in the data as XML structure? It's not always feasible, but if you can do it, it might be a better choice. – JaakkoK Oct 17 '09 at 18:55

4 Answers4

5

I'm not buying SOAP.

Don Box's original vision of a Simple Object Access Protocol is anything but simple now. It's become a bloated, design by committee mess.

Throw in all the additional dependencies on bloated libraries and you have a potential mess on your hands.

Tool vendors love SOAP, but I don't see much for anyone else.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • Thanks for the quick response. It validates my suspicions. I am looking for specific talking points. Right now we (on this project) are in handwaving mode. – Wannabe Tycoon Oct 17 '09 at 17:55
  • It started as a protocol for every platform to communicate. Currently it's a fat sheep which lots of frameworks/solutions still advocate. Well, I'm not keen about it too. – o.k.w Oct 17 '09 at 17:56
3

I think that you will find that PHP developers are more likely to prefer RESTful interfaces. Here is a 2003 article about it.

http://onlamp.com/pub/a/php/2003/10/30/amazon_rest.html

RESTful interfaces are a growing phenomenon and if you need to attract developers to your platform it will be easier if you catch the wave.

Having said that, is there a good reason why you cannot support multiple interfaces? This is fairly common in web services that do not have a captive audience. You could support your legacy model, a clean RESTful model and a SOAP/WSDL model. Then take stock after 6 months to a year to see which model is the most popular and least effort to support.

When it comes to making the site more accessible to outsiders, REST has more widespread usage. As far as saving your project, it is possible that SOAP would do this because it demands a certain amount of rigor in interface design, however the same could be said of REST. If this is a key criterion, then you should probably abandon the hand-coded XML and go with a high-level interface design that could be implemented as both REST and SOAP.

I know some people believe that SOAP and REST are fundamentally different approaches, but if you take a RESTful approach to the interface design, you shouldn't have great difficulty in creating a SOAP version. Don't try to do it the other way around though.

Michael Dillon
  • 31,973
  • 6
  • 70
  • 106
  • Michael, I'm considering your post "the answer", although this thread was really just a start in order to evaluate the claims being made about SOAP. So far the chorus seems to be a resounding "it will be a lot harder than you're being told". Thanks for the concrete recommendations. – Wannabe Tycoon Oct 18 '09 at 05:10
1

Here is a classic, hilarious, debunking of SOAP - The "S" stands for Simple". The community I move in is completely converted to REST.

peter.murray.rust
  • 37,407
  • 44
  • 153
  • 217
0

If you look around at RESTful interfaces on the net, you'll notice that SOAP is nearly universally avoided. SOAP is such a complex beast that it effectively locks out languages with no existing SOAP package, since nobody is going to implement it themselves. Raw XML, on the other hand, is pretty universal at this point, and not that difficult to implement in-house if necessary.

Tom
  • 10,689
  • 4
  • 41
  • 50