SOA – Service Oriented Architecture

La arquitectura de la mano del negocio…

Equipo de Arquitectura, Septiembre 2011

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

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?

• Desarrollador:

• OK, si jefe… ya tenemos SOA…

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

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

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

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.

Enfoque tradicional vs SOA

Enfoque tradicional vs SOA

Proveedores de Tecnologías SOA

• Microsoft• IBM• Tibco• Oracle• Software AG• SAP• Sonic Software

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.

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.

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.

SOA y el negocio de la empresa

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.

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.

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

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.

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.

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.

Buenas y malas prácticas al momento del diseño

• Los 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).

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