I have read this question here: http://stackoverflow.com/questions/1367798/consuming-a-php-soap-webservice-with-asp-net
So does SOAP really hold his promise of Interoperability ?
+1
A:
Yes, absolutely; it's just that old and/or crappy implementations of it have given it a bad reputation. Too many SOAP implementations out there are "very nearly" SOAP compliant, but "very nearly" is no good.
Modern SOAP stacks (e.g. WCF, JAX-WS) make a much better job of it.
skaffman
2010-05-04 20:21:36
If they are so many "very nearly" soap clients is soap really meant to be usable as it was supposed to be as "S" was used to mean "Simple" until it was clearly forgotten :)If so many advanced technological firms cannot even make it how can average clients ?
2010-05-09 11:16:03
@asksuperuser: I agree, various parties made it much harder than it really needed to be in the early days, some out of incompetence, some out of self-interested malice (I'm looking at you, Microsoft). On top of that, various half-baked open-source implementations were written by those who didn't understand what they were doing, further muddying the interop waters. And, as always, any protocol that starts with "Simple" is usually anything but (SOAP, SNMP, SMTP, etc)
skaffman
2010-05-09 11:32:40
+1
A:
Yes^
^Assuming that everyone supports/implements/follows the protocol correctly. That is, it is no different than any other data-exchange/data-format or protocol.
pst
2010-05-04 20:22:23
But isn't the protocol suppose to help implementation ? Why do people have so many difficulties ? And I note that no one was capable to solve the question they asked.
2010-05-06 01:47:08
@asksuperu Generally the more complex and unwieldy a protocol, the harder it is to get right. And the harder it is to get programmers to care. This is at least part of the reason why simple web-services/JSON have become popular. Easy to specify (informally) and easy to view/generate/use -- at least for simple cases :-)
pst
2010-06-18 05:24:24
+1
A:
Yes
Have used it on several projects. Indispensable when integrating with 3rd party vendors.
On the client side, I recommend using SOAPUI for testing the service (interoperability can take more time at the config layer)
Once you are confident in the service definitions, then you can also use Apache Axis to auto-generate your classes.
For simple SOAP requests, you can also use straight up http requests and and XML parsing. (In JAva this is easy enough with javax.xml)
DaveG
2010-05-04 20:27:41
I haven't used SoapUI yet seems over-complicated to me compared to SoapSonar. But when I tested a simple helloworld .NET webservice, SoapSonar got an error.So I really wonder if SOAP which originally means "Simple Object Access Protocol" was just a hype about so-called simplicity. When it comes to Interoperability betweeen client and server it seems hard in the real world to get what the theory says.
2010-05-06 01:51:08
In the .NET world it is very easy to connect to a SOAP ws by adding a web resource to a project. The MSVS IDE autogenerates all the code you need.SOAP does have more overhead than REST, but it better suited than REST for many case, such security, federation, etc.I would not say it is hype, or that it is not simple in the real world. My experience is that it is simple and and easy to adapt to.The notion of simple is relative. Compare to CORBA, RMI, DCOM and other interoperability frameworks, SOAP really is amazingly simple.
DaveG
2010-05-07 15:59:52
I don't say it is not simple to create a soap webservice in VS Studio. I say that it doesn't seem to be really interoperable since even a SOAP Client like soapsonar cannot be sure to be able to query the service created with VS Studio. Maybe it's fault of one or the other or both, but result is since they can't cope to really talk to each other, it fails in its promise.
2010-05-09 11:13:44