La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Arquitectura Orientada a Servicios (SOA) Diego González - CTO Hernán de Lahitte - arquitecto

Presentaciones similares


Presentación del tema: "Arquitectura Orientada a Servicios (SOA) Diego González - CTO Hernán de Lahitte - arquitecto"— Transcripción de la presentación:

1 Arquitectura Orientada a Servicios (SOA) Diego González - CTO Hernán de Lahitte - arquitecto

2 Agenda Orígenes de SOA Principios fundamentales Diseño de aplicaciones ImplementacionesTecnologíasFrameworksProyectos

3 Orígenes de SOA Arquitectura de aplicaciones distribuidas Cliente-Servidor Separación del origen de datos Modelo tres capas Objetos distribuidos Arquitectura de Web Services Modelo stateless Nuevos lenguajes de programación Utilización de patrones de diseño

4 Orígenes de SOA Integración de aplicaciones Reutilización limitada de funcionalidad Distintas plataformas Distintos lenguajes Limitaciones técnicas de integración entre plataformas TransaccionesSeguridadHerramientas Futuro desafío en el diseño de aplicaciones Composición integral de aplicaciones

5 Orígenes de SOA Requerimientos no funcionales que aplican a toda la organización AdministraciónMonitoreoSeguridadMetadatos Aparición de Aspect Oriented Programming Proponiendo el concepto Cross-Cutting Concerns Intercepción como base de la extensibilidad

6 Orígenes de SOA Objetos distribuidos Han demostrado necesitar mucho más desarrollo teórico Tiempo de vida Circulación de referencias Diversidad de tecnologías Estándares muy dependientes de la plataforma Dificultad para acordar alcances Quien se encarga de SeguridadTransacciones

7 Orientación a servicios Centrado en el concepto de servicio Las aplicaciones exponen y consumen servicios Un servicio es Unidad atómica de funcionalidad reutilizable Definen claramente su interfaz Requerimientos no funcionales son independientes de la plataforma

8 Leyes (tenets) de SOA Limites explícitos Qué hace y que no hace un servicio? Servicios autónomos Autocontenidos e independientes de otros servicios Interfaz como esquema y no como clases Exponer sus requerimientos como estructura de datos y contratos Compatibilidad basada en políticas Qué requiere de quien lo consume?

9 No leyes de SOA Invocación puede ser sincrónica o asincrónica Interacción orientada a mensajes Transparencia de ubicación de servicios Catálogo de servicios

10 Modelo de Dominio/Tabla Una interfaz por delante del modelo de dominio. Producto Cliente Factura ItemFactura Aplicación Facturar Obtener Facturación

11 Ventajas Fuerte separación entre capas o loosely coupled applications Separación tecnológica Declaración de los requerimientos no funcionales Administración unificada Con una única herramienta que administra servicios Transparencia de locación Reusabilidad simplificada

12 Ventajas Exposición de servicios granatizados En lugar de exponer clases o interfaces que pueden ser mal usadas Agregación de servicios Un servicio puede agregar a otros servicios para garantizar atomicidad Composición de lógica de negocio Intercepción como base de la extensibilidad Buenos niveles de escalabilidad Paralelismo en el desarrollo

13 Requerimientos Definición de servicios independientemente de la implementación, ubicación o uso Implementación y provisión de servicios como proveedor Localización y uso de servicios como consumidor Composición de servicios a partir de otros servicios y relglas de negocio Servicios internos y externos Soporte de interacción sincrónica y asincrónica Orquestación de UI basadas en servicios y reglas de ngocio Soporte para múltiples formas de interacción humana Transformación de datos automáticos entre distintas estructuras de datos. Soporte para simulación, prueba y depuración de servicios

14 Diseño de aplicaciones SOA Identificación de servicios Identificar los procesos a partir de los casos de uso Definir los servicios que se utilizan durante los procesos detectados Determinar una jerarquía de servicios en función de la reusabilidad interna y externa Crear servicios externos que componen servicios internos Evitar la proliferación de servicios Limitar los servicios a los requeridos por los procesos

15 Diseño de aplicaciones SOA Categorización de servicios UnaProcessActivityEntityInfraestructure XWIF Service Model Utility service Business service Controller service Proxy service Wrapper service Coordination service (for atomic transactions) Process service Coordination service (for business activities)

16 Categorización de servicios Clientes o agentes Entity Services Activity Services Process Services Datos Componente Partner Legacy Infrastructure Services

