Introduccin a los Servicios Web

Comunicacin entre sistemas heterogneos

El sistema del departamento de Compras est en Windows/Visual Basic y requiere informacin del departamento de Contabilidad que utiliza HP-UX/Oracle. El nuevo departamento de Web requiere acceso tanto al de Contabilidad y Compras para desplegar informacin de clientes pero ste ya se encuentra en el flexible y portable lenguaje Java. Las incongruencias se hacen evidentes: desde privilegios de acceso (seguridad), representacin de datos, transacciones y otra gran gama de posibilidades. Esta comunicacin entre sistemas heterogneos presenta el siguiente problema:

Cmo interactuamos?

Qu es un Servicio Web?
Un servicio Web (Web service) es una coleccin de protocolos y estndares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programacin diferentes y ejecutadas sobre cualquier plataforma pueden utilizar los servicios Web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopcin de estndares abiertos. Las organizaciones OASIS (Organization for the Advancement of Structured Information Standards) y W3C (World Wide Web Consortium) son los comits responsables de la arquitectura y reglamentacin de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera ms exhaustiva estos estndares.

What Are Web Services?

Web services are a result of the natural evolution of the Web. There are numerous definitions given for Web services, ranging from the highly technical ones to simplistic. For example, the World Wide Web Consortium (W3C) organization, which establishes the standards for Web services, defines them as follows: A Web service is a software system identified by a URI whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols. A simpler definition, and perhaps more useful, might be: a Web service is a software application, accessible on the Web (or an enterprises intranet) through a URL, that is accessed by clients using XML-based protocols, such as Simple Object Access Protocol (SOAP) sent over accepted Internet protocols, such as HTTP. Clients access a Web service application through its interfaces and bindings, which are defined using XML artifacts, such as a Web Services Definition Language (WSDL) file.

Typical Web Service Scenarios

Interoperability requirements for the enterprise application in a heterogeneous enterprise environment. Integration requirements for those whose environments contain various Enterprise Information Systems (EISs). Types of clients expected to be supported, such as J2EE applications, wireless devices, PDAs, and so forth. Availability of tools to implement the solution. Level of sacrifice, in terms of complexity and performance, that can be tolerated to achieve the advantages (interoperability, diverse client reach, and so forth) of Web services.

Ejemplo de escenario

Estndares empleados
Web Services Protocol Stack: As se denomina al conjunto de servicios y protocolos de los servicios Web. XML: Es el formato estndar para los datos que se vayan a intercambiar. SOAP o XML-RPC: Protocolos sobre los que se establece el intercambio. Otros protocolos: los datos en XML tambin pueden enviarse de una aplicacin a otra mediante protocolos normales como HTTP, FTP, o SMTP. WSDL: Es el lenguaje de la interfaz pblica para los servicios Web. Es una descripcin basada en XML de los requisitos funcionales necesarios para establecer una comunicacin con los servicios Web. UDDI: Protocolo para publicar la informacin de los servicios Web. Permite a las aplicaciones comprobar qu servicios Web estn disponibles. WS-Security: Protocolo de seguridad aceptado como estndar por OASIS. Garantiza la autenticacin de los actores y la confidencialidad de los mensajes enviados.

 Aportan interoperabilidad entre aplicaciones de software independientemente de sus propiedades o de las plataformas sobre las que se instalen. Los servicios Web fomentan los estndares y protocolos basados en texto, que hacen ms fcil acceder a su contenido y entender su funcionamiento. Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los sistemas de seguridad firewall sin necesidad de cambiar las reglas de filtrado. Permiten que servicios y software de diferentes compaas ubicadas en diferentes lugares geogrficos puedan ser combinados fcilmente para proveer servicios integrados. Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estndar.

