INSTITUTO TECNOLOGICO INFOCAL
SISTEMAS INFORMÁTICOS
SOAP
ESTUDIANTE:
ALCAZAR LLAMPAS JASADMA
BALLIVIAN CHALLCO ALICIA
BOLO FORONDA CRISTHIAN DAVID
DOCENTE: ING. MILTON COARITE
LA PAZ- BOLIVIA
13 DE MARZO DE 2024
INDICE
I. INTRODUCCION......................................................................................................3
II. OBJETIVOS..............................................................................................................4
a. OBJETIVO GENERAL..............................................................................................4
b. OBJETIVO ESPECIFICO......................................................................................... 4
III. DESARROLLO.......................................................................................................5
A. definicion DE SOAP............................................................................................5
B. CONCEPTO SOAP.............................................................................................6
C. PARTES DE SOAP.............................................................................................6
D. OBJETIVOS DE SOAP.......................................................................................6
E. Estructura de mensajes SOAP...........................................................................8
F. Modelo de intercambio de mensajes SOAP.......................................................9
G. DIFERENCIAS ENTRE REST Y SOAP..............................................................9
H. ejemplo sencillo de mensajes SOAP................................................................10
I. Partes de un mensaje SOAP...............................................................................10
J. SERIALIZACION..................................................................................................12
K. rotocolo HTTP mediante SOAP........................................................................15
L. VENTAJAS Y DESVENTAJAS.........................................................................16
IV. conclusion............................................................................................................ 17
V. BIBLIOGRAFIA.......................................................................................................17
2
I. INTRODUCCION
En esta investigación se pretende explicar de forma general una descripción de
SOAP (Simple Object Access Protocol); donde trataremos de introducir nociones
generales del tema.Debido a que hoy en día existen diferentes arquitecturas para
realizar el desarrollo de los servicios web, lo que hace que los programadores
tengan dudas respecto a cuál de ellas es la mejor en ciertos puntos.
El desarrollo de servicios web tiene como objetivo utilizar las diferentes tecnologías
para cubrir con los requerimientos solicitados por el cliente, y para ello existen
diferentes arquitecturas que ayudaran a los programadores.
La arquitectura Soap es un mecanismo que permite exponer la información la cual
se presenta de acuerdo a modelos de empaquetado de datos modular y diversos de
mecanismos de codificación de datos. Así nos permitirá que la arquitectura SOAP
se pueda utilizar en rangos que trabajen los modelos de comunicación RPC
(Remote Procedure Call).
3
II. OBJETIVOS
A. OBJETIVO GENERAL
Analizar y evaluar la arquitectura SOAP, para el desarrollo de servicios web.
B. OBJETIVO ESPECIFICO
Comprender las características generales que presenta SOAP
Investigar su estructura y requerimientos técnicos, ventajas y desventajas de
SOAP
Demostrar un ejemplo del funcionamiento de SOAP
4
III. DESARROLLO
A. DEFINICION DE SOAP
ROZANSKI, Uwe (2009, pág. 504) manifiesta que actualmente SOAP es:
Un protocolo simple y ligero basado en XML que viaja sobre protocolos de
transporte estándar como HTTP. Bajo SOAP está un protocolo para la llamada de
un método, similar a DCOM o IIOP de CORBA. La diferencia principal es que se
trata de un archivo XML que puede crearse manualmente o generarse
automáticamente. Si se tiene que llamar un Web Service, el cliente crea un archivo
SOAP, que contienen el nombre del método a llamar y sus parámetros en texto sin
codificar. El servidor interpreta el mensaje SOAP, llama el método deseado con
los parámetros transmitidos y devuelve al Client el resultado de nuevo como un
archivo SOAP. No es necesario elaborar o interpretar uno mismo los mensajes
SOAP. Para ello existen bibliotecas completas como JAX-RPC Y JAX-WS.
CALDERON, Leidy Paola (Internet, 12/2010, 05/04/2012 17:16) considera que
SOAP es:
Un protocolo de servicios web que define la manera de comunicar dos objetos por
medio del intercambio de mensajes basados en XML facilitando en comparación
con otros protocolos la lectura de los mensajes y contando con las ventajas del
uso de XML, fue creado por Microsoft, IBM y otros y está actualmente bajo el
auspicio de la W3C. SOAP especifica el formato del mensaje que accede e invoca
a los objetos, en vez de especificar los objetos en sí. Los mensajes SOAP son
básicamente transmisiones de dirección única emisor-receptor. Además permite
establecer un protocolo de invocación de servicios remotos, basado en protocolos
estándares de Internet: HTTP para la transmisión y XML para la codificación de
datos y de igual manera es independiente de la plataforma, lenguaje de desarrollo
e implementación.
Un mensaje SOAP es un documento XML que consta de los siguientes elementos:
Envelope (sobre): define un marco de referencia general para expresar que
es lo que contiene el mensaje, quien debe recibirlo, y si es opcional u
obligatorio.
Header (cabecera): es opcional y contiene meta información referente al
mensaje, contiene la información referente del receptor y un conjunto de
opciones de entrega.
Body (cuerpo): contiene la información de la llamada y de la respuesta.
SOAP es un protocolo simple y ligero que se utiliza en los servicios web para
5
definir la comunicación de los objetos a través del intercambio de mensajes
basados en XML y para interpretar los mensajes SOAP hay algunas
herramientas que ayudan con esta labor.
B. CONCEPTO SOAP
La funcionalidad que aporta SOAP es la de proporcionar un mecanismo simple y
ligero de intercambio de información entre dos puntos usando el lenguaje XML.
SOAP no es más que un mecanismo sencillo de expresar la información mediante
un modelo de empaquetado de datos modular y una serie de mecanismos de
codificación de datos. Esto permite que SOAP sea utilizado en un amplio rango de
servidores de aplicaciones que trabajen mediante el modelo de comunicación RPC
(Remote Procedure Call).
Protocolo Simple de Acceso a Objetos. Se basa en XML y permite la interacción
entre varios dispositivos y que tiene la capacidad de transmitir información
compleja a través de los protocolos de la capa de aplicación del modelo TCP/IP.
Su estructura es sencilla, se compone de dos capas header (cabecera) que
contiene la información de transmisión del mensaje a nivel de red. El body
(cuerpo) que contiene la especicación del mensaje que irá a ser consumido por el
servicio web.
C. PARTES DE SOAP
El SOAP envelope que define el marco de trabajo que determina qué se
puede introducir en un mensaje, quién debería hacerlo y si esa operación
es opcional u obligatoria.
Las reglas de codificación SOAP que definen el mecanismo de serialización
que será usado para encapsular en los mensajes los distintos tipos de
datos.
La representación SOAP RPC que define un modo de funcionamiento a la
hora de realizar llamadas a procedimientos remotos y la obtención de sus
resultados.
D. OBJETIVOS DE SOAP
A la hora de realizar el diseño de SOAP se han tenido en cuenta una serie de
consideraciones con el fin de cumplir una serie de objetivos claros, objetivos que
le darán el potencial que reside en SOAP y que le harán tan atractivo. Éstos son:
Establecer un protocolo estándar de invocación a servicios remotos que
esté basado en protocolos estándares de uso frecuente en Internet, como
son HTTP (Hiper Text Transport Protocol) para la transmisión y XML
(eXtensible Markup Language) para la codificación de los datos.
6
Independencia de plataforma hardware, lenguaje de programación e
implementación del servicio Web.
SOAP es un protocolo extremadamente útil, ya que el protocolo de comunicación
HTTP es el empleado para la conexión sobre Internet, por lo que se garantiza que
cualquier cliente con un navegador estándar pueda conectarse con un servidor
remoto. Además, los datos en la transmisión se empaquetan o serializan con el
lenguaje XML, que se ha convertido en algo imprescindible en el intercambio de
datos ya que es capaz de salvar las incompatibilidades que existían en el resto de
protocolos de representación de datos de la red.
Por otra parte, los servidores Web pueden procesar las peticiones de usuario
empleando tecnologías tales como Servlets, páginas ASP (Active Server Pages),
páginas JSP (Java Server Pages) o sencillamente un servidor de aplicaciones con
invocación de objetos mediante CORBA, COM o EJB.
Un ejemplo típico de diseño de un servicio Web utilizando las ventajas de SOAP
podría ser el siguiente:
La especificación SOAP indica que las aplicaciones deben ser independientes del
lenguaje de desarrollo, por lo que las aplicaciones cliente y servidor pueden estar
escritas con HTML, DHTML, Java, Visual Basic o cualquier otra herramienta o
lenguaje disponibles.
7
E. ESTRUCTURA DE MENSAJES SOAP
• Envoltorio: todo mensaje SOAP tiene como raíz un elemento envoltorio en
el cual se indica la versión de mensaje que se utiliza. Dicha versión se
exterioriza por medio de XML namespace.
En el caso de la versión SOAP 1.1 la uri es:
http://schemas.xmlsoap.org/soap/envelope/ mientras que en SOAP 1.2 la
URI es: http://www.w3.org/2001/09/soap-envelope.
• Cabecera: El protocolo incorpora dos atributos dentro de la cabecera del
mensaje. Estos son Actor y MustUnderstand.
o Actor: El atributo actor es una URI utilizada para indicar el primer
elemento de la aplicación SOAP que procesa el mensaje. Cuando un
mensaje viaja desde su origen a su destino, puede que pase por
varios nodos intermediarios formando lo que se llama un message
path hasta llegar al destino. Los nodos intermediarios son capaces
de recibir y forwardear los mensajes SOAP. Cada nodo dentro del
message path se identifica por una URI. En caso de omitirse este
atributo, el destino último será el receptor.
o MustUnderstand: Especifica si la cabecera del mensaje es opcional
u obligatoria. Si el valor está seteado como verdadero (true),
entonces quien recibe el mensaje debe entenderlo y procesarlo.
Caso contrario devolverá un error.
Dentro de la cabecera del mensaje se puede incorporar información
adicional a ser transferida como por ejemplo, una firma digital en el caso
de los Servicios Web protegidos.
8
• Cuerpo: Dentro del cuerpo del mensaje se encuentra la información para
ser procesada por el receptor del mismo.
• Error: El elemento de error será incluido en el cuerpo del mensaje en caso
de que se produzca una falla. El protocolo define cuatro mensajes de
errores pero también se le permite definir al programador sus propios
errores.
Para que la información que se transmiten entre los diferentes sistemas pueda ser
interpretada de igual manera por cada uno de ellos, se utiliza un conjunto de
reglas de codificación de tipos de datos. Los mensajes SOAP utilizan la
especificación definida por XML para la declaración de tipos. Aún así, también
define su propio conjunto de tipos para definir constructores no estandarizados por
XML como es el caso de los arreglos.
F. MODELO DE INTERCAMBIO DE MENSAJES SOAP
El intercambio SOAP es un Servicio Web diseñado para estar ubicado entre el
consumidor del servicio y el proveedor. Este conjunto de intermediarios por el cual
pasa un mensaje SOAP es denominado message path. A su vez cada
intermediario a lo largo de ese camino se conoce como actor.
La construcción del camino por el cual pasa un mensaje SOAP es realizada por el
protocolo WS-ROUTING. Lo que hace SOAP es determinar que partes del
mensaje deben ser procesadas por cada actor dentro del message path. El cual
estará indicado por el valor del atributo actor.
G. DIFERENCIAS ENTRE REST Y SOAP
Las principales diferencias en el funcionamiento de ambos son:
• SOAP es un estilo de arquitectura orientado a RPC, mientras que para
REST solamente existen los métodos de HTTP y está orientado a recursos.
• REST no permite el uso estricto de “sesión” puesto que por definición es sin
estado, mientras que para SOAP, al ser orientado a RPC, los servicios Web
crean sesiones para invocar a los métodos remotos.
• SOAP utiliza HTTP como un túnel por el que pasa sus mensajes, se vale de
XML para encapsular datos y funciones en los mensajes. Si dibujásemos
una pila de protocolos, SOAP iría justo encima de HTTP, mientras que
REST propone HTTP como nivel de aplicación.
9
H. EJEMPLO SENCILLO DE MENSAJES SOAP
Supongamos que tenemos un servicio Web el cual contiene una relación de
productos junto con una serie de características de estos, y supongamos que le
queremos hacer una consulta acerca del precio de uno de los productos cuyo
código es RHAT. El código relativo a la petición de consulta en lenguaje SOAP
sería:
Como respuesta a esta petición vendría de vuelta el siguiente mensaje en el que
se le dice que el precio del producto pedido es 4.12:
I. PARTES DE UN MENSAJE SOAP
Un mensaje SOAP no es más que un documento en formato XML que está
constituido por tres partes bien definidas que son: el SOAP envelope, el SOAP
header de carácter opcional y el SOAP body. Cada uno de estos elementos
contiene lo siguiente:
10
El envelope es el elemento más importante y de mayor jerarquía dentro del
documento XML y representa al mensaje que lleva almacenado dicho
documento.
El header es un mecanismo genérico que se utiliza para añadir
características adicionales al mensaje SOAP. El modo en la que se añadan
cada uno de los campos dependerá exclusivamente del servicio
implementado entre cliente y servidor, de forma que cliente y servidor
deberán estar de acuerdo con la jerarquía con la que se hayan añadido los
distintos campos. De esta forma será sencillo separar entre sí los distintos
datos a transmitir dentro del mensaje.
El body es un contenedor de información en el cual se almacenarán los
datos que se quieran transmitir de lado a lado de la comunicación. Dentro
de este campo, SOAP define un elemento de uso opcional denominado
Fault utilizado en los mensajes de respuesta para indicar al cliente algún
error ocurrido en el servidor.
Un ejemplo de uso del header, donde se indica un cierto parámetro útil para el
servicio Web que le indica como debe procesar el mensaje sería:
Un ejemplo de uso del nuevo elemento body sería el siguiente, en el que se ha
detectado un error en la aplicación que corre sobre el servidor que provoca que no
opere convenientemente, por lo que se le indica al cliente:
11
El atributo encodingStyle se utiliza para indicar las reglas de serialización
utilizadas en el mensaje SOAP. No existe un formato de codificación por defecto,
sino que existen una serie de posibles formatos a utilizar. El valor de este atributo
es una lista ordenada de una o más URIs que identifican la regla o reglas de
serialización que pueden ser utilizadas en el mensaje, en el orden en el que se
han de aplicar.
De entre todas las posibles, las más utilizadas son:
• http://schemas.xmlsoap.org/soap/encoding/
• http://my.host/encoding/restricted http://my.host/encoding/.
• Todo mensaje SOAP debe tener un elemento Envelope asociado a la
dirección de red http://schemas.xmlsoap.org/soap/envelope/. Si un mensaje
recibido por una aplicación SOAP contiene en este elemento un valor
distinto al anterior la aplicación trataría dicho mensaje como erróneo.
J. SERIALIZACION
A la hora de introducir los datos en un mensaje SOAP existen una serie de normas
a tener en cuenta. De esta forma SOAP define una serie de tipos básicos que
serán empaquetados de forma directa y una serie de mecanismos para
empaquetar tipos complejos y estructurados formados por elementos simples.
12
En un inicio, SOAP consideró un conjunto de tipos como tipos simples con el fin
de realizar un mapeo directo entre el propio documento SOAP y tipos básicos de
Java.
Además de todos estos tipos sencillos, SOAP implementa una serie de
mecanismos para serializar tipos complejos con elementos simples en su interior.
De esta forma tenemos:
• Structs
Un struct no es más que un elemento que contiene un conjunto de elementos hijos
almacenados cada uno de ellos en un campo propio. Un ejemplo podría ser:
En términos de Java tendríamos un objeto de tipo Quote dentro del cual hay dos
elementos sencillos: uno de tipo String llamado Symbol y el otro de tipo double y
de nombre Price. Es decir:
• Arrays
Un array en un mensaje SOAP es representado mediante un elemento cuyo tipo
es SOAP-ENC:Array.
13
Aunque en Java sea obligatorio que dentro de un array haya únicamente
elementos del mismo tipo, SOAP no presenta esta restricción, sino que es posible
albergar elementos de distintos tipos, así un ejemplo sería:
Si quisiésemos restringir explícitamente el tipo de los elementos almacenados en
el array podríamos hacerlo de la forma:
En SOAP también es posible implementar arrays bidimensionales, incluso arrays
que almacenan strings. Un ejemplo de esto sería:
Este mismo Array que hemos explicado su realización en SOAP, en tecnología
Java sería de la manera:
O un ejemplo algo más complicado sería un Array que contiene a su vez dos
arrays cada uno de los cuales contiene a su vez un Array de Strings:
14
K. ROTOCOLO HTTP MEDIANTE SOAP
Una de las funcionalidades con las que cuenta SOAP y que lo hace
extremadamente atractivo es el envío de mensajes SOAP vía protocolo HTTP,
todo ello realizado de forma directa por medio de las librerías de SOAP. Este
hecho provoca que existen ciertas diferencias entre un mensaje SOAP normal y
uno enviado haciendo uso del protocolo HTTP.
De esta forma deben cumplirse dos aspectos:
• El HTTP header del mensaje de petición al servicio Web debe contener un
campo SOAPAction. El campo SOAPAction alerta a los servidores Web y
firewalls por los que pase de que el mensaje contiene documento SOAP,
esto facilita a dichos firewalls el filtrado de las peticiones SOAP sin
necesidad de tener que explorar el contenido del body del mensaje.
• Si la petición SOAP al servicio Web falla, el servidor debe devolver en el
mensaje de respuesta un error del tipo HTTP 500 Internal Server Error en
vez de un 200 OK que se envía cuando todo ha ido bien.
Un ejemplo de todo esto sería el siguiente extracto de código en el que lanza una
petición HTTP de tipo POST contra un Servlet que corre en la dirección Web
www.ibiblio.org bajo el control del usuario de nombre elharo:
15
El servidor envía la respuesta de vuelta al cliente y después cierra la conexión.
Como cualquier otra respuesta HTTP el mensaje SOAP empieza con el código de
retorno HTTP. Suponiendo que la petición tuvo éxito y no ocurrió ningún error en
el servidor, el mensaje de respuesta sería:
L. VENTAJAS Y DESVENTAJAS
Ventajas
Aportan interoperabilidad entre aplicaciones de software
independientemente de sus propiedades o de las plataformas sobre las que
seinstalen.
Los servicios Web fomentan los estándares y protocolos basados en texto,
que hacen más fácil acceder a su contenido y entender su funcionamiento.
16
Permiten que servicios y software de diferentes compañías ubicadas en
diferentes lugares geográficos puedan sercombinados fácilmente para
proveer servicios integrados.
Basado en estándares
Desventajas
Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en
firewall cuyas reglas tratan de bloquear
La comunicación entre programas.
Existe poca información de servicios web para algunos lenguajes de
programación
No es la solución a todos los problemas
Relativamente nuevo, algunos estándares no definidos
Dependencia de la disponibilidad de servidores y comunicaciones
IV. CONCLUSION
Debido a las investigaciones realizadas los desarrolladores tienen como
conclusión que la arquitectura SOAP es más complicada y tediosa para su
desarrollo, por esa razón se ha empezado a reemplazar esa arquitectura por la
REST que permitirá visualizar gran cantidad de información masiva.
La arquitectura SOAP permite a los programadores agrupar la dificultad del
sistema, de forma que dé lugar a las interfaces creadas automáticamente, las
cuales facilitan el diseño del sistema.
La ventaja de la arquitectura SOAP es que utiliza lenguajes de niveles altos que
permiten implementar y llamar al servicio.
V. BIBLIOGRAFIA
Aransay, A. L. (2009). Revisión de los Servicios Web SOAP/REST: Características
y Rendimiento.
Carmona, P. (2014). “Plataformas De Integración: Servicios Web Basados En
REST Y SOAP”
https://fabioalfarocc.blogspot.com/2012/08/ventajas-y-desventajas-del-soap.html
Rojas, Diego. ¿Qué es SOA – Service Oriented Architecture?. 21/12/2008 21:37,
09/04/2012 16:03, http://icomparable.blogspot.com/2008/12/qu-es-soaservice-
oriented-architecture.html
Acedo, José. Web Service: Definición, utilización y estructura del
WSDL.18/01/2012, 05/04/2012 17.40,
17
http://programacion.jias.es/2012/01/webservice-definicion-utilizacion-estructura-
del-wsdl/
18
