El documento proporciona una introducción a la arquitectura orientada a servicios (SOA), definiendo conceptos clave como servicios, composiciones e inventario de servicios. Explica que SOA es un paradigma de diseño que se orienta al negocio y la organización, permitiendo automatizar procesos a través de la reutilización de servicios. También destaca las ventajas de SOA como la agilidad, eficiencia y alineación entre TI y el negocio.

1. ARQUITECTURA ORIENTADA A SERVICIOS (SOA)

2. CONCEPTOS BÁSICOS INGENIERÍA DE SOFTWARE DISCIPLINAS DE INGENIERÍA DE SOFTWARE DISEÑO DE SOFTWARE PARADIGMAS DE DISEÑO SOA

3. Ingeniería de Software Definición 1: Ingeniería del Software es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software [Zelkovits, 1978]. Definición 2: Ingeniería del Software es la aplicación practica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación necesaria requerida para desarrollar, operar(funcionar) y mantenerlos [Bohem, 1976]. Definición 3: Ingeniería del Software trata del establecimiento de los principios y métodos de la Ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales [Bauer, 1972].

4. Un Modelo para procesos de Ingeniería de SW

5. Disciplinas y Enfoque Iterativo de RUP

6. Diseño de Software Después de comprender los requerimientos, el diseño es el MAPA de cómo construir el sistema Un principio de diseño es un lineamiento de diseño comúnmente aceptado que cuando se aplica resulta en características específicas de diseño Un paradigma de diseño representa un conjunto de principios de diseño complementarios que colectivamente se aplican para soportar objetivos comunes Un patrón de diseño identifica un problema común y proporciona una solución recomendada Un estándar de diseño es una convención interna y específica para una organización, para regir sus diseños

7. Paradigmas de Diseño

8. Paradigmas de Diseño Bajo Nivel (Binario) Bulbos, Tarjetas perforadas Bajo Nivel (Ensamblador) Mnemónicos para funciones Direcciones de memoria con etiquetas. 10100001111101010101

9. Paradigmas de Diseño Lenguajes Procedurales Uso de vocabulario relativo al problema en resolución Describen paso-a-paso el procedimiento EXACTO para resolver un problema. La realidad debe modelarse con base en las capacidades del lenguaje. Difícil de comprender para no-programadores. COBOL, FORTRAN, ALGOL, BASIC Ejemplo:

10. Paradigmas de Diseño Lenguajes Orientados a Objetos Los datos y los métodos para manipularlos se encapsulan en una unidad conceptual llamada objeto. Permiten modelar la realidad, adaptando el código a la misma. La syntaxis es my natural y comprensible incluso para no programadores. Grandes capacidades de reuso de código, agilidad para desarrollar y aplicar cambios. JAVA, .NET Ejemplo:

11. ¿Y SOA? También es un paradigma de diseño Pero se orienta a la organización y al NEGOCIO, no al paradigma de programación.

12. Imperativos de Negocio…….La Tormenta Perfecta Presiones Competitivas Presiones Regulatorias Poder del Cliente Sobrecarga de Información La Fuerza Cambiante de Trabajo

13. Imperativos y Facilitadores de Negocio…….La Tormenta Perfecta Presiones Competitivas Presiones Regulatorias Poder del Cliente Sobrecarga de Información La Fuerza Cambiante de Trabajo SOA Ambientes de Desarrollo Orientados al Negocio Web 2.0/ Rápido Desarrollo de Aplicaciones Metadatos/ Semántica Cómputo Social

14. ¿Por qué SOA? SOA abarca 9 de las 10 Principales Prioridades de la Administración de TI

15. El Problema de la Alineación Lo que explica la Línea de Negocio Lo que entiende el Gerente de Proyecto Lo que diseña el Analista de Negocios Lo que interpreta el desarrollador de TI Lo que describe el CIO al negocio Cómo se documenta el proyecto Lo que realmente se utiliza Lo que el presupuesto puede comprar El soporte proporcionado Lo que realmente quería el trabajador del proceso Nueva Aplicación Nueva Aplicación Nueva Aplicación Requerimientos, oportunidades, etc. actuales.

