Un servicio web, normalmente, está descrito por un documento WSDL (Web Services Description Language) como ya sabemos. En este documento, las operaciones del Servicio Web y los mensajes soportados se describen en abstracto y posteriormente se unen a un protocolo de red concreto y se asigna el formato del mensaje.
Como también sabemos o deberíamos saber, un documento WSDL típico se compone de los elementos: types, message, y portType para las definiciones abstractas, binding y service para la especificación concreta y, todos ellos, están envueltos dentro del elemento definitions. Cuando hablamos de estilos de este documento debemos escoger entre RPC y document para asignar un valor a la propiedad styles del elemento binding. Este elemento es el que actúa como enlace WSDL y que describe cómo el servicio está enlazado a un protocolo de mensajería, ya sea HTTP GET / POST, MIME, o SOAP.
Este artículo va para todos aquellos que se preguntan cómo puede hacer la comunición SOAP con tipos de datos simples y complejos. Es decir, cómo enviar-recibir parámetros mediante SOAP. Una de las cosas que todos vemos, o solemos ver, al principio cuando nos metemos en el mundo del los Servicios Web es el XML-RPC (un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP para la transmisión de mensajes) pero, si investigáis un poco, descubriréis que muchos lenguajes no se llevan muy bien que digamos con este protocolo.
Una API (Application Programming Interface o Interfaz de programación de aplicaciones) es un conjunto de funciones y métodos que ofrece una biblioteca que permite su utilización de forma remota como una capa de abstracción. Google, por ejemplo, tiene la Google SOAP Search API que permite a los desarrolladores consultar entre los millones de páginas web indexadas por Google directamente desde una aplicación cualquiera usando un Web Service, a través de los estándar SOAP y WDSL. Un Web Service o Servicio Web, por su parte, es un sistema software diseñado para soportar la interoperabilidad de máquina a máquina en una red. En el contexto de aplicaciones Web, usualmente se refiere a un conjunto de APIs que se pueden acceder a través de Internet y ejecutar en un sistema remoto que aloja el servicio solicitado. Las máquinas interactúan con el Web service utilizando unos mensajes especiales llamodos SOAP que se han de establecer previamente.
Si no sabéis mucho sobre SOAP o no habéis leído el artículo anterior Paso de Parámetros en SOAP y PHP I, os recomiendo que lo leáis para aclarar algunas ideas antes de entrar en más detalle. Un error que cometen muchos diseñadores cuando van a programar un Servicio Web es intentar entender SOAP como si de un lenguaje tradicional se tratase. Digo esto porque uno, al pensar en Arrays, imagina una lista de elementos con nombre y, generalmente, no lo ve como una estructura de datos compleja.
SOA es un paradigma de arquitectura para sistemas de información (SSII) que busca el mínimo acoplamiento entre sus componentes y que promueve su reutilización, favoreciendo la identificación de un conjunto de servicios en red y la definición de los procesos por los cuales interactúan. El conjunto de técnicas, recomendaciones y tecnologías que denominamos Service-Oriented Architecture (SOA) buscan que los nuevos SSII sean modulares, abiertos e independientes. La arquitectura que nos presenta SOA se basa en definir unos servicios que componen una capa de abstracción entre el negocio y la tecnología y, la habilidad para responder a cambios en los requisitos. Por tanto, un servicio será la unidad básica de funcionalidad en la arquitectura SOA y se definirá como un conjunto coherente de funcionalidad, autocontenido, sin estado e independiente.
Antes de nada, si no habéis leído el articulo de introducción, os invito a que lo hagáis ya que dicho artículo pone de manifiesto los conceptos previos necesarios para entender como crear o implantar un servicio web. Podéis acceder a él pinchando en el siguiente enlace: Crear un Web Service con PHP y MySQL (Introducción). La version 5 de PHP incorpora clases para la creacion de webservices y su invocacion desde clientes remotos mediante el uso de la extensión SOAP y que admite los subconjuntos de especificaciones SOAP 1.1, SOAP 1.2 y WSDL 1.1.
CEO de IslaVisual, Manager, Full Stack Analyst Developer y formador por cuenta ajena con más de 25 años de experiencia en el campo de la programación y más de 10 en el campo del diseño, UX, usabilidad web y accesibilidad web. También es escritor y compositor de música, además de presentar múltiples soft kills como la escucha activa, el trabajo en equipo, la creatividad, la resiliencia o la capacidad de aprendizaje, entre otras.
Especializado en proveer soluciones integrales de bajo coste y actividades de consultoría de Usabilidad, Accesibilidad y Experiencia de Usuario (UX), además de ofrecer asesoramiento en SEO, optimización de sistemas y páginas web, entre otras habilidades.
Consentimiento para cookies y datos
Este sitio web utiliza cookies para permitir la navegación entre páginas, procesar información de dispositivos finales, cargar imágenes desde CDNs externos (como pixabay) y extraer datos personales recopilados por Google Analytics (como objetivo analilzar el tráfico o la IP origen, entre otros).
Ten en cuenta que, al rechazar las cookies, se eliminará todo rastro dejado y se abandonará la página de manera inmediata.