Download Tema 1: Introducción a las tecnologías de integración de aplicaciones

Tema 1: Introducción a las tecnologías
de integración de aplicaciones
Índice
Introducción
Integración de Aplicaciones
Modelo de referencia
Integración de Plataforma
Historia: RPC, CORBA, JAVA RMI, DCOM,…
Servicios Web
Integración de Aplicaciones / Procesos
SOAP
El enfoque REST
Gestión de flujos inter-aplicación
WS-BPEL (Web Services Business Process Execution
Language)
Integración de datos
Introducción (1)
Integración de aplicaciones
Hacer colaborar entre sí a aplicaciones distribuidas,
heterogéneas y posiblemente autónomas.
Distribución: las diferentes aplicaciones pueden ejecutarse
en máquinas conectadas a través de una red:
LAN
Internet
Autonomía: El sistema de integración no puede esperar que
la aplicación cambie su forma de actuar para facilitar la
integración
Aplicaciones heredadas
Aplicaciones de otros departamentos
Aplicaciones de otras empresas (B2B)
Introducción (2)
Heterogeneidad
Máquinas: mainframes, servidores (Sun, IBM, HP, etc.),
estaciones de trabajo (Compatibles PC, Apple Macintosh,
Sun, IBM, HP, etc.)
Sistemas operativos: Solaris, HP-UX, AIX, Linux, MacOS, MSWindows (9x, NT, 2000, XP), etc.
Redes: TCP/IP, Novell Netware, lenguajes .NET (Visual C#
.NET, Visual Basic .NET, Visual C++ .NET), etc.
Aplicaciones en distintos lenguajes: Java, C++, Visual Basic,
Visual C++, Delphi, COBOL, etc.
Distintas arquitecturas de datos: ficheros, bases de datos de
distintos modelos y fabricantes, sitios web,…
Distintos esquemas y formatos de datos. Ejemplo:
App A: DIRECCION=“C\ Alcala, 32, 28080 Madrid”.
App B: CALLE=“Calle Alcalá” NUM=“32”, CP=“28080”,
CIUDAD=“Madrid”.
Introducción (y 3)
Heterogeneidad: Razones
Decisiones de ingeniería
Razones de coste
Diferentes personas eligen diferentes soluciones a un mismo
problema
Se compra el tipo de software/hardware que cumpla los
requisitos y tenga un precio razonable
Aplicaciones antiguas
No es posible desecharlas y rehacerlas con las tecnologías más
modernas
Es preciso seguir utilizándolas hasta amortizar su coste de
desarrollo y obtener beneficio
Modelo de referencia (1)
INTEGRACIÓN B2B
INTEGRACIÓN DE APLICACIONES Y
PROCESOS
INTEGRACIÓN DE DATOS
INTEGRACIÓN DE PLATAFORMA
Modelo de referencia (2)
Integración de Plataforma
Integración de Datos
Independencia de arquitectura de almacenamiento.
Independencia de heterogeneidades de esquema/formato.
Integración de Aplicaciones / Procesos
Comunicación de aplicaciones en diferentes máquinas.
Independencia de localización, hardware, SO y lenguaje de
programación.
Creación rápida de aplicaciones basadas en aplicaciones
existentes. Procesos de negocio modelados como flujos.
Integración B2B
¿Qué debemos considerar cuando las aplicaciones que se
comunican pertenecen a organizaciones diferentes?
Seguridad, minimizar acoplamiento, estándares sectoriales,…
Modelo de referencia (y 3)
INTEGRACIÓN B2B
TEMA 4
TEMA 5
TEMA 3
INTEGRACIÓN DE APLICACIONES Y
PROCESOS
INTEGRACIÓN DE DATOS
INTEGRACIÓN DE PLATAFORMA
Ejemplo (1)
Una empresa de telecomunicaciones utiliza, entre otras, las
siguientes aplicaciones:
Aplicación de Facturación.
Aplicación de gestión de incidencias.
Tiene información sobre las facturas y los pagos de proveedores y
clientes.
Construida enteramente en la organización en los 80 utilizando COBOL.
Gestiona eficazmente miles de facturas cada mes, pero hay poco
personal capaz de modificarla.
Gestiona las incidencias detectadas por los clientes.
Construida utilizando un paquete comercial que expone APIs C++.
Aplicación ERP.
Entre otras cosas, permite gestionar los recursos de la operadora, los
costes asociados a su uso, y los márgenes de rentabilidad en sus
actividades.
Construida utilizando un paquete comercial que expone APIs JAVA.
Ejemplo (2)
CRM Productos.
Tiene información sobre los clientes de telefonía, Internet y voz de la
operadora.
Construido internamente utilizando un paquete comercial que expone
APIs C++.
CRM Clientes Hosting / Housing.
Tiene información sobre empresas clientes de Hosting / Housing.
La operadora sólo ha empezado a ofrecer estos servicios
recientemente. Un nuevo departamento se ocupa de ello.
Construida utilizando una aplicación comercial online (e.g.
Salesforce.com, Sugarcrm.com).
La aplicación no reside en el CPD de la empresa sino en los servidores del
proveedor.
El interfaz de uso para los usuarios humanos es web.
La aplicación ofrece una interfaz Servicio Web SOAP para leer y modificar
los datos contenidos en la misma.
La aplicación también ofrece un API para extender y adaptar su
comportamiento a las preferencias y necesidades de la empresa.
¡ Cuesta muy poco, está lista para ser usada en 10 minutos y no hay que
depender del Departamento de Informática para mantenerla !
Ejemplo (y 3)
Aplicación de Pedidos de “Instaladores ACME”:
La operadora no dispone de personal propio para realizar las
instalaciones ni las reparaciones que requieran un
desplazamiento al hogar/oficina del cliente. En su lugar,
subcontrata esta actividad a otras empresas.
“Instaladores ACME” es una empresa especializada en este tipo
de actuaciones que trabaja habitualmente con la operadora.
Recientemente, se ha implantado un procedimiento por el cuál
la operadora puede enviar ordenes de actuación a
“Instaladores ACME” a través de un servicio web.
De esta forma, el proceso puede automatizarse.
Integración de Plataforma (1)
Historia:
70’s: Comunicación de procesos en red
80’s: Tecnologías de invocación de procedimientos remotos
CORBA (Common Object Request Broker Architecture)
JAVA RMI (Remote Method Invocation)
Microsoft DCOM (Distributed Component Object Model).
00’s: Tecnologías de Servicios Web
Sun RPC (Remote Procedure Call)
DCE (Distributed Computing Environment)
90’s: Tecnologías de objetos distribuidos
Sockets
REST (REpresentional State Transfer)
SOAP (Simple Object Access Protocol)
NOTA: La influencia de cada tecnología no se ciñe sólo a la
década mostrada en la transparencia. Ejemplo: CORBA, RMI,
DCOM e incluso Sockets siguen en uso.
Ejemplo: Integración de Plataforma
Ejemplo: para determinar la prioridad de una incidencia de un
cliente, quiero saber cuánto se le factura al cliente.
Incidencias
(C++)
Facturación
(COBOL)
Servidor
aplicaciones
web (Java)
HTTP
Navegador
Aplicación standalone
cliente
(Delphi / VBasic)
Integración de Plataforma (2)
Comunicación de procesos en red
Procesos en diferentes nodos de la red pueden intercambiar
datos utilizando APIs de red (e.g. sockets TCP/IP).
No importa topología de la red, plataforma hardware, SO o
lenguaje de programación.
Visión de muy bajo nivel. Utilizar desde un programa
servicios proporcionados por programas que se ejecutan en
otro nodo es un proceso costoso y “poco amigable”.
Integración de Plataforma (3)
Invocación de procedimientos remotos
Un proceso expone una serie de operaciones (procedimientos) que
pueden ser invocados desde cualquier programa de la red.
Las operaciones y sus parámetros se describen en un fichero de
definición utilizando un lenguaje especial.
Para hacer un programa cliente que invoque a un procedimiento
remoto, un compilador especial genera un programa llamado
“stub” partiendo del fichero de definición.
Con el “stub”, el programador del cliente puede invocar el
procedimiento remoto de forma muy parecida a la de un
procedimiento local (transparencia).
El stub es el que realmente recibe la llamada del cliente, envía un
mensaje al servidor y recibe la respuesta del mismo.
Visión orientada a programación estructurada (paradigma
dominante en los 80), no a programación OO.
Tecnología dominante: SUN RPC.
Integración de Plataforma (4)
Tecnologías de objetos distribuidos
Conceptualmente muy similar a RPC.
Cada nodo de la red puede exponer una serie de objetos.
Permiten la invocación de métodos de objetos remotos.
Utiliza el paradigma de programación OO (dominante en los
90 y hasta la actualidad).
JAVA RMI. No proporciona independencia del lenguaje de
programación (debe utilizarse JAVA).
Por su facilidad de uso ganó gran aceptación en la comunidad
JAVA.
Sigue siendo un “building block” importante en la arquitectura JEE
(Java Platform Enterprise Edition).
DCOM. Solución propietaria de Microsoft.
Muy utilizado en la comunidad Microsoft.
Difícil la interoperabilidad con el “resto del mundo” (JAVA).
Integración de Plataforma (y 5)
Tecnologías de objetos distribuidos
CORBA
Estandarizado por el OMG (http://www.omg.org). Consorcio
constituido por un gran número de empresas (Iona, Borland,
HP, IBM, Oracle, Sun, etc.)
Las APIs están estandarizadas -> El desarrollador no depende
de un fabricante.
Existen múltiples implementaciones de distintos fabricantes
para las plataformas y lenguajes más usuales (C++, Java, Ada,
COBOL, C, Smalltalk, etc.).
El OMG ha estandarizado numerosos servicios CORBA útiles
para cualquier aplicación:
Servicio de nombres
Seguridad
Transacciones
Ámbito de aplicación de CORBA
CORBA ha sido y continúa siendo una buena tecnología para
abordar integraciones complejas en intranets
Eficiente y probado
Buen soporte para seguridad, transacciones, comunicación basada
en eventos, etc.
Uso en Internet
IIOP: Protocolo para permitir que diferentes sistemas que utilicen
CORBA se comuniquen a través de TCP/IP.
Existen firewalls que no reconocen IIOP
Hay fabricantes que venden proxies de IIOP, pero no todas las
empresas que han adoptado las tecnologías de Microsoft los tienen
Existen túneles IIOP sobre HTTP, pero no son óptimos
Microsoft no fabrica implementaciones de CORBA
Hay terceros que sí lo hacen (ej.: Iona, Borland, etc.), pero no se
puede esperar que todas las empresas que han adoptado las
tecnologías de Microsoft usen CORBA
Servicios Web (1)
La Web proporciona un mecanismo de transporte
universal, eficiente, robusto, escalable y probado
tanto en aplicaciones inter-organización como intraorganización.
Muchas de las tecnologías comentadas hasta el
momento fueron diseñadas antes de la emergencia
de la Web o no fueron específicamente diseñadas
para aprovecharse de ella.
Servicios Web (2)
Un Servicio Web expone un conjunto de puntos de
acceso (endpoints) que pueden ser invocados por
procesos externos.
Un endpoint puede ser visto normalmente como una
operación que recibe ciertos parámetros y devuelve
un resultado, quizás efectuando alguna acción por el
camino.
Están basados en tecnologías surgidas alrededor de
la Web:
Típicamente, los puntos de acceso son accedidos mediante
HTTP y sus direcciones se expresan mediante URLs.
Las invocaciones y las respuestas de las mismas se codifican
típicamente mediante XML.
Servicios Web (3)
Suele distinguirse entre dos estilos de servicios web:
Servicios web SOAP.
Añaden un nuevo conjunto de protocolos (SOAP) y lenguajes
para permitir RPCs y envío de mensajes entre aplicaciones a
través de la web.
Estandarizados por el W3C.
Suelen utilizar HTTP como mecanismo de transporte, pero no
obligatoriamente.
Servicios web REST.
No añaden nuevos protocolos ni lenguajes: utilizan solamente
HTTP 1.1 y formatos como XML para especificar mensajes.
Pueden utilizarse para implementar RPCs, pero también dan
soporte a un nuevo estilo arquitectónico para diseñar
aplicaciones distribuidas (Servicios Web REST “puros” o
“RESTful Web Services”.
XML
Lenguaje de tags (similar en sintaxis a HTML)
Permite expresar información estructurada y fácilmente
parseable por una aplicación
Estandarizado por el W3C ( http://www.w3.org)
Es extensible:
XML no impone un conjunto de tags, sino sólo unas pocas normas
de uso (los tags se abren y se cierran y en medio puede tener
otros tags anidados, todos los documentos tienen un tag raíz, los
tags pueden tener atributos, etc.)
Sus campos de aplicación son innumerables
Integración de aplicaciones heterogéneas, configuración de
aplicaciones, generación de la capa vista de una aplicación
web/WAP, bases de datos, etc.
XML: Ejemplo (1)
La operadora podría enviar el siguiente texto sobre
HTTP (o HTTPS) a “Instaladores Acme”
Elegimos HTTP (o HTTPS) porque todos los firewalls lo
soportan
<?xml version=“1.0”>
<InstallationManagement>
<makeInstallation id=“3098”>
<type product=“cablemodem” bandwidth=“100”/>
<client name=“John Smith”>
<address street=“Real 16, 3º” city=“A Coruña”/>
<phone number=“981222222”/>
</client>
<details> Llamar antes. Mejor por la tarde </details>
</makeInstallation>
</InstallationManagement>
XML: Ejemplo (y 2)
Cuando “Instaladores Acme” acepta realizar la orden
de intervención puede contestar con algo del estilo:
<?xml version=“1.0”>
<InstallationManagement>
<makeInstallationResponse id=“3098” status=“accepted”>
<scheduleddate day=“20” month=“3” year=“2007”/>
</makeInstallationResponse>
</InstallationManagement>
NOTA: Este es un ejemplo de servicio web REST. En
Servicios SOAP XML también se utiliza pero con otro
propósito.
Servicios Web SOAP (1)
WSDL (Web Services Description Language)
Permite especificar en XML las operaciones, parámetros y
tipos de datos de un servicio web.
La idea es similar al fichero de definición de RPC.
SOAP (originalmente “Simple Object Access
Protocol”)
Protocolo basado en XML para envío de mensajes
estructurados (“objetos”)
Normalmente funciona sobre HTTP (también SMTP, JMS,…).
Cuando un cliente invoca una operación de un servicio,
envía un mensaje SOAP indicando la operación a invocar y
los valores de los parámetros.
El servicio devuelve un mensaje SOAP con la respuesta.
Servicios Web SOAP (2)
Los interfaces ofrecidos por un servicio se expresan
en WSDL (Web Service Definition Language)
Existen compiladores para generar WSDL partiendo
de interfaces en lenguajes populares (e.g. JAVA)
<wsdl:portType name=“IncidencesProvider">
<wsdl:operation name="getIncidencesByClient“
parameterOrder=“in0">
<wsdl:input name="getIncidencesByClientRequest"
message="impl:getIncidencesByClientRequest"/>
<wsdl:output name="getIncidencesByClientResponse"
message="impl: getIncidencesByClientResponse "/>
<wsdl:fault name="IncorrectClientException"
message="impl: IncorrectClientException"/>
</wsdl:operation>
</wsdl:portType>
El compilador de WSDL permite generar
Un “Stub” (Proxy) del objeto remoto (cliente)
Un Skeleton (Adapter) para implementar el interfaz remoto
(servidor)
Servicios Web SOAP (3)
UDDI (Universal Description, Discovery and
Integration of Web Services)
Protocolo para interaccionar con un servidor (registro UDDI)
que proporciona operaciones (vía SOAP) para registrar y
buscar servicios web
Cada servicio web se registra dando, su nombre, una
descripción del servicio (ej.: la URL de su WSDL, una
descripción textual, etc.), etc.
Especificación: http://www.uddi.org
Servicios web SOAP (y 4)
Registro UDDI
Instalador-1
SOAP
SOAP
Operadora
SOAP
SOAP
Instalador-2
Internet
SOAP
...
Instalador-N
APIs para Servicios web SOAP
Existen APIs (comerciales y gratuitas) para los
lenguajes más usuales.
Generan WSDL desde el lenguaje deseado.
Partiendo del WSDL, generan Stubs y Skeletons.
En general, las APIs no son estándares, sin embargo,
no afecta a la interoperabilidad
En el caso de Java
La interoperabilidad es posible porque los protocolos (SOAP,
WSDL, UDDI) están estandarizados
Las APIs son estándares
Forman parte de JEE
Al igual que en CORBA, podemos cambiar de fabricante sin
que afecte al código fuente
En el caso de los lenguajes de Microsoft
Las APIs forman parte de .NET
REST (1)
REpresentational State Transfer. Estilo arquitectónico propuesto
por Roy Fielding en 2000.
RPC, CORBA, RMI, DCOM,…, incluso SOAP: ¿el mismo perro con
distinto collar?
La Web es, sin duda, la aplicación distribuida más exitosa de la
historia, y no sigue esa arquitectura.
REST: Estilo arquitectónico para construir aplicaciones
distribuidas inspirado en las características de la web.
Mucha gente piensa que la arquitectura de las aplicaciones
distribuidas no ha cambiado significativamente en 25 años.
Los defensores de REST (RESTafaris) creen que REST es la clave
para construir aplicaciones distribuidas tan escalables, accesibles,
robustas y eficientes como la web.
Sin embargo, frecuentemente REST se utiliza como sinónimo de
servicios web que, en lugar de las tecnologías SOAP, utilizan
directamente HTTP y XML (aunque sea al “viejo” estilo).
Ejemplo: Invocación a “Instaladores Acme”.
REST (y 2)
En el enfoque REST el protocolo de transporte es siempre HTTP
REST nos obliga a “parsear” el mensaje XML devuelto.
En el enfoque SOAP y el resto de enfoques derivados de RPC,
manejamos directamente los objetos de nuestro lenguaje de
programación (Java, C++).
Tener un protocolo por encima de HTTP (SOAP) nos permite
tener un lugar donde incluir información para manejar aspectos
como seguridad, transacciones,…
SOAP puede utilizar diferentes mecanismos de transporte: HTTP,
SMTP, JMS … pero casi siempre se usa HTTP.
Sin embargo, hoy en día, estas funcionalidades aún no están
disponibles en SOAP.
Muchas veces se utiliza REST no tanto por sus ventajas
arquitectónicas (que, en ocasiones, se ignoran) sino porque:
Es más fácil invocar un servicio REST que un servicio SOAP.
Hay problemas de interoperabilidad en las implementaciones de SOAP.
Las tecnologías HTTP / XML son inter-operables universalmente.
Ámbito de aplicación de servicios web (1)
Integración de aplicaciones en intranets
Cuando se utilizan, se suele seguir el enfoque SOAP.
No son una alternativa tan eficiente y madura como CORBA
CORBA dispone de numerosos servicios (seguridad,
transacciones, etc.)
Sin embargo
Gozan de “industry momentum” y en consecuencia muchas
empresas se decantan por su uso
Es una tecnología soportada por todos los fabricantes.
Ámbito de aplicación (y 2)
Integración de aplicaciones en Internet (B2B y
Mashups)
A pesar de sus inconvenientes frente a CORBA, el enfoque
de Servicios Web SOAP es ya el más utilizado en
integraciones B2B.
CORBA, RMI y DCOM tienen aún su espacio.
Sobre todo fuera del mundo corporativo (Mashups), REST es
muy utilizado, aunque SOAP tiene su espacio:
Como ya se ha dicho, un servicio REST es más fácil de invocar
que SOAP y, actualmente, tiene menos problemas de
interoperabilidad -> Mayor accesibilidad.
Sites como Google, Amazon,… ofrecen también API REST.
En la actualidad, el factor decisivo para su uso no suelen ser
las novedades en cuanto a patrones arquitectónicos.
Flujos inter-aplicación (1)
Los procesos de negocio se componen de múltiples
interacciones entre aplicaciones. Ejemplo: tratar incidencia
1.
2.
3.
Se obtienen los datos de la incidencia de la aplicación de
incidencias.
Se consulta a la aplicación de Facturación para ver si el cliente
está al día de los pagos.
Si lo está:
1.
2.
3.
4.
4.
Se envía los datos de la incidencia a la aplicación CRM.
Se invoca a la aplicación ERP para obtener un recurso que examinará
la incidencia (invocación asíncrona).
Cuando la incidencia ha sido evaluada, si se precisa una intervención
remota, se envía un mensaje a la aplicación B2B del instalador
escogido.
…
Si no lo está
1.
2.
La incidencia es rechazada.
…
Flujos inter-aplicación (y 2)
Sistemas EAI (Enterprise Application Integration):
Lógica de control inter-aplicación declarativa
Soporte para envío/recepción de mensajes síncronos y
asíncronos
Transacciones multi-aplicación
Soporte para la creación sencilla de “adaptadores” para las
aplicaciones existentes
Hasta ahora, soluciones poco basadas en estándares
En intranets son una realidad plenamente establecida
Evolución:
Los sistemas EAI están evolucionando para dar mayor
soporte a comunicaciones B2B
Los servicios web jugarán un papel crucial mediante los
estándares emergentes para la orquestación y la coreografía
de servicios web: WS-BPEL, BPML, etc.
Integración de datos distribuidos
Combinar automáticamente los datos procedentes de
diversas fuentes es difícil:
Heterogeneidad, Autonomía, Distribución,…
Actualidad:
Data Warehouse: son una realidad para aplicaciones batch
de generación de informes y análisis de tendencias con
datos intra-organización. No soportan:
Acceso a datos en tiempo real
Integración de datos en aplicaciones B2B
Enfoques emergentes:
EII (Enterprise Information Integration). Pretende
proporcionar acceso unificado en tiempo real a múltiples
fuentes de información tanto intra-organización como interorganización
Integración de datos distribuidos: Ejemplo
Vista unificada de cliente: Tabla (puede ser “virtual”)
que contenga los datos de los clientes junto con su
número de incidencias abiertas y su nivel de
facturación
Requiere obtener datos de clientes de ambas aplicaciones
CRM.
Deben cruzarse con los datos de los clientes con la
aplicación de incidencias y con los de la aplicación de
facturación.
SOA
SOA (Service Oriented Architecture)
Modelar arquitecturas de sistemas como un conjunto de
servicios poco acoplados (se minimizan las dependencias
entre ellos).
Los servicios definen formalmente sus operaciones mediante
un “contrato” independiente del lenguaje de programación.
De esta forma, los servicios pueden interoperar.
Para construir aplicaciones que combinen varios servicios se
apuesta por flujos inter-aplicación y/o tecnologías de
integración de datos.
El punto de vista SOA sobre la reusabilidad es de
granularidad gruesa: reusar servicios, no objetos.
Se hace énfasis en la fácil publicación y localización de
componentes reusables.
Aunque en teoría es independiente de la tecnología, se basa
fuertemente en las tecnologías de Servicios Web.