xml - etiquetas - ¿Por qué un mensaje SOAP tiene que ser enviado a través de HTTP?
etiquetas xml (9)
Visión general
SOAP es un protocolo de mensajería y, en pocas palabras, es solo otro lenguaje XML.
Su finalidad es el intercambio de datos a través de redes. Su preocupación es la encapsulación de estos datos y las reglas para transmitirlos y recibirlos.
HTTP es un protocolo de aplicación y los mensajes SOAP se colocan como carga útil HTTP.
Aunque existe la sobrecarga de HTTP, tiene la ventaja de que es un protocolo que está abierto a cortafuegos, bien comprendido y ampliamente soportado. Por lo tanto, los servicios web se pueden acceder y exponer a través de la tecnología ya existente.
Los mensajes SOAP generalmente se intercambian a través de HTTP . Aunque es posible utilizar otros protocolos (de aplicación), por ejemplo, SMTP o FTP , los enlaces no HTTP no están especificados por las especificaciones de SOAP y no son compatibles con WS-BP (especificación de interoperabilidad) .
Podría intercambiar mensajes SOAP a través de TCP sin procesar, pero luego tendría servicios web que no son interoperables (no son compatibles con WS-BP).
Hoy en día, el debate es por qué tienen la sobrecarga de SOAP y no se envían datos a través de HTTP ( RESTful WS ).
¿Por qué usar HTTP para SOAP ?
Intentaré abordar con más detalle la pregunta en el OP, preguntando por qué usar HTTP para SOAP:
En primer lugar, SOAP define un formato de encapsulación de datos y eso es todo.
Ahora la mayoría del tráfico en la web es a través de HTTP. HTTP es literario EN TODAS PARTES y está soportado por una infraestructura bien establecida de servidores y clientes (a saber, navegadores). Además es un protocolo muy bien entendido.
Las personas que crearon SOAP querían usar esta infraestructura lista y
- Los mensajes SOAP se diseñaron para que puedan ser canalizados a través de HTTP
- En las especificaciones, no se refieren a ningún otro enlace que no sea HTTP, sino que se refieren específicamente a HTTP como un ejemplo de transferencia.
El túnel a través de HTTP ayudaría en su rápida adopción. Debido a que la infraestructura de HTTP ya está en el lugar, las empresas no tendrían que gastar dinero extra para otro tipo de implementación. En su lugar, pueden exponer y acceder a los servicios web utilizando la tecnología ya implementada.
Específicamente en Java, un servicio web puede implementarse como un punto final de servlet o como un punto final de EJB. Por lo tanto, todos los sockets, hilos, flujos, transacciones HTTP, etc. subyacentes de la red son manejados por el contenedor y el desarrollador se enfoca solo en la carga útil XML.
Por lo tanto, una empresa tiene Tomcat o JBoss ejecutándose en el puerto 80 y el servicio web también está implementado y es accesible. No se hace ningún esfuerzo por programar en la capa de transporte y el contenedor robusto se encarga de todo lo demás.
Finalmente, el hecho de que los firewalls estén configurados para no restringir el tráfico HTTP es una tercera razón para preferir HTTP.
Dado que el tráfico HTTP generalmente está permitido, la comunicación de clientes / servidores es mucho más fácil y los servicios web pueden funcionar sin problemas de bloqueadores de seguridad de la red como resultado del túnel HTTP.
SOAP es XML = texto plano para que los firewalls puedan inspeccionar el contenido del cuerpo HTTP y bloquearlo en consecuencia. Pero en este caso, también podrían mejorarse para rechazar o aceptar SOAP según el contenido. Esta parte que parece preocuparle no está relacionada con los servicios web o SOAP, y tal vez debería comenzar un nuevo hilo sobre cómo funcionan los firewalls.
Dicho esto, el hecho de que el tráfico HTTP no esté restringido a menudo causa problemas de seguridad, ya que los firewalls son esencialmente pasados por alto, y esa es la razón por la que entran las puertas de enlace de las aplicaciones.
Pero esto no está relacionado con este post.
Resumen
Así que para resumir las razones para usar HTTP:
- HTTP es popular y exitoso
- La infraestructura HTTP está instalada, por lo que no hay costos adicionales para implementar servicios web.
- El tráfico HTTP está abierto a firewalls, por lo que no hay problemas durante el funcionamiento del servicio web como resultado de la seguridad de la red.
A continuación se muestra un mensaje de solicitud SOAP de demostración:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:SessionOrder
xmlns:t="http://example.com"
xsi:type="xsd:int" mustUnderstand="1">
5
</t:SessionOrder>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<GetStockQuote
xmlns="http://someexample.com">
<Price>MSFT</Price>
</GetStockQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Y podemos ver, este mensaje SOAP está codificado como si fuera una página web. ¿Por qué tenemos que usar el protocolo HTTP? El mensaje SOAP es solo un XML, por qué no solo usamos XML como el protocolo de intercambio de información y eliminamos los encabezados HTTP (por lo tanto, dejamos solo a HTTP).
Muchas gracias.
Actualización - 1
HTTP no es un protocolo de nivel de transporte. Es solo un protocolo de nivel de aplicación. No tiene nada que ver con el transporte. En realidad, mi pregunta es ¿cuál es el motivo de agregar cosas HTTP a un mensaje SOAP?
Básicamente, SOAP es el estándar de servicios web que contiene descripciones del mensaje en forma de XML. Esa estructura de mensaje pasará en el momento del servicio web llamado por el solicitante del servicio. En la arquitectura SOA, una de las características más importantes es la interoperabilidad, en SOA SOAP desempeña un papel masivo que pasó a través de HTTP / HTTPS y, por lo tanto, puede cruzar los firewalls, otras arquitecturas como DCOM, CORBA y RPC no cruzan el firewall.
El motivo de usar HTTP fue atravesar los cortafuegos. La mayoría de las personas de TI de la red no permiten que se abra cualquier puerto, pero por alguna razón siempre permitieron que el puerto 80 esté abierto para páginas web. Debido a que los servidores web han sido probados a lo largo de los años, es "más fácil" protegerlos. Al utilizar HTTP, tiene un conjunto existente de herramientas para tratar con un protocolo de comunicaciones.
Es responsabilidad del desarrollador elegir la capa de transferencia para el Protocolo simple de acceso a objetos. El XML no es un protocolo de red, por lo que los datos no se pueden transferir utilizando solo XML. Tiene que ser embalado en algo.
Otra razón podría ser que (si recuerdo correctamente) HTTP también se designa como un "estándar de oro" por la forma en que se debe ver / trabajar un protocolo de Internet, por lo que si tuviera que desarrollar un protocolo propio, básicamente (en una El mundo ideal al menos) termina con algo muy similar si sigues todas las RFC. Por lo tanto, ¿por qué no usar HTTP, uno de los protocolos más comunes y conocidos del mundo?
SOAP no tiene que ser enviado a través de HTTP. Los desarrolladores utilizan con más frecuencia HTTP y POST el jabón como si fuera un HTTP POST normal porque probablemente estemos más familiarizados con HTTP que otros protocolos como SMTP, agregue esto al hecho de que ya implementamos REST sobre HTTP. Por ejemplo, aquí es cómo enviamos SOAP a través del protocolo de correo electrónico SMTP. Enviando SOAP sobre SMTP
Es solo una práctica común usar HTTP
SOAP puede ser enviado a través de diferentes transportes. HTTP es solo uno de ellos.
Todos los navegadores son compatibles con HTTP y es el protocolo de Internet más utilizado. SOAP es un protocolo de comunicación que especifica el formato para enviar mensajes. RPC y CORBA tienen problemas de compatibilidad y seguridad, mientras que HTTP es compatible con todos los navegadores. Ahora que HTTP se comunica a través de TCP / IP. Un método SOAP es una solicitud / respuesta HTTP que se compila con las reglas de codificación SOAP. utilizando SOAP, un protocolo enviado a los datos de W3C puede incluirse en XML y transmitirse utilizando cualquier número de Protocolos de Internet.
también puede usar TCP y se llamó .NET Remoting antes y ahora es parte de WCF ...