Unidad 1 Introducción SOA IS213-DSD-20212B. Agenda Introducción. Conceptos Principios SOA SOA Diseño Descomposición de procesos en servicios Conclusiones.

Presentación del tema: "Unidad 1 Introducción SOA IS213-DSD-20212B. Agenda Introducción. Conceptos Principios SOA SOA Diseño Descomposición de procesos en servicios Conclusiones."— Transcripción de la presentación:

1 Unidad 1 Introducción SOA IS213-DSD-20212B

2 Agenda Introducción. Conceptos Principios SOA SOA Diseño Descomposición de procesos en servicios Conclusiones

3 Introducción

4 Wells Fargo ‘93 “Service-Based” Forma de hacer SW basado en servicios ‘96 Gardner “Service-Oriented” Forma de hacer SW Orientado a servicios Paradigma ‘99 “SOA” “Service Oriented Architecture” Paradigma que desarrolla la arquitectura Diseño ‘00 “WebServices” Implementación “GAP”BizTI Inversión vs Gasto ACTIVO Todo SW que se genere Debe redituar un retorno Fabricantes: -IBM -SUN/ORACLE -MS Thomas Erl

5 Conceptos

6 Arquitectura empresarial Hacia donde vamos Business Logic LegacyERPCRMFinance Business Logic LegacyERPCRMFinance Business Logic New Business Processes Business Services Aplicación, Silos de ActivosAplicaciones orientadas a servicios, activos Funcionalidad empresarial oculta en aplicaciones, silos de activos... interfaces propietarias que sirven a los silos Funcionalidad empresarial expuesta como servicios empresariales... servicios basados en estándares, compartidos y reutilizables ?

7 SOA Problemática RETOS / PROBLEMATICA  SOA – Heterogeneidad y descentralización – Cambios con altos impactos caros – Islas, desde el diseño, la modularización extensible no existía – Duplicamos datos y funciones

8 SOA Objetivos organizacionales Mayor interoperabilidad intrínseca Mayor federación Mayores opciones de diversificación de proveedores Mayor alineación empresarial y tecnológica Mayor ROI Mayor agilidad organizativa Reducción de la carga de TI

9 SOA Servicio Unidad lógica de la solución diseñada de acuerdo con la orientación al servicio. La lógica de la solución correspondiente en un programa de software que se convierte en un activo de TI principal, diseñado para respaldar un conjunto específico de objetivos estratégicos.

10 SOA Servicio Un servicio existe como una unidad de software independiente con características de diseño propias que apoyan el logro de los objetivos estratégicos del negocio Cada servicio está asignado a su propio contexto funcional y abarca un conjunto de capacidades relacionadas con este contexto. Estas capacidades están disponibles para su invocación por un programa cliente y son comúnmente expresadas a través de contrato de servicio publicado

11 SOA Servicio Recurso A Servicio Recurso CRecurso D Proveedores de Servicios Un Servicio ofrece una funcionalidad por la cual la necesidad del Consumidor es satisfecha por el Proveedor de Servicios Desacopla los recursos utilizados por el Proveedor de aquellos usados por el Consumidor de Servicios El Proveedor de Servicios tiene la capacidad para realizar los Servicios requeridos El Proveedor de Servicios puede cambiar recursos sin impactar en el Consumidor El Consumidor de Servicios requiere la funcionalidad ofrecida por el Servicio Varios Consumidores pueden compartir un Servicio reduciendo el coste global y mejorando la coherencia Recurso B Consumidores de Servicios

12 SOA Tipos de servicio Los servicios se clasifican de acuerdo: – El tipo de lógica que encapsulan – Medida del potencial reuso de esta lógica – Como esta lógica esta relacionada con los dominios dentro de la empresa

13 SOA Servicios de Entidad (Entity service) Representa un servicio de negocio cuyo contexto funcional lo constituye una o más entidades del negocio Es altamente reusable porque es agnóstico a la mayoría de los procesos cliente, empleado, factura, reclamo. Muchas de las operaciones que exponen este tipo de servicios son las típicas de un CRUD (Create, Read, Update, Delete). Ejemplos: – Registrar Cliente – Actualizar factura – Cambiar estado al reclamo

14 SOA Servicios de utilidad (Utility service) Los servicios de utilidad son aquellos que encapsulan una funcionalidad multi- propósito. Son servicios que no cubren una necesidad concreta de negocio. Estos servicios contienen un alto potencial de reusabilidad (uno de los principios básicos en el diseño de servicios). Ejemplo: – Correo – Auditoria

