Have you ever consumed SOAP web services?

[stytagm]

How much pain did it cause you? The SOAP protocol is a bit wobbly, and I'm especially interested to hear from people using non .Net languages. How easy is it in Java? or Python? Do Perl libraries prefer subtly different SOAP envelopes to those beloved by Rails? Is it even worth attempting in c++? How many different SOAP libraries are there in Javascript? etc etc etc

Let me explain myself: I'm thinking (in a mostly academic, navel-gazing kind of way) about writing an online app, with a SOAP interface (all you REST and JSON devotees calm down, this is just an exercise, think of SOAP as a client must-have, it might be stupid but there's no changing it). If I implement it in .Net, and provide a nice WSDL, will it really be easy for anyone in any language to consume?

I've written and consumed SOAP web services using .NET, and as long as there's a valid WSDL document, it's a doddle.

I've also tried to consume (allegedly) SOAP web services without a WSDL from a client who'd written SOAP libraries themselves, and it was a living hell, to the point that I created my own web service with the same function signature, just to get a WSDL to use, and when that didn't work we went back to the supplier, who re-wrote the whole thing from scratch (using standard Java libraries we suspect) and provided a WSDL, it was then a doddle!

So, if I was to write a service in ASP.Net, throw it live and provide the WSDL meta data, could I then sit back and market it, or would I have teething problems from my consumers?

(or should I just can it and use JSON / REST in the first place!)

[TiG]

I've been consuming SOAP webservices for ages, in 3 businesses and seen all sorts sizes shapes and forms of people's attempts at Soap interfaces. (this ranges from the RTIG government standard for bus/transport times - which has a 300+ page data definition schema, to a noddy webservice knocked up in 5 minutes)

The simple rules I would follow now, first I wouldn't touch a SOAP interface without a WSDL, regardless of how its created, via any Method, APACHE has a nice method to generate it too from one of their checkers.

However I think what you are talking about has already been done. I don't have the link at home but there are several "soap checker" interfaces that do something exactly like what I think you are describing.

TiG

[directhex]

i did it with amazon web services, in mono

t'was easy peasy

but since you asked for non-.net, i can't help

[TheAnimus]

First off, Webservices and Soap are generally buzz words, rather than specifications. Just to clarify (even thou u've said SOAP) WebServices are a big wide world of interoperability generally over HTTP. We've got JSON and WS-* as two fundementaly different protocols, that are at opposite ends at the idea about how to do things scale.

But, soap is more standardised, and is very easy to consume.

There are two tools for this on C++ that i've used before, both have been ok, but both have had quirks. I can't remeber the names of them, will post tommorow when at work with them if no one else has in the main time.

Just wanted to say my "make sure you know its going to be standardised" speach in first

[stytagm]

Thanks for the responses

Tig, I'm not doing anything to validate SOAP, I was considering offering a software solution which was hosted and accessed via an online call. I was just wondering if SOAP is as easy for users of other programming languages as it is for .Net users.

Animus, you've sort of hit the nail on the head. In a project where I was both providing (in .net) and consuming (in javascript) a "web service", I used a sort of REST model as it's simpler and much much lighter weight than something like SOAP. Horses for courses. Unfortunately it's difficult to talk about this whole topic without sounding like a web 2.0 evangelist. I can assure you buzzwords (especially vague ones) irritate me too.

But anyway, remembering that this is all hypothetical, my imaginary business will make money for every consumer of my service (in the business sense of the word) but concerns like bandwidth and latency just have no bearing on my likely profitability in comparison to the number of programmer hours needed to hook into it. To quote Ted Dziuba, "Scalability is not your problem, getting people to give a **** is"

So how should I implement an online, real time API to my (non existent) software, such that the maximum number of programmers would have to exert the minimum amount of effort to call my API from their own code.

[yamangman]

Do it however you like, but write some documentation?

[directhex]

the lowest effort (and most 'dangerous' from a make-sure-your-app-is-secure perspective) option is a simple webapp with query string parsing

[TheAnimus]

Do you need any authentification? If not a simple SOAP with WSDL is probably the best bet, keeping all the types as privative as posisble.

(also worth noting that theres nothing wrong with the concepts of a restful implementation!)