¿Por qué usar SOAP sobre JSON y formato de datos personalizado en una aplicación "ENTERPRISE"?

Question

Trabajo en una empresa financiera de tamaño medio donde todas nuestras aplicaciones se comunican entre sí utilizando SOAP y solo utilizamos JSON para solicitudes AJAX de sitios web.

Recientemente, en una nueva sesión de planificación de proyectos, alguien me preguntó por qué teníamos que usar SOAP para la comunicación entre aplicaciones. ¿Por qué no usar JSON o incluso el formato de datos personalizado? En mi corazón, sentí que estas alternativas no son "Enterprise-ready", pero en realidad no podía pensar en una respuesta convincente sobre por qué son malas.

Las dos únicas ventajas de SOAP que puedo pensar son herramientas y seguridad.

Los IDE modernos como Visual Studio tienen utilidad incorporada para generar clases a partir de definiciones WSDL, que no se obtienen si utiliza JSON o el formato de datos personalizado. En términos de seguridad, SOAP tiene estándares de seguridad bien definidos que no están disponibles en otros estándares de formato de datos.

¿Qué opinas? usas JSON como el formato de intercambio de datos entre las aplicaciones?

Answer 1

en mi humilde opinión, hay una gran razón todo el mundo se pega con jabón en lugar de utilizar JSON. Con cada configuración de JSON, siempre se viene con su propia estructura de datos para cada proyecto. No me refiero a cómo se codifican y pasan los datos, sino cómo se define el formato de datos, el modelo de datos.

SOAP tiene una manera madura de especificar que los datos estarán en la forma Cart es una colección de Productos y cada producto puede tener estos atributos, etc. Un documento WSDL bien elaborado realmente tiene esto clavado. Diablos, es una especificación W3C.

JSON tiene formas similares de la especificación de esta estructura de datos. Una clase de JavaScript viene a la mente como la forma más común de hacer esto.Una clase de JavaScript no es realmente una estructura de datos de ninguna manera agnóstica, bien establecida y ampliamente utilizada. Diablos, JavaScript realmente solo se ejecuta en un entorno, el navegador.

En resumen, SOAP como una forma de especificar la estructura de datos en un documento madurado con formato (WSDL). JSON no.

ACTUALIZACIÓN: Tengo que decir que me sorprende el número de votos atrasados ​​que ha recibido esta respuesta a lo largo de los años, dada su precisión en el momento. No pretendo odiar en JSON, pero después de reading a recent article, sigo manteniendo mis puntos anteriores. Mientras tanto, JSON-RPC parece estar prácticamente abandonado desde una perspectiva de formato estandarizado (versión 2.0, una propuesta de 2010) y ningún otro protocolo JSON aparentemente cercano al nivel de estandarización de SOAP. (Personalmente, esto no me ha impedido adoptar JSON-RPC 2.0 en entornos de producción. Nunca lo usaría en una propuesta para una empresa de Fortune 500).

Para ser claros, desde una perspectiva de uso interno, JSON es genial. Ligero. Rápido. Ampliamente utilizado. Razonablemente humanamente legible. Pero para la empresa, donde las corrientes de datos múltiples se combinan con frecuencia. Y la especificación de formato de datos entre docenas de departamentos es necesaria. XML es el líder establecido.

Answer 2

La razón para JSON es la simplicidad. Es fácil de leer, fácil de entender, tiene poca sobrecarga y tiene implementaciones en casi todos los idiomas.

Para llamar a algo "empresa" capaz es un poco loco, en mi humilde opinión. Es solo un formato de intercambio de datos. Ya sea SOAP, XML, JSON, lo que sea, es solo un formato de comunicación.

Tooling es agradable, lo reconozco; las clases autogeneradas son geniales. Pero, por otro lado, obtienes un lote de flexibilidad cuando administras tus clases a mano y, en general, no es tan difícil de hacer.

La seguridad es un tema que no en mi mente. Su formato de datos debe tener (de nuevo, en mi humilde opinión) nada que ver con su seguridad. Eso necesita estar en un nivel diferente por completo. Si bien SOAP tiene algunas extensiones de seguridad, etc., creo que, en su mayor parte, proporcionan mucha complejidad innecesaria. ¿Has intentado alguna vez leer algunas de las especificaciones para WS-Security? Yikes. ¿Qué tal si solo usas JSON + HTTPS? Es fácil, todo el mundo lo admite y funciona como un campeón ...

Ahora bien, eso no quiere decir que sea la solución correcta para cada problema, pero si solo buscas intercambio de datos, estoy vendido.

Personalmente, me encanta JSON como formato, y lo uso todo el tiempo.

Answer 3

JSON implica más esfuerzo que SOAP XML, pero normalmente produce paquetes mucho más pequeños y, por lo tanto, es más escalable. También es (en mi opinión subjetiva) mucho más fácil de leer, durante la depuración, olfateando el alambre, etc.

Answer 4

Una razón importante tiene nada por razones técnicas.

Una gran cantidad de sistemas "empresariales" se están vendiendo a grandes clientes "empresariales". El cliente exige SOAP y eso es lo que obtienen.

¿Cuáles son sus razones? A veces es muy pragmático: su equipo está familiarizado con SOAP y tienen muchos servicios SOAP existentes (y este equipo mantendrá el producto una vez entregado). A veces no lo es: lo leen en algún artículo y se hacen una idea.

Answer 5

No utilizaría SOAP a menos que los datos sean grandes o su estructura sea compleja. El JSON, AJAX, PHP o incluso el REST están bien.

Answer 6

Estoy usando SOAP para comunicarme desde un JavaEE (Jboss Ejb 3.1 @WebService) Backend al MS C# Winforms.

Quizás en el futuro habrá SOAP (versión X) que utilizará JSON comprimido como formato de intercambio de datos que lo hará rápido e ideal.

1. Restful es bueno para el intercambio de datos simple;
2. Ideal para javascript Solicitud de Ajax en una página web interactiva.