16. La Evolución de la Industria del Software Construir Comprar Componer Sistemas Centrales Pagos corporativos Manejo de Quejas Sistema de facturación Infraestructura de Negocio Automatización de Procesos SOA y Gobernabilidad Integración Modernización Servicios Web Integración 1970 1990 2000 1980 1960 2010 Foco en TI 2020 Sistemas de Soporte RH Nómina CRM

17. Definición de Arquitectura Orientada al Servicio (SOA – Service Oriented Architecture)

18. ¡No Se Puede Definir SOA Sin Analogías! ¿Qué es un Servicio? ¿Cómo lo Obtengo? ¿Qué es lo importante? Capacidades Distribuidas Granular – realizar una unidad de trabajo Confiabilidad y Calidad de Servicio Acoplada Libremente – ninguna suposición acerca de las necesidades de la otra parte Facilidad de uso basada en minimizar las dependencias artificiales

19. Elementos de SOA SOA está diseñada para soportar lógica orientada a servicios compuesta de servicios y composiciones de servicios, agrupados en un inventario global de servicios.

20. Más Conceptos de SOA Una composición de servicios está formada por servicios que se asocian para proporcionar funcionalidad requerida para automatizar un proceso o tarea de negocio específicos. La orientación a servicios define los servicios como “recursos empresariales agnósticos”, lo que implica que un servicio puede ser invocado por múltiples consumidores, involucrando incluso al servicio en diferentes composiciones. Una colección de servicios estandarizados es la base para el inventario de servicios que puede ser administrado independientemente en un ambiente aislado. Se pueden automatizar múltiples procesos de negocio creando composiciones que usan servicios agnósticos tomados del inventario. Un inventario de servicios establece un pool de servicios, muchos de los cuales serán diseñados deliberadamente para reusarse en múltiples composiciones.

21. Servicios, Composiciones e Inventario

22. Ventajas Operativas de SOA

23. Restricciones Arquitectónicas de SOA Un conjunto pequeño de interfaces simples y ubicuas Las interfaces deberían estar universalmente disponibles para todos los proveedores y consumidores Únicamente se encuentra codificada la semántica genérica en la interface – la semántica específica de las aplicaciones en los mensajes Mensajes descriptivos, es decir, los mensajes no prescriben ningún comportamiento del sistema , o sólo lo hacen en forma mínima Un esquema limita el formato, el vocabulario y la estructura de los mensajes Un esquema extensivo permite nuevas versiones de los servicios que serán introducidos sin romper los servicios existentes

24. Arquitectura Orientada al Servicio “ SOA es un estilo arquitectónico cuyo objetivo es lograr un acoplamiento libre entre los agentes de software interactuantes. Un servicio es una unidad de trabajo realizado por un proveedor de servicios para alcanzar los resultados finales deseados para un consumidor de servicios. Tanto el proveedor como el consumidor son papeles desempeñados por agentes de software en representación de sus propietarios”. “ http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html Consumidor Servicio Proveedor Consumidor Consumidor

25. Definición de SOA “ La Arquitectura Orientada al Servicio es un paradigma para la organización y utilización de capacidades distribuidas que pueden estar bajo el control de diferentes dominios de propiedad. Proporciona un medio uniforme para ofrecer, descubrir, interactuar con y utilizar capacidades para producir efectos deseados consistentes con condiciones previas y expectativas deseadas.” Comité Técnico del Modelo de Referencia OASIS SOA

26. SOA: Ofreciendo Resultados De Abajo Hacia Arriba Fundamento de una Arquitectura Administración y Control Agilidad y Libertad Dependiente Interdependiente Independiente Codependiente Mainframe Servidor de Aplicaciones Web SOA Servicios Web Punto a Punto

27. El Valor Real de “ SOA”

