Tema 1: Introduccin a las tecnologas de integracin de aplicaciones

ndice

Introduccin Integracin de Aplicaciones Modelo de referencia

Integracin de Plataforma Historia: RPC, CORBA, JAVA RMI, DCOM, Servicios Web

SOAP El enfoque REST

Integracin de Aplicaciones / Procesos Gestin de flujos inter-aplicacin WS-BPEL (Web Services Business Process Execution

Language)

Integracin de datos

Introduccin (1)

Integracin de aplicaciones Hacer colaborar entre s a aplicaciones distribuidas,

heterogneas y posiblemente autnomas. Distribucin: las diferentes aplicaciones pueden ejecutarse

en mquinas conectadas a travs de una red: LAN Internet

Autonoma: El sistema de integracin no puede esperar que la aplicacin cambie su forma de actuar para facilitar la integracin Aplicaciones heredadas Aplicaciones de otros departamentos Aplicaciones de otras empresas (B2B)

Introduccin (2)

Heterogeneidad Mquinas: 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, MS-Windows (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.

Introduccin (y 3)

Heterogeneidad: Razones Decisiones de ingeniera

Diferentes personas eligen diferentes soluciones a un mismo problema

Razones de coste 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 tecnologas ms

modernas Es preciso seguir utilizndolas hasta amortizar su coste de

desarrollo y obtener beneficio

Modelo de referencia (1)

INTEGRACIN DE PLATAFORMA

INTEGRACIN DE DATOS

INTEGRACIN DE APLICACIONES Y PROCESOS

INTEGRACIN B2B

Modelo de referencia (2)

Integracin de Plataforma Comunicacin de aplicaciones en diferentes mquinas. Independencia de localizacin, hardware, SO y lenguaje de

programacin.

Integracin de Datos Independencia de arquitectura de almacenamiento. Independencia de heterogeneidades de esquema/formato.

Integracin de Aplicaciones / Procesos Creacin rpida de aplicaciones basadas en aplicaciones

existentes. Procesos de negocio modelados como flujos.

Integracin B2B Qu debemos considerar cuando las aplicaciones que se

comunican pertenecen a organizaciones diferentes? Seguridad, minimizar acoplamiento, estndares sectoriales,

Modelo de referencia (y 3)

INTEGRACIN DE PLATAFORMA

INTEGRACIN DE DATOS

INTEGRACIN DE APLICACIONES Y PROCESOS

INTEGRACIN B2B

TEMA 3

TEMA 5

TEMA 4

Ejemplo (1)

Una empresa de telecomunicaciones utiliza, entre otras, las siguientes aplicaciones: Aplicacin de Facturacin.

Tiene informacin sobre las facturas y los pagos de proveedores y clientes.

Construida enteramente en la organizacin en los 80 utilizando COBOL. Gestiona eficazmente miles de facturas cada mes, pero hay poco

personal capaz de modificarla.

Aplicacin de gestin de incidencias. Gestiona las incidencias detectadas por los clientes. Construida utilizando un paquete comercial que expone APIs C++.

Aplicacin ERP. Entre otras cosas, permite gestionar los recursos de la operadora, los

costes asociados a su uso, y los mrgenes de rentabilidad en sus actividades.

Construida utilizando un paquete comercial que expone APIs JAVA.

Ejemplo (2)

CRM Productos. Tiene informacin sobre los clientes de telefona, Internet y voz de la

operadora. Construido internamente utilizando un paquete comercial que expone

APIs C++.

CRM Clientes Hosting / Housing. Tiene informacin sobre empresas clientes de Hosting / Housing. La operadora slo ha empezado a ofrecer estos servicios

recientemente. Un nuevo departamento se ocupa de ello. Construida utilizando una aplicacin comercial online (e.g.

Salesforce.com, Sugarcrm.com). La aplicacin 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 aplicacin ofrece una interfaz Servicio Web SOAP para leer y modificar

los datos contenidos en la misma. La aplicacin tambin 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 Informtica para mantenerla !

Ejemplo (y 3)

Aplicacin 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 cul la operadora puede enviar ordenes de actuacin a Instaladores ACME a travs de un servicio web.

De esta forma, el proceso puede automatizarse.

Integracin de Plataforma (1)

Historia: 70s: Comunicacin de procesos en red

Sockets 80s: Tecnologas de invocacin de procedimientos remotos

Sun RPC (Remote Procedure Call) DCE (Distributed Computing Environment)

90s: Tecnologas de objetos distribuidos CORBA (Common Object Request Broker Architecture) JAVA RMI (Remote Method Invocation) Microsoft DCOM (Distributed Component Object Model).

00s: Tecnologas de Servicios Web REST (REpresentional State Transfer) SOAP (Simple Object Access Protocol)

NOTA: La influencia de cada tecnologa no se cie slo a la dcada mostrada en la transparencia. Ejemplo: CORBA, RMI, DCOM e incluso Sockets siguen en uso.

Ejemplo: Integracin de Plataforma

Ejemplo: para determinar la prioridad de una incidencia de un cliente, quiero saber cunto se le factura al cliente.

Incidencias(C++)

Facturacin(COBOL)

Aplicacin standalonecliente

(Delphi / VBasic)

Servidor aplicacionesweb (Java)

Navegador

HTTP

Integracin de Plataforma (2)

Comunicacin 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 topologa de la red, plataforma hardware, SO o

lenguaje de programacin.

Visin 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.

Integracin de Plataforma (3)

Invocacin 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 parmetros se describen en un fichero de

definicin 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 definicin.

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, enva un mensaje al servidor y recibe la respuesta del mismo.

Visin orientada a programacin estructurada (paradigma dominante en los 80), no a programacin OO.

Tecnologa dominante: SUN RPC.

Integracin de Plataforma (4)

Tecnologas de objetos distribuidos Conceptualmente muy similar a RPC. Cada nodo de la red puede exponer una serie de objetos.

Permiten la invocacin de mtodos de objetos remotos. Utiliza el paradigma de programacin OO (dominante en los

90 y hasta la actualidad). JAVA RMI. No proporciona independencia del lenguaje de

programacin (debe utilizarse JAVA). Por su facilidad de uso gan gran aceptacin en la comunidad

JAVA. Sigue siendo un building block importante en la arquitectura JEE

(Java Platform Enterprise Edition).

DCOM. Solucin propietaria de Microsoft. Muy utilizado en la comunidad Microsoft. Difcil la interoperabilidad con el resto del mundo (JAVA).

Integracin de Plataforma (y 5)

Tecnologas de objetos distribuidos CORBA

Estandarizado por el OMG (http://www.omg.org). Consorcio constituido por un gran nmero de empresas (Iona, Borland, HP, IBM, Oracle, Sun, etc.)

Las APIs estn estandarizadas -> El desarrollador no depende de un fabricante.

Existen mltiples implementaciones de distintos fabricantes para las plataformas y lenguajes ms usuales (C++, Java, Ada, COBOL, C, Smalltalk, etc.).

El OMG ha estandarizado numerosos servicios CORBA tiles para cualquier aplicacin: Servicio de nombres Seguridad Transacciones

mbito de aplicacin de CORBA

CORBA ha sido y contina siendo una buena tecnologa para abordar integraciones complejas en intranets Eficiente y probado Buen soporte para seguridad, transacciones, comunicacin basada

en eventos, etc.

Uso en Internet IIOP: Protocolo para permitir que diferentes sistemas que utilicen

CORBA se comuniquen a travs 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 tecnologas de Microsoft los tienen

Existen tneles 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 tecnologas de Microsoft usen CORBA

Servicios Web (1)

La Web proporciona un mecanismo de transporte universal, eficiente, robusto, escalable y probado tanto en aplicaciones inter-organizacin como intra-organizacin.

Muchas de las tecnologas comentadas hasta el momento fueron diseadas antes de la emergencia de la Web o no fueron especficamente diseadas 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 operacin que recibe ciertos parmetros y devuelve un resultado, quizs efectuando alguna accin por el camino.

Estn basados en tecnologas surgidas alrededor de la Web: Tpicamente, 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

tpicamente mediante XML.

Servicios Web (3)

Suele distinguirse entre dos estilos de servicios web: Servicios web SOAP.

Aaden un nuevo conjunto de protocolos (SOAP) y lenguajes para permitir RPCs y envo de mensajes entre aplicaciones a travs de la web.

Estandarizados por el W3C. Suelen utilizar HTTP como mecanismo de transporte, pero no

obligatoriamente.

Servicios web REST. No aaden nuevos protocolos ni lenguajes: utilizan solamente

HTTP 1.1 y formatos como XML para especificar mensajes. Pueden utilizarse para implementar RPCs, pero tambin dan

soporte a un nuevo estilo arquitectnico para disear aplicaciones distribuidas (Servicios Web REST puros o RESTful Web Services.

XML

Lenguaje de tags (similar en sintaxis a HTML) Permite expresar informacin estructurada y fcilmente

parseable por una aplicacin Estandarizado por el W3C ( http://www.w3.org) Es extensible:

XML no impone un conjunto de tags, sino slo 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 raz, los tags pueden tener atributos, etc.)

Sus campos de aplicacin son innumerables Integracin de aplicaciones heterogneas, configuracin de

aplicaciones, generacin de la capa vista de una aplicacin web/WAP, bases de datos, etc.

XML: Ejemplo (1)

La operadora podra enviar el siguiente texto sobre HTTP (o HTTPS) a Instaladores Acme

Elegimos HTTP (o HTTPS) porque todos los firewalls lo soportan

Llamar antes. Mejor por la tarde

XML: Ejemplo (y 2)

Cuando Instaladores Acme acepta realizar la orden de intervencin puede contestar con algo del estilo:

NOTA: Este es un ejemplo de servicio web REST. En Servicios SOAP XML t bi tili t

Servicios Web SOAP (1)

WSDL (Web Services Description Language) Permite especificar en XML las operaciones, parmetros y

tipos de datos de un servicio web. La idea es similar al fichero de definicin de RPC.

SOAP (originalmente Simple Object Access Protocol) Protocolo basado en XML para envo de mensajes

estructurados (objetos) Normalmente funciona sobre HTTP (tambin SMTP, JMS,). Cuando un cliente invoca una operacin de un servicio,

enva un mensaje SOAP indicando la operacin a invocar y los valores de los parmetros.

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)

Servicios Web SOAP (3)

UDDI (Universal Description, Discovery andIntegration of Web Services) Protocolo para interaccionar con un servidor (registro UDDI)

que proporciona operaciones (va SOAP) para registrar y buscar servicios web

Cada servicio web se registra dando, su nombre, una descripcin del servicio (ej.: la URL de su WSDL, una descripcin textual, etc.), etc.

Especificacin: http://www.uddi.org

Servicios web SOAP (y 4)

Instalador-1

Instalador-N

Instalador-2

...

SOAP

SOAP

SOAP

Internet

Registro UDDI

Operadora

SOAP

SOAP

APIs para Servicios web SOAP

Existen APIs (comerciales y gratuitas) para los lenguajes ms usuales.

Generan WSDL desde el lenguaje deseado. Partiendo del WSDL, generan Stubs y Skeletons. En general, las APIs no son estndares, sin embargo,

no afecta a la interoperabilidad La interoperabilidad es posible porque los protocolos (SOAP,

WSDL, UDDI) estn estandarizados En el caso de Java

Las APIs son estndares Forman parte de JEE Al igual que en CORBA, podemos cambiar de fabricante sin

que afecte al cdigo fuente En el caso de los lenguajes de Microsoft

Las APIs forman parte de .NET

REST (1) REpresentational State Transfer. Estilo arquitectnico propuesto

por Roy Fielding en 2000. RPC, CORBA, RMI, DCOM,, incluso SOAP: el mismo perro con

distinto collar? Mucha gente piensa que la arquitectura de las aplicaciones

distribuidas no ha cambiado significativamente en 25 aos. La Web es, sin duda, la aplicacin distribuida ms exitosa de la

historia, y no sigue esa arquitectura. REST: Estilo arquitectnico para construir aplicaciones

distribuidas inspirado en las caractersticas de la web. 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 sinnimo de servicios web que, en lugar de las tecnologas SOAP, utilizan directamente HTTP y XML (aunque sea al viejo estilo).

Ejemplo: Invocacin a Instaladores Acme.

REST (y 2)

En el enfoque REST el protocolo de transporte es siempre HTTP SOAP puede utilizar diferentes mecanismos de transporte: HTTP,

SMTP, JMS pero casi siempre se usa 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 programacin (Java, C++).

Tener un protocolo por encima de HTTP (SOAP) nos permite tener un lugar donde incluir informacin para manejar aspectos como seguridad, transacciones, Sin embargo, hoy en da, estas funcionalidades an no estn

disponibles en SOAP.

Muchas veces se utiliza REST no tanto por sus ventajas arquitectnicas (que, en ocasiones, se ignoran) sino porque:

Es ms fcil invocar un servicio REST que un servicio SOAP. Hay problemas de interoperabilidad en las implementaciones de SOAP.

Las tecnologas HTTP / XML son inter-operables universalmente.

mbito de aplicacin de servicios web (1)

Integracin 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 tecnologa soportada por todos los fabricantes.

mbito de aplicacin (y 2)

Integracin de aplicaciones en Internet (B2B y Mashups) A pesar de sus inconvenientes frente a CORBA, el enfoque

de Servicios Web SOAP es ya el ms utilizado en integraciones B2B. CORBA, RMI y DCOM tienen an 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 ms fcil de invocar

que SOAP y, actualmente, tiene menos problemas de interoperabilidad -> Mayor accesibilidad.

Sites como Google, Amazon, ofrecen tambin API REST. En la actualidad, el factor decisivo para su uso no suelen ser

las novedades en cuanto a patrones arquitectnicos.

Flujos inter-aplicacin (1)

Los procesos de negocio se componen de mltiples interacciones entre aplicaciones. Ejemplo: tratar incidencia1. Se obtienen los datos de la incidencia de la aplicacin de

incidencias.2. Se consulta a la aplicacin de Facturacin para ver si el cliente

est al da de los pagos.3. Si lo est:

1. Se enva los datos de la incidencia a la aplicacin CRM.2. Se invoca a la aplicacin ERP para obtener un recurso que examinar

la incidencia (invocacin asncrona). 3. Cuando la incidencia ha sido evaluada, si se precisa una intervencin

remota, se enva un mensaje a la aplicacin B2B del instalador escogido.

4.

4. Si no lo est1. La incidencia es rechazada.2.

Flujos inter-aplicacin (y 2)

Sistemas EAI (Enterprise Application Integration): Lgica de control inter-aplicacin declarativa Soporte para envo/recepcin de mensajes sncronos y

asncronos Transacciones multi-aplicacin Soporte para la creacin sencilla de adaptadores para las

aplicaciones existentes Hasta ahora, soluciones poco basadas en estndares En intranets son una realidad plenamente establecida

Evolucin: Los sistemas EAI estn evolucionando para dar mayor

soporte a comunicaciones B2B Los servicios web jugarn un papel crucial mediante los

estndares emergentes para la orquestacin y la coreografa de servicios web: WS-BPEL, BPML, etc.

Integracin de datos distribuidos

Combinar automticamente los datos procedentes de diversas fuentes es difcil: Heterogeneidad, Autonoma, Distribucin,

Actualidad: Data Warehouse: son una realidad para aplicaciones batch

de generacin de informes y anlisis de tendencias con datos intra-organizacin. No soportan: Acceso a datos en tiempo real Integracin de datos en aplicaciones B2B

Enfoques emergentes: EII (Enterprise Information Integration). Pretende

proporcionar acceso unificado en tiempo real a mltiples fuentes de informacin tanto intra-organizacin como inter-organizacin

Integracin de datos distribuidos: Ejemplo

Vista unificada de cliente: Tabla (puede ser virtual) que contenga los datos de los clientes junto con su nmero de incidencias abiertas y su nivel de facturacin Requiere obtener datos de clientes de ambas aplicaciones

CRM. Deben cruzarse con los datos de los clientes con la

aplicacin de incidencias y con los de la aplicacin de facturacin.

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 programacin. De esta forma, los servicios pueden interoperar.

Para construir aplicaciones que combinen varios servicios se apuesta por flujos inter-aplicacin y/o tecnologas de integracin de datos.

El punto de vista SOA sobre la reusabilidad es de granularidad gruesa: reusar servicios, no objetos.

Se hace nfasis en la fcil publicacin y localizacin de componentes reusables.

Aunque en teora es independiente de la tecnologa, se basa fuertemente en las tecnologas de Servicios Web.