Por qué se considera que HTTP/SOAP es "grueso"

Question

He escuchado algunas opiniones de que la pila de llamadas del servicio web SOAP/HTTP es "gruesa" o "pesada", pero realmente no puedo precisar por qué. ¿Se consideraría grueso debido a la serialización/deserialización del sobre SOAP y el mensaje? ¿Es realmente una operación pesada?

¿O simplemente se considera "grueso" en comparación con una transferencia de datos en bruto/binario a través de una conexión fija?

¿O es alguna otra razón? ¿Alguien puede arrojar algo de luz sobre esto?

Answer 1

SOAP está diseñado para ser lo suficientemente abstracto como para usar otros transportes además de HTTP. Eso significa, entre otras cosas, que no aprovecha algunos aspectos de HTTP (principalmente el uso RESTful de URL y métodos, por ejemplo, PUT /customers/1234 o GET /customers/1234).

SOAP también evita los mecanismos TCP/IP existentes por el mismo motivo: ser independiente del transporte. De nuevo, esto significa que no puede aprovechar el transporte, como la administración de secuencias, el control de flujo, el descubrimiento de servicios (por ejemplo, accept()), una conexión en un puerto conocido significa que el servicio existe), etc.

SOAP usa XML para toda su serialización, mientras que eso significa que los datos son "legibles universalmente" con solo un analizador XML, introduce tanto texto repetitivo que realmente necesita un analizador SOAP para funcionar de manera eficiente. Y en ese punto, usted (como consumidor de software) ha perdido el beneficio de XML de todos modos; a quién le importa cómo se ve la carga útil a través del cable si necesita libSOAP para manejarlo de todos modos.

SOAP requiere WSDL para describir las interfaces. El WSDL en sí no es un problema, pero tiende a anunciarse como mucho más "dinámico" de lo que realmente es. En muchos casos, se crea un único WSDL, y el código productor/consumidor se genera automáticamente a partir de eso, y nunca cambia. En general, eso requiere muchas herramientas sin resolver realmente el problema original (cómo comunicarse entre diferentes servidores). Y dado que la mayoría de los servicios SOAP se ejecutan a través de HTTP, el problema original era ya principalmente resuelto para comenzar.

Answer 2

En primer lugar, depende mucho de cómo se implementan sus servicios (es decir, puede hacer mucho para reducir la carga útil simplemente teniendo cuidado de cómo se realizan las firmas de métodos).

Dicho esto, no solo el sobre de jabón sino el mensaje en sí mismo puede ser mucho más voluminoso en formato xml en lugar de un formato binario optimizado. Simplemente elegir la clase correcta y los nombres de los miembros pueden reducirlo mucho ...

Considere los siguientes ejemplos de retornos de métodos serializados de métodos que devuelven una colección de cosas. Simplemente elegir el nombre correcto de [serialización] para clases/contenedores y miembros puede marcar una gran diferencia en la verbosidad de la solicitud/respuesta de jabón serializado si devuelve datos repetidos (por ejemplo, listas/colecciones/matrices).

nombres cortos/Breves:

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ShortIDName> 
    <id>0</id> 
    <name>foo 0</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>1</id> 
    <name>foo 1</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>2</id> 
    <name>foo 2</name> 
    </ShortIDName> 
    ... 
</ArrayOfShortIDName> 

nombres largos:

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    ... 
</ArrayOfThisClassHasALongClassNameIDName> 

Answer 3

creo que es principalmente que el sobre SOAP añade una gran cantidad de sobrecarga para construir el mensaje, especialmente para el caso común de una solicitud simple con solo unos pocos parámetros no profundamente estructurados. Compare eso con un servicio web de estilo REST donde los parámetros simplemente se incluyen en la consulta URL.

A continuación, añadir a que la complejidad de WSDL y las implementaciones típicas de la biblioteca "de la empresa" ...

Answer 4

lo consideraba "gruesa", debido a la relativamente grande implicado de arriba con el embalaje y desembalaje de un mensaje (serializar y deserializar)

Considere un servicio web con un método web llamado Add que toma dos enteros de 32 bits. La persona que llama empaqueta dos enteros y recibe un entero único en respuesta. Donde realmente solo se transmiten 96 bits de información, la adición de los paquetes SOAP probablemente agregará alrededor de 3.000 o más bits adicionales en cada dirección. Un aumento de 30x

