Creando Arquitecturas

Transcripción

1 Creando Arquitecturas orientadas a servicios SOA Suite Abril 2013 Buenos Aires - Argentina

2 Índice 1. Introducción. 2. Nuestro camino para la creación de SOAs. 3. Como justificar el cambio? 4. Nuestras preguntas para desarrollar un roadmap. 5. Como desarrollar un roadmap orientado a SOA.

3 SOA Suite Nuestro camino para crear SOAs

4 SOA Suite Creando arquitecturas orientadas a servicios Nuestro camino para crear SOAs 4

5 SOA Suite Creando arquitecturas orientadas a servicios Nuestro camino para crear SOAs Probablemente ya relevado y evaluado por la organización Nuestra área de especialización como consultores SOA 5

6 SOA Suite Como justificar el camino a tomar

7 Para comenzar a justificar el cambio tenemos que pensar que este tipo de infraestructuras tienen la misma forma que los juegos de LEGO. Como justificar el camino a tomar La orientación a servicios cambia el ambiente de aplicaciones a bloques tecnológicos de LEGO que pueden ser acoplados con cualquier configuración virtual. Como en el juego el único límite acerca de lo que se puede elaborar es la imaginación del arquitecto. La tecnología deja de ser el límite para componer aplicaciones. Esta forma de diseñar provee a la tecnología un instrumento sumamente flexible para la estrategia del negocio. 7

8 Como justificar el camino a tomar De la imagen anterior rescatamos las siguientes justificaciones de negocios. > Flexibilidad del negocio y composición de aplicaciones enun100%,lamadredetodoslosbeneficiosajustificar. > Reducir el costo de mantenimiento de aplicaciones. > Reducir el riesgo de desarrollo de nuevas aplicaciones. 8

9 Como justificar el camino a tomar 9

10 Como justificar el camino a tomar Basándonos en lo beneficios anteriormente mencionados, podemos identificar diferentes tipos de ganancias o reducción de costos asociados a los mismos. $ Con nuestro framework podemos identificar drivers que nos llevan de beneficios y flexibilidad a valor agregado, reducción de costos e incremento en las ganancias. 10

11 Como justificar el camino a tomar 11

12 Como justificar el camino a tomar En un roadmap hacia SOA los costos pueden variar acorde a si estamos consumiendo servicios, brindando servicios o ambos escenarios. Cada uno de los componentes de la figura incluyen uno o mas costos, por ejemplo software, servicios, hardware, etc.. 12

13 Como justificar el camino a tomar Para calcular un ROI de manera simple nosotros podemos dividir los beneficios adquiridos por el framework por los costos acorde al escenario que tengamos que desarrollar. 13

14 SOA Suite Cómo elaborar un Roadmap

15 Como elaborar un Roadmap Una vez justificado el esfuerzo, tenemos los elementos necesarios para crear un roadmap orientado a servicios. Un roadmap orientado a servicios es un proceso incremental que puede ser llevado a cabo en diversas etapas de diseño, análisis y construcción. >Blueprints e inventario de servicios. >Service Oriented Analisys. >Service Oriented Design y modelos de servicios. >Proceso de delivery y arquitectura tecnológica 15

16 SOA Suite Pasos para crear un Roadmap

17 Pasos para crear un Roadmap A continuación se detallan pasos y metodología para la creación de un roadmap de una plataforma orientada a servicios. 17

18 SOA Suite Inventario de Servicios

19 1) Inventario de Servicios El objetivo principal en un roadmap SOA consta del esfuerzo de producir una colección de servicios reutilizables y que satisfacen el modelo de negocios. >Los servicios pueden ser estructurados en capas y tipos de servicios. >Con que tipos de servicios de implementación cuento actualmente?(composite applications). >Antes de desarrollar cualquier implementación, es deseable establecer un blueprint de servicios en modo conceptual. 19

20 Inventario de Servicios SOA nos provee de la habilidad de definir servicios para el negocio, describir como el negocio funciona (con sus correspondientes entradas y salidas) y desacoplar su implementación. 20

