arquitectura de proyectos de it -...

Arquitectura de Proyectos de IT

Arquitecturas de Integración

© 2006

Ing. Gastón EscobarIng. Nicolás PasseriniIng. Juan AriasIng. Santiago Blanco

Agenda� Enterprise Architecture� Integración de Sistemas� Evolución histórica� Métodos de integración� Mecanismos de integración� Conceptos de mensajería� Web Services

–Conceptos

2Arquitectura de Proyectos de IT

Conceptos

–Estándares� Web Services� REST

Enterprise Architecture

� Es la lógica organizadora de los procesos de negocio y la infraestructura IT, reflejando los requerimientos de integracióny estandarización que permitan seguir la estrategia empresarial.

� Es necesario definir– Sistemas interactuando

3Arquitectura de Proyectos de IT

– Sistemas interactuando

– Forma de interacción

– Mecanismos de interacción

� La estrategia de la empresa es lograda mediante la interacción de todos los sistemas componentes de la EA.

Integración de Sistemas

� Porque?– Una arquitectura empresarial esta formada por distintas soluciones

SW, que deben interactuar -> Implementación de lo mejor para cada situación

– Crear aplicaciones no es fácil -> La solución completa la dan todos en conjunto

4Arquitectura de Proyectos de IT

en conjunto

� Queremos integrar:– Personas

– Procesos

– Información

� Tipos de integración– Aplicación a aplicación

– Aplicaciones con personas

– Personas entre si

– Empresas entre si

– …

Definición

“La integración de sistemas significa el compartir datos y procesos de negocio en forma irrestricta entre distintas aplicaciones interconectadas…”

Gartner Group

A lo que podemos agregarle:

5Arquitectura de Proyectos de IT

A lo que podemos agregarle:

“…De forma tal que cada proceso de negocio o porción de datos sea implementado de la mejor manera por la aplicación mas adecuada, y compartido al resto”

Tener en cuenta

� Performance– Latencia de red, tiempo de interpretación de mensajes

� Disponibilidad– Los puntos de comunicación deben estar disponibles cuando se

requieran

� Seguridad

6Arquitectura de Proyectos de IT

� Seguridad– Va en contra de la performance

– Las interfaces deben ser utilizadas por quienes esten habilitados

� Robustez– Transactionabilidad

– Entrega asegurada

Evolución Histórica

Monolíticos EAI BPM + EDA

7Arquitectura de Proyectos de IT

Distribuidos SOA

90´s 2000 2005+ 2008+

Sistemas distribuidos

� Integración punto a punto� Fácil de implementar� Se acuerda la forma de integración entre las partes� Cada cliente conoce al servidor de la funcionalidad� Las conexiones entre las aplicaciones son “duras”

8Arquitectura de Proyectos de IT

Enterprise Application Integration

� EAI es el proceso de crear una infraestructura integrada para unir sistemas dispares, a través de una empresa.

� Nace de la necesidad de integrar sistemas heterogéneos como ERP, CRM, etc.

� Comprende– Aceptación de mensajes

– Transformación

TraducciónCRM

9Arquitectura de Proyectos de IT

– Traducción

– Ruteo

– Entrega de mensajes

� Topologías– HUB/Spoke

– BUS

EAI

CRM

ERP

VentasHR

…

Enterprise Service Bus

� Es un patrón de arquitectura.

� Provee una infraestructura que elimina cualquier conexión directa entre los consumidores y los proveedores de los servicios.

� Infraestructura común para invocaciones, mensajes y eventos.

10Arquitectura de Proyectos de IT

� Basado en estándares (JMS, SOAP, etc.)

ESB – Capacidades mínimas

� Communications– Routing, addressing, request/response, publish/subscribe, …

� Integration– Adapters, protocol transformation, …

11Arquitectura de Proyectos de IT

� Service interaction– Service Interface definition, substitution of service

implementation, …

� Management– Administration Capability

SOA

� Es un enfoque basado en el concepto de Servicios. Las necesidades y funciones de infraestructura requeridas para crear sistemas distribuidos son provistos como servicios que entregan, en forma individual o colectiva, funcionalidad para aplicaciones u otros servicios.