Ventajas

 Para realizar transacciones no pueden compararse en su grado de desarrollo con los estndares abiertos de computacin distribuida como CORBA. Su rendimiento es bajo si se compara con otros modelos de computacin 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 encuentran ni la concisin ni la eficacia de procesamiento. Al apoyarse en HTTP, pueden esquivar medidas de seguridad basadas en firewall cuyas reglas tratan de bloquear o auditar la comunicacin entre programas en ambos lados de la barrera. Existe poca informacin de servicios Web para algunos lenguajes de programacin.

Desventajas

Motivaciones para crear Servicios Web

La principal razn para usar servicios Web es que se basan en HTTP sobre TCP en el puerto 80. Dado que las organizaciones protegen sus redes mediante firewalls -que filtran y bloquean gran parte del trfico de Internet-, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los navegadores. Los servicios Web se vehiculan por este puerto, por la simple razn de que no resultan bloqueados. Otra razn es que, antes de que existiera SOAP, no haba buenas interfaces para acceder a las funcionalidades de otros ordenadores en red. Las existents eran ad hoc y poco conocidas, tales como EDI, RPC, u otras APIs. Una tercera razn por la que los servicios Web son muy prcticos es que pueden aportar gran independencia entre la aplicacin que usa el servicio Web y el propio servicio. De esta forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad ser cada vez ms importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos ms pequeos es cada da ms acusada.

In a service-oriented architecture, you have the following: A service that implements the business logic and exposes this business logic through well-defined interfaces. A registry where the service publishes its interfaces to enable clients to discover the service. Clients (including clients that may be services themselves) who discover the service using the registries and access the service directly through the exposed interfaces.

Service-oriented Architecture

Vista por capas de un Servicio Web

To enable this architecture

A mechanism that enables clients to access a service and registry. A mechanism to enable different services to register their existence with a registry and a way for clients to look up the registry of available services. Web services are based on an architecture in which the service can be located over the network and its location is transparent, which means that clients may dynamically discover a particular service they wish to use. A mechanism for services to expose well-defined interfaces and a way for clients to access those interfaces.

Diseo de un Servicio Web

En general, un servicio Web: Expone una interfaz que sus clientes usan para realizar peticiones al servicio. Publica los detalles del servicio disponible a los asociados y a clientes interesados. Recibe solicitudes de los clientes Delega las peticiones recibidas a la lgica de negocios apropiada y procesa dichas solicitudes. Formula y enva una respuesta a la peticin.

Lgicamente diseemos un WS
Un ejemplo cualquiera:

Flujo de un Web Service en JAVA

Plataformas
Servidores de aplicaciones para servicios Web: Axis y el servidor Jakarta Tomcat (de Apache) ColdFusion MX de Macromedia Java Web Services Development Pack (JWSDP) de Sun Microsystems (basado en Jakarta Tomcat) JOnAS (parte de ObjectWeb una iniciativa de cdigo abierto) Microsoft .NET Novell exteNd (basado en la plataforma J2EE) WebLogic WebSphere Zope es un servidor de aplicaciones Web orientado a objetos desarrollado en el lenguaje de programacin Python VERASTREAM de AttachmateWRQ para modernizar o integrar aplicaciones host IBM y VT Mono

Surgimiento de XMLRPC y SOAP

El surgimiento de XMLRPC/SOAP tiene sus races en la manera que son invocados procedimientos remotos en diversos sistemas de computo, por ende, es conveniente describir este proceso. Diversos Sistemas Operativos y Lenguajes Conocemos que la gran mayora de las corporaciones van conformando su sistema de informacin a travs de las necesidades que surgen en distintas reas de operacin, lo que trae aparejada una disparidad en reas que varan desde lenguajes, protocolos de comunicacin, sistemas operativos, bases de datos y otros elementos. Esta discrepancia no seria tan crtica si los diversos sistemas pudieran permanecer aislados. Sin embargo, la realidad es otra.

 Protocolo de llamada a procedimiento remoto que usa XML para codificar las llamadas y HTTP como mecanismo de transporte. Es un protocolo muy simple ya que slo define unos cuantos tipos de datos y comandos tiles, adems de una descripcin completa de corta extensin. La simplicidad del XML-RPC est en contraste con la mayora de protocolos RPC que tienen una documentacin extensa y requieren considerable soporte de software para su uso. Fue creado por la empresa UserLand Software en asociacin con Microsoft en el ao 1995. Al considerar Microsoft que era muy simple y adicionar funcionalidades y despus de varias etapas de desarrollo el estndar dej de ser sencillo y se convirti en lo que es actualmente se conoce como SOAP.