15 SOA Servicios de tarea (Task service) Representa un servicio de negocio cuyo contexto funcional es una tarea o proceso principal del negocio Tiende a ser menos reusable Actúa como un controlador de otros servicios Su alcance es más amplio que un servicio de tipo entidad. La entidad también contiene tareas pero su alcance está limitado a la entidad Ejemplo: – Gestión de clientes – Gestión de reclamos

16 Otros tipos de servicios SOA Service Wrapper -Tipo de lógica de servicio que se encarga de conectar una lógica que ya existe pero que no se ha expuesto como servicio. Se encarga de “envolver” alguna lógica existente para exponerlo como un servicio. Ejemplo: hay un sistema de Foxpro que tiene un sistema de inventario que funciona bien. Como visión de negocio (rápido, costo) entonces en vez de hacer algo nuevo, que demora y es costoso, se “envuelve” y expone como servicio para que sea utilizado por otros, dando la apariencia de ser algo nuevo, pero es algo expuesto desde un sistema Foxpro.

17 Otros tipos de servicios SOA Service Integration -La lógica ya existe, pero no está lista como está, entonces hay que integrarla a la solución propuesta. Ejemplo: Necesito enviar SMS para mensajes informativos. Pero tengo que enviar por tres operadores distintos. Puedo tener la posibilidad de enviar a cualquiera o tener un servicio que integre los tres y que el servicio se encargue de negociar por cual operador enviar el mensaje. Envíos de correos, por SMTP, por Google, por MS. Se debe tomar una decisión, o cada aplicación resuelve como enviar correo, pero eso afecta el tema de rentabilidad, es costoso. Entonces se elabora un servicio que integre los envíos y que todas las aplicaciones utilicen este servicio. El servicio decide por que vía enviar el correo.

18 Otros tipos de servicios SOA Service Hybrid -Se pueden combinar servicios básicos de Utility/ Task/ Entity/ Wrapper/ Integration. -Se recomienda no utilizar este tipo de servicio porque son muy acoplados y su mantenimiento es complicado y costoso. - Es como si tuviéramos un artefacto que haga todo en casa, cuando se malogra, no podemos hacer nada.

19 Otros tipos de servicios SOA Service Controller -Es como un integration pero para la aplicación, su labor es sumar otras nuevas funcionalidades tomando como base la ya existente. -Ejemplo: Ya existe una funcionalidad que registra personas, otra que registra distrito, otra que envía correo. Se hace una nueva funcionalidad que notifique a algunas personas sobre algo, mediante el uso de estas funcionalidades (que controle los anteriores para generar una nueva función).

20 8 Principios de orientación a servicios

21 Principios SOA ¿Por qué utilizarlos? El maximizar beneficios y mitigar riesgos es una propuesta de diseño requiere un análisis integral de las áreas de negocio y una propuesta sistémica que guíe el diseño. Si un diseño no sigue principios o lineamientos marco la probabilidad que no sea exitosa es muy alta.

22 Principios SOA  Contrato de servicio estandarizado (Standardized Service Contract)  Bajo Acoplamiento (Service Loose Coupling)  Abstracción del servicio (Service Abstraction)  Reutilización del servicio (Service Reusability)  Autonomía del servicio (Service Autonomy)  Servicio Sin estado (Service Statelessness)  Descubrimiento del servicio (Service Discoverability)  Capacidad de composición del servicio (Service Composability) Thomas Erl -2,005

23 Principio 1: Contrato estandarizado Contrato de servicio: Corresponde a la parte pública de un servicio; incluye su descriptor ¿qué ofrece?, ¿dónde se ubica?, ¿cómo invocarlo?, esquema(s), políticas y acuerdos de nivel de servicio. “Los servicios dentro del mismo inventario o dominio siguen los mismos estándares de diseño de contrato.” Áreas de estandarización: 1.Expresiones funcionales.- Nomenclatura y tipos de mensajes. 2.Modelo de datos.- Estructuras y tipos de datos. 3.Políticas.- Requerimientos y términos de uso. SLA o nivel de servicio que un cliente espera de su proveedor. WSDL – XSL SLA Doc. de diseño

