Unidad 1 Introducción SOA IS213-DSD-20221B. 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-20221B. 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-20221B

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 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

7 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.

8 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

9 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

10 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

11 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

12 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

13 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.

14 8 Principios de orientación a servicios

15 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

16 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

17 Caso : Dos servicios no estandarizados 17 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

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

19 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.

20 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.

21 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

22 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]

23 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”

24 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

25 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

26 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?

27 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).

28 SOA Diseño

29 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 se centra en definir 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

30 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)

31 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)

32 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:

33 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.

34 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

35 ¿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).

36 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

37 Solución SOA Diseño - DF

38 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

39 CASO: Reserva de Asesorías 39 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

40 Descomposición de procesos en servicios

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

42 ¿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

43 Pasos a seguir Modelamiento de servicios

44 Procesos de negocio

45

46

47

48 Servicios agnósticos candidatos Entidad Utilidad

49 Procesos de negocio

50 No Agnóstica Agnóstica Cliente

51 Procesos de negocio

52

53 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