XML-RPC

 En XMLRPC siempre se habla en trminos de cliente/servidor, existe un sistema que realiza la solicitud ("el cliente") y otro que la atiende ("el servidor"), y como es de imaginarse un elemento clave en ambos puntos es el parser XML.

Arquitectura de XMLRPC

Implementaciones de XMLRPC
Aunque es posible disear desde cero cualquier tipo de cliente y/o servidor para emplear XML, hoy en da ya existen diversas implementaciones para diversos ambientes y lenguajes. Es a travs de estas implementaciones que se logran ahorrar diversas labores como configuraciones de parser, cuestiones de seguridad, integracin a servidores de paginas y otros detalles secundarios. Utilizando estas estructuras ("Frameworks"), el desarrollo se concentra en los procedimientos especficos y no en detalles comunes o secundarios que siempre son utilizados en XMLRPC. Algunas implementaciones:
XMLRPC Apache para Java XMLRPC-PHP para PHP XMLRPC-ASP para COM/Vbasic XMLRPC-C para C y C++

SOAP
El protocolo de acceso simple a objetos (Simple Object Access Protocol SOAP) es un protocolo estndar creado por Microsoft, IBM y otros, est actualmente bajo el auspicio de la W3C que define cmo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. SOAP es uno de los protocolos utilizados en los servicios Web. SOAP usa el cdigo fuente en XML. Esto es una ventaja ya que facilita su lectura por parte de humanos, pero tambin es un inconveniente dado que los mensajes resultantes son ms largos. El intercambio de mensajes se realiza mediante tecnologa de componentes (ver ingeniera de software). El trmino Object en el nombre significa que se adhiere al paradigma de la Programacin Orientada a Objetos.

Arquitectura de SOAP
SOAP esta diseado para realizar intercambios de informacin en XML en sistemas altamente distribuidos, especficamente Internet. Uno de los conceptos integrados a SOAP que no existe en XMLRPC es el uso de un lenguaje neutro, descendiente de XML, para describir las funciones/mtodos residentes en "el servidor ". Esto tiene una ventaja muy evidente: Al utilizar el lenguaje neutro WSDL para describir las funcionalidades de "el servidor", ste funciona como un contrato al que se deben apegar los distintos "clientes ". Lo anterior facilita que puedan ser escritos "clientes" en diversos lenguajes a partir de este contrato.

Tecnologa de SOAP
SOAP es un marco extensible y descentralizado que permite trabajar sobre mltiples pilas de protocolos de redes informticas. Los procedimientos de llamadas remotas pueden ser modelados en la forma de varios mensajes SOAP interactuando entre s. SOAP funciona sobre cualquier protocolo de Internet, generalmente HTTP, que es el nico homologado por el W3C. SOAP tiene como base XML, con un diseo que cumple el patrn Cabecera-Desarrollo de diseo de software, como otros muchos diseos, verbigracia HTML. La cabecera (Header) es opcional y contiene metadatos sobre enrutamiento (routing), seguridad o transacciones. El desarrollo (Body) contiene la informacin principal, que se conoce como carga til (payload). La carga til se acoge a un XML Schema propio.

Estructura del mensaje

Implementaciones de SOAP
Al igual que XMLRPC, hoy en da ya existen diversas herramientas para desarrollar aplicaciones SOAP que incluyen generadores de WSDL para distintos lenguajes, servidores UDDI y otros paquetes ms. Algunas de estas herramientas son:
Web services Pack de Sun para Java Toolkit IBM web services para Java WASP para C++ y Java Toolkit Microsoft SOAP para COM/VBasic/.Net

