With a recent project our .Net based dev team has been tasked with integrating with a whole host of java based web services around the world, and we really have had a surprisingly (well, we are certainly not surprised any more) large amount of issues because the XML generated by WCF is not accepted by the java services.

It also seems that there is not really that much good information to find on the subject, we have gotten some good tips from Yaron Nave's excellent WCF blog, http://webservices20.blogspot.com, and also on the MSDN WCF forum http://social.msdn.microsoft.com/Forums/en-US/wcf/threads.

Are there anyone here who really feel that they got this down, and know the definitive resource on the subject? Would be interested in tips on books, blogs or any websites.

I am torn on setting the answer accepted on this thread, because each of the two best answers has some value:
1. We will probably end up with doing more HTTP Webrequest implementations instead of fighting WCF.
2. But the WCF Express Interop Bindings 1.0 was also a very sensible tip.

  • I know nothing about WCF, but is it producing SOAP based XML packets or just a chunk of XML that could be consumed by a RESTful service? Commented May 4, 2012 at 8:38
  • 1
    Returns XML, JSON or RDF+XML.
    – Alan B
    Commented May 4, 2012 at 9:09
  • can you give examples of what went wrong between wcf client and java webservice? do you mean webservice=soap or something different?
    – k3b
    Commented May 4, 2012 at 11:15
  • 1
    It is outside of the scope of this question to go into the specifics, you can check out my profile on stack overflow for examples. Here, I just want to hear if anyone else is having the same problem with WCF (or .Net in general) clients interop with webservices based on other platforms.
    – Bjørn
    Commented May 4, 2012 at 11:21

3 Answers 3


Ah yes...SOAP, the vaunted holy grail of computing. A lingua franca that promised interop between systems around the world.

And then you get into the differences between SOAP implementations on Java and PHP and .NET. Or even between the WebSphere SOAP service and the Apache SOAP client. Never mind dealing with different WS-I compatability standards. Now please tell me why you need a compatibility standard for a protocol that was built for compatibility, talk about ironic (and I mean real irony, not the Alanis Morrissette brand of irony).

The only time you won't run into issues in getting two SOAP endpoints communicating is when they are both on the same platform and in most cases the platform will have a more efficient remote operation protocol.

What I'm saying here is that for the most part, SOAP is useless. Now lower case soap, I use that every day and I'm thankful that most people do the same.

That being said, if you're insisting on beating your head against a brick wall. Here is a good place to start Microsoft has a set of bindings to enable interop with most of the major Java servers. The fun part of course is finding out which ones work with which of the services you are integrating.

  • 5
    SOAP is the new CORBA :)
    – gbjbaanb
    Commented May 10, 2012 at 14:56
  • Somehow I seem to be doing it successfully rather frequently in client integration projects. YMMV apparently. Commented Nov 10, 2015 at 2:35

In my opinion, your observation is quite accurate. The high level implementations of XML based communication is usually not compatible with different platforms, even if they are both called "SOAP". Subtle differences in implementation, probably both within the scope of the standard implemented, create problems in real life use.

My recommendation for service providers: Use a simple implementation rather than a very complex and theoretically better implementation. For example, don't include any extremely complex authentication schemes if you don't need them.

My recommendation for service consumers (you, I presume): When communicating to a high level implementation on a different platform than yours, degrade to a lower level implementation. It suddenly becomes quite simple if you simply figure out what the actual XML to send is and then use normal good coding practices to accomplish that, as an alternative to insisting on using the high level implementation of your own platform.

Hope it wasn't too abstract. In short, when you're on the .NET platform connecting to a Java platform, you may want to simply assemble the headers and xml in a HttpWebRequest and send it off that way.


You'll have the same problems consuming PHP web services too.

Our only answer to this was to change the protocol type to REST rather than SOAP. We never got the SOAP stuff to interoperate, so much for Simple!

  • In most cases, we have absolutely no option to change the existing web services in any way, we are going to have to connect to them with SOAP, no matter what. So I am afraid no Answer Solved for you. ;)
    – Bjørn
    Commented May 4, 2012 at 11:12
  • 1
    >"no option to change the existing web services in any way" In that case; brace yourself, you're in for a rough ride. I've just recovered from 2 weeks of head-banging, trying to call a wcf/soap web service from java/android. My salvation was that I - unlike you - had access to the service and made it expose a REST/JSON endpoint. Way to go. If you can.
    – BaBu
    Commented May 10, 2012 at 9:47
  • @Bjørn oh well, sorry to tell you this then but to use the technical term, you're screwed. I guess the only answer is to stop using WCF and use a different SOAP client.
    – gbjbaanb
    Commented May 10, 2012 at 14:59
  • Our team is laughing and crying from your answers. :) Thanks gentlemen.
    – Bjørn
    Commented May 11, 2012 at 7:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.