1

PLATAFORMAS DE INTEGRACIÓN.

SERVICIOS WEB BASADOS EN REST Y SOAP.

Patricia Carmona Barbero.

Ingeniería Técnica en Informática de Gestión.

PORTFOLIOS para la asignatura ISG2.

2

PLATAFORMAS DE INTEGRACIÓN.SERVICIOS WEB BASADOS EN REST Y SOAP

PLATAFORMAS DE INTEGRACIÓN .................................................................................................. 3

Introducción. ....................................................................................................................................... 3

Avances tecnológicos. ...................................................................................................................... 3

SERVICIOS WEB .................................................................................................................................. 4

Concepto. ............................................................................................................................................ 4

Requisitos de un SW. ........................................................................................................................ 4

Ventajas y Desventajas de los SW. ................................................................................................ 5

Elementos de un SW. ....................................................................................................................... 5

Arquitectura de SW. .......................................................................................................................... 6

ARQUITECTURA REST ......................................................................................................................... 7

Introducción. ....................................................................................................................................... 7

Principios Básicos. ............................................................................................................................ 7

Conclusión. ......................................................................................................................................... 9

ARQUITECTURA SOA. ....................................................................................................................... 10

Introducción. ..................................................................................................................................... 10

Definición. ......................................................................................................................................... 10

Arquitectura SOA. ............................................................................................................................ 10

Elementos de la arquitectura SOA ................................................................................................ 10

Servicios. ........................................................................................................................................... 11

ESTANDARES BASICOS ..................................................................................................................... 13

SOAP. ................................................................................................................................................ 13

WDSL. ................................................................................................................................................. 15

UDDI. .................................................................................................................................................. 17

ESB. Enterprise Service Bus ......................................................................................................... 19

COMPARATIVA. ...................................................................................................................................... 22

REST vs SOAP. ............................................................................................................................... 22

REFERENCIAS. ......................................................................................................................................... 23

3

PLATAFORMAS DE INTEGRACIÓN

INTRODUCCIÓN .

Las plataformas de integración surgen de la necesidad de interrelacionar datos de distintas aplicaciones ya en uso. El

éxito radica en definir una plataforma y una arquitectura de integración que sea ágil, fiable y flexible a la hora de

realizar cambios, migraciones o bien la inclusión de nuevas aplicaciones o flujos de negocio a nuestro "Mapa de

Integración".

AVANCES TECNOLÓGICOS .

Como podemos ver a lo largo del tiempo que los avances en el mundo tecnológico surgen de la demanda de mejorar

en la comunicación.

En los años 70 ya empezamos con la comunicación entre distintos ordenadores conectados en red mediante Sockets,

también conocidos como conectores que permitían la comunicación bidireccional entre procesos lanzados por una

misma máquina o distinta.

Hacia los 80`s el problema radicaba en la invocación entre procesos remotos, donde un proceso puede ejecutar un

procedimiento que pertenece al entorno de otro proceso, dando lugar a la creación de RPC (“remote procedure call”)

mecanismo de comunicación a alto nivel entre computadoras vía red y el sistema software DCE (“Distributed

Computing Environment”); basado en un modelo cliente/servidor.

Los siguientes avances hacia los años 90´s con la implantación de los lenguajes orientados a objetos se centraron en

la heterogeneidad del entorno ya que las redes que unen las distintas máquinas pueden usar diferentes tecnologías

(Ethernet, ATM, FDDI,etc.),protocolos (TCP/IP, X.25,OSI,IPX/SPX,etc.),plataformas y lenguajes de programación;

naciendo así COBA que permite la invocación de métodos de objetos remotos sin que importe el lenguaje en el que

estén escritos el llamador y el llamado, ni las plataformas (s.o. y hw.) y redes de comunicación intermedias; como

también son el caso de Java RMI,DCOM/COM+/ActiveX

A finales de los 90´s principios de los 00`s con la adopción global de Internet, las empresas necesitaban extender sus

plataformas tecnológicas para la comunicación entre socios y clientes; se tenía CORBA o DCOM, pero ninguno de los

dos dominaban el mercado, por lo que las empresas que suministraban estos canales de comunicación usaban otras

tecnologías.

Fue entonces a primero de 2000 cuando apareció el protocolo SOAP(“ Simple Object Access Protocol”) con

interoperatibilidad con XML (“Extensible Markup Language”) y REST (“Representional State Transfer”) propuesto por

Roy Fielding como servicios web para solucionar el problema.

4

SERVICIOS WEB

CONCEPTO.

Se trata de una tecnología relativamente reciente ,existen múltiples definiciones de lo que es un sistema software para

considerarse servicio web (SW); una muy sencilla sería hablar de ellos como un conjunto de aplicaciones o de

tecnologías con capacidad para interoperar en la Web proporcionando mecanismos de comunicación entre diferentes

aplicaciones; En general, los servicios web son sólo APIs Web que pueden ser accedidas en una red, como internet, y

ejecutadas en un sistema de hosting remoto.

Los SW, constituyen una avance tecnológico que no está ligado a ninguna tecnología, ya que una de sus premisas es

la interoperabilidad multiplataforma. Un SW es más una idea, un concepto cuya implementación debe respetar una

