Tema 1: Introduccin a las tecnologas de integracin de aplicaciones

ndice

Introduccin

Integracin de Aplicaciones Modelo de referencia Historia: RPC, CORBA, JAVA RMI, DCOM, Servicios Web

Integracin de Plataforma

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

Introduccin (y 3)

Heterogeneidad: Razones

Decisiones de ingeniera

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 No es posible desecharlas y rehacerlas con las tecnologas ms modernas Es preciso seguir utilizndolas hasta amortizar su coste de desarrollo y obtener beneficio

Razones de coste

Aplicaciones antiguas

Modelo de referencia (1)

INTEGRACIN B2B

INTEGRACIN DE APLICACIONES Y PROCESOS

INTEGRACIN DE DATOS

INTEGRACIN DE PLATAFORMA

Modelo de referencia (2)

Integracin de Plataforma

Comunicacin de aplicaciones en diferentes mquinas. Independencia de localizacin, hardware, SO y lenguaje de programacin. Independencia de arquitectura de almacenamiento. Independencia de heterogeneidades de esquema/formato. Creacin rpida de aplicaciones basadas en aplicaciones existentes. Procesos de negocio modelados como flujos. Qu debemos considerar cuando las aplicaciones que se comunican pertenecen a organizaciones diferentes?

Integracin de Datos

Integracin de Aplicaciones / Procesos

Integracin B2B

Seguridad, minimizar acoplamiento, estndares sectoriales,

Modelo de referencia (y 3)
INTEGRACIN B2B

TEMA 4

INTEGRACIN DE APLICACIONES Y PROCESOS

TEMA 5

INTEGRACIN DE DATOS

TEMA 3

INTEGRACIN DE PLATAFORMA

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. Gestiona las incidencias detectadas por los clientes. Construida utilizando un paquete comercial que expone APIs C++. 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.

Aplicacin de gestin de incidencias.

Aplicacin ERP.

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++. 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).

CRM Clientes Hosting / Housing.

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 Sun RPC (Remote Procedure Call) DCE (Distributed Computing Environment) CORBA (Common Object Request Broker Architecture) JAVA RMI (Remote Method Invocation) Microsoft DCOM (Distributed Component Object Model). REST (REpresentional State Transfer) SOAP (Simple Object Access Protocol)

80s: Tecnologas de invocacin de procedimientos remotos

90s: Tecnologas de objetos distribuidos

00s: Tecnologas de Servicios Web

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)

Servidor aplicaciones web (Java)

Aplicacin standalone cliente (Delphi / VBasic)

HTTP

Navegador

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). Muy utilizado en la comunidad Microsoft. Difcil la interoperabilidad con el resto del mundo (JAVA).

DCOM. Solucin propietaria de Microsoft.

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. IIOP: Protocolo para permitir que diferentes sistemas que utilicen CORBA se comuniquen a travs de TCP/IP. Existen firewalls que no reconocen IIOP

Uso en Internet

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

Microsoft no fabrica implementaciones de CORBA

Servicios Web (1)

La Web proporciona un mecanismo de transporte universal, eficiente, robusto, escalable y probado tanto en aplicaciones inter-organizacin como intraorganizacin. 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. 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.

Servicios web REST.

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.) Integracin de aplicaciones heterogneas, configuracin de aplicaciones, generacin de la capa vista de una aplicacin web/WAP, bases de datos, etc.

Sus campos de aplicacin son innumerables

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

<?xml version=1.0> <InstallationManagement> <makeInstallation id=3098> <type product=cablemodem bandwidth=100/> <client name=John Smith> <address street=Real 16, 3 city=A Corua/> <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 intervencin 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 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)
<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 (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)

Registro UDDI Instalador-1 SOAP SOAP SOAP SOAP

Internet
SOAP

Instalador-2

...
Instalador-N

Operadora

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 Las APIs son estndares Forman parte de JEE Al igual que en CORBA, podemos cambiar de fabricante sin que afecte al cdigo fuente Las APIs forman parte de .NET

En el caso de Java

En el caso de los lenguajes de Microsoft

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. En el enfoque SOAP y el resto de enfoques derivados de RPC, manejamos directamente los objetos de nuestro lenguaje de programacin (Java, C++).

REST nos obliga a parsear el mensaje XML devuelto.

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.) Gozan de industry momentum y en consecuencia muchas empresas se decantan por su uso Es una tecnologa soportada por todos los fabricantes.

Sin embargo

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 incidencia
1.

2.

3.

Se obtienen los datos de la incidencia de la aplicacin de incidencias. Se consulta a la aplicacin de Facturacin para ver si el cliente est al da de los pagos. Si lo est:
1. 2.

3.

4.

Se enva los datos de la incidencia a la aplicacin CRM. Se invoca a la aplicacin ERP para obtener un recurso que examinar la incidencia (invocacin asncrona). Cuando la incidencia ha sido evaluada, si se precisa una intervencin remota, se enva un mensaje a la aplicacin B2B del instalador escogido. La incidencia es rechazada.

4.

Si no lo est
1. 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 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.

Evolucin:

Integracin de datos distribuidos

Combinar automticamente los datos procedentes de diversas fuentes es difcil:

Heterogeneidad, Autonoma, Distribucin, Data Warehouse: son una realidad para aplicaciones batch de generacin de informes y anlisis de tendencias con datos intra-organizacin. No soportan:

Actualidad:

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 interorganizacin

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.