![Cerrar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
¿Qué son los servicios web?
Comencemos con una idea general de lo que son los servicios web, y por qué son importantes para el desarrollo de software.
Después de todo ¿cuál es el problema?
Si usted no se hubiese cansado de escuchar todo tipo de información acerca de la arquitectura orientada a los servicios (SOA) y los servicios web, no estaría aquí, entonces la pregunta es ¿por qué tanto problema con esto? La respuesta es que se trata de algo importante porque es un cambio de paradigma en la forma en que las aplicaciones se comunican entre ellas. Las SOAs existen desde hace muchísimo tiempo. Al principio se trataba mayormente de aplicaciones middleware en las que un único tipo de middleware posee, como mínimo, los dos extremos del cable. Por otra parte, los servicios web, están compuestos por un grupo de estándares que tratan de posibilitar que diversos sistemas puedan comunicarse, sin la necesidad de un middleware en particular, de lenguaje de programación, o incluso de un sistema operativo. Veamos la progresión desde donde comenzamos hasta llegar a ahora.
Al principio, fueron las computadoras. Y fue algo bueno. Las computadoras hacían tareas aparentemente milagrosas, automatizaban muchas cosas que la gente hacía a mano, desde cálculos complejos, para pasar a las finanzas, y a muchas otras tareas.
Pero las aplicaciones tradicionales son “silos”. La aplicación de recursos humanos no podía hablar con la de finanzas que, a su vez, no podía hablar con la aplicación de distribución. Todas estas aplicaciones tenían su propio hogar, en sus propias computadoras y, si bien eran útiles, no era una buena forma de compartir datos entre ellas. Uno tenía la opción de escribir procesos batch (por lotes) para pasar los datos de un sistema al otro, pero eso no era una sustitución de la integración en tiempo real.
El paso siguiente en nuestra cadena de evolución es la computación distribuida. La computación distribuida permitía que diferentes aplicaciones se comunicaran entre sí, aun estando en computadoras distintas. Las tecnologías tipo CORBA, NTS, y Enterprise Java Beans (EJB), proporcionaron un sistema que incluía un registro de estilos, para que las aplicaciones pudiesen encontrar componentes con los que querían interactuar, y luego llamarlos como si estuviesen ubicados en la máquina local.
Estos sistemas era compatibles mediante middleware, o más específicamente, mediante middleware orientado a mensajes, que proporcionaba los dos requisitos. Ahora se pueden crear las aplicaciones de manera tal que pueden acceder a los recursos de otros sistemas, incluso si se encuentran en ubicaciones geográficas diferentes.
Pero seguía habiendo un problema. Si bien las aplicaciones se podían comunicar a cualquier parte dentro del sistema, éste seguía siendo un sistema cerrado. Como mínimo su aplicación de cliente debía usar la misma tecnología de la aplicación del servidor. Asimismo, por regla general, los sistemas no estaban diseñados para que se accediera a ellos por fuera de la organización individual que los había creado.
El siguiente, y casi inevitable vínculo en esta cadena evolutiva son los servicios web. Basados en XML, y, en la mayoría de los casos, HTTP, los “servicios web” todavía significas muchas cosas para mucha gente, pero en este caso, hablaremos de los servicios web como el intercambio entre sistemas de mensajes basados en SOAP.
Estos mensajes se componen de XML, que es un estándar abierto basado en texto, accesible por cualquier persona desde cualquier aplicación (cualquier aplicación que no esté diseñada para aceptarlo). Esto amplía el mundo de su aplicación para que cualquier persona pueda acceder a ella en su red. (Si eso le enciende alarmas de seguridad, está bien, aprenderá cómo resolverlo en la parte cuatro de esta serie.)
El servicio web basado en SOAP implica el envío de un mensaje XML, tal como aparece en el Listado 1.
Listado 1. Servicio web basado en SOAP
<SOAPenv:Envelope
xmlns:SOAPenv="http://schemas.xmlSOAP.org/SOAP/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAPenv:Body>
<req:getNumberOfArticles xmlns:req="http://daily-moon.com/CMS/">
<req:category>classifieds</req:category>
</req:getNumberOfArticles>
</SOAPenv:Body>
</SOAPenv:Envelope>
|
Estos mensajes van de un sistema a otro, por lo general, vía HTTP. El sistema receptor interpreta el mensaje, hace lo que se supone que debe hacer, y devuelve una respuesta con la forma de otro mensaje SOAP.
Es un sistema simple, y como tal, hay muchos aspectos de la computación a nivel de empresa que no los contempla. Afortunadamente, se han tomado en cuenta muchos de estos aspectos, y tienen sus propias especificaciones para determinar la manera en que debe producirse esta transacción para incorporar muchos de los aspectos de seguridad y otros del middleware tradicional orientado a mensajes.
Sería negligente si no mencionara que SOAP no es la única forma de hacer servicios web. Existen otras formas basadas en XML para enviar mensajes entre sistemas, algunas de las cuales son adecuadas para un entorno de empresa, y otras que no lo son. Por ejemplo, Amazon fue una de las primeras empresas basadas en Web en ofrecer a su público el acceso de servicios web a su sistema. Amazon incluye un servicio basado en SOAP, pero también proporciona un servicio basado en Representational State Transfer (Transferencia de Estado Representacional, REST).
REST es un tipo de servicio web en el que el usuario simplemente accede a la URL, y la respuesta es un auténtico documento XML, como el que aparece en el Listado 2.
Listado 2. Respuesta REST
<currentArticles>
<category>classifieds</category>
<subcategory>forsale</subcategory>
<article id="888204">
<articleHeadline></articleHeadline>
<articleText>30 ft ladder, only used once. Willing to let
go for half it's worth. Has slight dent near the middle.
Harder than a human head. $150 OBO.</articleText>
</article>
<article id="888242">
<articleHeadline></articleHeadline>
<articleText>Vintage 1963 T-Bird. Less than 300 miles.
Driven by my daughter until I took it away. Serious inquires only.
555-3264 after 7 PM.</articleText>
</article>
</currentArticles>
|
No hay un formato en particular para estos mensajes. Simplemente se trata de lo que sea el dato.
Otro tipo de servicios web implica el uso de un estándar, tal como XML-RPC. En este caso, los comandos se envían a un sistema a través de XML, como aparece en el Listado 3.
Listado 3. XML-RPC
<?xml version="1.0"?>
<methodCall>
<methodName>CMS.getNumberOfArticles</methodName>
<params>
<param>
<value><string>classifieds</string></value>
</param>
<param>
<value><string>forsale</string></value>
</param>
</params>
</methodCall>
|
La respuesta viene con un formato similar.
Como usted aprenderá a usar SOAP, puede pensar que REST y XML-RPC son mucho más sencillos que un sistema basado en SOAP. Y tiene razón. De alguna manera lo son. Sin embargo, no hablamos de una aplicación sencilla para visualizar el estado del tiempo en su sitio Web. Aquí se trata de aplicaciones a nivel de empresa, y estas aplicaciones necesitan atributos a nivel de empresa, como por ejemplo seguridad, interoperatividad, etc. Estas capacidades están cubiertas por especificaciones adicionales que nacieron en torno a los servicios web basados en SOAP, lo que, a la larga, hace de SOAP una mejor opción para las aplicaciones a nivel de empresa.
Veamos algunas de estas especificaciones.
Especificaciones básicas de los servicios web
Por lo general, las especificaciones de los servicios web entran en dos categorías: especificaciones básicas de servicios web y especificaciones ampliadas de servicios web. Las especificaciones básicas son:
- SOAP: El fundamento de todos los servicios web basados en SOAP, la especificación SOAP detalla el formato de los mensajes. También detalla la forma en que las aplicaciones deben tratar determinados aspectos del mensaje, tales como los elementos del “encabezado”, lo que le permitirá crear aplicaciones en las que un mensaje pasa entre múltiples intermediarios antes de llegar a su destino final. Este tutorial abarcará la especificación SOAP.
- WDSL: Web Services Description Language (Lenguaje de descripción de los servicios web) es una especificación que detalla una forma estándar de describir un servicio web basado en SOAP, que incluye la forma que deberán tomar los mensajes, y a dónde deben ser enviados. También detalla la respuesta a ese mensaje. Combinado con las herramientas adecuadas, WSDL le permite crear de manera programática, una llamada a un servicio web sin saber en realidad lo que busca el servicio web; la aplicación puede extraer esos detalles del archivo WSDL y proporcionarle las interfaces programáticas para que las use. Nos ocuparemos de WSDL en la parte dos de esta serie.
- UDDI: Universal Description, Discovery and Integration (Descripción, Descubrimiento e Integración Universales) es un estándar que ha sufrido algunos cambios desde su concepción inicial. La idea era proporcionarle a las empresas una forma de registrar sus servicios en un registro global, y consultar ese registro global para buscar servicios que quisieran utilizar. Sin embargo, como es comprensible que muchas empresas sean algo renuentes a abrir sus sistemas a desconocidos, no se materializó este objetivo. No obstante, UDDI se afianzó como un registro interno de servicios e información de servicios; la parte tres de esta serie da detalles de su uso.
Esos son los fundamentos. También existen literalmente docenas de estándares ampliados para hacer que los servicios basados en SOAP sean más útiles.
Especificaciones ampliadas de los servicios web
De las docenas de especificaciones WS-* que andan dando vueltas, varias se destacan como particularmente útiles para la empresa. Y son:
- WS-Security (Seguridad para servicios web): Esta especificación maneja el encriptado y las firmas digitales, lo que le permitirá crear una aplicación para que los mensajes no pueden ser ‘espiados’, y donde es imposible el no rechazo. La parte cuatro de esta serie se ocupa de WS-Security.
- WS-Policy (Política de los servicios web): Esta especificación es una ampliación de WS-Security, la que le permitirá detallar de una manera más específica cómo y quiénes pueden usar un servicio web. La parte cinco de esta serie se ocupa de WS-Policy.
- WS-I: Aunque se supone que los servicios web están diseñados para tener interoperabilidad, en realidad hay bastante flexibilidad en las especificaciones de que las interpretaciones entre las distintas implementaciones pueden causar problemas. WS-I proporciona un conjunto de estándares y prácticas para prevenir ese tipo de problemas, como así también, pruebas estandarizadas para verificar problemas. WS-I es el objeto de la parte seis de esta serie.
- WS-BPEL (Lenguaje de ejecución de procesos de negocios para servicios web): un servicio único está bien, pero en la mayoría de los casos no se trata de una aplicación. Como mínimo, la computación a nivel de empresa necesita que usted cree servicios múltiples dentro de un sistema general, y WS-BPEL le proporciona el medio para especificar interacciones tales como el procesamiento bifurcado y coincidente, necesario para crear esos sistemas. La parte siete de esta serie se ocupa de WS-BPEL.
Otras especificaciones, que tienen un papel importante en los servicios web, no
están incluidas en esta serie e incluyen WS-ReliableMessaging, que le permite estar seguro de que se ha
recibido una, y solo una, copia de un mensaje, y que ha sido recibida
definitivamente; WSRF, el Web Services Resource Framework (Marco de trabajo de
recursos de servicios web), le permite usar estados en un entorno que,
básicamente, no guarda estados precedentes; y Web Services Distributed
Management (WSDM) (Gestión de servicios web distribuidos), que trata el problema
de la gestión y el uso de los servicios web. Encontrará más información acerca
de estas especificaciones y otras en Resources (Recursos) de este tutorial.
En este tutorial, usted seguirá al departamento Clasificados del diario Daily Moon a medida que investigan cómo integrar sus propios sistemas con la interfaz basada en servicios web que usa el sistema de gestión de contenidos. Usted creará una aplicación que crea un mensaje basado en SOAP, lo envía al servicio, y recibe una respuesta. Una vez que lo haya hecho, verá cómo crear un servicio que responda solicitudes y envíe una respuesta propia. Esto lo hará mediante la creación de aplicaciones Java, con un servidor de aplicaciones y sin él.