serie de reglas e interfaces para poder ser accedido por cualquier sistema conectado a la red, siempre que disponga de

permiso para ello.

Haremos una última noción del concepto servicio web citando a Marcos Escover en una charla en 2003 sobre Servicios

Web :

"Un Web Service es un componente de software que se comunica con otras aplicaciones codificando los mensaje en

XML y enviando estos mensaje a través de protocolos estándares de Internet tales como el Hypertext Transfer Protocol

(HTTP). Intuitivamente un Web Service es similar a un sitio web que no cuenta con un interfaz de usuario y que da

servicio a las aplicaciones en vez de a las personas. Un Web Service, en vez de obtener solicitudes desde el

navegador y retornar páginas web como respuesta, lo que hace es recibir solicitudes a través de un mensaje

formateado en XML desde una aplicación, realiza una tarea y devuelve un mensaje de respuesta también formateado

en XML.

Microsoft y otras empresas líderes están promocionando SOAP como estándar de los mensajes para los Web

Services. Un mensaje SOAP se parece mucho a una carta: es un sobre que contiene una cabecera con la dirección del

receptor del mensaje , un conjunto de opciones de entrega (tal como la información de encriptación), y un cuerpo o

body con la información o data del mensaje.

Microsoft y otros proveedores líderes promocionan los Web Services como un modelo de programación para la

comunicación entre aplicaciones. Estas compañías piensan que la conexión de aplicaciones a través de la Internet

mejorará la capacidad de las empresas para trabajar conjuntamente con sus socios de negocio, proveedores y clientes.

Creando una capa de Web Services sobre una aplicación corporativa existente, las organizaciones podrán permitir que

sistemas externos puedan invocar las funciones de la aplicación a través de Internet (o una intranet corporativa) sin

tener que modificar la aplicación misma. Por ejemplo, varias compañías están hoy en día creando Web Services que

actúan como front end para aplicaciones de entrada de órdenes que están residentes internamente en un mainframe.

Estas compañías permiten a los sistemas de compras de sus clientes enviar órdenes de compra a través de la Internet.

Poner una capa de web services sobre las aplicaciones existentes es una solución muy interesante para integrar las

aplicaciones desarrolladas por los diferentes departamentos y así reducir los costos de integración."

REQUISITOS DE UN SW.

Un servicio web debe satisfacer los siguientes requisitos:

Proporcionarnos un servicio remoto para poder ser usado desde distintas plataformas (Interoperabilidad)

Adecuarse al medio actual; Internet

No debe haber ambigüedad en el tipo de datos del mensaje enviado y recibido (Interfaces tipificadas)

Debería poder ser construida sobre un estándar de Internet ampliamente adoptado para aprovechar los

conjuntos de herramientas y productos existentes creados para dicha tecnología.

5

Tiene que dar soporte a distintos lenguajes de programación (Java, Visual Basic, PERL,….)

No debe estar ligada a ninguna estructura de componentes; Los protocolos subyacentes deberían

proporcionar un nivel base de comunicación entre infraestructura de objeto distribuidos existentes.

VENTAJAS Y DESVENTAJAS DE LOS SW.

Ventajas de los SW:

* Aumenta la interoperatibilidad entre programas independientemente de la plataforma en donde están instalados.

* Aumenta la interoperatibilidad entre servicios y programas de diferentes compañías y ubicados en diferentes

lugares geográficos.

* Fomentan los estándares y protocolos basados en texto, haciendo más fácil acceder y entender su contenido y

funcionamiento (pero, en general, produciendo una baja en su rendimiento).

* Al emplear HTTP, pueden utilizar un sistema firewall sin cambiar las reglas de filtrado.

Desventajas de los SW:

* No son tan desarrollados para realizar transacciones comparado a otros sistemas como CORBA (Common

Object Request Broker Architecture).

* Su rendimiento es bajo comparado con otros sistemas como CORBA, DCOM o RMI, especialmente por el uso

de protocolos y estándares basados en texto.

ELEMENTOS DE UN SW.

Los SW, constituyen un avance tecnológico que no está ligado a ninguna tecnología, ya que como hemos nombrado

uno de sus requisitos es la interoperabilidad multiplataforma. Un SW es más una idea, un concepto cuya

implementación debe respetar una serie de reglas e interfaces para poder ser accedido por cualquier sistema

conectado a la red, siempre que disponga de permiso para ello.

Fuera de la implementación tenemos una serie de partes bien diferenciadas que hay que tener en cuenta a la hora de

utilizar un SW. En la siguiente imagen quedan reflejadas y su conexión.

6

Como se puede ver, la entidad proveedora y la que realiza la petición, se ponen de acuerdo respecto a la descripción

del servicio (mediante un documento en WSDL) y la semántica que guiarán la interacción entre los agentes. Cada uno

de los agentes, implementa la semántica del servicio, pero desde el punto de vista que le corresponde, es decir, desde

el punto de vista del proveedor o del consumidor (el que realiza la petición). Ambos agentes (el solicitante y el

proveedor) intercambian mensajes SOAP en nombre de los respectivos propietarios.

ARQUITECTURA DE SW.

El concepto de Arquitectura de SW es un concepto muy amplio que podríamos desglosar en otras arquitecturas a su