12Arquitectura de Proyectos de IT

“SOA consists of best practices, plus the discipline to follow them. Expecting to get architecture by buying software is about as likely as

learning to play Mozart by buying a piano.”

Source: ZapThink

Principios SOA

Principios SOA

Alineación con el negocio

Enfoques arquitectónicos

•Reducción de costo•Mejora del servicio•Oportunidades de negocio

•SOA<>ESB•SOA<>Productos•Abstracción•Encapsulamiento•Independencia

13Arquitectura de Proyectos de IT

Gobierno

Se requiere un soporte de la organización, ya que

supone no solo un cambio técnico, sino

organizacional

SOA - Conceptos

� SOA != Web Services� SOA no existe en una caja� Lo mas importante es el concepto de orientación a servicios

� Es aplicable en contextos empresariales– No se debe pensar un sistema isolado orientado a servicios

14Arquitectura de Proyectos de IT

– No se debe pensar un sistema isolado orientado a servicios

– Utilizar servicios para Comunicación

� Principios– Un sistema es una entidad proveedora de servicios

– Los servicios deben ser fácilmente ubicables

– Los servicios deben tener un contrato claro

BPM + CEP

� BPM (Business Process Management)– Metodologías, herramientas y prácticas para gestionar procesos de

negocio.

– Los procesos son la interacción entre sistemas y personas, o personas entre si, aplicando reglas de negocio

– Desarrollarlos, administrarlos y mantenerlos no es trivial

15Arquitectura de Proyectos de IT

– Desarrollarlos, administrarlos y mantenerlos no es trivial

– Se complementan con los Business Rules Engine

� EDA (Event Driven Architecture)– Se basa en el concepto de eventos como disparadores de acciones

– Los eventos son cambios de estado con significado de ser atendidos

– Complemento a SOA

– Estilos: Simple, Encadenados, Complejos

Métodos de integración

Application Level

User Interface Level

16Arquitectura de Proyectos de IT

Data Level

Method Level

Métodos de integración

� User interface level

– Esta integración se realiza generalmente con la aplicación final que el usuario está operando.

– Se usa en casos en que el acceso directo a la base de datos no es

17Arquitectura de Proyectos de IT

– Se usa en casos en que el acceso directo a la base de datos no es fácil o no es posible. También se usa cuado la lógica de negocios está embebida en la UI.

– Por lo general se usa como la última posibilidad.

� Ejemplos– http://www.kapowtech.com

– http://www.openspan.com

� Application Level

– Estas interfaces dan acceso a servicios provistos por una aplicación particular o un paquete de servicios.

