La interoperabilidad de servicios web de WCF a Java parece sorprendentemente problemática. ¿Algún buen recurso?


13

Con un proyecto reciente, nuestro equipo de desarrollo basado en .Net tiene la tarea de integrarse con una gran cantidad de servicios web basados ​​en Java en todo el mundo, y realmente hemos tenido una gran cantidad de problemas (bueno, ya no nos sorprende). porque el XML generado por WCF no es aceptado por los servicios de Java.

También parece que en realidad no hay tanta buena información para encontrar sobre el tema, hemos recibido algunos buenos consejos del excelente blog WCF de Yaron Nave, http://webservices20.blogspot.com , y también en el foro MSDN WCF http: //social.msdn.microsoft.com/Forums/en-US/wcf/threads .

¿Hay alguien aquí que realmente sienta que entendió esto y conoce el recurso definitivo sobre el tema? Estaría interesado en consejos sobre libros, blogs o cualquier sitio web.

Editar:
No estoy seguro de configurar la respuesta aceptada en este hilo, porque cada una de las dos mejores respuestas tiene algún valor:
1. Probablemente terminemos haciendo más implementaciones de HTTP Webrequest en lugar de luchar contra WCF.
2. Pero el WCF Express Interop Bindings 1.0 también fue un consejo muy sensato.


No sé nada sobre WCF, pero ¿está produciendo paquetes XML basados ​​en SOAP o solo una porción de XML que podría ser consumida por un servicio RESTful?
Martijn Verburg

1
Devuelve XML, JSON o RDF + XML.
Alan B

¿Puedes dar ejemplos de lo que salió mal entre wcf client y java webservice? ¿te refieres al servicio web = jabón o algo diferente?
k3b

1
Está fuera del alcance de esta pregunta entrar en detalles, puede consultar mi perfil en el desbordamiento de la pila para ver ejemplos. Aquí, solo quiero saber si alguien más está teniendo el mismo problema con los clientes WCF (o .Net en general) interoperabilidad con servicios web basados ​​en otras plataformas.
Bjørn

Respuestas:


15

Ah sí ... SOAP, el alardeado santo grial de la informática. Una lingua franca que prometía interoperabilidad entre sistemas de todo el mundo.

Y luego entras en las diferencias entre las implementaciones SOAP en Java y PHP y .NET. O incluso entre el servicio SOAP de WebSphere y el cliente SOAP de Apache. No importa tratar con diferentes estándares de compatibilidad WS-I. Ahora, por favor, dígame por qué necesita un estándar de compatibilidad para un protocolo creado para compatibilidad , hablemos de ironía (y me refiero a la verdadera ironía, no a la marca de ironía Alanis Morrissette ).

El único momento en que no se encontrará con problemas para que dos puntos finales SOAP se comuniquen es cuando ambos están en la misma plataforma y, en la mayoría de los casos, la plataforma tendrá un protocolo de operación remota más eficiente.

Lo que digo aquí es que, en su mayor parte, SOAP es inútil. Ahora jabón en minúsculas, lo uso todos los días y estoy agradecido de que la mayoría de la gente haga lo mismo.

Dicho esto, si insistes en golpearte la cabeza contra una pared de ladrillos. Aquí es un buen lugar para comenzar Microsoft tiene un conjunto de enlaces para permitir la interoperabilidad con la mayoría de los principales servidores Java. La parte divertida, por supuesto, es descubrir cuáles funcionan con cuáles de los servicios que está integrando.


55
SOAP es el nuevo CORBA :)
gbjbaanb

De alguna manera, parece que lo estoy haciendo con éxito con bastante frecuencia en proyectos de integración de clientes. YMMV aparentemente.
David J. Liszewski

9

En mi opinión, su observación es bastante precisa. Las implementaciones de alto nivel de comunicación basada en XML es por lo general no es compatible con diferentes plataformas, incluso si son ambos llamados "jabón". Las diferencias sutiles en la implementación, probablemente tanto dentro del alcance del estándar implementado, crean problemas en el uso de la vida real.

Mi recomendación para los proveedores de servicios: use una implementación simple en lugar de una implementación muy compleja y teóricamente mejor. Por ejemplo, no incluya esquemas de autenticación extremadamente complejos si no los necesita.

Mi recomendación para los consumidores de servicios (usted, supongo): cuando se comunique con una implementación de alto nivel en una plataforma diferente a la suya, degrada a una implementación de nivel inferior. De repente, se vuelve bastante simple si simplemente averigua cuál es el XML real para enviar y luego utiliza buenas prácticas de codificación normales para lograrlo, como una alternativa a insistir en usar la implementación de alto nivel de su propia plataforma.

Espero que no haya sido demasiado abstracto. En resumen , cuando está en la plataforma .NET que se conecta a una plataforma Java, es posible que desee simplemente ensamblar los encabezados y xml en una HttpWebRequest y enviarlo de esa manera.


4

También tendrá los mismos problemas al consumir servicios web PHP.

Nuestra única respuesta a esto fue cambiar el tipo de protocolo a REST en lugar de SOAP. Nunca conseguimos que SOAP interoperara, ¡tanto por Simple!


En la mayoría de los casos, no tenemos absolutamente ninguna opción para cambiar los servicios web existentes de ninguna manera, vamos a tener que conectarnos a ellos con SOAP, pase lo que pase. Así que me temo que no hay respuesta resuelta para ti. ;)
Bjørn

1
> "ninguna opción para cambiar los servicios web existentes de ninguna manera" En ese caso; prepárate, te espera un viaje difícil. Me acabo de recuperar de 2 semanas de golpes en la cabeza, tratando de llamar a un servicio web wcf / soap desde java / android. Mi salvación fue que yo, a diferencia de usted, tuve acceso al servicio y lo hice exponer un punto final REST / JSON. Camino a seguir. Si puedes.
BaBu

@ Bjørn oh bueno, lamento decirte esto entonces, pero para usar el término técnico, estás jodido. Supongo que la única respuesta es dejar de usar WCF y usar un cliente SOAP diferente.
gbjbaanb

Nuestro equipo se ríe y llora por sus respuestas. :) Gracias caballeros.
Bjørn
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.