vez:

· Arquitectura de interoperabilidad.

· Arquitectura orientada a servicios.

· Arquitecturas SOA y REST.

De estad dos últimas entraremos en profundidad más adelante.

Para concluir este apartado definiremos cada una de las partes de un bloque constructivo de un SW.

Descubrimiento: La aplicación cliente que necesita acceder a la funcionalidad que expone un SW necesita una

forma de resolver la ubicación de servicio remoto. Esto se logra mediante un proceso llamado,

descubrimiento (discovery). El descubrimiento se puede proporcionar mediante un directorio centralizado así

como por otros métodos ad hoc. UDDI,Disco…

Descripción: Una vez que se ha resuelto el extremo de un SW dado, el cliente necesita suficiente información

para interactuar adecuadamente con el mismo. La descripción de un SW implica meta datos estructurados

sobre la interfaz que intenta utilizar la aplicación cliente así como documentación escrita sobré el SW.

WSDL,XML…

Formato del mensaje: Para el intercambio de datos, el cliente y el servidor tienen que estar de acuerdo en un

mecanismo común de codificación y formato de mensaje. SOAP..

Codificación: Los datos que se trasmiten entre el cliente y el servidor necesitan codificarse en un cuerpo de

mensaje. XML…

7

Transporte: Una vez se ha dado formato al mensaje y se han serializado los datos en el cuerpo del mensaje

se debe transferir entre el cliente y el servidor utilizando algún protocolo de transporte. HTTP,SMTP…

ARQUITECTURA REST

INTRODUCCIÓN.

REST, Representational State Transfer, es una técnica de arquitectura software para sistemas web más restringido y

fiable. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los

principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad

de desarrollo.