24 Caso : Dos servicios no estandarizados 24 1)¿El nombre de ambos servicios sigue el mismo estándar de nomenclatura? 2)La nomenclatura utilizada para definir las operaciones ¿siguen el mismo patrón? 3)La forma de establecer los nombres de los atributos de los mensajes ¿es similar en todas las estructuras? 4)Los tipos de datos primitivos (texto, date) ¿son los mismos en los atributos de ambos servicios? 5)Ambos servicios ¿utilizan la misma estructura de datos (Alumno- Student) para referirse a la misma unidad de negocio Estudiante? 6)Ambos servicios ¿entregan y reciben mensajes con el mismo protocolo? 7)Las políticas de seguridad para ambos servicios ¿son homogéneas? Matrícula de alumnos Actualización de alumnos Dos servicios para una universidad

25 Solución : Dos servicios estandarizados 25 Patrón de centralización de esquema

26 Principio 2: Bajo acoplamiento “Los consumidores pueden quedar acoplados sólo al contrato y este debe quedar a su vez desacoplado de su entorno” Se busca minimizar acoplamientos negativos y maximizar los positivos. Para aumentar la interoperabilidad y variedad de implementaciones que un servicio puede tener. El contrato no debe estar acoplado ni a los consumidores ni a la lógica e implementación para permitir que pueda evolucionar sin impacto a los clientes.

27 Principio 3: Abstracción Solo de interés público Evitar exponer uso de tecnologías internas, ids, referencias bds, así evita acoplamientos No exponer lógica del servicio, algoritmos, impediría refactorización interna del servicio. Solo exponer políticas y acuerdos del servicio, disponibilidad, No detales de uso interno. “Los contratos de servicios exponen sólo la información esencial acerca del servicio. ” Encapsular y proteger la información interna de un servicio, así como exponer solo la información que permita a los consumidores su reutilización sin quedar fuertemente acoplados.

28 Principio 4: Reutilización “Los servicios contienen y expresan lógica que puede ser aprovechada como recurso reutilizable para la organización desde el punto de vista de negocio.” “Potencial… de reutilización” General-particular Buscar antes de hacer

29 Principio 5: Autonomía Un servicio no puede contener lógica que dependa de nada externo al propio servicio, ya sea un modelo de datos, un sistema de información, o cualquier otra cosa. El servicio tiene control solo sobre la lógica que encapsula. Un servicio es autónomo porque su única relación con el mundo exterior, al menos desde la perspectiva de SOA, es a través de su interfaz o contrato. Autogobierno, auntocontrolado [Auto-self]

30 Principio 6: Sin estado “Los servicios minimizan el uso de recursos de manejo de estado y de ser necesario lo delegan para mejorar su escalabilidad.” Idealmente, todos los datos que necesita el servicio para trabajar deben provenir directamente de los parámetros de entrada. Ideal, requisito para la composición. Incrementa la escalabilidad. Mejora la autonomía. Total disponibilidad Mejor rendimiento Los servicios SOA no deben guardar información alguna sobre datos de sesión, ni sobre eventos previos, ni sobre resultados de servicios invocados previamente. Es decir, los servicios no deben tener estado. Alzhéimer “corren buenos tiempos para el desarrollador de backend, sólo tiene que preocuparse por una invocación al servicio y dar una respuesta. El resto lo tienen que “manejar” los desarrolladores de frontend”

31 Principio 7: Descubrimiento “Los servicios son descritos con información de sus capacidades para que puedan ser utilizados y entendidos.” Catálogo de servicios -publicar -buscar servicios ws-discovery

32 Principio 8: Facilidad de composición Este principio nos dice que todo servicio debe estar construido de tal manera que pueda ser utilizado para construir servicios genéricos de mayor complejidad de mayor jerarquía reutilizable general. Composición: Automatización de un proceso o tarea de negocio. Componer diferentes capacidades de negocio. Cuando no existe ningún servicio que satisfaga las funcionalidades requeridas por el solicitante, debe existir la posibilidad de combinar varios servicios existentes que en conjunto cumplan con la necesidad deseada

33 Principio 8: Facilidad de composición Caso : Un servicio con poca capacidad para ser compuesto Servicio para facilitar las reprogramaciones de las asesorías para cursos de tesis en la universidad. Luego de revisar la definición de su contrato planteamos las siguientes preguntas de reflexión sobre el principio SOA-8 1)¿La estructura de entrada está pensada para ser usada desde varios procesos de negocio? 2)¿La estructura de salida está diseñada pensando en ofrecer la mejor información posible para que otros servicios de mayor nivel puedan aprovechar los resultados de una reprogramación a futuro? 3)¿El mecanismo de BD que utiliza ayuda a que el servicio pueda ser compuesto varias veces para muchos procesos sin que tenga un impacto negativo en su rendimiento?

