I know that SO has a lot of discussions about SOAP, bloat, XML, and alternative mechanisms like REST.
Here is the situation. The new team member does say SOAP, based on the complexity of manual protocol execution. He recommends gSOAP (the project is all in C ++.) He states that WSDL cleans up a lot of dirty manual C ++.
I am currently processing most XML-based text messaging networks and the expat XML library. Therefore, I have some programming efforts (not so many) associated with changing message formats or adding to parameter lists. At the end of the sender, I pack the XML request and send it through a plain old TCP socket. In the receiver, I parse XML using the DOM or SAX. Etc. So far, it has worked fine. XML messages are fairly compact and average several hundred characters. And I understand every element in these posts.
We want one part of the product (server) to be available for websites that are encoded using PHP. This partly explains here that the SOAP interface will be “easier” for script authors. Everyone in this project believes that SOAP is their salvation.
I see the introduction of a new large library, such as gSOAP, as very damaging to the momentum of a mature project.
I am wondering if there is another and more compact way to do what SOAP gives us. And how to balance the requirements of gSOAP or other SOAP tools that make development life easier against harsh reality.
IE, they tell me that WSDL is better, simpler, more workmanlike, etc. than manually coding C ++ using the XML library. That it puts the semantics of C ++ objects directly in the declaration of network messages. The fact is that many of the XML messages that I have defined do not map one for one to a separate, separate object on the receiving side.
Or maybe I'm not worried about anything.
But the reality when I look through the posts here seems to contradict what I was told locally.