3 ms·

Any sufficiently complicated distributed architecture contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of SOAP.

by thom 11y ago

arethuza 11y ago
I must admit that having been through multiple generations of tools and approaches to support distributed programming - ONC RPC, CORBA, SOAP and now REST the one I liked least was SOAP - largely as it seems to favor initial ease of use (particularly in tools like Visual Studio) than long term operational support and ease of debugging. Interesting to see that they had started using JSON Schema for specifying documents in a RESTful world - I've just started that myself and it seems to work fairly well.
- thom 11y ago
  Indeed, drag and drop SOAP/WSDL based on objects in your app never really gave you a great API, just like randomly creating opaque REST endpoints never gives you a great API. Most SOAP stacks are extremely well orchestrated, I'd be interested to hear the specific operational and debugging issues you had. Look, I'm not madly in love with SOAP and I don't intend to throw myself on a bonfire of downvotes in its defence, but all the problems described in the article have been solved for a long time, including the ones lamented at the end - headers and authentication. People are of course welcome to go to whatever lengths they like to have complete control of their stack, I'd just hate to think it was because either nobody in the room mentioned it, or that they wrote it off because it was enterprisey.
  - arethuza 11y ago
    Indeed, I don't hate SOAP - it's a bit like Java - there is less wrong with the actual technology than you'd think and people can use it sanely. A culture problem more than a technology problem.
  - brightball 11y ago
    Totally agree with you there. It's been kinda funny watching the popularity of JSON grow while the world around it constantly spends time reinventing everything around XML like schemas. The biggest difference between REST and WSDL services just boiled down to whether you were using a scripting language or a strongly typed language. Strongly typed languages greatly benefited the extra schema details that WSDL provided. Scripting languages didn't have to care so WSDL seemed bloated and unnecessary. It's only when you start running into all of the problems associated with SOA that WSDL/SOAP already had solved that you truly start to appreciate the original spec.
    - aikah 11y ago
      > Scripting languages didn't have to care so WSDL seemed bloated and unnecessary This is an excellent point. And even a stronger point when one think about the popularity JSON. There is very little advantage with using JSON with Java for instance (architecture wise). XML,SOAP and co gets a lot of hate today. And it's funny how people are now reinventing the wheel with GraphQL and co ... when all that is needed has already been invented but for some religious reasons devs refuse to take advantage of it.
tokenrove 11y ago
I don't know why this was downvoted; we're basically watching as the whole SOA/ESB movement from ten years ago is being reinvented today. If we aren't conscious of the mistakes made then, we'll repeat them again.
- InvisibleCities 11y ago
  I've worked on classic WCF/SOAP/ESB systems, as well as the modern equivalent, and NServiceBus + REST beats absolutely everything from the old days, hands down. It's not even close.
  - thom 11y ago
    Service buses are slightly orthogonal to the point - where do I get schema info for one of your REST endpoints? Looking at C# code? My experience of ESBs is that they provide some valuable technological decoupling, but don't free you from the coordinated governance that SOA should really deliver. Which is fine, because you obviously don't always need that.

Any sufficiently complicated distributed architecture contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of SOAP.

by thom 11y ago

Any sufficiently complicated distributed architecture contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of SOAP.

arethuza 11y ago

I must admit that having been through multiple generations of tools and approaches to support distributed programming - ONC RPC, CORBA, SOAP and now REST the one I liked least was SOAP - largely as it seems to favor initial ease of use (particularly in tools like Visual Studio) than long term operational support and ease of debugging. Interesting to see that they had started using JSON Schema for specifying documents in a RESTful world - I've just started that myself and it seems to work fairly well.

thom 11y ago
Indeed, drag and drop SOAP/WSDL based on objects in your app never really gave you a great API, just like randomly creating opaque REST endpoints never gives you a great API. Most SOAP stacks are extremely well orchestrated, I'd be interested to hear the specific operational and debugging issues you had. Look, I'm not madly in love with SOAP and I don't intend to throw myself on a bonfire of downvotes in its defence, but all the problems described in the article have been solved for a long time, including the ones lamented at the end - headers and authentication. People are of course welcome to go to whatever lengths they like to have complete control of their stack, I'd just hate to think it was because either nobody in the room mentioned it, or that they wrote it off because it was enterprisey.
- arethuza 11y ago
  Indeed, I don't hate SOAP - it's a bit like Java - there is less wrong with the actual technology than you'd think and people can use it sanely. A culture problem more than a technology problem.
- brightball 11y ago
  Totally agree with you there. It's been kinda funny watching the popularity of JSON grow while the world around it constantly spends time reinventing everything around XML like schemas. The biggest difference between REST and WSDL services just boiled down to whether you were using a scripting language or a strongly typed language. Strongly typed languages greatly benefited the extra schema details that WSDL provided. Scripting languages didn't have to care so WSDL seemed bloated and unnecessary. It's only when you start running into all of the problems associated with SOA that WSDL/SOAP already had solved that you truly start to appreciate the original spec.
  - aikah 11y ago
    > Scripting languages didn't have to care so WSDL seemed bloated and unnecessary This is an excellent point. And even a stronger point when one think about the popularity JSON. There is very little advantage with using JSON with Java for instance (architecture wise). XML,SOAP and co gets a lot of hate today. And it's funny how people are now reinventing the wheel with GraphQL and co ... when all that is needed has already been invented but for some religious reasons devs refuse to take advantage of it.

tokenrove 11y ago

I don't know why this was downvoted; we're basically watching as the whole SOA/ESB movement from ten years ago is being reinvented today. If we aren't conscious of the mistakes made then, we'll repeat them again.

InvisibleCities 11y ago
I've worked on classic WCF/SOAP/ESB systems, as well as the modern equivalent, and NServiceBus + REST beats absolutely everything from the old days, hands down. It's not even close.
- thom 11y ago
  Service buses are slightly orthogonal to the point - where do I get schema info for one of your REST endpoints? Looking at C# code? My experience of ESBs is that they provide some valuable technological decoupling, but don't free you from the coordinated governance that SOA should really deliver. Which is fine, because you obviously don't always need that.