¿Es cierto que la interoperabilidad SOAP es un mito?

Question

quiero decir, verdad verdadera interoperabilidad: de Java a .NET, desde PHP a Java, etc.

Lo digo porque nuestros poderes que quieren que implementar la API de cara al público con los servicios web SOAP, y estoy tratando de hacer un punto fuerte a favor de RESTful XML/JSON API.

Su razonamiento es mucho lavado de cerebro inducida:

• SOAP es un protocolo basado en estándares (por no hablar de uno de nuestros desarrolladores ha pasar últimos 4 días enterrados en configuración XML y de seguridad personalizadas serializadores simbólicos tratando de alguna manera doblar el cliente WCF para que llame al servicio WSE 3.0 y produce todo tipo de errores oscuros),
• SOAP es seguro (pero en lo que respecta al negocio no necesitamos cifrado ni firmas digitales: HTTP sobre SSL será más que suficiente)
• Por último, SOAP es interoperable, y este parece ser el producto de mayor venta nt para ellos (todo el punto de esta pregunta)

Reitero: ¿es SOAP realmente interoperable? Tus historias de guerra del mundo real serán excelentes.

Answer 1

Siempre y cuando se adhiera a los estándares SOAP WS-I-based, la interoperabilidad suele ser bastante fácil. WS-I fue diseñado para abordar los problemas iniciales de interoperabilidad que sufrieron las primeras implementaciones de SOAP.

Los problemas tienden a aparecer cuando se utilizan servicios web anteriores a WS-I (por ejemplo, material codificado con rpc), o cuando se utilizan las sofisticadas extensiones de seguridad de las que WCF hace una gran cantidad. Esos se vuelven complejos y difíciles de depurar cuando salen mal.

Answer 2

Sí, en su mayor parte, aunque a veces puede ser una batalla. Tengo una serie de servicios basados ​​en estándares y algunos idiomas/bibliotecas parecen ser más fáciles que otros.

Sin embargo, no todo está feliz en tierra SOAP. Una biblioteca especialmente traviesa (Apache Axis), por defecto compila una copia del WSDL en sus stubs ... lo cual no es extraño en sí mismo porque .net hace lo mismo ... pero el problema es que también valida el WSDL para cualquier cambio en absoluto. Y si se detecta un cambio, vomita.

Digamos que tiene un método de creación de usuario y agrega la inicial del segundo 5 meses en el futuro. Rompe el servicio para todos los consumidores que usan Axis ... incluso si NO se requiere una inicial del segundo nombre y el servicio no se preocupara si usted lo envió. Entonces, en nuestro lugar, tenemos que enviar mensajes a los clientes con meses de anticipación de agregar cualquier parámetro opcional para que puedan contratar a sus contratistas nuevamente para que simplemente recompilen el WSDL en la noche de estreno.