Este documento presenta una introducción a la arquitectura orientada a servicios (SOA). Explica que SOA organiza las funciones de las aplicaciones empresariales en servicios interoperables basados en estándares que pueden combinarse rápidamente para satisfacer las necesidades del negocio. También describe los principios de SOA, los pasos para implementarla, y conceptos clave como servicios, ESB y gobernanza.

1. SOA – Service Oriented Architecture La arquitectura de la mano del negocio… Equipo de Arquitectura, Septiembre 2011

2. Temario Que es SOA Principios Pasos para implementar SOA Enfoque tradicional vs SOA Proveedores de tecnologías SOA SOA y el negocio de la empresa Arquitectura SOA Servicios ESB Governance Buenas y malas prácticas al momento del diseño

3. Que es SOA ¿entonces SOA es Implementar usando Web Services? Integración?? Entonces tiene que ser una estrategia de TI? Una situación que tristemente ocurre: Desarrollador: Jefe!, ya tenemos listo el Web Service! Jefe: Ah muy bien!!, entonces con eso ya tenemos implementado SOA?

4. Desarrollador: OK, si jefe… ya tenemos SOA…

5. Y entonces? SOA es un estilo de arquitectura que enfatiza el uso de servicios de red, seguros, compartibles, que realizan tareas atómicas y desacoplados para incrementar la flexibilidad del negocio de una manera interoperable y agnóstica tecnológicamente. Es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio . Es una estrategia de TI que organiza funciones contenidas en las aplicaciones empresariales, en servicios interoperables basados en estándares que pueden combinarse rápidamente para satisfacer las necesidades del negocio (Definición de Oracle).

6. Organiza las funciones contenidas en aplicaciones empresariales convirtiéndolas en servicios. Se aproxima a la estrategia de negocio de la empresa Es un compromiso organizacional, que permite adoptar las premisas de este paradigma y enmarcarlas dentro de la estrategia de la empresa. Implica un cambio de mentalidad tanto en las líneas directivas como de las áreas operativas de la empresa.

7. Principios Contratos de servicio estandarizados Servicios con bajo acoplamiento Abstracción Reusabilidad Autonomía Sin estado Capacidad de Descubrimiento Composición Interoperabilidad

8. Pasos para implementar SOA Definir Roles y responsabilidades de las aplicaciones: Qué aplicación va a proveer qué servicio. Por ejemplo, el saldo de la cuenta corriente se lo pido al core y el de una tarjeta de crédito es un web service que le pido a Master Card (por ejemplo). Comunicar: Definir los conectores entre las diferentes aplicaciones y ese conector envía y recibe información de las aplicaciones al ESB. Definir los servicios: Se deben identificar las funcionalidades del negocio que necesitemos exponer como servicio, considerando cada uno de los principios vistos anteriormente. Las Reglas de negocio: dada una definición de procesos de negocio (BPM), se debe identificar donde que papel juegan las tecnologías disponibles para construir nuestros servicios. Governance: contempla lo necesario para un planteamiento y dirección de este nuevo esquema SOA.

9. Enfoque tradicional vs SOA

10. Enfoque tradicional vs SOA

11. Proveedores de Tecnologías SOA Microsoft IBM Tibco Oracle Software AG SAP Sonic Software

12. SOA y el negocio de la empresa TI tiene un rol particularmente importante dentro de la estrategia de una empresa A pesar de ello, no es vista como un área confiable, ni menos como un “socio” de la estrategia de negocio. Como resultado, tenemos un GAP entre las necesidades de la empresa y la ejecución de TI.

13. SOA y el negocio de la empresa Las compañías y empresas desarrollan las estrategias de negocio por un lado, y luego, intentan implementarlas a través de una estrategia distinta de TI. Estas son consideradas desde puntos de vista distintos. Estrategia de negocio: considera la empresa en su conjunto a largo plazo. Estrategia de TI: Se considera a corto plazo para atender las necesidades puntuales de una línea de negocio. Como se puede esperar, ambas no son compatibles para obtener un resultado acorde con la empresa en su conjunto.

14. SOA y el negocio de la empresa Se espera que TI soporte y responda rápidamente frente a las necesidades de cambio. Se debe aumentar la productividad. Minimizar el GAP entre las necesidades del negocio y la ejecución por parte del área de TI. Se requieren cambios fundamentales y fundacionales para alinear ambas estrategias.

15. SOA y el negocio de la empresa

16. Arquitectura SOA Como vimos anteriormente, SOA es, entre otras cosas, un estilo de arquitectura que permite construir sistemas basados en componentes de granularidad gruesa llamados servicios. Cada servicio expone procesos y comportamientos a través de contratos.

17. Servicios “ Es un mecanismo para acceder a una o más capacidades, donde el acceso es provisto por medio de una interface bien descrita y se ejerce en conformidad con restricciones y políticas tal cual se especifica en la descripción del servicio”. Merriam Webster Es una unidad de software independiente que no pertenece a un contexto específico, tiene una funcionalidad atómica y bien definida, que establece un contrato para su utilización y descubrimiento. Además, es altamente reutilizable y puede formar parte de un proceso de mayor potencia. Lo más importante es que representa una funcionalidad común y repetitiva del negocio.

18. ESB – Enterprise Service Bus Un ESB es una infraestructura de software que facilita la integración de aplicaciones. Es muy valorable en una arquitectura SOA ya que permite el intercambio de mensajes, ejecuta transacciones, orquesta servicios y realiza la publicación y suscripción entre aplicaciones heterogéneas y distribuidas. Según Sonic un ESB es “ un bus vertical que conecta distintos end-points usando protocolos de red y lenguajes que ya existen en la empresa. Lo vemos como una tecnología incremental más que una fundacional”.

19. Governance Es una estructura de administración que permite cumplir con éxito el proyecto de implementar SOA en una empresa, y lograr los objetivos propuestos del negocio. Esta estructura contempla los niveles estratégicos, tácticos y operacionales. Se debe definir el modelo de governance: Que hacer: define el SOA roadmap (plan de ruta SOA). Quién lo hace: La estructura organizacional, grupos de trabajo (SOA Office). Como hacerlo: Los procesos de administración, las normas. Como medirlo: Definición de métricas para medir el % de éxito.

20. Governance “ SOA governance ya no es una opción, es un imperativo, sin esta administración no se logra el ROI, y todo proyecto SOA estará en peligro.” Gartner. “ Un SOA mal implementado esta por debajo del 35% de reutilización”. Gartner. “ El 80% de la falla de los proyectos SOA esta en la carencia de mecanismos de governance”. Gartner.

21. Governance El desgaste de comprometer a un Jefe de Proyecto en SOA, por lo general la respuesta es: “ La aplicación es posible de desarrollar sin servicios, a mi me evalúan por hacer aplicaciones, y a mi cliente no le interesa si se hace de esta forma, luego, ¿que gano? No está interiorizada la idea de compartir, o de pensar en los beneficios a mediano plazo. Se han propuesto catálogos completos de servicios, soluciones del tipo “ Big Bang” , NO recomendados por SOA.

22. Buenas y malas prácticas al momento del diseño L os servicios se nombran para maximizar su uso - Erróneo: insertarRegistroCliente() - Correcto: crearNuevoCliente() El servicio tiene un gran número de parámetros (coarse grained) - Erróneo: crearNuevoCliente(rut,nombre,apellidos,e-mail,telefono) - Correcto: crearNuevoCliente(objetoCliente) Servicios Parlanchines (Chatty Services) - Erróneo: consultaUF() – ups… - Correcto: ( NO implementar este tipo de funciones como servicio).

23. Tack så mycket!! (Muchas Gracias!!)