Arquitectura Orientada a Servicios (SOA)

Presentación del tema: "Arquitectura Orientada a Servicios (SOA)"— 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
Implementaciones Tecnologías Frameworks Proyectos

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 Transacciones Seguridad Herramientas 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ón Monitoreo Seguridad Metadatos 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 Seguridad Transacciones

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 Servicios autónomos
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 Facturar Aplicación Cliente Obtener Facturación ItemFactura Factura

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 Agregación de servicios
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 Una Process Activity Entity Infraestructure 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 Infrastructure Services Entity Services Activity Services Process Services Legacy Datos Partner Componente

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 WebServices WebApplications Migrando aplicaciones WinForms

19 Migrando de aplicaciones SOA
Desde Hacia Orientación a Procesos Creada para el cambio Desarrollo e implantación incremental y en paralelo Orientación a Funciones Creada para durar Ciclos de desarrollo prolongados 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 Frameworks ASMX WSE
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 Productos Frameworks BizTalk EDRA MBI FABRIQ
Si bien está más orientado a la integración de aplicaciones Es un hub de mensajes extensible Frameworks EDRA MBI FABRIQ

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 EDRA=Shadowfax The EDRA uses four guiding principles to help ease the transition from tightly coupled distributed objects to standards-based, loosely coupled services: ● Separating the service interface from the internal service implementation to allow for deployment scenarios that are optimized for scalability, reliability, security, performance, and availability. ● Separating business logic from cross-cutting concerns such as logging, monitoring, or raising business events. (A cross-cutting concern is a type of functionality that can be applied to multiple classes or applications.) ● Separating business logic from the underlying transport so that multiple transports can be used to access a single service implementation. ● Developing stable service interfaces to ensure resiliency of deployed services. Microsoft developed the SDRA after talking with customers and reviewing solutions that were developed to solve similar problems on both the Microsoft® .NET and J2EE platforms. The SDRA provides the following: ● Architectural guidance describing how to address the preceding four principles. ● An extensible application framework that incorporates reusable assets to facilitate development of distributed applications using ASP.NET Web services, Microsoft Windows® operating system Message Queuing, Enterprise Services, and, in the future, Web Service Enhancements (WSE) and Indigo. ● Four QuickStart applications that demonstrate key capabilities of the framework. ● An application template to help you set up a development environment to implement services and build client applications that use the services.

24 ¿Que es MBI? MBI es un framework para crear, ejecutar y mantener aplicaciones corporativas basadas en plataforma Microsoft.NET 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 Microsoft Business Integrator es un framework desarrollado por la práctica de consultoría de Microsoft Argentina (MCS) en base a la experiencia recogida por su participación en diversos proyectos de desarrollo e integración de aplicaciones de negocio y su profundo conocimiento de la tecnología y las herramientas de Microsoft Corporation. Su objetivo principal es proveer un marco integrado que facilite la creación y administración de aplicaciones corporativas y de misión crítica utilizando herramientas y tecnologías provistas por Microsoft Corporation y basadas en un modelo de procesamiento distribuído. El modelo Microsoft Business Integrator profundiza el modelo propuesto por SOA, a través de una arquitectura mucho más detallada, prescriptiva y refinada, basada en la experiencia que ha acumulado Microsoft a través de sus servicios de consultoría y soporte (MCS y PSS). El objetivo, al igual que SOA es proveer una plataforma tecnológica robusta, confiable, económica y ágil. Este Marco Tecnológico abarca todos los componentes de los sistemas de información, sean estos técnicos u organizacionales y logra sus objetivos con las siguientes estrategias: Basado en EDRA: Primeramente conocido como Shadowfax es el nombre clave para "Enterprise Development Reference Architecture" (EDRA) que esta orientado a simplificar el desarrollo de aplicaciones distribuidas, proveyendo una serie de pautas estandarizadas de uso común en soluciones orientadas a proveer servicios de negocios. Profundizando el modelo de aplicación: - Proveyendo una fuerte separación en la capa de presentación de la lógica de navegación y el formateo de pantallas. - Facilitando el tratamiento de entidades persistentes en múltiples fuentes de datos y en aplicaciones externas. - Incluyendo soporte explícito para aspectos de integración de aplicaciones y de manejo del procesos de negocio. Construyendo una arquitectura técnica común: - Alineado al modelo. - Otorgando una solución común a problemas técnicos recurrentes. Transacciones, parametrización, usuarios, etc. - Proveyendo soporte nativo para la integración de aplicaciones. - Abstrayendo la plataforma técnica subyacente. Implementando un marco de trabajo: - Conjunto de herramientas y procesos que faciliten la construcción y administración de aplicaciones compatibles con la arquitectura propuesta. Es importante destacar que los niveles de productividad de un grupo de tecnología no están sólo focalizados en el desarrollo. Comúnmente cuando se plantea el problema de la productividad se piensa en el desarrollo, es por eso es que tradicionalmente se hace hincapié en aumentar la productividad a través de la reutilización de componentes (por ejemplificar un caso). Sin embargo los componentes no son las únicas piezas que una organización puede reutilizar. Los procesos, las herramientas, las buenas prácticas o incluso las cosas menos obvias también pueden ser reutilizados contribuyendo a la productividad total de la organización. Algunos ejemplos de elementos reutilizables, pero menos evidentes, son los planes de trabajo o templates de pruebas. Es por esto que MBI pretende ser una propuesta integral, que se extienda más allá de ser un conjunto de reglas y normativas de programación.

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 SOA EDRA (Shadowfax) MBI 3.0 Shadowfax + MBI 3.0
EDRA (Shadowfax) MBI 3.0 Shadowfax + MBI 3.0

28 Mas información http://msdn.microsoft.com/architecture