Se agrega a esto el rendimiento relativamente lento asociado con serializar y deserializar el mensaje en UTF-8 (o lo que sea) XML. Es cierto que es bastante rápido en estos días, pero ciertamente no es trivial.

Answer 5

La relación señal-ruido de SOAP es demasiado baja. Para una conversación simple hay demasiados gastos generales estructurales sin valor de datos; y se requiere demasiada configuración explícita (en comparación con la configuración implícita, como JSON).

No comenzó de esa manera, pero terminó siendo un póster de lo que le sucede a una buena idea cuando se involucra un comité de estándares.

Answer 6

1 - Los esquemas XML, que son una parte clave de la especificación WSDL, son realmente, realmente grandes y complicados. En la práctica, las herramientas que hacen cosas como el esquema XML del mapa a las construcciones del lenguaje de programación solo terminan soportando parte de las características del esquema XML.

2 - Las especificaciones WS- *, por ejemplo, WS-Security y WS-SecureConversation, son de nuevo grandes y complicadas. Están casi diseñados para que nadie tenga menos recursos que Microsoft o IBM alguna vez podrá implementarlos por completo.

Answer 7

SOAP y WSDL son estándares extremadamente complicados, que tienen muchas implementaciones que admiten diferentes subconjuntos de los estándares. SOAP no se adapta muy bien a una interfaz de función externa simple de la misma manera que lo hace XML-RPC. En su lugar, debe comprender los espacios de nombres XML, sobres, encabezados, WSDL, esquemas XML, etc. para producir mensajes SOAP correctos. Todo lo que necesita hacer para llamar a un servicio XML-RPC es definir y endpoint y llamar a un método en él. Por ejemplo, en Ruby:

require 'xmlrpc/client' 

server = XMLRPC::Client.new2("http://example.com/api") 
result = server.call("add", 1, 2) 

Además de XML-RPC, hay otras técnicas que también pueden ser mucho más sencillo y ligero, como XML sin formato o JSON través de HTTP (que normalmente se denomina REST, sin embargo, que implica ciertas otras consideraciones de diseño). La ventaja de algo como XML o JSON sobre HTTP es que es fácil de usar desde JavaScript o incluso una página web tonta con un envío de formulario. También se puede crear fácilmente desde la línea de comandos con herramientas como curl. Funciona con casi cualquier idioma, ya que las bibliotecas HTTP, las bibliotecas XML y las bibliotecas JSON están disponibles en casi todas partes, e incluso si un analizador JSON no está disponible, es muy fácil escribir el suyo.

Editar: debo aclarar que me refiero a la forma de SOAP conceptualmente peso pesado es, a diferencia de peso pesado que es, en términos de cantidad bruta de datos.Creo que la cantidad de datos en bruto es menos importante (aunque se suma rápidamente si necesita manejar muchas pequeñas solicitudes), mientras que lo conceptualmente pesado es bastante importante, porque eso significa que hay muchos más lugares donde algo puede salir mal, donde puede haber una incompatibilidad, etc.

Answer 8

Acepto el primer afiche, pero me gustaría añadirlo. La definición gruesa y delgada es relativa. Con transportes como JSON o REST, SOAP emergente parece pesado en la superficie para ejemplos de "hello world". Ahora, como ya sabrá, SOAP es muy pesado y WS 2.0 en general es la empresa/características robustas. JSON no es seguro de la misma manera que WS 2.0. No he oído hablar de SOAP como grueso, pero muchas tuercas que no son XML ven estas especificaciones como pesadas o gruesas. Para que quede claro, no estoy hablando en favor ni en contra, ya que ambos tienen su lugar. XML más legible y legible por humanos y por lo tanto "más grueso". La última pieza es que algunas personas ven a HTTP como un protocolo de conexión persistente pesado dado las tendencias web más recientes, como AJAX, en lugar de servir en una página grande. La sobrecarga de conexión es grande dado que realmente no hay ningún beneficio.

En resumen, ninguna razón real que no sea alguien quiere llamar a SOAP/HTTP de espesor, es todo relativo. Menos estándares son perfectos y para todos los escenarios. Si tuviera que adivinar, algún desarrollador web inteligente piensa que está siendo tan inteligente al hablar sobre cómo son las tecnologías XML y cómo es Super JSON. Cada uno tiene un lugar.