34 Principio 8: Facilidad de composición Solución: un servicio con mayor capacidad de ser compuesto 1)La estructura de salida de la reprogramación básica tiene una estructura de tipo Reservación, así puede ser aprovechado por otros servicios controladores 2)Se han considerado aspectos de falla o errores de negocio para que los consumidores estén preparados y no reimplementen 3)Se han incluido otras funcionalidades para procesos masivos 4)Cambio en la BD que tiene mejor rendimiento (particionado).

35 Resumen

36 SOA Diseño

37 Para el diseño de los servicios es importante alinearse a técnicas de la Ingeniería de SW para el diseño de una Aplicación. Toda aplicación de tecnología se define en base a diferentes aspectos lógicos centrados principalmente en: a) Lógica de presentación b) Lógica del negocio c) Lógica de los datos Para el diseño de servicios solo debemos centrarnos en los puntos b) y c) y las técnicas más usadas son: –Por descomposición funcional (DF) –Por descomposición de procesos (DP) Técnicas para el diseño SOA Diseño

38 Consideraciones Para definir un servicio se debe tener en cuenta aspectos importantes de Service-Oriented. Paso 1 -Un servicio debe diseñarse en base a las 3R -¿es Rentable para el negocio? -¿es Reutilizable para otras aplicaciones? -¿es Rendidora a nivel de red? Paso 2 - Determinar si un servicio es genérico (agnóstico) o específico (Ad-hoc)

39 Consideraciones SOA Diseño Paso 3 -Determinar si la lógica del servicio ya existe en la capa de aplicación (TI) con el propósito de reutilizar. -¿Ya existe? Paso 4 -Si no existe, se debe tomar una decisión sobre el tipo de lógica que tiene el servicio. ¿Qué tipo de lógica es? Se utiliza el Service Models (tipos de modelos o plantillas que existen para los diferentes tipos de servicios)

40 Consideraciones SOA Diseño Un servicio es una unidad lógica que agrupa operaciones -Operación 1 -Operación 2 -Operación 3 -Operación 1 -Operación 2 -Operación 3 Servicio -RegistrarCliente -BuscarCliente -ModificarCliente -RegistrarCliente -BuscarCliente -ModificarCliente ClienteService Ejemplo:

41 Consideraciones SOA Diseño Algunos fabricantes (IBM, MS, Oracle) -Primero piensa en el servicio -Luego incluye las operaciones Algunos otros (T.Erl, SAP) -Identifica primero la operación -Luego encapsulas la operación en el servicio.

42 SOA Diseño - DF PEEVisiónMisiónPEEVisiónMisión Transacciones Aplicaciones Trx AP Fuentes de datos Top-Down Bottom-Up Entidades De negocio Procesos De negocio NEGOCIO TECNOLOGÍA SERVICIOS Agile Servicios candidatos TOGAF SOA

43 ¿cómo encontramos servicios? SOA Diseño - DF 1.Stake Holders 2.Business Functions – Organigrama (Est. Fija) 3.Business Process (Est. Dinámica) 4.Business Entities 5.Plan Estrategico – Visión/Misión Top Down Expertos que sepan TI- Negocio. 1. Transacciones 2. Aplicaciones 3. Fuente de Datos Alineadas al negocio Botton Up Visión consumidor Basado en la necesidad que existe de los usuarios que utilizan los servicios. En la visión del negocio. Crecimiento y proyecciones de los objetivos estratégicos. Visión Proveedor Técnicos, expertos, conocedores de TI, conocen las transacciones. CTO (Chief Technology Officer).

44 Ejercicio SOA Diseño - DF La universidad necesita implementar un sistema de asesorías para sus cursos de Proyecto profesional. Luego se hacer un relevamiento de procesos e identificar las necesidades se han identificado los siguientes requerimientos funcionales: -Solicitar disponibilidad de los asesores especializados en temas específicos de acuerdo al tema elegido por el alumno. -Coordinar horarios en los que van a estar disponibles estos asesores. -Que los alumnos puedan Hacer la reserva, solicitar los turnos, puedan hacer su solicitud poner su tema (que es lo que esperan) y que la universidad se reserve el derecho a confirmar o cancelar la reserva de acuerdo a políticas establecidas. -Turnos -Solicitud -Confirmación/Cancelación -Calificar la asesoría por parte del alumno -Que se puedan Ver los resultados notificar a todas las instancias de la universidad. También en el análisis se han identificado la reutilización de sistemas que ya existen como el sistema central (alumnos, docentes, pagos) y el sistema de matrícula (cursos, ciclos). Se solicita a partir de esta especificación funcional llegar a una arquitectura distribuida de servicios