Modo de trabajo
A partir de WSDL se describen las funcionalidades del Web service. En XMLRPC es necesario conocer de antemano que funciones/mtodos residen en "el servidor" y no solo esto, sino que adems se requiere conocer el lenguaje en el que esta escrito "el servidor A travs de WSDL se logra aislar el lenguaje especifico del Web service. Adems del uso de WSDL, a SOAP se le ha incorporado UDDI, cuyo principio radica en el intercambio comercial entre empresas denominado "EBusiness". A travs de UDDI se logra concentrar y publicar Web services en un directorio centralizado. Adems de UDDI existen otros mecanismos para concentrar y publicar Web services tales como ebXML y WSIL.

Web Services Description Language El Lenguaje para Descripcin de Servicios Web es un formato XML que se utiliza para - WSDL de "propuesta de describir servicios Web, cuya versin 1.1 est en estado
recomendacin" por parte del W3C. WSDL describe la interfaz pblica a los servicios Web.

Est basado en XML y describe la forma de comunicacin, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catlogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan despus al protocolo concreto de red y al formato del mensaje.

Uso y Generacin de WSDL

El diseo de Clientes en SOAP generalmente es llevado acabo a partir de un archivo escrito en WSDL. Mediante una definicin de este tipo es posible distribuir los detalles del Web service en un lenguaje neutro, lo cual permite que la definicin (Cliente) sea implementada en distintos lenguajes y ambientes tales como: C++, Perl o VBasic/.NET. WSDL tambin se encuentra basado en el lenguaje XML y es generado a partir de diversas herramientas proporcionadas en distintos ambientes SOAP. El siguiente enlace describe como generar un archivo WSDL a travs de herramientas proporcionadas con Axis:
Generacin de WSDL ("Web Services Description Language")

UDDI y ebXML
Generado un archivo WSDL para nuestro Web service, podr ser accedido desde diversas plataformas y lenguajes. Existe otro eslabn crtico para desarrollos SOAP:
"Universal Description, Discovery and Integration Directory" (UDDI) o "Electronic Business XML Working Group " (ebXML).

Universal Description, Discovery, and Integration - UDDi

UDDI son las siglas del catlogo de negocios de Internet denominado Universal Description, Discovery, and Integration. El registro en el catlogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS) entroncada en el contexto de los servicios Web. El registro de un negocio en UDDI tiene tres partes: 1. Pginas blancas - direccin, contacto y otros identificadores conocidos; 2. Pginas amarillas - categorizacin industrial basada en taxonomas; y 3. Pginas verdes - informacin tcnica sobre los servicios que aportan las propias empresas. UDDI es uno de los estndares bsicos de los servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para interactuar con los servicios Web del catlogo de registros.

UDDI
Surgi con la intencin de centralizar servicios Web comunes, as como ofrecer un deposito central donde se puede acudir a realizar bsquedas de servicios Web especficos, las metodologas que han sido descritas anteriormente solamente permiten que el servicio Web sea descubierto siempre y cuando nos sea proporcionado el archivo WSDL. Ha sido desarrollado por un grupo de empresas entre las que figuran principalmente Microsoft, IBM y SAP, estas compaas as como algunos otros consorcios se encargan de mantener y ofrecer este tipo de servicios en Internet, algunos directorios de prueba que puede utilizar son los siguientes:
UDDI IBM UDDI Microsoft UDDI SAP

UDDI habilita descripcin dinmica, descubrimiento e integracin de Web services.

UDDI (2)
De esta manera si usted posee varios Web services tales como:
ofrecer estado de tiempo, cotizaciones sobre sus productos comerciales, procesamiento de transacciones financieras, etc.,

es posible publicarlos a un directorio UDDI, permitiendo que sean descubiertos en un directorio conocido y centralizado.

