Surely this isn't a surprise?

If X is designed to process SOAP calls and Y makes a SOAP call to X, you sort of expect it to work, its the whole point of having a standard, even one as rabidly verbose as SOAP...

Interesting to see how its done in Flex though.

As for performance, in most cases wouldn't a HTTP Endpoint be better than creating a .NET web service?

The only thing lacking I've found in HTTP Endpoints is when trying to consume one, ironically enough, *in* .NET which throws a wobbler over the SQL XML datatype.

The only surprise is

The only surprise is that MS haven't screwed up^H^H extended the SOAP spec so it only works with their client.

It's not like they've got form or anything...

@Tom Chiverton

Why would Microsoft try to screw up their own spec?

They were behind SOAP in the first place, and whilst MS may do many evil and boneheaded things, they tend to do those things to any inconvenient competition and not to themselves. Vista being a notable exception obviously.

And lets be honest, given your average SOAP request resembles the contents of Encyclopaedia Britannica in length, if MS managed to shrink it that could only be a good thing.

SOAP Fault?

This phrase conjures up visions of someone failing to have a shower for too long...

@Tom Chiverton

I find it quite surprising, I recollect having interop issues with Microsoft SOAP a long time ago.

http://www.windowsdevcenter.com/pub/a/oreilly/windows/news/soapreview_0600.html

I can, ICANN. Can U2 ..... Ergo Do We.

"I might be missing something here... .. but would the end result of the .NET version be truly browser-independent?" .... By William Old Posted Thursday 17th July 2008 18:52 GMT

Yes ..... and Create an Engine Searching Operating Systems for Driver Codes for a Ubiquitous Operating System with AIdDynamic Drive. A Pandora's Box of Virtual Opportunity. :-)

But you could never expect HyperVirtualisation Flight Controls to be Normal or Conventional. That would be Totally Illogical.

.

wcf server/client completly independent

<what you would expect from a single stack>

err, wcf is completly independent on the underlying delivery mechanism. calling a soap service, a .net service, a named pipe or iven a rest endpoint is almost identical from the callers view when using wcf.

the only thing you have to switch out is the binding object (and in the case of a rest service add an attribute saying where the arguemnts to the method goes in the url)

all the underlying stuff is encapsulated in the binding object.

the same holds true for hosting. if you want your spiffy .net service to become a soap service the only thing you have to do is swap out the binding object.

this can even be done with the built in config system so you dont even have to recompile your code..

so, if you feel the built in soapbinding isnt good enough, make your own, change 1 line in your config files and bam, your wcf server/client uses your own soap(or what ever else) implementation instead

dont belive me? check out msdn..

http://msdn.microsoft.com/en-us/library/ms733027.aspx

re: end result of the .NET version be truly browser-independent

btw, silverlight Is truly browser independent.. it even wraps the javascript api of each browser so that you have a consistent api across all browsers..

(fyi, microsoft have contributed all their silverlight unit tests to the moonlight project, the aim is to have moonlight 100% complient with silverlight)

and no i dont work at microsoft, iand even if i did, what im saying is true and can be verified by 5 minutes of googleing (maybe 30 minutes if you use live search:P)