POOII

Introducción a los Servicios Web

Comunicación entre sistemas heterogéneos

El sistema del departamento de Compras está en Windows/Visual Basic y requiere información del departamento de Contabilidad que utiliza HP-UX/Oracle.

El nuevo departamento de Web requiere acceso tanto al de Contabilidad y Compras para desplegar información de clientes pero éste ya se encuentra en el flexible y portable lenguaje Java.

Las incongruencias se hacen evidentes: desde privilegios de acceso (seguridad), representación de datos, transacciones y otra gran gama de posibilidades.

Esta comunicación entre sistemas heterogéneos presenta el siguiente problema:

¿Cómo interactuamos?

La solución por excelencia: CORBA, complicado y costoso

La manera en que muchas empresas aíslan sus sistemas de este tipo de problemas es mediante la arquitectura común para solicitud de objetos ("Common Object Request Broker Architecture" CORBA), donde se logra una interoperabilidad de sistemas, sin embargo, esta interoperabilidad tiene su costo.

Entrar en los detalles específicos de un diseño CORBA sería excesivo. Basta decir que antes de programar en "x" lenguaje, debe ser llevado a un diseño en un lenguaje para definición de interfaces ("Interface Definition Language“ - IDL), lo que es de por si solo una ardua labor. Posteriormente debe realizarse el diseño (vía el IDL) en el lenguaje especifico, instalar un software llamado ORB ("Object Request Broker") que aísla a los diversos sistemas y finalmente coordinar toda esta instalación.

Obviamente lo anterior requiere no solo trabajo extenso, sino un conocimiento exhausto acerca de las implicaciones que trae a un sistema CORBA: Seguridad, Transacciones, y otras consideraciones.

En el mundo de XMLRPC/SOAP todo esto se simplifica.

¿Qué es un Servicio Web? Un servicio Web (Web service) es una colección de

protocolos y estándares que sirven para intercambiar datos entre aplicaciones.

Distintas aplicaciones de software desarrolladas en lenguajes de programación 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 adopción de estándares abiertos.

Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación 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 más exhaustiva estos estándares.

Visión general - Escenario

Otros servicios Web

Servicios Webde tus socios

Capa de acceso a datos y almacenamiento

Capa de lógica de negocio de la aplicación

TuCompañia.com

Internet + XML

Otras aplicaciones

Usuarios finales

Ejemplo de escenario

Visión general - ¿Para qué sirven? Permiten interconectar

Aplicaciones Diferentes clientes

No sólo browsers Cualquier dispositivo

PC, móvil, PDA, ...

Distribución de la lógica de la aplicación Permiten una Web programable

No sólo puramente interactiva

Visión general - ¿Qué aporta? Nuevas oportunidades empresariales: facilitan

la comunicación con los socios. Ofrecen a los usuarios experiencias mucho

más personalizadas e integradas, por medio de la nueva gama de dispositivos inteligentes.

Reducen la duración del ciclo de creación. Ponen fácilmente sus propios servicios Web

XML a disponibilidad de otros.

Infraestructura - Tecnologías subyacentes

Communications: Internet

Universal Data Format: XML

Wire Format: Service Interactions: SOAP

Description: Formal Service Descriptions: WSDL

Simple, Open, Broad Industry Support

Direcory: Publish & Find Services: UDDI

Inspection: Find Services on server: DISCO

Infraestructura - Tecnologías subyacentes XML (eXtensible Markup Language)

Formato universal para documentos estructurados y datos en la Web administrado por W3C

UDDI (Universal Description, Discovery and Integration) Servicio de directorio que permite publicar y/o describir

servicios Web DISCO

Permite encontrar servicios Web en un sitio dado WSDL (Web Service Description Language)

Una gramática basada en XML que permite describir las capacidades de un servicio Web

SOAP (Simple Object Access Protocol) Protocolo ligero para el intercambio de información en

entornos distribuidos y descentralizados administrado por W3C

Estándares empleados Web Services Protocol Stack: Así se denomina al conjunto de

servicios y protocolos de los servicios Web. SOAP o XML-RPC: Protocolos sobre los que se establece el

intercambio. Otros protocolos: los datos en XML también pueden enviarse de

una aplicación a otra mediante protocolos normales como HTTP, FTP, o SMTP.

WSDL: Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web.

UDDI: Protocolo para publicar la información de los servicios Web. Permite a las aplicaciones comprobar qué servicios Web están disponibles.

WS-Security: Protocolo de seguridad aceptado como estándar por OASIS. Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.

Infraestructura - ¿Cómo acceder?Directoryhttp://www.uddi.org

UDDI

DISCO

WSDL

SOAP

Inspectionhttp://www.ibuyspy.com/ibuyspy.disco

Descriptionhttp://www.ibuyspy.com/ibuyspycs/InstantOrder.asmx?wsdl

Wire Format

Localiza un servicio

Enlace al Discovery Document (XML)

Pide un Discovery Document

Devuelve el Discovery Document (XML)

Devuelve la descripción del servicio (XML)

Devuelve la respuesta del servicio (XML)

Pide un servicio

Pide una descripción del servicio

Clie

nte

del

ser

vici

o W

eb

UD

DI

u o

troservicio

de

directo

rio

Servicio

Web

Ventajas Aportan 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 firewall 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.

Permiten la interoperabilidad entre plataformas de distintos fabricantes por medio de protocolos estándar.

Desventajas 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 encuentran ni la concisión 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 comunicación entre programas en ambos lados de la barrera.

Existe poca información de servicios Web para algunos lenguajes de programación.

Motivaciones para crear Servicios Web La principal razón 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 tráfico 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 razón de que no resultan bloqueados.

Otra razón es que, antes de que existiera SOAP, no había 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 razón por la que los servicios Web son muy prácticos es que pueden aportar gran independencia entre la aplicación 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 más importante, dado que la tendencia a construir grandes aplicaciones a partir de componentes distribuidos más pequeños es cada día más acusada.

Service-oriented ArchitectureIn 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.

Vista por capas de un Servicio Web

Diseño 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 lógica de

negocios apropiada y procesa dichas solicitudes. Formula y envía una respuesta a la petición.

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 código 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 programación 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 raíces 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 mayoría de las

corporaciones van conformando su sistema de información a través de las necesidades que surgen en distintas áreas de operación, lo que trae aparejada una disparidad en áreas que varían desde lenguajes, protocolos de comunicación, sistemas operativos, bases de datos y otros elementos. Esta discrepancia no seria tan crítica si los diversos sistemas pudieran permanecer aislados. Sin embargo, la realidad es otra.

XML-RPC 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 sólo define unos cuantos tipos de datos y comandos útiles, además de una descripción completa de corta extensión.

La simplicidad del XML-RPC está en contraste con la mayoría de protocolos RPC que tienen una documentación extensa y requieren considerable soporte de software para su uso.

Fue creado por la empresa UserLand Software en asociación con Microsoft en el año 1995. Al considerar Microsoft que era muy simple y adicionar funcionalidades y después de varias etapas de desarrollo el estándar dejó de ser sencillo y se convirtió en lo que es actualmente se conoce como SOAP.

SOAP El protocolo de acceso simple a objetos (Simple Object Access

Protocol - SOAP) es un protocolo estándar creado por Microsoft, IBM y otros, está actualmente bajo el auspicio de la W3C que define cómo 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 código fuente en XML. Esto es una ventaja ya que facilita su lectura por parte de

humanos, pero también es un inconveniente dado que los mensajes resultantes son más largos.

El intercambio de mensajes se realiza mediante tecnología de componentes (ver ingeniería de software).

El término Object en el nombre significa que se adhiere al paradigma de la Programación Orientada a Objetos.

SOAP La especificación SOAP indica cómo se deben

codificar los mensajes que circularán entre las dos aplicaciones.

Fue definido inicialmente por Microsoft, Userland Software y DevelopMentor, a día de hoy se trata de una especificación mantenida por el W3C que cuenta con el apoyo de otros fabricantes como IBM, HP, Oracle, etc.

La especificación SOAP define dos modelos de mensajes: Un mensaje que se enviará desde la aplicación cliente a la

aplicación servidor, solicitando la ejecución de un método al que se pasan una serie de parámetros.

Un mensaje que se enviará desde la aplicación servidor a la cliente, y que contendrá datos XML con los resultados de la ejecución del método solicitado.

Arquitectura de SOAP SOAP esta diseñado para realizar

intercambios de información en XML en sistemas altamente distribuidos, específicamente 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/métodos 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.

Tecnología de SOAP

SOAP es un marco extensible y descentralizado que permite trabajar sobre múltiples pilas de protocolos de redes informáticas.

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 diseño que cumple el patrón Cabecera-Desarrollo de diseño de software, como otros muchos diseños, verbigracia HTML.

La cabecera (Header) es opcional y contiene metadatos sobre enrutamiento (routing), seguridad o transacciones.

El desarrollo (Body) contiene la información 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 día ya existen

diversas herramientas para desarrollar aplicaciones SOAP que incluyen generadores de WSDL para distintos lenguajes, servidores UDDI y otros paquetes más.

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/métodos residen en "el servidor" y no solo esto, sino que además se requiere conocer el lenguaje en el que esta escrito "el servidor“

A través de WSDL se logra aislar el lenguaje especifico del Web service.

Además del uso de WSDL, a SOAP se le ha incorporado UDDI, cuyo principio radica en el intercambio comercial entre empresas denominado "E-Business".

A través de UDDI se logra concentrar y publicar Web services en un directorio centralizado.

Además de UDDI existen otros mecanismos para concentrar y publicar Web services tales como ebXML y WSIL.

Web Services Description Language - WSDL

El Lenguaje para Descripción de Servicios Web es un formato XML que se utiliza para describir servicios Web, cuya versión 1.1 está en estado de "propuesta de recomendación" por parte del W3C.

WSDL describe la interfaz pública a los servicios Web.

Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo.

Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje.

Uso y Generación de WSDL El diseño de Clientes en SOAP generalmente es

llevado acabo a partir de un archivo escrito en WSDL. Mediante una definición de este tipo es posible

distribuir los detalles del Web service en un lenguaje neutro, lo cual permite que la definición (Cliente) sea implementada en distintos lenguajes y ambientes tales como: C++, Perl o VBasic/.NET.

WSDL también 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 través de herramientas proporcionadas con Axis: Generación 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 eslabón crítico para desarrollos SOAP: "Universal Description, Discovery and Integration

Directory" (UDDI) o "Electronic Business XML Working Group " (ebXML).

Web Service Inspection Language - WSIL WSIL es una especificación 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 búsquedas en un directorio centralizado, mediante WSIL se inspecciona un "Web-Server" conocido, realizando una búsqueda por Web services. Es mediante archivos escritos en WSIL que se logra su descubrimiento.

Es una especificación muy reciente. Sus implementaciones son mínimas, puede consultar mayores detalles de WSIL en: Especificación WSIL 1.0

Razones para WSILExisten dos razones principales por las que surgió WSIL: Falta de Moderación: Debido a la misma escalabilidad con la

que fue diseñado UDDI, existe una clara falta por moderar los Web services que son publicados en este tipo de Directorios. Lo anterior trae consigo la publicación de "Web Services Description Language" inválidos, la duplicidad de WSDL e inclusive la publicación de Web services no disponibles.

Falta de Calidad de Servicio (QoS): Este punto aunque relacionado con el anterior se refiere a la garantía del servicio ofrecido por el proveedor del Web service, esto es: debido a que UDDI es un directorio público en Internet, ¿quién 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 información sea realizado en XML. Aquí se esta tomando el primer paso en sencillez:

la representación de datos no posee ningún formato específico ya que XML es texto-simple.

XMLRPC/SOAP ha sido diseñado alrededor de HTTP (el protocolo utilizado en Internet), lo que no sólo facilita el problema de acceso("Firewalls") que siempre es un problema en sistemas CORBA, sino que abre la puerta a la posibilidad de acceder métodos remotos en maquinas de cualquier empresa, en el proceso automatizando intercambios de información de una manera transparente.

XMLRPC o SOAP: ¿Cuál es la diferencia ?

XMLRPC fue el primer mecanismo que surgió para invocar procedimientos remotos vía XML, ofrece una manera muy sencilla de invocar operaciones en sistemas heterogéneos a través de una estructura simple.

SOAP ("Simple Object Access Protocol") es una implementación más robusta para llevar acabo una intercomunicación 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 descripción: WSDL y directorios distribuidos para su ubicación: UDDI o ebXML.

J2EE y Servidor de Aplicaciones

Especificaciones de las tecnologías J2EE

1. Java™ 2 Platform, Enterprise Edition Specification, Version 1.4 (J2EE specification).

2. Java™ API for XML-Based RPC Specification, Version 1.1 (JAXP specification). 3. Java™ API for XML Processing Specification, Version 1.2 (JAXP specification).4. SOAP with Attachments API for Java Specification, Version 1.2

(SAAJ specification).5. Java API for XML Registries Specification, Version 1.0 (JAXR specification). 6. Web Services for J2EE Specification, Version 1.1.7. Java API for XML Binding Specification (JAXB specification).8. Java™ Servlet Specification, Version 2.4 (Servlet specification).9. JavaServer Pages™ Specification, Version 2.0 (JSP specification).10.Enterprise JavaBeans™ Specification, Version 2.1 (EJB specification).11.J2EE™ Connector Architecture Specification, Version 1.5 (

Connector specification).12.Java™ Message Service Specification, Version 1.0.2 (JMS specification).

J2EE 1.4 Platform Architecture

Java Application Servers Un Java Application Server (ya denominado Application

Server) proporciona el ambiente necesario para ejecutar EJB's y su estructura es la siguiente:

Los dos componentes principales de un Application Server son el "Servlet Engine" (Web-Container) y "Enterprise Bean Engine" (Bean-Container) aunque no sean comercializados como tal. Dentro del "Servlet Container" residen y se ejecutan JSP's y Servlet's, mientras que en el "Enterprise Bean Container" se ejecutan los EJB's.

Application servers fully J2EE Compliant Existen varios en el mercado. Entre los mas usados: Sun Application Server (gratuito para desarrolladores) Apache Tomcat (Open Source - gratuito) JBoss (Open Source – gratuito) Oracle 10g Application Server (descarga gratuita) IBM Websphere (bajo licencia comercial) BEA WebLogic (bajo licencia comercial)

En estos "Application Servers" no existe una clara distinción (al menos para el programador final) entre el "Servlet Engine" y el "EJB Engine" por lo que la ejecución de componentes se lleva acabo de una manera relativamente transparente.

En este curso se utiliza Sun Application Server, aunque debe destacarse que también NetBeans posee la opción de utilizar Apache Tomcat, el cual trae como servidor asumido.

Puede consultar detalles adicioanles sobre Servidores de Páginas y de aplicaciones en:

"Web Servers" y "Java Application Servers"

Herramientas J2EE SUN Microsystems Developer Network

XML Sun Developer Network Java API for XML Processing (JAXP) Java API for XML Registries (JAXR) Java API for XML-based RPC (JAX-RPC) Java Architecture for XML Binding (JAXB)

Introducción a JAXB con NetBeans SOAP with Attachments API for Java (SAAJ) The J2EE 1.4 Tutorial for NetBeans IDE 4.1