Comments on: A rant about the complexity of working with SOAP services http://blog.mashupguide.net/2007/08/15/a-rant-about-the-complexity-of-working-with-soap-services/ A blog about Raymond Yee's Book Pro Web 2.0 Mashups: Remixing Data and Web Services Wed, 07 Jan 2009 03:33:20 +0000 http://wordpress.org/?v=2.7 hourly 1 By: All You Need Is A Good Clean SOAP Toolkit | Financial Web Services - Xignite Blog http://blog.mashupguide.net/2007/08/15/a-rant-about-the-complexity-of-working-with-soap-services/comment-page-1/#comment-39748 All You Need Is A Good Clean SOAP Toolkit | Financial Web Services - Xignite Blog Sun, 23 Nov 2008 19:47:18 +0000 http://blog.mashupguide.net/2007/08/15/a-rant-about-the-complexity-of-working-with-soap-services/#comment-39748 [...] SOAP vs. REST debate, mainly because this blog started after the battle began raging. But a recent post by Raymond Yee–who is writing a book about mashups–suggested a [...] [...] SOAP vs. REST debate, mainly because this blog started after the battle began raging. But a recent post by Raymond Yee–who is writing a book about mashups–suggested a [...]

]]> By: sdubois http://blog.mashupguide.net/2007/08/15/a-rant-about-the-complexity-of-working-with-soap-services/comment-page-1/#comment-608 sdubois Fri, 24 Aug 2007 00:57:14 +0000 http://blog.mashupguide.net/2007/08/15/a-rant-about-the-complexity-of-working-with-soap-services/#comment-608 I disagree quite a bit. I think the assumption you make here is that to use SOAP as a developer, you have to know the intricacies of the protocols (SOAP and WSDL). But you really don't have to. It all depends on the toolkit you use. I'll take an analogy. Do we require internet users to know HTML to navigate the web? No we don't. On the user side, the browser takes care of it. If end users had to read HTML pages in plain text they would find it very obscure indeed. On the server side you could be writing your HTML by hand (which you would then need to understand) or you could use some advance tool that allowed you to write pages in a WYSIWIG fashion and completely hide the HTML. So it all depends on the tools and how well they hide the protocol from you. If you want to write a web service by hand, you will have to know SOAP and WSDL. If you use a good toolkit, all you have to do is write a function call and you have a web service. If you want to consume a web service without a good SOAP toolkit, you will have to learn the standards but not otherwise. I personnaly wrote dozens of web services which collectively have served billions of SOAP requests to hundreds of firms around the world yet I have never read the SOAP specs and I can barely read a WSDL by hand. All I had to do was to write meaningful function calls. Clients who use good SOAP toolkit can go from pointing to our WSDL to consuming data in their application in less that 60 seconds without a hint of what the protocols are about (Something impossible to do with REST). Those who come to us with more primitive languages will have to spend more time working out the details. SOAP's bad rap comes from those who just have not wanted to use more advanced SOAP toolkits. It's very sad indeed. To me is it as if back in 1996, we had abandoned the power of the web and stopped building web pages because a bunch of people insisted in using a text editor to open HTML pages instead of a browser and complained about how unreadable this HTML was. Unfortunately, :-), php and python are not ones of those better SOAP toolkits. I would love to discuss further sduboisATxigniteDOTcom I've written around 50 web I disagree quite a bit. I think the assumption you make here is that to use SOAP as a developer, you have to know the intricacies of the protocols (SOAP and WSDL). But you really don't have to. It all depends on the toolkit you use.

I'll take an analogy. Do we require internet users to know HTML to navigate the web? No we don't. On the user side, the browser takes care of it. If end users had to read HTML pages in plain text they would find it very obscure indeed.

On the server side you could be writing your HTML by hand (which you would then need to understand) or you could use some advance tool that allowed you to write pages in a WYSIWIG fashion and completely hide the HTML.

So it all depends on the tools and how well they hide the protocol from you.

If you want to write a web service by hand, you will have to know SOAP and WSDL. If you use a good toolkit, all you have to do is write a function call and you have a web service.

If you want to consume a web service without a good SOAP toolkit, you will have to learn the standards but not otherwise. I personnaly wrote dozens of web services which collectively have served billions of SOAP requests to hundreds of firms around the world yet I have never read the SOAP specs and I can barely read a WSDL by hand. All I had to do was to write meaningful function calls.

Clients who use good SOAP toolkit can go from pointing to our WSDL to consuming data in their application in less that 60 seconds without a hint of what the protocols are about (Something impossible to do with REST).

Those who come to us with more primitive languages will have to spend more time working out the details.

SOAP's bad rap comes from those who just have not wanted to use more advanced SOAP toolkits.

It's very sad indeed. To me is it as if back in 1996, we had abandoned the power of the web and stopped building web pages because a bunch of people insisted in using a text editor to open HTML pages instead of a browser and complained about how unreadable this HTML was.

Unfortunately, :-), php and python are not ones of those better SOAP toolkits.

I would love to discuss further
sduboisATxigniteDOTcom

I've written around 50 web

]]>