Este mecanismo facilita el intercambio comercial por un medio electrnico, algo que resulta difcil utilizando XMLRPC, ya que no existe una metodologa para descubrir servicios en una red como Internet. Desde luego un desarrollo con SOAP es sumamente ms complejo que con XMLRPC, debido principalmente a que se debe interactuar con tecnologas adicionales como WSDL y UDDI, pero a su vez ofrece mayor flexibilidad y potencial a escala futura.

ebXMLWeb que surgi previo a UDDI y ebXML es otro tipo de registro para servicios

que es desarrollado por la organizacin para el progreso de estndares sobre informacin estructurada ("Organization for the Advancement of Structured Information Standards OASIS) as como por la divisin de las Naciones Unidas para simplificar procedimientos y prcticas en Admnistracin, Comercio y Transporte CEFACT ("United Nations Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport").
Puede consultar mayores detalles: http://www.ebxml.org

Para accesar un directorio UDDI o ebXML generalmente se utiliza un Navegador ("Netscape" o "Explorer") para dar de alta los respectivos Web services por lo que su uso es relativamente sencillo. Sin embargo, aunque la forma clsica de acceder Directorios para Web services sea un Navegador, existen otros mecanismos como JAXM ("Java API for XML Registries") que permiten acceder este tipo de directorios de una manera programtica.

Web Service Inspection Language WSIL es una especificacin WSIL muy reciente iniciada por IBM y

Microsoft que ofrece un mecanismo complementario a UDDI y ebXML para encontrar Web services en una red como Internet. A diferencia de UDDI donde se realizan bsquedas en un directorio centralizado, mediante WSIL se inspecciona un "WebServer" conocido, realizando una bsqueda por Web services. Es mediante archivos escritos en WSIL que se logra su descubrimiento. Es una especificacin muy reciente. Sus implementaciones son mnimas, puede consultar mayores detalles de WSIL en:
Especificacin WSIL 1.0

Razones para WSIL

Existen dos razones principales por las que surgi WSIL: Falta de Moderacin: Debido a la misma escalabilidad con la que fue diseado UDDI, existe una clara falta por moderar los Web services que son publicados en este tipo de Directorios. Lo anterior trae consigo la publicacin de "Web Services Description Language" invlidos, la duplicidad de WSDL e inclusive la publicacin de Web services no disponibles. Falta de Calidad de Servicio (QoS): Este punto aunque relacionado con el anterior se refiere a la garanta del servicio ofrecido por el proveedor del Web service, esto es: debido a que UDDI es un directorio pblico en Internet, quin garantiza que el Web service utilizado o comprado cumpla con determinados requerimientos? Esto nos lleva al antiguo concepto de negocios: Comprar o adquirir a quien ya conocemos, y es precisamente en este principio en el que esta basado WSIL.

Conclusiones
Mediante XMLRPC/SOAP se logra que el intercambio de informacin sea realizado en XML. Aqu se esta tomando el primer paso en sencillez:
la representacin de datos no posee ningn formato especfico ya que XML es texto-simple.

XMLRPC/SOAP ha sido diseado alrededor de HTTP (el protocolo utilizado en Internet), lo que no slo facilita el problema de acceso("Firewalls") que siempre es un problema en sistemas CORBA, sino que abre la puerta a la posibilidad de acceder mtodos remotos en maquinas de cualquier empresa, en el proceso automatizando intercambios de informacin de una manera transparente.

XMLRPC o SOAP: Cul es la diferencia ? XMLRPC fue el primer mecanismo que surgi para invocar

procedimientos remotos va XML, ofrece una manera muy sencilla de invocar operaciones en sistemas heterogneos a travs de una estructura simple. SOAP ("Simple Object Access Protocol") es una implementacin ms robusta para llevar acabo una intercomunicacin en XML. A diferencia de XMLRPC, a SOAP se le han integrado diversos mecanismos que le permiten operar en ambientes distribuidos mas complejos tales como:
un lenguaje neutro para su descripcin: WSDL y directorios distribuidos para su ubicacin: UDDI o ebXML.