¿Qué son los servicios web? Architectura, tipos, ejemplo

¿Cómo funcionan los servicios web?

El diagrama anterior muestra una vista muy simplista de cómo funcionaría realmente un servicio web. El cliente invocaría una serie de llamadas a servicios web mediante solicitudes a un servidor que albergaría el servicio web real.

Estas solicitudes se realizan a través de lo que se conoce como llamadas a procedimientos remotos. Las llamadas a procedimientos remotos (RPC) son llamadas realizadas a métodos alojados en el servicio web correspondiente.

Como un ejemplo, Amazon proporciona un servicio web que ofrece precios de productos vendidos en línea a través de amazon.com. La interfaz o capa de presentación puede estar en .Net o Java pero cualquiera de los lenguajes de programación tendría la capacidad de comunicarse con el servicio web.

El componente principal del diseño de un servicio web son los datos que se transfieren entre el cliente y el servidor, y eso es XML. XML (lenguaje de marcado extensible) Es una contraparte de HTML y un lenguaje intermedio fácil de entender que entienden muchos lenguajes de programación.

Entonces, cuando las aplicaciones se comunican entre sí, en realidad lo hacen en XML. Esto proporciona una plataforma común para que las aplicaciones desarrolladas en varios lenguajes de programación se comuniquen entre sí.

Los servicios web utilizan algo conocido como SOAP (Protocolo simple de acceso a objetos) para enviar datos XML entre aplicaciones. Los datos se envían a través de HTTP normal. Los datos que se envían desde el servicio web a la aplicación se denominan mensaje SOAP. El mensaje SOAP no es más que un documento XML. Dado que el documento está escrito en XML, la aplicación cliente que llama al servicio web se puede escribir en cualquier lenguaje de programación.

¿Por qué necesitas un Servicio Web?

Las aplicaciones empresariales modernas utilizan una variedad de plataformas de programación para desarrollar aplicaciones basadas en web. Algunas aplicaciones pueden desarrollarse en Java, otros en .Net, mientras que algunos otros en Angular JS, Node.js, etc.

La mayoría de las veces, estas aplicaciones heterogéneas necesitan algún tipo de comunicación entre ellas. Dado que se crean con lenguajes de desarrollo diferentes, resulta muy difícil garantizar una comunicación precisa entre ellas.

Aquí es donde entran los servicios web. Los servicios web proporcionan una plataforma común que permite múltiples aplicaciones creadas en varios lenguajes de programación tener la capacidad de comunicarse entre sí.

Tipo de servicio web

Existen principalmente dos tipos de servicios web.

1. Servicios web SOAP.
2. Servicios web RESTful.

Para que un servicio web sea completamente funcional, es necesario contar con ciertos componentes. Estos componentes deben estar presentes independientemente del lenguaje de desarrollo que se utilice para programar el servicio web.

Veamos estos componentes con más detalle.

SOAP (Protocolo simple de acceso a objetos)

SOAP se conoce como protocolo de mensajería independiente del transporte. SOAP se basa en la transferencia de datos XML como mensajes SOAP. Cada mensaje tiene algo que se conoce como documento XML. Sólo la estructura del documento XML sigue un patrón específico, pero no el contenido. La mejor parte de los servicios web y SOAP es que todo se envía a través de HTTP, que es el protocolo web estándar.

Esto es en qué consiste un mensaje SOAP

• Cada documento SOAP debe tener un elemento raíz conocido como elemento . El elemento raíz es el primer elemento de un documento XML.
• El “sobre” a su vez se divide en 2 partes. El primero es el encabezado y el siguiente es el cuerpo.
• El encabezado contiene los datos de enrutamiento, que son básicamente la información que le indica al documento XML a qué cliente debe enviarse.
• El cuerpo contendrá el mensaje real.

El siguiente diagrama muestra un ejemplo sencillo de la comunicación vía SOAP.

Discutiremos SOAP en detalle en este tutoriales.

WSDL (lenguaje de descripción de servicios web)