45 Solución SOA Diseño - DF

46 SOA Diseño Usaremos TOP-DOWN Descomposición funcional (Lógica y Datos) Servicio “Unit of Grouping” (Módulo) Principle driven Operación “ Unit Of Work” (transacción) -Biz-Oriented -Net Enabled Mensaje “Unit of Comunication” (Trama) Data Transfer Object DTO Nodo “Unit of Process” (Servidor) Aloja el servicio Service-Layer Application Layer (TI) Business Layer Customer Layer Service Interface Layer Application Service Layer Business Service Layer Orchertration Layer Service-Models Wrapper Integration Sistemas existentes Entity Task Lógica con permanencia en el tiempo Process (BPM) Utility Controller Hybrid (*) Genérica Específica Alumnos Docentes Pagos Cursos ciclos Horarios + Registrar horario + Modificar horario +Consultar alumnos +Consultar asesores +Consultar cursos + Consultar horario Reservas + Registrar reserva + Efectuar sol asesoria + Confirmar asesoría +Enviar correo + Registrar calificación + Evaluar asesoría Calificaciones + Modificar reserva HorariosService ReservasService SocratesService PlatonService NotificacionesService GestionAsesoriaService Aprobacion Asesoria Service Otros procesos manuales Excel Conectarse Al BPM CalificacionService Usuarios que usan el sistema Máquinas que usan el sistema Front en cluster

47 CASO: Reserva de Asesorías 47 Buscar Asesores - ERP Listar Asesores - ERP Obtener Asesor - ERP Consultar Alumnos - ERP Registrar Disponibilidad Consultar Disponibilidad Evaluar Reserva Crear Reserva Actualizar Reserva Registrar Horario de Asesoria Obtener Horario de Asesoría Programar Turnos de Asesoría Consultar Cursos – Sistema Matrícula – DB Calificar Asesoria Enviar Correo de Confirmación de Registro de Asesoría Gestionar Disponibilidad de Asesores, armar horarios Buscar Asesores - ERP Listar Asesores - ERP Obtener Asesor - ERP Consultar Alumnos - ERP Registrar Disponibilidad Consultar Disponibilidad Evaluar Reserva Crear Reserva Actualizar Reserva Registrar Horario de Asesoria Obtener Horario de Asesoría Programar Turnos de Asesoría Consultar Cursos – Sistema Matrícula – DB Calificar Asesoria Enviar Correo de Confirmación de Registro de Asesoría Gestionar Disponibilidad de Asesores, armar horarios

48 Descomposición de procesos en servicios

49 Relación de servicios relacionados al proceso de negocio Automatización de un proceso de negocio Procesos de negocio Servicio

50 ¿qué es un proceso de negocio? Un proceso de negocio es una colección de actividades o tareas relacionadas y estructuradas que en una secuencia específica produce un servicio o producto. Los procesos reciben insumos para transformarlos utilizando recursos de la empresa. Los procesos de negocio normalmente atraviesan varias áreas funcionales

51 Pasos a seguir Modelamiento de servicios

52 Procesos de negocio

53

54

55

56 Servicios agnósticos candidatos Entidad Utilidad

57 Procesos de negocio

58 No Agnóstica Agnóstica Cliente

59 Procesos de negocio

60

61 Referencias ISO 12207 (http://www.12207.com/). The Open Group Architecture Framework (http://www.opengroup.org/). OASIS Reference Model for Service Oriented Architecture (http://www.oasis- open.org/committees/tc_cat.php?cat=soa). Enterprise SOA: Service-Oriented Architecture Best Practices. Dirk Krafzig, Karl Banke, Dirk Slama. Prentice Hall PTR. November 09, 2004. ISBN 0131465759. IBM SOA (http://www-306.ibm.com/software/solutions/soa/). Oracle SOA (http://www.oracle.com/technologies/soa/index.html).http://www.oracle.com/technologies/soa/index.html Identificación de servicios por descomposición https://www.youtube.com/watch?feature=player_detailpage&v=TauAUHGtH_w#t=433 https://www.youtube.com/watch?feature=player_detailpage&v=TauAUHGtH_w#t=433 Arquitectura https://youtu.be/y46TBEf21Gs https://www.ted.com/talks/ole_scheeren_why_great_architecture_should_tell_a_stor y/transcript?language=es https://www.ted.com/talks/ole_scheeren_why_great_architecture_should_tell_a_stor y/transcript?language=es

62 Conclusiones