SOA y SOAP: no es lo mismo

En el mundo de la integración orientada a servicios en ocasiones es fácil equivocarse cuando estamos hablando y confundir SOA con SOAP. En un principio, se trata de acrónimos muy parecidos pero que en la realidad se trata de cosas diferentes.

Con esta breve entrada, podremos ver la diferencia entre ambos. Sabremos así distinguir entre un paradigma de arquitectura orientada a servicios y una tipología de mensaje.

 SOA: Service Oriented Architecture

Pero, realmente qué es esto de SOA. Según el manifiesto original de SOA que podemos encontrar en serviceorientation.com se trata de:

La Orientación a Servicios es un paradigma que enmarca lo que usted hace.
La Arquitectura Orientada a Servicios (SOA) es un tipo de arquitectura
que resulta de aplicar la orientación a servicios.

En un primer momento, se definieron 8 principios básicos de que debería cumplir SOA. Posteriormente, con la evolución de los servicios, se añadió la «interoperabilidad» como un nuevo principio:

1. Contratos de servicio estandarizados: para que los servicios interactuen entre ellos, estos deben de hacerlo mediante un contrato formal que describa cada servicio y defina los términos en los que será entregada la información
2. Servicios con bajo acoplamiento: los servicios deben ser diseñados para interactuar entre ellos de forma autónoma, evitando dependencias entre los mismos
3. Abstracción: contarán con una parte visible del servicio y su contrato. De esta forma, los consumidores del servicio, se abstraerán de la lógica del servicio y la tecnología utilizada en el mismo
4. Reusabilidad: todos los servicios deben ser diseñados para el soporte potencial de la reutilización de lógicas de negocio existentes. El fin de éstos servicios no es sustituir a las msimas
5. Autonomia: la lógica del servicio debe ser autónoma y no tener dependencia de la lógica de otros servicios. Un servicio debe poder ser ejecutado de manera independiente
6. Sin estado: los servicios deben ser diseñados para maximizar el bajo acoplamiento y su escalabilidad. El manejo del estado en los mismos podría impedir estas características
7. Capacidad de descubrimiento: los servicios deben contener descripciones para ser descubiertos y entendidos por humanos y los consumidores del servicio, permitiéndoles emplear la lógica descrita en los mismos
8. Composición: los servicios podrían estar a su vez compuestos por otros servicios. De esta manera se podrían definir diferentes modelos granulares de servicio. Permitiría de esta forma capas de abstración de servicios por medio de la agrupación a alto nivel de servicios complejos a bajo nivel
9. Interoperabilidad: se trata de la capacidad de poder orquestar servicios para que trabajen entre sí. La falta de alguno de los principios anteriores, repercutiría definitivamente en este último, haciendo imposible el mismo

Aquí podéis encontrar un póster con los principios de SOA resumidos (pdf)

SOAP: Simple Object Access Protocol

En la misma página que indicaba antes, podéis encontrar una referencia a las especificaciones de tecnología de los servicios o «Service Technology Specs» y dento de «WS-* Specs» encontramos (entre otros) la siguiente definición de SOAP:

Aunque originalmente se concibió como una tecnología para salvar la brecha entre las distintas plataformas de comunicación basadas en RPC*, SOAP ha evolucionado hasta convertirse en el formato de mensajería más compatible con el protocolo para su uso con servicios Web XML.

La especificación SOAP establece un formato de mensaje estándar que consiste en un documento XML capaz de alojar RPC y datos centrados en documentos. Esto facilita los modelos de intercambio de datos síncronos (petición y respuesta) así como asíncronos (impulsados por el proceso). Con WSDL estableciendo un formato de descripción de punto final estándar para aplicaciones, el formato de mensaje centrado en documentos es mucho más común.

* RPC: Remote Process Caller – Llamada a procedimiento remoto

Mensaje SOAP

Al igual que ocurre con SOA, SOAP también cosnta de 3 características principales, que son las que definen el prototipado del mensaje:

1. Extensibilidad: por medio de la aplicación de seguridad y WS-routing aplicables en el desasrrollo
2. Neutralidad: para ser utilizado sobre múltiples protocolos de transporte como HTTP, SMT, JMS o TCP
3. Independencia: permitiendo la abstación de la tecnología, para aplicar cualquier modelo de programación

Dentro del sitio W3C, podemos consultar las dos versiones de especificación existentes: SOAP 1.1 y SOAP 1.2

Ejemplo de este tipo de servicios serían los denominados JAX-WS – Java API for XML-based Web Services (usando WSLD/SOAP)

Visto todo lo anterior, podríamos resumir diciendo que SOA es un paradigma de arquitectura orientada a servicios que permite entre otros, el uso de SOAP, como forma de mensajería de la misma.

Espero que esta entrada os sea útil y recordad, SOAP en tecnología, no es un jabón 😉

Nos leemos