REST se sustenta sobre los estándares de HTTP y URI (“ uniform resource identifier” (en español identificador uniforme

de recursos), que sirve para identificar recursos en Internet.

Un concepto importante en REST es la existencia de recursos; Para manipular estos recursos, los componentes de la

red (clientes y servidores) se comunican a través de una interfaz estándar (HTTP) e intercambian representaciones de

estos recursos.

PRINCIPIOS BÁSICOS.

Para considerar un sistema como REST se debe apoyar en unos principios básicos o restricciones:

1Cliente-Servidor

La primera restricción que tiene REST está en común con el estilo Cliente-Servidor. Separar lo que es competencia del

cliente y el servidor es el principio de todo. Hay que distinguir lo que concierne al interfaz del usuario del

almacenamiento de datos. De esta manera se ayuda a mejorar la portabilidad de la interfaz de usuario a través de

múltiples plataformas. Además también se mejora la escalabilidad porque se simplifican las componentes del servidor

al no tener que implementar las funcionalidades que van asociadas a la interfaz del usuario. Otro factor importante es

que la separación permite a los componentes desarrollarse independientemente.

2 Sin estado

Cada petición del cliente debe contener toda la información necesaria para que el servidor la comprenda y no necesite

mirar ningún dato almacenado previamente sobre el contexto de la comunicación.

Esta restricción mejora la visibilidad, eficiencia y escalabilidad. La visibilidad mejora porque el servidor no tiene que

ocuparse de mirar en otros sitios ni realizar más operaciones para comprender la naturaleza de una simple petición. La

8

eficiencia aumenta porque se hace más fácil recuperarse de errores parciales. La escalabilidad se ve también afectada

porque al no hacer falta almacenar los estados entre las peticiones, los componentes pueden liberar recursos más

rápidamente.

3 Caché

Las respuestas a una petición deben poder ser etiquetadas como cacheable o no-cacheable. Si una respuesta es

cacheable, entonces al cliente cache se le da permiso para reutilizar la respuesta más tarde si se hace una petición

equivalente.

4 Interfaz uniforme

La principal característica que distingue a REST del resto de estilos de arquitecturas de red es el énfasis de usar una

interfaz uniforme entre los componentes. Las operaciones disponibles sobre los recursos son siempre las mismas y su

semántica es conocida por todos los clientes y servicios.

En REST sobre HTTP, lo más normal es tener estas operaciones

o POST: Crea nuevos recursos. Como retorno, se ofrece el ID automáticamente creado

o GET: Lista un recurso

o PUT: Reemplaza un recurso con otro (Útil para el update)

o DELETE: Elimina un recurso

La desventaja de usar una interfaz uniforme es que degrada la eficiencia porque la información transferida está en una

forma estandarizada y no según las necesidades que tenga la aplicación. Un diseño de interfaz que utiliza REST será

eficiente con transferencias de datos web (suelen ser datos voluminosos).

5 Recursos

Los recursos se definen como fuentes de información específica y son muy importantes en REST. Un cliente accede a

los recursos que el servidor dispone. Imagine una aplicación empresarial con información de clientes.

Los recursos generalmente son transmitidos entre el servidor y el cliente usando formatos como HTML, XML o JSON.

No obstante, los recursos también pueden ser imágenes, texto plano o cualquier otro formato.

Esta imagen muestra una arquitectura REST.

9

CONCLUSIÓN.

REST es una arquitectura y no un protocolo como SOAP, y se basa en acciones sobre recursos para permitir la

interacción de un cliente con un servidor. La implementación sobre HTTP es la más común y ha permitido la creación

de otras tecnologías.

REST describe un estilo arquitectónico de sistemas en red como, por ejemplo, aplicaciones Web. Las limitaciones

REST, aplicadas como un todo, generan una arquitectura simple, escalable, eficiente, segura, confiable y extensible.

Los servicios web RESTful han surgido como una alternativa prometedora distinta a los servicios basados en SOAP por

su simplicidad y naturaleza liviana, además de la capacidad de transmitir datos directamente sobre HTTP. La

arquitectura multinivel tanto para servicios web como para aplicaciones Web dinámicas conlleva a la reutilización,

simpleza, extensibilidad y a una clara separación de las responsabilidades de los componentes. Ajax y los servicios

web RESTful se ajustan naturalmente el uno al otro. Usando Ajax y los servicios web RESTful juntos, los

desarrolladores logran crear interfaces de alta calidad.

10

ARQUITECTURA SOA.

INTRODUCCIÓN.

Los desarrolladores de estilos arquitectónicos han dado un nuevo punto de vista al desarrollo de los estilos

arquitectónicos del software, entendiendo que el software debe entregarse en forma de servicio no de objeto.

Este nuevo giro de concepto recibe el nombre de Computación Orientada a Servicios (SOC). En parte, esta tendencia

es posible gracias al soporte ofrecido por los estándares y la presencia dominante de las tecnologías de la red. Los

servicios deben definir de manera declarativa sus requisitos funcionales y no funcionales, además de sus capacidades

mediante un formato inteligible por las maquinas y previamente convenido. Mediante estas descripciones, se puede

llevar a cabo el descubrimiento de manera automática de servicios, la selección y la vinculación. De aquí que nazca la

Arquitectura Orientada a Servicios (SOA). La característica principal de SOA es que es una arquitectura con

acoplamiento débil. Acoplamiento débil significa que el cliente de un servicio es esencialmente iindependiente de lla

construcción de ese servicio.

DEFINICIÓN.

“SOA es un modelo de componentes que interrelaciona las diferentes unidades funcionales de las aplicaciones,

denominadas servicios, a través de interfaces y contratos bien definidos entre esos servicios. La interfaz se define de

forma neutral, y debería ser independiente de la plataforma hardware, del sistema operativo y del lenguaje de

programación utilizado. Esto permite a los servicios, construidos sobre sistemas heterogéneos, interactuar entre ellos

de una manera uniforme y universal.” *

ARQUITECTURA SOA.

Los conceptos que hoy en día están asociados a la arquitectura SOA aparecen con la adopción de Internet y el

protocolo HTTP. En 2003, Roy Schulter acuñó el término SOA.

Esta arquitectura define y proporciona la infraestructura necesaria para que el intercambio de información y la

participación en los procesos de negocio se lleve a cabo con total independencia de la plataforma hardware-software

sobre la que trabajan: sistema operativo, lenguaje de programación, características de los equipos, etc.

Esta arquitectura presenta un modelo de construcción sistemas distribuidos en el que la funcionalidad demandada será

entregada a la aplicación a través de servicios.

ELEMENTOS DE LA ARQUITECTURA SOA

11

Servidores

Un servicio de negocio es un componente reutilizable de software, con significado funcional completo, y que está

compuesto por:

Contrato: especificación de la finalidad, funcionalidad, forma de uso y restricciones del

servicio.

Interfaz: mecanismo de exposición del servicio a los usuarios.

Implementación: debe contener la lógica o el acceso a datos.

Repositorio de servicios

Un repositorio de servicios proporciona facilidades para descubrir servicios y adquirir la

información necesaria para su uso, en particular fuera del alcance temporal y funcional

del proyecto en el que se crearon.

Además de la propia información de contrato, los repositorios pueden proporcionar

información acerca de:

Localización.

Personas de contacto.

Restricciones técnicas.

Service Level Agreements (SLAs).

Bus de servicios

El bus de servicios es el elemento de las arquitecturas SOA que conecta los servicios con sus consumidores y que

proporciona:

Conectividad: el propósito principal de un bus de servicios es interconectar a los

participantes de una arquitectura SOA.

Soporte a la heterogeneidad de tecnologías: debe ser capaz de conectar a participantes

basados en distintos lenguajes de programación, sistemas operativos, entornos de

ejecución y protocolos de comunicación.

Soporte a la heterogeneidad de paradigmas de comunicación: debe ser capaz de

mantener distintos modos de comunicación (por ejemplo comunicaciones síncronas y

asíncronas).

Consumidores de servicios

Definimos consumidores de servicios como aquellos elementos de una arquitectura SOA que:

Pueden descubrir servicios a través de un repositorio.

Realizan llamadas a los mismos de acuerdo al contrato y a través del interfaz definido a

tal efecto.

SERVICIOS.

Un servicio representa una función de negocios claramente definida que puede ser invocada remotamente mediante

protocolos de comunicación estándar, definidos mediante interfaces e independientes de su implementación.

Los servicios deben poder ser invocados utilizando protocolos de comunicación estándar que enfatizan la

interoperabilidad e independencia de ubicación.

Los servicios en SOA representan procesos de negocio. Hay una relación directa entre los procesos de negocio de una

empresa y los servicios que se van a implementar en SOA, de tal manera que un proceso de negocio estará formado

por la llamada a varios servicios.

12

No existe una definición estándar de cules son los Principios de la Orientación a Servicios, por lo tanto, lo único que se

puede proporcionar es un conjunto de Principios que estén muy asociados con la Orientación a Servicios. Estos

Principios según Thomas Erl son:

Los Servicios deben ser reutilizables: Todo servicio debe ser diseñado y construido pensando en su

reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso

dentro del dominio público para su uso masivo.

Los Servicios deben proporcionar un contrato formal: Todo servicio desarrollado, debe proporcionar un

contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos

de entrada de cada una de las funcionalidades y los datos de salida. De esta manera, todo consumidor del

servicio, accederá a este mediante el contrato, logrando así la independencia entre el consumidor y la

implementación del propio servicio. En el caso de los Servicios Web, se logrará mediante la definición de

interfaces con WSDL.

Los Servicios deben tener bajo acoplamiento: Los servicios tienen que ser independientes los unos de los

otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio,

se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y

el que lo llama. Si se consigue este bajo acoplamiento, entonces los servicios podrán ser totalmente

reutilizables.

Los Servicios deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser

utilizado para construir servicios genéricos de alto nivel a partir de servicios de bajo nivel. En el caso de los

Servicios Web, esto se logrará mediante el uso de os protocolos para orquestación (WS-BPEL) y coreografía

(WS-CDL).

Los Servicios deben ser autónomos: Todo servicio debe tener su propio entorno de ejecución. De esta

manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde

el punto de vista de la plataforma de ejecución.

Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información. Esto es así

porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena

algún tipo de información, se pueden producir problemas de inconsistencia de datos. La solución, es que un

servicio sólo contenga lógica, y que toda información esté almacenada en algún sistema de información sea

del tipo que sea.

Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para

que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las

mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando sus

interfaces en registros UDDI.

Una forma muy habitual es tomar los servicios como servicios web implementados por el protocolo SOAP.

13

ESTANDARES BASICOS

SOAP.

Definición.

Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un protocolo creado por David Winer, XML-

RPC en 1998. SOAP es el primer protocolo de empaquetamiento de mensajes que ha sido aceptado prácticamente por

todas las grandes compañías de software del mundo.

Este protocolo está pensado para el intercambio de información en entornos descentralizados y distribuidos. Usa las

tecnologías relacionadas con XML a fin de definir un marco de trabajo extensible para los mensajes y se apoya en

WSDL Y UDDI.

Los dos objetivos de diseño principales de SOAP son la simplicidad y la extensibilidad. Para alcanzar estos objetivos,

SOAP simplemente elimina de su arquitectura aquellos aspectos que con más frecuencia se encuentra en los sistemas

distribuidos. Podemos agregar las características que nosotros queramos simplemente extendiendo la especificación.

La actual versión de SOAP (v 1.2) está distribuida básicamente en tres partes:

· Primera parte. Definición del marco de trabajo para los mensajes

de SOAP. Consiste en:

1. El modelo de procesamiento de SOAP, que define las reglas para procesar un mensaje SOAP.

2. El modelo de Extensibilidad de SOAP, que define los conceptos relacionados con las características y los módulos

de SOAP.

3. La construcción del mensaje SOAP, que define la estructura de un mensaje que sigue el protocolo SOAP.

· Segunda parte. Documento de introducción cuyo propósito no es otro que el de proveer de un sencillo tutorial sobre

las características de la versión 1.2 de SOAP.

· Tercera parte. Describe el conjunto de adjuntos que puede usarse en conexión con el marco de mensajes de SOAP.

Ventajas y Desventajas.

Algunas de las Ventajas de SOAP son:

No esta asociado con ningún lenguaje: los desarrolladores involucrados en nuevos proyectos pueden elegir

desarrollar con el ultimo y mejor lenguaje de programación que exista pero los desarrolladores responsables

de mantener antiguas aflicciones heredadas podrían no poder hacer esta elección sobre el lenguaje de

programación que utilizan. SOAP no especifica una API, por lo que la implementación de la API se deja al

lenguaje de programación, como en Java, y la plataforma como Microsoft .Net.

No se encuentra fuertemente asociado a ningún protocolo de transporte: La especificación de SOAP no

describe como se deberían asociar los mensajes de 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.

No está atado a ninguna infraestructura de objeto distribuidoLa mayoría de los sistemas de objetos

distribuidos se pueden extender, y ya lo están alguno de ellos para que admitan SOAP.

Aprovecha los estándares existentes en la industria: Los principales contribuyentes a la especificación SOAP

evitaron, intencionadamente, reinventar las cosas. Optaron por extender los estándares existentes para que

coincidieran con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificación de los mensajes,

14

en lugar de utilizar su propio sistema de tipo que ya están definidas en la especificación esquema de XML. Y

como ya se ha mencionado SOAP no define un medio de trasporte de los mensajes; los mensajes de SOAP

se pueden asociar a los protocolos de transporte existentes como HTTP y SMTP.

Permite la interoperabilidad entre múltiples entornos: SOAP se desarrollo sobre los estándares existentes de

la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estándares pueden

comunicarse mediante mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo,

una aplicación de escritorio que se ejecute en una PC puede comunicarse con una aplicación del back-end

ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP.

Los inconvenientes que podemos encontrar son:

SOAP consumirá mayor ancho de banda que otros protocolos que tienen su misma finalidad. Esto es debido

a que SOAP al estar basado en XML tendrá un mayor tamaño que el resto de protocolos basado en enviar

datos binarios.

SOAP es más costoso de desarrollar que otros protocolos. Es un protocolo basado en ASCII por lo que los

datos necesitan ser convertidos a secuencias más bien que ser convertidos a su forma binaria. Esto

consume un gran número de ciclos del servidor.

Requiere más memoria. Construidos estas secuencias y analizarlas conllevará un mayor uso de memoria y

posiblemente genere más “basura” que otros protocolos.

Seguridad: SOAP usa el mismo punto de entrada en los firewalls corporativos que el puerto HTTP-80, por lo

que sus mensajes pasan fácilmente a través de los firewalls.

Formato de un mensaje SOAP.

Un mensaje SOAP define de una manera uniforme cómo dos objetos en diferentes procesos pueden comunicarse por

medio de intercambio de datos codificados mediante XML de forma estructurada y tipada. SOAP es uno de los

principales protocolos utilizados en los servicios Web. También define una forma de realizar invocaciones a

procedimientos remotos (RPC) utilizando HTTP.

Todas estas transacciones se expresan mediante un mensaje SOAP que consta de:

Sobre (Envelope): Elemento raíz del documento. Contiene dos subelementos: el Body y el Header. También

puede contener otros elementos hijo.

Cuerpo (Body): El cuerpo Body contiene la información principal del mensaje, es decir, la carga de datos del

mensaje que se conoce como carga útil.

Cabeceras (Header): La cabecera Header es opcional y contiene información que describe el mensaje, datos

adicionales que no necesariamente pertenecen al cuerpo del mensaje, y también metadatos sobre

enrutamiento (routing), seguridad o transacciones.

15

WDSL.

Definición.

WSDL (Web Services Description Language) es un lenguaje que usando XML define una gramática mediante la cual

podemos describir los servicios de la red como colecciones de nodos de comunicación, también conocidos como

servicios, que tienen la capacidad de intercambiar mensajes.Permite describir la interfaz pública de los servicios web;

eso significa que detalla los protocolos 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. WSDL se utiliza a menudo junto con SOAP y XML Schema.

WSDL es extensible y se pude utilizar para describir, prácticamente, cualquier servicio de red, incluyendo SOAP sobre

HTTP e incluso protocolos que no se basan en XML como DCOM sobre UDP.

Estructura de un documento WDSL.

El WSDL nos permite tener una descripción de un servicio web. Especifica la interfaz abstracta a través de la cual un

cliente puede acceder al servicio y los detalles de cómo se debe utilizar.

Un documento WSDL utiliza los siguientes elementos en la definición de servicios de red:

Types: contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos (por ejemplo XSD).

Message: definición abstracta y escrita de los datos que se están comunicando.

Operation: descripción abstracta de una acción admitida por el servicio.

Port Type: conjunto abstracto de operaciones admitidas por uno o más puntos finales.

Binding: especificación del protocolo y del formato de datos para un tipo de puerto determinado.

Port: punto final único que se define como la combinación de un enlace y una dirección de red.

Service: colección de puntos finales relacionados.

16

Ventajas de WSDL.

1. Las principales ventajas de WSDL son:

o WSDL facilita escribir y mantener servicios mediante una aproximación estructurada para definir

interfaces web

o WSDL facilita el acceso a esos servicios web reduciendo el código que hay que escribir para hacer

un cliente

o WSDL facilita hacer cambios para ampliar los servicios, reduciendo la posibilidad de que los

clientes dejen de funcionar al llamar a esos servicios

17

UDDI.

Definición.

UDDI son las siglas del catálogo de negocios de Internet denominado Universal Description, Discovery and Integration.

UDDI es uno de los estándares básicos 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 catálogo de registros.

UDDI es un único registro conceptual distribuido a lo largo de multitudde nodos que replican la información unos de

otros. UDDI pretende ser lasolución al descubrimiento y la integración de SW, que de otra forma,sería una labor

inabordable.

UDDI constituye un registro en el que las empresas “dan de alta” los SWque desarrollan, a fin de que posibles usuarios

interesados en hacer usode esos servicios para realizar determinadas acciones en sus negocios,puedan encontrarlos

sin demasiada dificultad.

Conceptos Principales.

Los principales conceptos de UDDI son:

UDDI Data Model: Incluye tipos de datos que incluyen descripción de los servicios, por ejemplo, cual es su

función (businessService) o quien es el publicador del servicio (businessEntity).

UDDI Nodes and Registers: incluye una específica definición de las relaciones de jerarquía que hay entre los

servidores que tienen implementaciones de UDDI.

Essential Programmatic Interfaces: provee funcionalidades claves como publicar o buscar información sobre

un servicio en el registro UDDI.

Organización de UDDI.

Una organización puede registrar tres tipos de información dentro de unregistro UDDI:

· Páginas blancas. Constituida por información básica de contacto e identificadores de la empresa, incluyendo el

nombre del empresa, dirección, información de contacto. Esta información permite a otros descubrir los SW de una

empresa basándose en la identificación del negocio.

· Páginas amarillas. Consiste en información que describe al SW mediante diferentes categorizaciones o taxonomías.

Esta información permite descubrir SW basándose en esta categorización.

· Páginas Verdes. Consiste en información técnica que describe el comportamiento y las funciones soportadas por un

SW. Esta información incluye punteros que, entre otras cosas, indican dónde están ubicados los SW.

18

Estructura de datos UDDI.

La imagen anterior muestra la relación entre las principales estructuras de datos de UDDI.

Una estructura <businessEntity> representa la información básica de un negocio. Esta consiste en información de

contacto, una categorización, identificadores, descripciones y relaciones con otros negocios. El registro UDDI permite a

las compañías establecer distintos tipos de relaciones con otra compañías.

La estructura <publisherAssertion> se utiliza para establecer relaciones públicas entre dos estructuras tipo

<businessEntity>. Diremos que una relación entre dos estructuras <businessEntity> es pública o visible cuando ambas

entidades creen la misma relación mediante dos documentos <publisherAssertion> independientes.

La estructura <businessService> representa una única clasificación lógica del servicio. Esta estructura se utiliza para

describir un conjunto de servicios que son provistos por el negocio. Estos servicios van desde los SW, a cualquier tipo

de servicio que pueda ofrecer el negocio, aunque no sean de carácter electrónico.

La estructura <bindingTemplate> contiene punteros a descripciones técnicas y a las URL de los puntos de acceso,

pero no contiene información sobre la especificación del servicio. Esta estructura cuenta con una descripción textual,

opcional, sobre el SW.

La estructura <tModel> es un tipo de huella digital mediante la cual podemos determinar como interactuar con un SW

en particular. Esta estructura tampoco provee la especificación del SW, pero en su lugar, cuenta con punteros a la

ubicación de la especificación para su acceso.

19

ESB. ENTERPRISE SERVICE BUS

Definición.

ESB es un software destinado a la integración de aplicaciones. Su cometido es facilitar el ofrecimiento y la

demanda de servicios, gracias a la creación y la gestión de distintos flujos de datos, de manera totalmente

transparente para los desarrolladores de aplicaciones.

Un ESB parte de la idea de desacoplamiento introducido por el broker de mensajes incorporando una

definición abierta de la forma de integración entre consumidores y publicadores de servicios. Un ESB usa

WSDL y XML, estándares abiertos e interoperables, sobre una capa de transporte, típicamente HTTP. De

esta manera los conectores no definen la implementación sino la capa de transporte y una interfaz de

servicio. En el caso de un broker de mensajes los consumidores y publicadores de servicios asumen

cierto conocimiento sobre los tipos de mensajes intercambiados y la tecnología empleada como es el

caso de JMS o MSMQ.

Por consiguiente, un ESB puede distribuirse a lo largo de la organización, no necesitando un punto central

de integración, y permitiendo la interoperabilidad entre sistemas implementados en las más diversas

tecnologías.

Características.

Las características más destacadas de un ESB son las siguientes:

Transparencia de la localización.- Un ESB debe ofrecer una plataforma central para comunicar

aplicaciones desacoplando las localizaciones del productor y del consumidor del servicio.

Conversión de protocolos de transporte.-El ESB debe integrar de forma coherenteaplicaciones

que empleen internamente protocolos de transporte distintos, realizando las conversiones

oportunas (HTTP a JMS, SMTP a FTP, etc). Para ello, los distintos recursos se conectarán al bus

a través de los adaptadores adecuados.

Transformación de mensajes.- Un ESB debe ser capaz de transformar mensajes de un formato a

otro, haciendo uso de estándares abiertos tales como XSLT o XPath.

Encaminamiento de mensajes.- Para cada mensaje que entre al bus, el ESB debe decidir cuál es

el punto de destino apropiado, basándose en el contenido del mensaje, en su procedencia, o

cualesquiera otras reglas de encaminamiento que se definan. De esta forma, un cliente puede

20

hacer uso de un servicio sin necesidad de conocer la localización exacta del proveedor del

mismo.

Seguridad.- Incluyendo mecanismos de autenticación, autorización y encriptado, para satisfacer

los requisitos de seguridad que defina cada proveedor de servicios conectado al bus.

Algunos de los ESB que pueden encontrarse en el mercado son Oracle ESB o IBM WebSphere, como

ejemplos comerciales, y Mule, Apache ServiceMix o WSO2, en la categoría open source.

Ventajas y Desventajas.

Los beneficios que aporta el uso de ESB son:

Acomodación de sistemas existentes más rápida y barata

Mayor flexibilidad; más fácil de cambiar si hay nuevos requisitos.

Basado en normas

Posibilidad de escalar desde soluciones puntuales hasta implementaciones de empresa (bus

distribuido).

Tipos de servicio listos-para-funcionar (ready-to-use) predefinidos

Mayor configuración en vez de tener que codificar la integración.

Sin motor de normas central, sin divisor central

Parches incrementales con tiempo de apagado instantáneo; la empresa se hace "refactorizable".

Algunos inconvenientes que nos pueden surgir son:

Normalmente requiere un Modelo de Mensajes de Empresa, lo cual exige una administración

adicional.

Requiere una administración constante de versiones de mensajes para asegurar el pretendido

beneficio de un emparejamiento flexible. Una administración incorrecta, insuficiente o incompleta

de las versiones de mensaje puede ocasionar un emparejamiento estricto en lugar del pretendido

emparejamiento flexible.

Normalmente precisa más hardware que para un simple sistema de mensajes de punto-a-punto.

21

Se precisan conocimientos en el análisis de middleware para configurar, administrar y operar un

ESB.

Mayor latencia general causada por los mensajes que atraviesan la capa extra del ESB,

especialmente si se compara con las comunicaciones punto-a-punto. La mayor latencia también

se origina por un procesamiento de XML extra (el ESB normalmente utiliza XML como lenguaje

de comunicación).

El ESB se convierte en un elemento único de fallo.

Aunque los sistemas de ESB pueden requerir un esfuerzo significativo para ser implementados,

no producen un valor comercial sin el consiguiente desarrollo de servicios AOS para el ESB

Conclusión.

La necesidad de un ESB surge de la complejidad de las organizaciones que deben coordinar e integrar

sus procesos de negocio, sistemas operacionales y datos sin renunciar a la innovación tecnológica

imprescindible para ser competitivos. Un ESB es la implementación de SOA, una arquitectura que permite

mantener integrados los sistemas, nuevos y legados, en un estilo completamente distribuido e

interoperable.

22

COMPARATIVA.

REST VS SOAP.

Muchos diseñadores de Servicios Web están llegando a la conclusión que SOAP es demasiado complicado. Por tanto,

están comenzando a utilizar Servicios Web basados en REST para mostrar cantidades de datos masivos. Este es el

caso de grandes empresas como eBay y Google.

REST y SOAP se denominan a menudo "Web de servicios," y uno a menudo se utiliza en lugar de la otra, pero son

totalmente diferentes enfoques. REST es un estilo de arquitectura para generar aplicaciones de cliente-servidor. SOAP

es una especificación de protocolo para intercambiar datos entre dos extremos. Aunque SOAP no requiere el estilo

RPC está enfocado a ella.

REST proporciona las ventajas siguientes sobre SOAP:

es ligero, se basa en HTTP y no tiene estados (para permitir la escalabilidad).

es compatible con los marcadores y el almacenamiento en memoria caché.

mantiene el contrato de datos libremente.

Las tecnologías frontend como WEB 2.0 y AJAX consumen fácilmente REST.

REST mejora el rendimiento.

Cuando Usar uno u otro.

Usaremos SOAP :

- Cuando se establece un contrato formal donde se describe todas las funciones de la interfaz. El lenguje WSDL(Web

Services Description Language) nos permite definir cualquier detalle.

- Cuando es necesario que la arquitectura aborde requerimientos complejos no funcionales.Por ejemplo en el uso de

transacciones, seguridad o direccionamiento, casos donde es necesario mantener la información contextual y el estado.

- En casos donde la arquitectura necesita manejar un procesado asíncrono debido al tiempo que necesita para realizar

una parte del procesado de la petición.

Y REST si nos encontramos:

- Cuando el servicio web no necesita tener estado.

- Cuando buscamos mejorar el rendimiento, una infraestructura caching puede mejorarlo.

- En momentos donde el productor como el consumidor conocen el contexto y contenido que van a intercambiar.

- REST es muy util para el consumo como servicio web en dispositivos moviles donde tenemos escasos recursos.

- REST es un acierto en la creación de servicios que se utilizaran de agregadores de información en mashup o sitios web

existentes. También cuando usemos tecnologías como AJAX o framewoks javascript.

23

REFERENCIAS.

Algunas de las páginas web que nos han ayudado como referencia para la realización de este documento han sido:

http://www.slideshare.net/jcejas/caso-de-exito-de-plataforma-de-integracion-corporativa#btnNext

http://www.fic.udc.es/files/asignaturas/39ADOO/Tema1.pdf

http://www.slideshare.net/soreygarcia/aplicaciones-distribuidas-presentation#btnNext

http://www.fing.edu.uy/inco/grupos/lins/seminario/2010/Introduccion_WS-REST.pdf

http://www.desarrolloweb.com/manuales/54/

http://www.slideshare.net/Mache007/arquitectura-orientada-a-servicios-soa-12818946

http://www.monografias.com/trabajos29/protocolo-acceso/protocolo-acceso.shtml

http://www.sicuma.uma.es/sicuma/independientes/argentina08/Dapozo-Litwak/index.htm

http://icomparable.blogspot.com.es/2009/04/que-es-un-esb-enterprise-service-bus.html

http://www.dosideas.com/noticias/java/498-el-papel-del-esb-en-una-solucion-soa.html

Así como la visita a la biblioteca de la escuala donde podemos encontrar libros tales como:

SOA Open Source / Jeff Davis

REST in practice : [hypermedia and systems architecture] / Jim Webber, Savas Parastatidis, and Ian Robinson

SOAP : Cross platform, Web service development, Using XML / Scott Seely.