Probablemente uno de los aspectos que más dolores de cabeza produce a los desarrolladores de hoy en día, son los problemas de interoperabilidad que ocurren cuando tenemos que ser capaces de interconectar distintos sistemas, situación que hoy en día ocurre con una frecuencia cada vez mayor. En este artículo veremos una manera de resolver estos problemas de una manera muy elegante y potente a través del uso de los servicios web.
En este artículo aprenderás…
Lo que deberías saber…
Y es que si pensamos un poco en la evolución que ha seguido la tecnología en los últimos años, vemos que las empresas han realizado unas inversiones en lo que genéricamente se denomina como Tecnologías de la Información, o TIs, enormes y que en muchas ocasiones no han sido del todo rentabilizadas, de hecho es muy común oír hoy en día que las inversiones en TI no aportan ninguna diferencia competitiva entre las empresas, ya que el tener, por ejemplo un CRM implantado en una empresa, no significa tener una ventaja respecto a la competencia ya que a lo buen seguro también lo tendrá, lógicamente estamos suponiendo que ambas empresas han realizado un proceso de implantación correcto. Por tanto, es difícil que las empresas quieran invertir más dinero en este tipo de soluciones y por el contrario lo que van a querer es sacar partido al software que ya tienen en funcionamiento. Y esto plantea una difícil cuestión para los desarrolladores, ya que hoy en día estamos en el mundo de Internet y es necesario poner a disposición de nuestros clientes o de nuestros socios de negocio información que reside en sistemas legados, pongamos el caso de aplicaciones realizadas en entorno Hosts en donde los usuarios estaban acostumbrados a trabajar con terminales (con pantallas en blanco y negro), y ahora la información que manipulan debe estar accesible en la web o dentro de una Intranet corporativa por poner un ejemplo.
Un servicio web se define como un componente de software que se comunica con otras aplicaciones mediante mensajes en XML que se envían a través de protocolos estándares de Internet tales como el protocolo HTTP (Hypertext Transfer Protocol), de manera que en vez de retornar paginas web como respuesta, lo que se hace es devolver un mensaje de respuesta que también se encuentra formateado en XML.
Generalmente se adapta como válido que:
En los próximos párrafos veremos más en detalle cada uno de estos elementos.
Los servidores UDDI son el mecanismo estándar para catalogar los Servicios Web es a través de un mecanismo denominado UDDI (o Universal Description, Discovery and Integration). UDDI es una iniciativa industrial abierta y sirve como un registro o directorio de servicios web, de manera que en su definición han participado empresas como Microsoft, IBM, Sun, Oracle y muchas otras. La versión beta de UDDI se lanzó en diciembre de 2000, entrando en producción en mayo de 2001.
Los directorios de servicios o registro podemos encontrarlos en cualquiera de estas formas, como:
La forma en la que funciona un servidor UDDI no es muy complicada: en primer lugar debe existir algún nodo público de consulta al que podamos preguntar, respecto a esto hay que decir que algunas empresas disponen de estos nodos, por ejemplo actualmente tanto Microsoft como IBM proporcionan nodos públicos conformes a la especificación 1 del estándar UDDI, aunque es probable que otros fabricantes también pongan a disposición de los usuarios sus propios nodos. Una vez que sabemos a quien debemos preguntar, se envía un mensaje SOAP al servidor UDDI, el cual devuelve el documento WSDL asociado al Servicio Web que se quiere acceder, sobre SOAP y WSDL vamos a hablar enseguida por lo que no preocuparos porque en seguida quedará todo explicado y lo entenderéis mucho mejor, baste por ahora decir que SOAP será nuestra forma de preguntar y WSDL será la tarjeta de identificación en donde se nos indicará todo lo que debemos saber para hacer uso del servicio web.
Toda esta labor (UDDI + SOAP + WSDL) debe de hacerse de manera manual o bien mediante la programación de agentes específicos para el servicio web que se desea invocar, lo que en la mayoría de las ocasiones implica realizar un trabajo bastante pesado.
El lenguaje de descripción de servicios Web (WSDL, Web Service Description Language) es un lenguaje basado en XML y que describe un servicio Web, de manera que a través de un documento WSDL se proporciona la información necesaria al cliente para interaccionar con el servicio web. WSDL es extensible y se puede utilizar para describir, prácticamente, cualquier servicio de red. Y lo hace mediante un mecanismo muy simple que se basa en que los servicios de red se describen, de manera abstracta, como colecciones de puntos finales de comunicación o puertos capaces de intercambiar mensajes.
Fijaros que hemos dicho de manera abstracta cuando indicamos la manera de descripción de los servicios web por parte de WSDL, y esto aunque a simple vista pueda parecer poco importante, es de gran ayuda ya que tanto las operaciones (puertos) como los datos (mensajes) que se invocan e intercambian en un servicio respectivamente pueden ser reutilizables, volveremos sobre esta idea un poco más adelante, pero veamos antes cuales son los elementos estándar de un documento WSDL.
WSDL hace uso de los siguientes elementos para la definición de un servicio:
SOAP son las siglas de Simple Object Access Protocol, que deriva del protocolo creado por David Winer en 1998 (XML-RPC) . SOAP presenta una serie de ventajas muy interesantes que ha supuesto que casi la totalidad de las empresas del sector apuesten por él y que consisten en tres características, a saber:
Un mensaje SOAP se compone de lo que se denomina como sobre, el cual contiene el cuerpo del mensaje y cualquier información de cabecera que se utiliza para describir le mensaje. El elemento raíz del documento se denomina Envelope y puede contener dos sub elementos, denominados Body y Header. El elemento Header (que es opcional) contiene información sobre el mensaje, por ejemplo quien compuso el mensaje y un posible receptor del mismo, mientras que el elemento Body o cuerpo, contiene la carga de datos del mensaje.
SOAP también proporciona un patrón de mensajes estándar para facilitar el comportamiento de tipo RPC, en este comportamiento se emparejan dos mensajes para facilitar la asociación de un mensaje de petición con un mensaje de respuesta.
El mensaje de respuesta puede contener los resultados de la llamada al método o una estructura de error que debe estar bien construida.
Los siguientes son los mensajes de petición y respuesta SOAP que se enviaran y se devolverán desde el servicio web de ejemplo que estamos codificando y que muestran lo que acabamos de ver.
La petición es algo de este estilo:
POST WebServiceTest/Service.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://tempuri.org/HelloWorld" <?xml version="1.0" encoding="utf-8" ?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > <soap:Body> <HelloWorld xmlns="http://tempuri.org/" /> <soap:Body> <soap:Envelope>
Mientras que la respuesta será algo de este estilo:
HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8" ?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" > <soap:Body> <HelloWorldResponse xmlns="http://tempuri.org/" > <HelloWorldResult>string <HelloWorldResult> <HelloWorldResponse> <soap:Body> <soap:Envelope>
Ya hemos descrito que es un servicio web y cuales son los elementos que lo constituyen, vamos a resumir cuales son las ventajas y los inconvenientes que presentan.
En cuanto a las ventajas que podemos encontrar en el uso de los servicios web tenemos que:
No obstante, a pesar de estas ventajas, que resultan indudables, los servicios web también presentan algunos inconvenientes que no debemos de obviar, los más destacados son:
Como hemos visto hasta ahora, todos los elementos que usamos cuando trabajamos con servicios web se basan en el uso intensivo de XML, y es que el uso de XML aporta una serie de beneficios muy importantes que nacen de la propia naturaleza del XML como metalenguaje. Por tanto, el uso de XML en esta tecnología se justifica por:
Dado que ya tenemos claro que es un servicio web y cuales son los elementos que debemos tener en cuenta, vamos a ponernos ahora manos a la obra para ver como podemos crear un servicio web, veremos como crear el servicio web, como invocarlo desde un cliente y realizaremos un pequeño ejemplo de interoperabilidad desde otro entorno en donde también haremos la invocación.
Para la realización de los ejemplos de este artículo es necesario que nos descarguemos desde el sitio web de Microsoft la herramienta Visual Web Developer 2005 Express Edition ya que esta herramienta dispone de todo lo necesario para que podamos realizar la creación y el testeo de nuestros servicios web de una manera muy cómoda a través de diferentes opciones que van a simplificar mucho el trabajo. Veremos las herramientas de las que disponemos cuando realicemos la creación de nuestro primer ejemplo en la siguiente sección.
Vamos a ponernos entonces manos a la obra, lo primero que veremos es como realizaríamos la creación de un servicio web básico con las herramientas que pone a nuestra disposición Visual Web Developer. En este primer ejemplo crearemos el siempre socorrido "Hola Mundo" y nos detendremos en los elementos que hemos estado explicando anteriormente para que veáis como se integran de forma natural en el entorno de trabajo.
Lo primero que tenemos que hacer para crear un servicio web Visual Web Developer es crear un nuevo sitio web mediante la secuencia de acciones "File >> New Web Site", se nos debe de abrir un cuadro de diálogo en donde aparecen las diferentes soluciones de este tipo que se pueden crear, en nuestro caso nos interesa que seleccionemos la que aparece con el nombre de "ASP.NET Web Service". Fijaros que a parte de poder indicar la ruta en donde queremos que resida nuestra solución, tenemos también la posibilidad de indicar el lenguaje en el cual queremos crear el servicio, nosotros seleccionaremos C# pero podéis elegir Visual Basic si estáis más cómodos con él, los cambios que habrá que realizar en el código son mínimos. El nombre que vamos a dar a esta primera solución es "WebServiceTest"
Una vez aceptamos en el cuadro de dialogo anterior, entraremos en el entorno de desarrollo en donde tendremos seleccionado por defecto una clase de nombre "Service" la cual implementará la lógica de negocio de nuestro negocio y actuará como interface de acceso desde los clientes que necesiten acceder a la funcionalidad desde el exterior.
Rápidamente vemos que un servicio web en .NET es toda aquella clase que hereda de la clase "WebService" del namespace "System.Web.Services.WebService", esta clase dispone de un método que tiene la siguiente firma:
public string HelloWorld(){ return "Hello World"; } public function HelloWord() as string return "Hello World" end function
Intuimos rápidamente que este será un método accesible desde los clientes, y podemos deducir sin dejarnos muchas neuronas, que cualquier funcionalidad que queramos que sea accesible vía un servicio web bastará con crear un método accesor dentro de esta clase para que pueda ser invocado. Por ejemplo, si yo tengo un sistema de facturación ya implantado en mi empresa, que funciona mediante una arquitectura cliente – servidor clásica, funcionando todo ello sobre una base de datos Oracle, por poner un ejemplo, y necesito permitir que se puedan actualizar o consultar las facturas desde Internet, una posible solución sería crear las estructuras de clases necesarias para permitir exportar la funcionalidad a través de servicios web, lógicamente en función de la tecnología usada en esta aplicación el proceso será más o menos complejo pero básicamente consistirá en aplicar la filosofía que acabamos de describir.
Si realizamos la ejecución de esta aplicación veremos que Microsoft nos proporciona una página donde se muestra información sobre el servicio web creado, métodos que se puede invocar, formato de los mensajes SOAP, acceso al fichero WSDL que describe el servicio y por cada uno de los métodos del servicio un botón que permite su invocación para realizar las pruebas.
Para poder invocar un servicio web desde un cliente cualquiera en .NET, ya sea un cliente basado en Windows Forms como un cliente basado en Web Forms, debemos de proceder de la misma manera, no olvidemos que una de las características de los servicios web es que pueden ser invocados por cualquier clase de cliente.
Nosotros vamos a usar un cliente basado en Windows Forms muy sencillo, que consistirá en un formulario con un botón y una caja de texto en donde al pulsarlo se mostrará la ejecución del servicio, en este caso deberá aparecer la cadena "Hello World".
Crear la aplicación cliente no tiene mucho misterio, abrimos Visual C# Express e indicamos que queremos crear una nueva "Windows Application", que llamaremos "WebServiceClient". En el formulario que se nos crea por defecto añadiremos una caja de texto y un botón.
El siguiente paso que tenemos que seguir es añadir una referencia web al servicio web que queremos usar, para ello pulsamos sobre la opción "Project >> Add Web Referente", se nos abrirá una nueva pantalla en donde tenemos una caja de texto en donde debemos indicar el fichero WSDL del servicio web que queremos usar, que en este caso es http://localhost:3114/WebServiceTest/Service.asmx?WSDL, hacemos clic en el botón de "Go"y el entorno realizará la búsqueda del servicio web indicado de manera que en el entorno aparecerá, en caso de que el servicio exista, la relación de métodos que pueden invocarse, hecho lo cual pulsamos sobre el botón "Add Reference" de manera que el servicio web quedará referenciado en nuestro cliente y podrá usarse sin ningún problema. Una cosilla antes de seguir, el nombre como se referencia el servicio en el proyecto debemos de indicarlo en la caja de texto "Web Reference Name", nosotros lo hemos llamado "SaludoWS", y debe de aparecer en la ventana del "Solution Explorer".
Ahora ya solamente tenemos que añadir un poco de código al botón de invocación, el código que pondremos en el botón será:
SaludoWS.Service saludo = new SaludoWS.Service(); textBox1.Text = saludo.HelloWorld();
Pulsando F5 lanzaremos la aplicación y veremos que al pulsar el botón, en la caja de texto aparece el mensaje "Hello World".
Todo lo que hemos explicado resulta bastante interesante, pero podemos hacerlo aun más si hacemos uso de otra plataforma de desarrollo para que veamos que todo esto que estamos diciendo funciona de verdad. Para este ejemplo vamos a intentar invocar nuestro servicio web desde una aplicación desarrollada en Java, si seguimos los pasos que os indicamos a continuación no debería de perderse nadie.
Creado el cliente lo unico que queda por hacer es arrancarlo y probar que se realiza la invocación de forma correcta, seleccionamos la carpeta con el nombre "WebServiceProject", hacemos clic en el botón derecho y en el menú contextual que se muestra seleccionamos "Run As >> Run on server". Arrancado el servidor nos conectamos a la siguiente dirección:
http://localhost:8080/WebServiceProject/sampleServiceSoapProxy/TestClient.jsp , en donde se ha generado un cliente de prueba Java, seleccionamos el método "helloWorld"y veremos como la cadena "Hello World" aparece en nuestro navegador.
Como hemos visto las posibilidades que los servicios web brindan cara a la interoperabilidad de aplicaciones resultan sumamente interesantes ya que de una manera muy cómoda podemos reutilizar la funcionalidad que se encuentra disponible en nuestros sistemas y que a costado mucho esfuerzo desarrollar. Por otro lado, los servicios web van a ser una herramienta fundamental en el desarrollo de lo que se conoce como Web Semántica.
La Web Semántica es la evolución de la web actual, actualmente nos encontramos en lo que se conoce como la segunda generación web, o web sintáctica, que se caracteriza por ser una web de contenido dinámico pero en donde no existe ningún mecanismo que indique qué es cada una de las páginas o sitios web que existen, la Web Semántica añadirá un valor añadido, meta información que describirá las características de los sitios web que facilitará que por ejemplo las búsquedas en Internet sean mucho más precisas y cercanas al lenguaje natural.
Dentro de la Web Semántica, hay dos conceptos que con más fuerza se están imponiendo por el enorme potencial que pueden añadir, nos referimos a los lenguajes de modelado de procesos de negocio y a los lenguajes de modelado de servicios web semánticos.
Cuando hablamos de Servicios Web, indicamos que éstos formaban parte de una arquitectura de referencia llamada SOA que se basaba en resolver las necesidades de software de los usuarios mediante la utilización e invocación de servicios. En muchas ocasiones estas necesidades se verán resueltas por la invocación de un único servicio, que en sí mismo presentará toda la lógica para dar respuesta al usuario. Sin embargo, en otras ocasiones será necesario del uso de la combinación de varios de ellos para poder resolver la necesidad, y es en esta situación cuando necesitaremos hacer uso de los Lenguajes de Modelado de Procesos.
BPEL o Business Process Execution Language, es un lenguaje XML diseñado para la orquestación de Servicios Web, entendiendo como orquestación el control centralizado de la invocación de diferentes Servicios Web, con cierta lógica de negocio añadida. A través de un documento BPEL, un analista de negocio es capaz de representar la lógica asociada y los elementos con los que se verá relacionado. Estos elementos serán Servicios Web y la lógica el proceso BPEL.
Si imaginamos un flujo de negocio determinado, con una entrada A y una salida Z, este se podría componer de muchos procesos internos que se lanzarían dependiendo de valores y respuestas anteriores. BPEL sería el encargado de orquestar todo el proceso diciendo qué proceso ejecutar (Servicio Web) y en qué momento.
Business Process Execution Lenguage o BPEL es un lenguaje que se utiliza para la modelización de procesos de negocio y que ha evolucionado a partir de otros dos lenguajes WSFL y XLANG. El objetivo de BPEL es favorecer lo que se denomina en inglés como "programming in large" o "programación a lo grande", que se caracteriza porque los procesos de programación se realizan por equipos de cualquier tamaño a lo largo de una cantidad de tiempo grande. El resultado son aplicaciones cuyo código no puede entenderse y mantenerse sin una aproximación basada en divide y vencerás, en donde el énfasis a la hora de particionar el trabajo está en la creación de módulos con interacciones entre ellos especificas y precisas, lo que requiere una planificación adecuada y una documentación exacta y cuidada.
En los párrafos anteriores hemos hablado de los servicios web, y decíamos que han añadido un nuevo nivel de funcionalidad a la Web actual, siendo un primer paso para conseguir la integración de componentes de software distribuido utilizando estándares web. Sin embargo, la tecnología actual que manejan, como es el uso de SOAP, WSDL y UDDI, aunque soportan la interoperabilidad entre ellos a través de estos estándares comunes, todavía requieren de la interacción humana. Por poner un ejemplo, un programador tiene que manualmente (o mediante la codificación de un agente) buscar los servicios web apropiados a fin de combinarlos de manera útil, lo cual limita la escalabilidad y repercute negativamente en el valor que se podría obtener si esto no fuese así.
También hemos visto, que la Web Semántica, trata de resolver los problemas inherentes que hay dentro de la Web Sintáctica, por lo que la pregunta que podemos hacernos es, ¿podemos hacer algo dentro de la Web Semántica para facilitar estas labores de descubrimiento, composición e invocación de servicios haciendo que la intervención humana quede relegada al mínimo imprescindible?
Realmente si consiguiésemos este objetivo, describir los servicios web de una manera entendible por una máquina, esto tendría un gran impacto en áreas como el comercio electrónico o la integración de aplicaciones de empresa, ya que se permitiría la cooperación entre diferentes sistemas y organizaciones de una manera, podríamos decir, natural. Este paradigma que estamos proponiendo, supondría además que los servicios web proporcionados por una empresa podrían ser localizados y utilizados por otros servicios y/o aplicaciones, de la misma empresa o de otras, de manera que podríamos componer sistemas mucho más complejos.
Mediante WSMO (Web Service Modeling Ontology o Ontología para el Modelado de Servicios Web) podemos describir los aspectos relevantes de un servicio que es accesible a través de una interface de servicio web, es decir, nos permite la automatización (total o parcialmente) de las tareas (descubrimiento, selección, composición, mediación, monitorización, etc.) involucradas en la interconexión e integración de servicios web, es decir, estamos transformando un servicio web en un Servicio Web Semántico.
Conceptualmente WSMO esta basado en WSMF o Web Service Modeling Framework, pero refina y extiende este framework y desarrolla una ontología formal y un conjunto de lenguajes para este propósito.
Llegados a este punto, tenemos que terminar porque se nos acaba el espacio. Esperamos que esta introducción al mundo de los servicios web os haya resultado de interés y que haya servido para despejar las dudas sobre su utilización, posibilidades que presentan y el indudable valor que van a portar en la evolución de la Web Semántica. Hasta la próxima.
Santiago Márquez
Ingeniero en Informática por la Universidad Oberta de
Caluña (UOC) Ha participado en proyectos de diversa
índole tanto a nivel nacional como internacional.
Actualmente desarrolla su actividad profesional como jefe de
proyecto en una importante multinacional europea gestionando la
implantación de procesos ITIL.
Contacto:
Publicado en la revista MSCoder num 3 de 2007
| © 1.997- 2.007 - La Güeb de Joaquín | ||||||
| Certifico que ésta página está realizada con electrones totalmente reciclables | ||||||
|