17 Diseño de aplicaciones SOA Diseño de los mensajes Una vez definidos los servicios ajustar los mensajes utilizados Como hacer aplicaciones clientes de SOA No asumir conectividad contínua ni servicios relacionados (seguridad, transacciones) Mapping Mensajes y entidades Diseñando interfaces de usuario SOA Soporada por servicios de UI Solo interactúa con el servidor cuando finaliza la operación. Coarse-Grained interaction.

18 Migrando aplicaciones a SOA Considerar una arquitectura con concepto de servicios Migrando componentes COM.Net Migrando ASP.NET WebServicesWebApplications Migrando aplicaciones WinForms

19 Migrando de aplicaciones SOA Orientación a Funciones Creada para durar Ciclos de desarrollo prolongados DesdeHacia Orientación a Procesos Creada para el cambio Desarrollo e implantación incremental y en paralelo Silos de Aplicaciones Acoplamiento Fuerte Orientación a Objetos Implementación Conocida Soluciones Orquestadas Acoplamiento Débil Orientación a Mensajes Abstracción

20 Ciclo de vida de aplicaciones Como se llega a SOA Integración de aplicaciones Nueva aplicación con nueva arquitectura Nueva interfaz para una aplicación existente Mantenimiento de aplicaciones Las aplicaciones cambian Exponer servicios evita mal uso de las clases Constante reutilización de servicios

21 Implementación FrameworksASMX Formato nativo.Net para exposición de WebServices Totalmente integrado con Visual Studio.NET Soporta únicamente HTTP (IIS + ASP.NET) WSE Permite crear servicios o clases proxy a servicios remotos Fácilmente extensible e interceptable No asume protocolo HTTP

22 Implementación ProductosBizTalk Si bien está más orientado a la integración de aplicaciones Es un hub de mensajes extensible FrameworksEDRAMBIFABRIQ

23 ¿Que es EDRA (Shadowfax)? Es una Guía de Arquitectura para estandarizar el desarrollo de sistemas distribuidos Es un Framework de Aplicaciones Extensible el cual incorpora recursos de la plataforma; ASP.NET-WS, MSMQ, Enterprise Services, Remoting, WSE Es una Implementación de Referencia que usa el Framework en un modelo bancario Es una iniciativa (PAG) apoyada en un fuerte feedback de la comunidad y la industria

24 ¿Que es MBI? Resuelve escenarios recurrentes de una empresa corporativa Es una arquitectura de referencia para la construcción de aplicaciones Incorpora mejores prácticas de Microsoft Corporation Arquitectura de integración común a todos los Portfolios de Soluciones Reducción de costos de desarrollo y mantenimiento MBI es un framework para crear, ejecutar y mantener aplicaciones corporativas basadas en plataforma Microsoft.NET

25 Shadowfax + MBI = MBI 3.0 Definición Implementación prescriptiva de Shadowfax Revisada por el equipo de PAG de Microsoft Corp. MBI 3.0 complementa a Shadowfax en escenarios que Shadowfax aún no resuelve MBI 3.0 implementa como componente central a Shadowfax MBI & Shadowfax proveen el contexto adecuado para la construcción de aplicaciones orientadas a servicios

26 ¿Que es FABRIQ? Q.NET + EntServices + WSE + SOA + HPC + Agent Arquitectura para el desarrollo de aplicaciones SOA en.Net de alta performance soportado sobre un modelo de redes de colas distribuidas interconectadas. Una aplicación que utiliza las mejores prácticas de WSE 2.0 Un frámework agil para la implementación de agentes Para Permitir la adopción de modelos asincrónicos de computación a la comunidad de desarrolladores y arquitectos. Mejorar el camino hacia Indigo para la comunidad.Net. Desarrollado por Arvindra Sehmi, MS EMEA, DPE – Project Lead Clemens Vasters, newtelligence AG – Architect Lead Eugenio Pace, MS Argentina, MCS – Development Lead

27 Mas información SOAhttp://msdn.microsoft.com/architecturehttp://msdn.microsoft.com/practiceshttp://msdn.microsoft.com/webservices EDRA (Shadowfax) MBI 3.0 orkspace.aspx?id= f b09c6 Shadowfax + MBI 3.0

28 Mas información


Descargar ppt "Arquitectura Orientada a Servicios (SOA) Diego González - CTO Hernán de Lahitte - arquitecto"

Presentaciones similares


Anuncios Google