21 Inventario de Servicios - Capas Cuando se construyen varios tipos de servicios, es evidente que los mismos pueden ser categorizados dependiendo de: > El tipo de lógica que encapsulan. > La extensión y potencia de reutilización que la lógica de negocios posee. > Como la lógica de negocios se relaciona con el dominio del negocio. Como resultado de la clasificación anterior se pueden representar tres tiposdeserviciosenunmodelosoa. >TaskServices. >EntityServices. >UtilityService. 21

22 Inventario de Servicios El uso de estos modelos de servicios en un roadmap SOA, resulta en la creación de capas de abstracciones de servicios lógicos, como muestra la figura. 22

23 Inventario de Servicios Task Services Se traducen en servicios de negocios con una cota funcional, directamente asociado a una función de negocio. Dentro del modelo de servicio de tareas: > Son los que poseen menos reusabilidad. > Son posicionados como controladores del resto de los servicios y responsables por componer y orquestar a otros que son agnósticos del proceso. 23

24 Inventario de Servicios - Entity Services Dentro de cada plataforma de aplicaciones, existen entidades de negocios las cuales interactúan con procesos. Algunos ejemplos son cliente, empleado, documentos, reclamo, stock, etc.. >Representan operaciones de negocios asociadas estrictamente con entidades. >Es considerado un modelo de servicios de alta reusabilidad. > Este modelo es agnóstico del proceso de negocios en el cual esta inmerso. 24

25 Inventario de Servicios - Utility Services Cada uno de los modelos de servicios descriptos anteriormente tienen foco en lógica de negocios, pero los mismos son soportados por otro tipos de servicios que tienen funcionalidad de infraestructura. > Son generalmente reconocidos como servicios de infraestructura o tecnología. > Generalmente provistos como funcionalidad nativa de un ESB. > Por ejemplo logging, notificaciones, manejo de excepciones. 25

26 SOA Suite Análisis orientado a Servicios

27 2) Análisis orientado a servicios Un análisis separado debe ser llevado a cabo para cada proceso de negocio, asociado a servicios del inventario creado en el proceso anterior. En el gráfico se diferencia el análisis tradicional con el nuevo modelo. 27

28 Análisis orientado a servicios 28

29 Análisis orientado a servicios Definición del alcance del análisis. >Que proceso de negocios afecta a otros servicios de implementación. >Con que servicios del inventario contamos para componer un negocio. >Cuantas capas de servicios afectará el proceso de negocios en análisis. >Que otros servicios se deben modelar para completar este proceso. 29

30 Análisis orientado a servicios Identificar sistemas afectados. >Es importante entender que sistemas van a ser afectados en la empresa acorde al alcance definido en el paso anterior. >Son relevantes especialmente los sistemas legacy los cuales generalmente deben ser encapsulados con servicios. >Este paso puede afectar al proceso de granularidad de los servicios. 30

31 Análisis orientado a servicios Modelado de servicios. Los siguientes tres principios de la orientación a servicios son aplicados al modelado de procesos. >Reutilización de los servicios. >Autonomía de los servicios. >Visibilidad de los servicios. 31

32 SOA Suite Diseño orientado a Servicios

33 3) Diseño orientado a servicios 33

34 Diseño orientado a servicios 34

35 Diseño orientado a servicios Como muestra la figura anterior, se sugiere una secuencia de diseños en los cuales los modelos de servicios pueden ser modelados. >Generalmente los servicios de entidad son los mas independientes. >Los servicios de utilidad si bien no tienen contexto de negocios inmerso en ellos son mas difíciles de modelar. >Luego de modelar estos dos tipos de servicios y testearlos en forma independiente se puede proceder a la composición de nuevos servicios de tareas. 35

36 Diseño orientado a servicios Durante el diseño del servicio se deben tener las siguientes consideraciones: >Para servicios de negocios es necesario diseñar el contrato que tendrá el mismo, sus entradas y salidas; una descripción(wsdl) estándar. >Para los servicios de implementación es necesario tener en cuenta como los mismos van a cooperar en el proceso de composición y su potencial reusabilidad. 36

37 SOA Suite Delivery Model

38 4) Delivery Model 38

39 Teléfono Dirección Alicia M. de Justo Piso 1. Of. 114 Buenos Aires, Argentina