No se puede utilizar un servicio web si no se puede encontrar. El cliente que invoca el servicio web debe saber dónde reside realmente el servicio web.

En segundo lugar, la aplicación cliente necesita saber qué hace realmente el servicio web, para poder invocar el servicio web correcto. Esto se hace con la ayuda del WSDL, conocido como lenguaje de descripción de servicios web. El archivo WSDL es nuevamente un archivo basado en XML que básicamente le dice a la aplicación cliente qué hace el servicio web. Al utilizar el documento WSDL, la aplicación cliente podría comprender dónde se encuentra el servicio web y cómo se puede utilizar.

Ejemplo de servicio web

A continuación se proporciona un ejemplo de servicios web de un archivo WSDL.

<definitions>	
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>
     
   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>
         
		 <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

Los aspectos importantes a tener en cuenta sobre los ejemplos de declaración WSDL de servicios web anteriores son los siguientes:

1. – El parámetro de mensaje en la definición WSDL se utiliza para definir los diferentes elementos de datos para cada operación realizada por el servicio web. Por lo tanto, en los ejemplos de servicios web anteriores, tenemos 2 mensajes que se pueden intercambiar entre el servicio web y la aplicación cliente, uno es la operación “TutorialRequest” y el otro es la operación “TutorialResponse”. La operación TutorialRequest contiene un elemento llamado “TutorialID” que es del tipo cadena. De manera similar, la operación TutorialResponse contiene un elemento llamado “TutorialName” que también es del tipo cadena.
2. – En realidad, esto describe la operación que puede realizar el servicio web, que en nuestro caso se llama Tutorial. Esta operación puede recibir dos mensajes: uno es un mensaje de entrada y el otro es un mensaje de salida.
3. – Este elemento contiene el protocolo que se utiliza. Entonces, en nuestro caso, lo estamos definiendo para usar http (http://schemas.xmlsoap.org/soap/http). También especificamos otros detalles para el cuerpo de la operación, como el espacio de nombres y si el mensaje debe estar codificado.

Discutiremos “WDSL” en detalle en este tutoriales.

Universal DescriptIón, descubrimiento e integración (UDDI)

UDDI es un estándar para describir, publicar y descubrir los servicios web proporcionados por un proveedor de servicios en particular. Proporciona una especificación que ayuda a alojar la información en servicios web.

Ahora discutimos en el tema anterior sobre WSDL y cómo contiene información sobre lo que realmente hace el servicio web. Pero, ¿cómo puede una aplicación cliente localizar un archivo WSDL para comprender las diversas operaciones que ofrece un servicio web? Entonces, UDDI es la respuesta a esto y proporciona un repositorio en el que se pueden alojar los archivos WSDL. Así, la aplicación cliente tendrá acceso completo a UDDI, que actúa como una base de datos que contiene todos los archivos WSDL.

Así como un directorio telefónico tiene el nombre, dirección y número de teléfono de una persona en particular, de la misma manera el registro UDDI tendrá la información relevante para el servicio web.. Para que una aplicación cliente sepa dónde se puede encontrar.

Ventajas de los servicios web

Ya entendemos por qué surgieron los servicios web en primer lugar, que era proporcionar una plataforma que permitiera que diferentes aplicaciones se comunicaran entre sí.

Pero veamos la lista de ventajas de los servicios web para saber por qué es importante utilizarlos.

1. Exponiendo la funcionalidad empresarial en la red – Un servicio web es una unidad de código administrado que proporciona algún tipo de funcionalidad a las aplicaciones cliente o usuarios finales. Esta funcionalidad se puede invocar a través del protocolo HTTP, lo que significa que también se puede invocar a través de Internet. Hoy en día todas las aplicaciones están en Internet lo que hace más útil la finalidad de los servicios web. Eso significa que el servicio web puede estar en cualquier lugar de Internet y proporcionar la funcionalidad necesaria según sea necesario.
2. Interoperabilidad entre aplicaciones – Los servicios web permiten que varias aplicaciones se comuniquen entre sí y compartan datos y servicios entre sí. Todos los tipos de aplicaciones pueden comunicarse entre sí. Entonces, en lugar de escribir código específico que solo puedan entender aplicaciones específicas, ahora puedes escribir código genérico que puedan entender todas las aplicaciones.
3. Un protocolo estandarizado que todos entienden – Los servicios web utilizan un protocolo industrial estandarizado para la comunicación. Las cuatro capas (transporte de servicios, mensajería XML, servicio Description y capas de descubrimiento de servicios) utiliza protocolos bien definidos en la pila de protocolos de servicios web.
4. Reducción del coste de la comunicación. – Los servicios web utilizan SOAP sobre el protocolo HTTP, por lo que puede utilizar su Internet de bajo costo existente para implementar servicios web.

1. Provider – El proveedor crea el servicio web y lo pone a disposición de la aplicación cliente que quiera utilizarlo.
2. Solicitante – Un solicitante no es más que la aplicación cliente que necesita ponerse en contacto con un servicio web. La aplicación cliente puede ser .Net, Java, o cualquier otra aplicación basada en lenguaje que busque algún tipo de funcionalidad a través de un servicio web.
3. Broker – El corredor no es más que la aplicación que proporciona acceso a la UDDI. La UDDI, como se analizó en el tema anterior, permite que la aplicación cliente ubique el servicio web.

El siguiente diagrama muestra cómo interactúan entre sí el proveedor de servicios, el solicitante de servicios y el registro de servicios.

1. Publicar – Un proveedor informa al corredor (registro de servicios) sobre la existencia del servicio web utilizando la interfaz de publicación del corredor para que el servicio sea accesible para los clientes.
2. Encuentre – El solicitante consulta al corredor para localizar un servicio web publicado.
3. aglutinante – Con la información que obtuvo del corredor (registro de servicios) sobre el servicio web, el solicitante puede vincular o invocar el servicio web.

Características del servicio web

Los servicios web tienen las siguientes características especiales de comportamiento:

1. Están basados ​​en XML – Los servicios web utilizan XML para representar los datos en las capas de representación y transporte de datos. El uso de XML elimina cualquier tipo de dependencia de red, sistema operativo o plataforma, ya que XML es el lenguaje común comprendido por todos.
2. Débilmente acoplado – Un acoplamiento flexible significa que el cliente y el servicio web no están vinculados entre sí, lo que significa que, incluso si el servicio web cambia con el tiempo, no debería cambiar la forma en que el cliente llama al servicio web. La adopción de una arquitectura de acoplamiento flexible tiende a hacer que los sistemas de software sean más manejables y permite una integración más sencilla entre diferentes sistemas.
3. SyncFuncionalidad cronológica o asincrónica – SyncLa cronicidad se refiere a la vinculación del cliente a la ejecución del servicio. En las operaciones sincrónicas, el cliente esperará a que el servicio web complete una operación. Un ejemplo de esto es probablemente un escenario en el que se está realizando una operación de lectura y escritura de una base de datos. Si se leen datos de una base de datos y luego se escriben en otra, las operaciones deben realizarse de manera secuencial. Las operaciones asincrónicas permiten que un cliente invoque un servicio y luego ejecute otras funciones en paralelo. Esta es una de las técnicas más comunes y probablemente la más preferida para garantizar que otros servicios no se detengan cuando se realiza una operación en particular.
4. Capacidad para admitir llamadas a procedimientos remotos (RPC) – Los servicios web permiten a los clientes invocar procedimientos, funciones y métodos en objetos remotos utilizando un protocolo basado en XML. Los procedimientos remotos exponen los parámetros de entrada y salida que debe admitir un servicio web.
5. Admite el intercambio de documentos – Una de las principales ventajas de XML es su forma genérica de representar no sólo datos sino también documentos complejos. Estos documentos pueden ser tan simples como representar una dirección actual o tan complejos como representar un libro entero.