servicio web
¿Te gustaría aprender Web Services Integracion?
Tenemos los cursos que necesitas. ¡Haz clic aquí!
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 primer lugar, que forman parte de lo que genéricamente se denomina como SOA o Arquitectura Orientada a Servicios. Esta arquitectura software se basa en el uso de servicios para resolver las necesidades de los requerimientos de los usuarios. Los servicios tal y como se ven en la arquitectura SOA se caracterizan por ofrecer un acoplamiento débil pero en donde la interoperabilidad es máxima, y para ello la definición de los servicios, operaciones y mensajes que se intercambian se definen de una manera abstracta e independiente de las plataformas. Veremos que los servicios web consiguen esto mediante el uso del protocolo SOAP y de WSDL.
- Y en segundo lugar, que los servicios web se componen de los siguientes elementos constitutivos:
- Elementos de Descubrimiento
- Elementos de Descripción
- Elementos de Formato
- Elementos de Codificación
- Elementos de Transporte
En los próximos párrafos veremos más en detalle cada uno de estos elementos.
Elemento de Descubrimiento. Que son los servidores UDDI
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:
- Páginas Blancas : Incluye la dirección, contacto y otros identificadores conocidos
- Páginas Amarillas : Incluye la categorización industrial basada en taxonomías
- Páginas Verdes : Información técnica sobre servicios que aportan las propias empresas
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.
Elemento de Descripción. Estructura de WSDL
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:
- Types : se utiliza como un mecanismo contenedor para definiciones de tipo de datos, por defecto se utiliza XMLSchema para estas definiciones apareciendo generalmente el documento de definición de tipos siguiendo al tipo que se define.
- Message: es la definición abstracta de los datos que se están comunicando. Es bastante común que parezcan varios elementos de este tipo en el documento WSDL y dependerá de los tipos de mensajes que se intercambien entre el cliente y el servicio web. Los mensajes se componen de elementos denominados «Part» que describen cada una de las piezas de las que consta el mensaje
- Port Type : se corresponde con el conjunto abstracto de operaciones admitidas. Hay cuatro tipos de puertos diferentes:
- Request-response (petición-respuesta): es una comunicación del tipo RPC en la que le cliente realiza una petición y el servidor envía la correspondiente respuesta.
- Solicit-response (solicitud-respuesta): Este puerto es contrario a la operación petición-respuesta. El servidor envía una petición y el cliente le envía de vuelta una respuesta.
- One-way (un-sentido): Comunicación del estilo documento en la que el cliente envía un mensaje pero no recibe una respuesta del servidor indicando el resultado del mensaje procesado.
- Notification (Notificación): Es la operación contraria a la operación un-sentido, en este caso el servidor envía una comunicación del estilo documento al cliente.
- Binding : sirven para la especificación del protocolo y del formato de datos para un tipo de puerto determinado. El elemento binding contiene las definiciones de la asociación de un protocolo (como SOAP) a un determinado bindingType. Las definiciones binding especifican detalles de formatos del mensaje y el protocolo.
- Port : O punto final único que se define como la combinación de un enlace y una dirección de red.
- Service : Es una colección de puntos finales relacionados.
El Protocolo SOAP
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:
- No esta asociado con ningún lenguaje: En SOAP no especifica una API determinada, por lo que la implementación se deja al lenguaje de programación, como pueden ser la plataforma .NET o Java.
- No se encuentra asociado a ningún protocolo de transporte: SOAP no describe como se deberían asociar los mensajes SOAP con HTTP. Un mensaje de SOAP no es más que un documento XML, por lo que puede transportarse utilizando cualquier protocolo capaz de transmitir texto.
- Aprovecha los estándares existentes en la industria: Por ejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar su propio sistema de tipo que ya están definidas en la especificación esquema de XML.
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>
Ventajas y desventajas de los Servicios Web
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:
- Aporta interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen.
- Los servicios web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento.
- Al apoyarse en HTTP, los servicios web pueden aprovecharse de los sistemas de seguridad sin necesidad de cambiar las reglas de filtrado.
- Permiten que servicios y software de diferentes compañías ubicadas en diferentes lugares geográficos puedan ser combinados fácilmente para proveer servicios integrados.
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:
- Para realizar transacciones no pueden compararse en su grado de desarrollo con los estándares abiertos de computación distribuida como CORBA.
- Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI, CORBA, o DCOM. Es uno de los inconvenientes derivados de adoptar un formato basado en texto. Y es que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento.
- Existe poca información de servicios web para algunos lenguajes de programación
La importancia del XML
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:
- Cualquier documento y cualquier tipo de dato puede expresarse como un documento XML, de este modo se pueden definir los datos independientemente del lenguaje o plataforma siendo un formato universal para el intercambio de datos. Cualquiera que lo desee puede crear un documento XML conforme a una DTD o XML Schema que necesite y utilizarlo en sus aplicaciones o transacciones. Este beneficio se resume generalmente diciendo que XML es un lenguaje abierto.
- Es auto descriptivo, se almacenan datos y la estructura de los mismos. Resulta muy fácil entender un documento XML echando simplemente un vistazo al mismo. Dicho de otra forma, XML es un metalenguaje .
- Es fácilmente compartible a través de la red, los ficheros XML son ficheros de texto, cualquier plataforma es capaz de operar con ellos.
- Se basa en el uso de Unicode, lo que permite crear documentos para cualquier idioma.
- Al hacer uso de los DTDs o XML Schema se pueden validar, lo que resulta muy útil cuando realizamos transacciones.
- Permite la integración tanto de datos estructurados (como las tablas relacionales) y poco estructurados (como los documentos)
- Finalmente XML es un lenguaje neutro, entendiendo por neutro que le es independiente el mecanismo de presentación que se utilice para mostrar los datos del mismo, lo que facilita aun más su interoperabilidad entre dispositivos de distinto tipo (por ejemplo la web vista desde un navegador y vista a través del móvil)
Creando Servicios Web en .NET
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.
El entorno de trabajo
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.
Creando el Servicio Web
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.
Invocando al Servicio Web Creado
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».
Un ejemplo de Interoperabilidad
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.
- Paso 1 : Descargamos Eclipse 3.2 desde la página web http://www.eclipse.org, la versión 3.2 es la última versión disponible de esta popular herramienta de programación, originalmente para desarrollos Java y ahora extendida para C++. La versión 3.2 de nombre Calipso lleva unos asistentes que permiten crear aplicaciones clientes que hagan uso de servicios web existentes, ahora veremos como. La instalación de la aplicación es tan sencilla como descomprimir el fichero zip descargado en la ruta que más os guste.
- Paso 2 : Para ejecutar un cliente de prueba Java, necesitaremos configurar un servidor en Eclipse, el servidor que vamos a configurar es Tomcat, que podéis descargar desde la página web de Apache. La instalación de Tomcat tampoco tiene misterios basta con ejecutar el fichero descargado y seguir las opciones que se presenta en el asistente.
- Paso 3 : Creamos el servicio web de prueba tal y como hemos descrito en las secciones precedentes con Visual Web Developer Express, debemos de arrancarlo y dejarlo en funcionamiento para que la prueba funcione bien.
- Paso 4 : Arrancamos Eclipse, para ello hacemos doble clic sobre el fichero de nombre «eclipse.exe» que debe de haberse creado en el directorio en donde descomprimisteis el fichero descargado.
- Paso 5 : Desde el entorno de Eclipse debemos de crear dos proyectos, uno de ellos será un proyecto de servidor que servirá para arrancar Tomcat, el otro será la aplicación cliente que invocará nuestro servicio web creado en .NET.
- Creación del Proyecto Servidor : Seleccionamos «File >> New >> Other»y seleccionamos de la carpeta «Server»la opción «Server, indicamos el tipo de servidor que queremos crear, en este caso Tomcat (debeis elegir la versión que se adecue a la que hayáis descargado) y la carpeta en donde lo hemos instalado.
- Creación del Proyecto Cliente : Igual que antes para crear el cliente lo que debemos hacer es seleccionar la opción «File >> New >> Other» y seleccionamos de la carpeta «Web Services» la opción «Web Service Client», desde esta opción accederemos a un asistente que permitirá crear nuestro cliente, en la caja de texto donde pone WSDL indicamos la ruta «http://localhost:3114/WebServiceTest/Service.asmx?WSDL» y el tipo de cliente que debemos crear es del tipo «Test Client».
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.
El futuro de los Servicios Web
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.
Los Lenguajes de Modelado de Procesos
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.
Los Lenguajes de Modelado de Servicios Web Semánticos
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.
Te invitamos a ver todos los artículos que tenemos para ti, coméntanos que tal te pareció este articulo y compártelo con más persona
¿Te gustaría aprender Web Services Integracion?
Tenemos los cursos que necesitas. ¡Haz clic aquí!
