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
Top Related