28. ¿Por qué SOA es tan Valiosos para los Negocios? Valor Costo Tiempo Desperdicio Se generan resultados y se construyen capacidades que crean el máximo valor para los elementos constitutivos del negocio. Se gasta menos en materiales y mano de obra y se maximiza el ROI directo. Se llega más rápido al objetivo; se reducen los costos de oportunidad y se genera un nuevo valor y momentum más pronto. Se reutiliza todo aquello que sea útil; no se pierde nada del valor; se apalancan los activos existentes.

29. Generar Valor con SOA Eficiencia a través de la automatización y la coordinación mejorada Eficiencia centrándose en la creación de valor Agilidad de negocio – implementación del cambio al momento del negocio Productividad de TI – desde el sostenimiento hasta las nuevas capacidades Transparencia operacional mejorada Colaboración mejorada Productividad y satisfacción mejoradas del trabajador Apalancamiento en capacidades existentes – “ Leave and Layer ” Desarrollo de una cultura orientada al desempeño y la mejora Desarrollo de una organización alineada Facilitan los negocios

30. Aspectos de una Arquitectura Orientada al Servicio SOA es una estrategia para facilitar un Valor de Negocio No se trata sólo de una “tecnología”. Entender SOA es un compromiso con la organización, el proceso y la tecnología SOA implica construir aplicaciones a partir de partes Un enfoque de componentes muy parecido a Corba o DCOM A diferencia de Corba o DCOM, SOA se basa en estándares y tiene un soporte masivo de la industria Uno de los pricipales valores de SOA se advierte en el concepto de re-utilización La reutilización de servicios internos o externos acelera el rendimiento de la inversión que se haga en cualquier estrategia de SOA

31. ¿Por qué Gobernabilidad?  ¡SOA no administrado es demasiado complejo! Seminario Básico de BPM + SOA | Página Legacy Finanzas CRM Cadena de Sumi- nistro Las ERPs se dividen en partes Las Aplicaciones Previas se convierten en Servicios Los sistemas complejos se rompen en piezas de servicio Los módulos se conectan de acuerdo a las necesidades del negocio

32. ¿Por qué Gobernabilidad? La Gobernabilidad proporciona Autoridades y responsabilidades Reglas claras y refuerzo de reglas Transparencia organizacional y técnica La Gobernabilidad SOA permite Dominar la complejidad de TI Soportar el cambio del proceso del negocio La Gobernabilidad SOA ahorra tiempo y dinero a los negocios Seminario Básico de BPM + SOA | Página

33. El Concepto SOA MONITOREO & ANÁLISIS GOBERNABILIDAD Integración de Legados Datos del Cliente Interacción del Cliente Historia del Pedido Polìtica de Pedidos Envío Orquestación de Servicio de Negocio Información del Cliente Administración de Pedidos Compensación de Pedidos CRM ERP Datos del Cliente Pedidos Logística Aplicaciones Compuestas Procesos de Negocio Obtener Datos Verificar Detalles Capturar Pedido Revisar Pedido Aprobar Pedido Iniciar Envío Administración de Pedidos Area Crítica Dominio de los Analistas de Negocio Dominio de los Arquitectos y Desarrolladores

34. Las 10 Mejores Prácticas de SOA Entender el Proceso Entender sus datos ¡Gobernar primero! Solicitar la validación de terceros Construir un caso de negocio enfocado al valor No (siempre) llamarlo SOA Foco en el negocio y en el suceso urgente La reutilización no es el único beneficio Empezar con poco….pensar en grande Promover una cultura de compartir BPM + SOA Basics Seminar | Page

35. Los 10 riesgos de SOA El Enfoque Escopeta/Exhuberancia Irracional No poder planear; planear para fallar Dictadura para combatir la anarquía Ignorar la seguridad No estandarizar SOA No pedir ayuda El tamaño cuenta Ignorar la inversión Ignorar su madurez Ejecutar SOA de abajo hacia arriba Seminario BPM + SOA Basics | Página

36. GRACIAS