A interoperabilidade de serviços da Web WCF para Java parece surpreendentemente problemática. Algum bom recurso?

Com um projeto recente, nossa equipe de desenvolvedores baseada em .Net foi incumbida de integrar-se a toda uma série de serviços Web baseados em Java em todo o mundo, e realmente tivemos uma quantidade surpreendentemente grande de problemas (bem, certamente não estamos mais surpresos) porque o XML gerado pelo WCF não é aceito pelos serviços java.

Também parece que não há realmente muita informação boa sobre o assunto; recebemos algumas boas dicas do excelente blog do WCF de Yaron Nave, http://webservices20.blogspot.com , e também no fórum do MSDN WCF http: //social.msdn.microsoft.com/Forums/en-US/wcf/threads .

Existe alguém aqui que realmente sente que conseguiu isso e conhece o recurso definitivo sobre o assunto? Estaria interessado em dicas de livros, blogs ou quaisquer sites.

Edit:
Estou empolgado em definir a resposta aceita neste tópico, porque cada uma das duas melhores respostas tem algum valor:
1. Provavelmente, acabaremos fazendo mais implementações de HTTP Webrequest em vez de combater o WCF.
2. Mas as Ligações de interoperabilidade 1.0 do WCF Express também foram uma dica muito sensata.

Ah, sim ... SOAP, o Santo Graal da computação. Uma língua franca que prometeu interoperabilidade entre sistemas em todo o mundo.

E então você se depara com as diferenças entre implementações SOAP em Java e PHP e .NET. Ou mesmo entre o serviço WebSphere SOAP e o cliente Apache SOAP. Não importa lidar com diferentes padrões de compatibilidade WS-I. Agora, por favor, diga-me por que você precisa de um padrão de compatibilidade para um protocolo criado para compatibilidade , fale sobre ironia (e quero dizer ironia real, não a marca de ironia Alanis Morrissette ).

O único momento em que você não se depara com problemas na comunicação de dois pontos de extremidade SOAP é quando ambos estão na mesma plataforma e, na maioria dos casos, a plataforma terá um protocolo de operação remota mais eficiente.

O que estou dizendo aqui é que, na maioria das vezes, o SOAP é inútil. Agora, em minúsculas, uso isso todos os dias e sou grato por a maioria das pessoas fazer o mesmo.

Dito isto, se você está insistindo em bater a cabeça contra uma parede de tijolos. Aqui é um bom ponto de partida A Microsoft possui um conjunto de ligações para permitir a interoperabilidade com a maioria dos principais servidores Java. A parte divertida do curso é descobrir quais funcionam com quais dos serviços que você está integrando.

Na minha opinião, sua observação é bastante precisa. As implementações de alto nível da comunicação baseada em XML geralmente não são compatíveis com plataformas diferentes, mesmo que ambas sejam chamadas de "SOAP". Diferenças sutis na implementação, provavelmente ambas dentro do escopo do padrão implementado, criam problemas no uso da vida real.

Minha recomendação para provedores de serviços: Use uma implementação simples em vez de uma implementação muito complexa e teoricamente melhor. Por exemplo, não inclua esquemas de autenticação extremamente complexos se não precisar deles.

Minha recomendação para os consumidores de serviços (você, presumo): ao se comunicar com uma implementação de alto nível em uma plataforma diferente da sua, diminua para uma implementação de nível inferior. De repente, torna-se bastante simples se você simplesmente descobrir qual é o XML real a ser enviado e usar boas práticas normais de codificação para fazer isso, como uma alternativa a insistir em usar a implementação de alto nível de sua própria plataforma.

Espero que não tenha sido abstrato demais. Em resumo , quando você está na plataforma .NET conectando-se a uma plataforma Java, pode simplesmente montar os cabeçalhos e o xml em um HttpWebRequest e enviá-lo dessa maneira.

Você também terá os mesmos problemas ao consumir serviços da web PHP.

Nossa única resposta para isso foi alterar o tipo de protocolo para REST, em vez de SOAP. Nunca tivemos o SOAP para interoperar, tanto para o Simple!