– Por lo general es considerada la mejor forma de acceder (es

Métodos de integración

18Arquitectura de Proyectos de IT

– Por lo general es considerada la mejor forma de acceder (es transparente para la aplicación y preserva la integridad de datos de la aplicación)

– JCA: J2EE Connector Architecture

Métodos de integración

� Method Level

– Este nivel se puede tomar como un subconjunto del anterior. Consiste en la posibilidad de compartir una serie de métodos comunes. Estos métodos pueden ser agrupados en un servidor central o estar distribuidos. Esta orientado a la reutilización de métodos.

19Arquitectura de Proyectos de IT

métodos.

– Este nivel requiere la posibilidad de realizar llamadas remotas a los métodos (como RPC) en las aplicaciones integradas

Métodos de integración

� Data Level

– Este nivel de integración se realiza entre los repositorios de datos de las aplicaciones a integrar.

– Push-based: llamadas a otra base de datos mediante links o stored

20Arquitectura de Proyectos de IT

– Push-based: llamadas a otra base de datos mediante links o stored procedures.

– Pull-based: se maneja con triggers y polling. Con los primeros se capturan eventos, y a partir de ahí se escribe información en tablas que actúan de intefarce.

Mecanismos de integración

� Puntuales / on line

– http/xml

– WebServices

– REST

– Colas / Mensajería

21Arquitectura de Proyectos de IT

Colas / Mensajería

– Archivos

– Base de datos

– Socket

– CORBA

� Masivos / off-line

– Colas / Mensajería

– Archivos

– Base de Datos

– ETL

Conceptos de Mensajería

� Permite� Transmisión segura� Mensajería asíncrona

� Se basa en el intercambio de mensajes

� Partes

22Arquitectura de Proyectos de IT

� Partes� Emisor� Receptor� Canal

Síncrono y Asíncrono

� Sincronismo– Comunicación directa

– Todas las partes involucradas estan presentes en el mismo momento.

– Ejemplos: http

23Arquitectura de Proyectos de IT

� Asincronismo– No requieren que todas las partes involucradas esten presentes al

mismo momento.

– Fire and Forget

– Ejemplos: e-mail, jms

� ¿Cuándo usar uno y otro?

Qué es un WebService?

� Es una colección de protocolos y estándares utilizados para intercambiar datos entre aplicaciones.

� Permiten comunicar aplicaciones por medio de los mismos protocolos que soportan Internet

� Son independientes de la plataforma� Son independientes del protocolo

OrientaciónOrientaciónA ServiciosA Servicios

(Hoy)(Hoy)

24Arquitectura de Proyectos de IT

� Son independientes del protocolo� Están ampliamente aceptados� Basados en estándares

– Especificaciones WS-*

Basado en ClasesPolimorfismo

Encapsulamiento

Basado en InterfacesCarga Dinámica

Metadatos enejecución

Basado en MensajesSchema+Contrato

Ligados vía Políticas

OrientaciónOrientacióna Objetosa Objetos(1980s)(1980s)

ComponentesComponentes(1990s)(1990s)

(Hoy)(Hoy)

Web Services - Standards

� WSDL� SOAP� UDDI� WS-Security� WSRP� WS-Coordination

25Arquitectura de Proyectos de IT

� WS-Coordination� WS-Transactions� BPEL4WS� WS-Policy

REST

� REpresentational State Transfer

� Basado en el concepto de recursos

� Interface Uniforme– Todos responden a los mismos métodos (ej. HTTP)

26Arquitectura de Proyectos de IT

– Todos responden a los mismos métodos (ej. HTTP)

� Una alternativa a WS-*

� HTTP <> REST– Muchas aplicaciones HTTP no siguen los principios REST

REST

� Principios– Todo recurso tiene un ID

– URI (http://apit.edu.ar/clases/integracion)

– Unir los recursos relacionados

– A través de sus Ids

Utilizar métodos estándares

27Arquitectura de Proyectos de IT

– Utilizar métodos estándares

– Basado en la especificacion HTTP (GET, POST, PUT, DELETE)

– Los recursos pueden tener multiples representaciones

– Para diferentes necesidades

– Utilizan comunicación stateless

– Mayor escalabilidad, independencia client - server

Puntos a tener en cuenta

� Disponibilidad de los datos� Momento en que son necesarios los datos� Transaccionalidad� Modificabilidad� Modelo canónico de entidades� Seguridad

28Arquitectura de Proyectos de IT

� Seguridad� Multiples plataformas� Sincronismo / Asincronismo� Existencia de contratos estándares por industria

– SID

– N7

Conclusiones

� Siempre caemos en la necesidad de integrar aplicaciones

� Existen diferentes formas de implementar la integración

� Para seleccionar la mas adecuada, debemos tener en cuenta muchas cuestiones

29Arquitectura de Proyectos de IT

muchas cuestiones

� Lo mas importante, es no ir siempre por la mas fácil o acostumbrada, sino tener un criterio que nos permita elegir la mejor alternativa

Bibliografía

� http://www.enterprise-architecture.info

� http://www.opengroup.org/architecture/togaf/

� Enterprise Integration Patterns – Designing, Building and

30Arquitectura de Proyectos de IT

� Enterprise Integration Patterns – Designing, Building and Deploying Messaging Solutions; Martin Fowler; Addison Wesley

� http://www.infoq.com/rest

� http://www.infoq.com/webservices