Este post tiene como fin aclarar que no es SOA, con el fin de evitar confusiones y malos entendidos a la hora de emprender un proyecto de implementación SOA.
Dino Esposito [Esposito Dino et at, 2009] indica que hay que tener claro que SOA no es una revolución, un objetivo en sí, una tecnología , ni tampoco una implementación de webservices.
No es una revolución porque hace más de 15 años que existe la infraestructura para integrar aplicaciones (EDI, CORBA, COM, DCOM etc). Lo que generó SOA fue la necesidad de integrar sistemas existente con el fin de implementar procesos de negocios usando software. Por lo tanto invocar objetos remotos, enviar mensajes ya existía antes que SOA, por lo tanto no es una revolución sino una evolución.
Tampoco es una tecnología en sí, pues SOA es totalmente independiente de proveedores y productos. Unos de los mayores beneficios de SOA es que se aplican sus principios a una organización en particular. No se debe pensar una implementación SOA en base a productos del mercado, se debe pensar en SOA tomándose en tiempo necesario para entender sus principios y aprender cómo aplicarlos en toda su infraestructura.
Decir que SOA son webservices es un error común pues a la hora de implementar los webservices son los más utilizados como mecanismo de comunicación entre los sistemas que forman la infraestructura SOA. Por lo tanto no todas las soluciones SOA utilizando webservices y no todos sistema basado en webservices es una implementación de SOA.
Como venimos diciendo ante de pensar como implementar SOA se debe tener bien definidos los procesos de negocio que suponemos que se van a mejorar mediante la implementación de SOA. Por lo tanto el objetivo no es implementar SOA sino mejorar uno o varios procesos de negocio determinados. Luego de analizar los procesos involucrados, la infraestructura, aplicaciones, tiempo y presupuesto disponible recién en ese momento estaremos en condiciones de decir si SOA es aplicable o no.
Referencias
[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.
domingo, octubre 25, 2009
viernes, octubre 16, 2009
Reflections about SOA implementation in the enterprise.
El tema de SOA no es nada nuevo, pero a la hora de querer conocer sobre este interesante tema el problema no fue encontrar información, sino todo lo contrario, clasificar y sacar conceptos útiles de las gran cantidad de información al respecto.
A mi criterio el tema de SOA fue un gran boom hace 6 o 7 años y luego fue madurando para ser un paradigma aplicable con exito en empresas donde la madures de sus procesos justifique la gran inversión que requiere implementar SOA. No solo es cuestión de soft y hard, sino también de un cambio cultural muy importante en la compañía. Es común que cada área de negocio tenga su propia genencia que sub procesos independientes y prioridades diferentes. por los general es obvio que todas está alineadas a un objetivo de negocio común, pues sino estraríamos en otros problema que es más un análisis de administradores de empresas y consultores asociados.
Pero de todas formas esta diferentes prioridades hace que a larga cada área sea como silos aislados en donde emprenden la contrucción de aplicaciones para resolver determinadas área de negocio, sin pensar (o poco) en lo que implementa las otas áreas.
Como consecuencia tenemos casos de duplicación de funcionalidad, repostorios con datos con entidades redundantes (por ej varias tablas de clientes o de proveedores).
La estandarización de esto requiere de un área que tenga una visión transversal a todas las áreas para poder alinearlos, definir estándares de integración, desarrollo , deployment etc con el fin de integrar las diferentes áreas de negocio. Esta área deberia estar formado por especialistas en las diferenes ramas del desarrollo y arquitectos empresariales.
Volviendo al tema de SOA, una vez que tenemos los procesos, podemos pensar en la implementación en sistemas software (primero los procesos , despues el software).
Ahora, para los más ansiosos paso a describir un resumen (o recordatorio según en caso) de los que es SOA desde el punto de vista ténico.
Arquitectura orientada a servicios
Servicios
Los servicios son sistemas autónomos, que poseen una especificación definida que pueden ser accedidos en forma remota desde otras aplicaciones de la compañía.
Desde el punto de punto de vista del consumidor del servicio no interesa como está implementado sino cual es el mensaje de entrada a recibir y cuál es el formato de la salida, de esta forma se pueden crear sistemas altamente escalables, distribuidos y reutilizables.
Para que los servicios puedan forma parte de una arquitectura orientada a servicios deben tener al menos las siguientes características
• Reusables: Proveen servicios de negocio que pueden ser utilizados por varias aplicaciones.
• Proporcionar un contrato formal: Indica que establece una interface formal para los mensajes de entrada y de salida. En la práctica se debe los mensajes tienen formato XML, por lo tanto se deben exponer esquemas XML (XSD) y no clases.
• Deben tener bajo acoplamiento
Significa que un cambio en la implementación de alguno de ellos debe afectar lo mínimo posible a los demás.
• Deben permitir la composición entre ellos.
Esta funcionalidad permite componer el resultado de la ejecución de varios servicios para ofrecer un solo resultado. En la práctica esto se podría implementar con un Enterprise Service Bus.
• Deben ser autónomos.
Indica que su implementación y administración se debe poder hacer independientemente de los demás, eta característica está muy asociada con la de bajo acomplamiento.
• No deben tener estado.
Indica que el servicio recibe el mensaje de entrada, lo procesa y luego responde el resultado sin mantener estado alguna entre ejecuciones.
• Deben poder ser descubiertos.
El descubrimiento de lo servicio es un factor muy importante para poder administrarlos, de esta forma el sistema consumidor puede conocer su especificación en un forma simple. Este proceso se implementa con un registro de servicios y una herramienta de UDDI.
TNets de SOA
En la práctica se definen 4 reglas que debe cumplir un sistema basado en SOA , estas reglas se las denomina TNets de SOA [Esposito Dino et at, 2009]
TNet N° 1; Las fronteras deben ser explícitas
La interacción con los servicios se debe hacer mediante interfaces públicas. Los métodos en la interface representan los puntos de entrada en el servicio y los datos en la firma de los métodos representan los mensajes de entrada y salida del servicio.
Las interfaces deben ser lo más simples posibles y no deben exponer datos internos a los servicios, la implementación interna de los mismos debe ser transparente para el consumidor.
TNet N° 2 ; Los servicios deben ser autónomos
Para el caso de los servicio esta regla indica que cada servicio debe poder ser implementado, administrado y versionado en forma independiente del sistema en el cual es implementado y consumido. Esto no indica que los servicio deben estar totalmente aislados del resto del sistema, lo que indica que debe tener el menor acoplamiento posible. Por lo tanto si necesita comunicarse con otros servicios lo debe hacer mediante contratos y políticas.
TNet N° 3: Usar contratos , no clases
Unos de los objetivos de SOA es la interoperabilidad, o sea todo servicio debe tener una inteface pública basadas en estándares de la industria e independiente de la plataforma. En el caso de un sistema basado en componentes las interfaces entre ellos comparten clases, para el caso de SOA esto no es válido porque el sistema sería dependiente de la plataforma.
Estas interfaces públicas se basan en contratos de servicios basado en mensajes.
Los mensajes compartidos son documentos XML y su contrato está especificado mediante esquemas xml (XSD).
Las diferentes implementaciones de SOA convierten esos mensajes XML en clases específica de una determinada plataforma y convierten las clases de respuesta en sus correspondientes mensajes XML como respuesta al consumidor del servicio.
TNet N° 4: La compatibilidad es basada en políticas
Que un servicio sea accesible y que lo pueda llamar no es una buena razón para el consumidor lo invoque. Los servicios y contratos son necesarios pero no suficientes, estos indican que es lo que se envía al servicio y que se espera de él.
Este TNet se refiere a la semántica de compatibilidad entre servicios, que un servicios haga exactamente lo que el consumidor espera. Esta semática se expone vía un acceso público y una política estándar. El estándar WS-Policy [W3C WS-Policy, 2007] específica como se debe implementar este TNet
Gobierno SOA
De la definición de SOA se desprende que para poder hacer una correcta implementación y mejorar el ROI es necesario un gobierno SOA, esto implica el proceso para poder administrar los servicios, publicarlos, controlar las versiones etc. Este factor es imprescindible porque en caso contrario no se puede aprovechar las ventajas que provee este estilo de arquitectura.
Según Bobby Wolf , Consultor WebSphere J2EE de IBM [Woolf Bobby, 2007], un proceso de gobierno SOA debe manejar al menos los siguientes aspectos.
• Definición del servicio
Involucra la técncias y herramientas que permiten identificar, describir la funcionalidad y comportamiento de un determinado servicio
• Ciclo de vida del servicio
Como todo desarrollo software los servicios deben respetar un ciclo de vida de desarrollo, para el caso particular de los servicios estos pueden tener los siguiente estados.
1. Planeado.
Cuando un nuevo servicio está siendo diseñado, pero aún no implementado
2. En prueba.
El servicio está implementado en un ambiente de prueba para que pueda ser probado por el grupo correspondiente.
3. Activo
En este estado el servicio está disponible para ser consumido y por lo tanto se considera un servicio productivo. Esto implica que debe tener alta disponibilidad no se puede dar de baja o modificar sin un adecuado proceso que mitigue el impacto en los consumidores.
4.Obsoleto:
En este estado el servicio aún está activo, pero su funcionalidad es obsoleta y por lo tanto a partir de pasar a este estado no se deben aceptar nuevos consumidores y se debe comunicar que el servicio será reemplazado.
5.Eliminado:
En este estado el servicio ya no está más disponible, muchas veces es inevitable y no siempre se pasa a este estado en forma planificada. Cosa que se debe evitar para evitar el impacto en los consumidores.
• Versionado
Los servicios tienen cierta funcionalidad que satisfacen una especificación funcional específica, por lo tanto el servicio puede cambiar por cambios funcionales, por errores detectados u otro motivo. Esta situación inevitable en todo software requrie ser adminstrado en forma correcta para evitar perjudicar a los consumidores. Lo que se debe hacer es versionar los servicios manteniendo las versiones antiguas disponibles hasta que por algún motivo se se consideren obsoletas.
Para versionar existen varias técnias y cada una tiene sus pro y contras y algunas de ellas son mandatorias cuando se implementan los servicios en determinada tecnología que solo utiliza determianda técnica. Como técnicas podemos mencionar:
- Cambio de nombre del servicio con un sufijo que indique la versión.
- Agregado de parámetros opcionales en la espcificación de la interface.
- Agregado de información de la versión en la cabecera de los mensajes.
- Enrutamiento dinámico por contenido, en donde el sistema envía el mensaje a la versión correspondientes.
• Migración
En muchas situaciones en que el servicio evoluciona de versión el consumir puede seguir usando alguna versión antigua, pero esto no siempre es así y necesariamente el cosumidor debe migrar de versión porque la nueva provee funcionalidad que justifican el esfuerzo , porque la versión actual se queda obsoleta etc. El proveedor del servicio no puede depender de la migración de los consumidores, a los sumo proporciona la mayor información para que estos migren en sus propios tiempos.
• Registros de servicios
Para que los consumidores puedan acceder a los servicios primero debe saber donde están ubicados y como acceder a ellos. Además permite administrar las versiones de los servicios.
Una vez que el consumidor comienza a invocar el servicios depende de él, por lo tanto no alcanza con publicar el servicios sino que debe existir un mecanismo para regitrar las dependencias entre lo servicios y los consumidores incluyendo notificaciones a los consumidores cuando hay cambios en el servicios publicado o cuando va a ser pasado al estado obsoleto.
• Modelos de mensajes de los servicios.
En una invocación de servicios el consumidor y el proveedore debene estar de acuerdo con el formato de los mensajes a intercambiar. Para evitar el caos que searía ponerse de acuerdo entre grupos de trabajo que separados, decenas de servicios y de consumidores se adopta utilizar un modelo de datos canónico.Un modelo de datos canónico es un grupo de formatos de datos que es independientes de cualquier aplicación y compartida por todas ellas. Dentro de los procesos de gobierno SOA debe haber uno que en forma neutral encargado de definir estos formatos de datos comunes.
• Monitoreo
Es un sistema SOA se debe garantizar un determina Nivel de Servicio Acordado (SLA), pues la caída de cualquier de ellos puede afectar el funcionamiento de los consumidores y de servicios asociados si el que falló por parte de una composición de servicios.
El sistema de monitoreo es el encargado de detectar y prevenir problemas antes que ocurran midiendo los recuros de lso servidores donde están implementados los servicios, si los tiempos de respuesta están dentro de los valores predeterminados etc.
• Propiedad del servicios
Cuando una aplicación usa un servicios, ¿quién es el responsable por el servicios?. La definición es ambigüa y se debe determinar en forma clara para evitar malos entendidos. En grandes empresas puede ser un área provea servicios para acceder a información referente a ella,pro lo tanto en ese caso el área de IT de esa área de negocio es la responsable por la diponibilidad y mantenimiento del servicio. En el caso de sistemas empresariales formado por composición de servicios esta responsabilidad se solapa, por lo tanto debe haber una cooperación entre analisistas de negocios, arquitectos empresariales, arquitectos de software, reponsables de tecnología y de áreas de desarrollo para alinear todo lo referente a los servicios al negocio de la empresa.
• Pruebas de los servicios
Como todo sistema software los servicios pasan por un estado de pruebas antes de implementar en un sistema productivo. Estas pruebas deben ser tanto funcionales como técnicas y las debe hacer el área proveedora de los servicios. Los consumidores lo único que debe probar es su propia funcionalidad y la conexión con los servicios consumidos, pues pueden asumir que los servicios publicados funcionan correctamente.
• Seguridad en los servicios
¿Cualquier usuarios puede acceder al servicios? ¿Todos los datos expuestos son públicos?, ¿La información compartida debe transmitirse por canales seguros? ¿Cómo se maneja el sistema de auditaría para evitar invocaciones no autorizadas?. Estas y muchas preguntas relacionadas con la intergradidad de los datos manejados y la disponibilidad de los servicios la maneja el área de seguridad y por lo tanto estos aspectos se deben considerar en la etapa de diseño de los servicios.
Conclusión:
SOA es un importante paradigma que si es bien aplicado puede ayudar en mucho a la integración de las áreas de negocio de la empresa, mejorar la reusabilidad de los desarrollos, tener un leguaje común de modelado etc. Los proveedores suelen poner como latigijo el tema de la mejora del ROI, este es un tema en donde no pude profundizar y no se que tan fácil es calcularlo.
Lo más importante para implementar SOA no es la técnología aplicada, productos y habilidades ténicas, sino procesos bien conformados, integración de las áreas y lo más importantes cambios cultural para pensar en "SOA" de los gerentes de negocios, de IT, analisistas y lideres de proyecto.
Luego de salvado este paso (nada fácil por cierto) pasamos las habilidades de la gente ténica de IT, deben pensar en el árbol pero tambien en el bosque para no plantar un eucalipto en un bosque de pinos, usar patrones de la industria para independizar los servicios de la plataformas del consumidor , diseñar pensando en la reutilización (en la medida de los posible) entre otroas cosas.
Por último, como los procesos de negocio cambian constantemente (como dice el famoso refrán "lo único constante es el cambio"), los sistemas que forman la solución SOA deben ser lo más flexibles posible para poder seguir ese cambio, ese también es una gran desafío.
Referencias
[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.
[W3C WS-Policy, 2007], Web Services Policy 1.5 – Framework,
http://www.w3.org/TR/ws-policy .
[Woolf Bobby, 2007], “Introduction to SOA governance, Governance: The official IBM definition, and why you need it”,
IBM SOA Governance
A mi criterio el tema de SOA fue un gran boom hace 6 o 7 años y luego fue madurando para ser un paradigma aplicable con exito en empresas donde la madures de sus procesos justifique la gran inversión que requiere implementar SOA. No solo es cuestión de soft y hard, sino también de un cambio cultural muy importante en la compañía. Es común que cada área de negocio tenga su propia genencia que sub procesos independientes y prioridades diferentes. por los general es obvio que todas está alineadas a un objetivo de negocio común, pues sino estraríamos en otros problema que es más un análisis de administradores de empresas y consultores asociados.
Pero de todas formas esta diferentes prioridades hace que a larga cada área sea como silos aislados en donde emprenden la contrucción de aplicaciones para resolver determinadas área de negocio, sin pensar (o poco) en lo que implementa las otas áreas.
Como consecuencia tenemos casos de duplicación de funcionalidad, repostorios con datos con entidades redundantes (por ej varias tablas de clientes o de proveedores).
La estandarización de esto requiere de un área que tenga una visión transversal a todas las áreas para poder alinearlos, definir estándares de integración, desarrollo , deployment etc con el fin de integrar las diferentes áreas de negocio. Esta área deberia estar formado por especialistas en las diferenes ramas del desarrollo y arquitectos empresariales.
Volviendo al tema de SOA, una vez que tenemos los procesos, podemos pensar en la implementación en sistemas software (primero los procesos , despues el software).
Ahora, para los más ansiosos paso a describir un resumen (o recordatorio según en caso) de los que es SOA desde el punto de vista ténico.
Arquitectura orientada a servicios
Servicios
Los servicios son sistemas autónomos, que poseen una especificación definida que pueden ser accedidos en forma remota desde otras aplicaciones de la compañía.
Desde el punto de punto de vista del consumidor del servicio no interesa como está implementado sino cual es el mensaje de entrada a recibir y cuál es el formato de la salida, de esta forma se pueden crear sistemas altamente escalables, distribuidos y reutilizables.
Para que los servicios puedan forma parte de una arquitectura orientada a servicios deben tener al menos las siguientes características
• Reusables: Proveen servicios de negocio que pueden ser utilizados por varias aplicaciones.
• Proporcionar un contrato formal: Indica que establece una interface formal para los mensajes de entrada y de salida. En la práctica se debe los mensajes tienen formato XML, por lo tanto se deben exponer esquemas XML (XSD) y no clases.
• Deben tener bajo acoplamiento
Significa que un cambio en la implementación de alguno de ellos debe afectar lo mínimo posible a los demás.
• Deben permitir la composición entre ellos.
Esta funcionalidad permite componer el resultado de la ejecución de varios servicios para ofrecer un solo resultado. En la práctica esto se podría implementar con un Enterprise Service Bus.
• Deben ser autónomos.
Indica que su implementación y administración se debe poder hacer independientemente de los demás, eta característica está muy asociada con la de bajo acomplamiento.
• No deben tener estado.
Indica que el servicio recibe el mensaje de entrada, lo procesa y luego responde el resultado sin mantener estado alguna entre ejecuciones.
• Deben poder ser descubiertos.
El descubrimiento de lo servicio es un factor muy importante para poder administrarlos, de esta forma el sistema consumidor puede conocer su especificación en un forma simple. Este proceso se implementa con un registro de servicios y una herramienta de UDDI.
TNets de SOA
En la práctica se definen 4 reglas que debe cumplir un sistema basado en SOA , estas reglas se las denomina TNets de SOA [Esposito Dino et at, 2009]
TNet N° 1; Las fronteras deben ser explícitas
La interacción con los servicios se debe hacer mediante interfaces públicas. Los métodos en la interface representan los puntos de entrada en el servicio y los datos en la firma de los métodos representan los mensajes de entrada y salida del servicio.
Las interfaces deben ser lo más simples posibles y no deben exponer datos internos a los servicios, la implementación interna de los mismos debe ser transparente para el consumidor.
TNet N° 2 ; Los servicios deben ser autónomos
Para el caso de los servicio esta regla indica que cada servicio debe poder ser implementado, administrado y versionado en forma independiente del sistema en el cual es implementado y consumido. Esto no indica que los servicio deben estar totalmente aislados del resto del sistema, lo que indica que debe tener el menor acoplamiento posible. Por lo tanto si necesita comunicarse con otros servicios lo debe hacer mediante contratos y políticas.
TNet N° 3: Usar contratos , no clases
Unos de los objetivos de SOA es la interoperabilidad, o sea todo servicio debe tener una inteface pública basadas en estándares de la industria e independiente de la plataforma. En el caso de un sistema basado en componentes las interfaces entre ellos comparten clases, para el caso de SOA esto no es válido porque el sistema sería dependiente de la plataforma.
Estas interfaces públicas se basan en contratos de servicios basado en mensajes.
Los mensajes compartidos son documentos XML y su contrato está especificado mediante esquemas xml (XSD).
Las diferentes implementaciones de SOA convierten esos mensajes XML en clases específica de una determinada plataforma y convierten las clases de respuesta en sus correspondientes mensajes XML como respuesta al consumidor del servicio.
TNet N° 4: La compatibilidad es basada en políticas
Que un servicio sea accesible y que lo pueda llamar no es una buena razón para el consumidor lo invoque. Los servicios y contratos son necesarios pero no suficientes, estos indican que es lo que se envía al servicio y que se espera de él.
Este TNet se refiere a la semántica de compatibilidad entre servicios, que un servicios haga exactamente lo que el consumidor espera. Esta semática se expone vía un acceso público y una política estándar. El estándar WS-Policy [W3C WS-Policy, 2007] específica como se debe implementar este TNet
Gobierno SOA
De la definición de SOA se desprende que para poder hacer una correcta implementación y mejorar el ROI es necesario un gobierno SOA, esto implica el proceso para poder administrar los servicios, publicarlos, controlar las versiones etc. Este factor es imprescindible porque en caso contrario no se puede aprovechar las ventajas que provee este estilo de arquitectura.
Según Bobby Wolf , Consultor WebSphere J2EE de IBM [Woolf Bobby, 2007], un proceso de gobierno SOA debe manejar al menos los siguientes aspectos.
• Definición del servicio
Involucra la técncias y herramientas que permiten identificar, describir la funcionalidad y comportamiento de un determinado servicio
• Ciclo de vida del servicio
Como todo desarrollo software los servicios deben respetar un ciclo de vida de desarrollo, para el caso particular de los servicios estos pueden tener los siguiente estados.
1. Planeado.
Cuando un nuevo servicio está siendo diseñado, pero aún no implementado
2. En prueba.
El servicio está implementado en un ambiente de prueba para que pueda ser probado por el grupo correspondiente.
3. Activo
En este estado el servicio está disponible para ser consumido y por lo tanto se considera un servicio productivo. Esto implica que debe tener alta disponibilidad no se puede dar de baja o modificar sin un adecuado proceso que mitigue el impacto en los consumidores.
4.Obsoleto:
En este estado el servicio aún está activo, pero su funcionalidad es obsoleta y por lo tanto a partir de pasar a este estado no se deben aceptar nuevos consumidores y se debe comunicar que el servicio será reemplazado.
5.Eliminado:
En este estado el servicio ya no está más disponible, muchas veces es inevitable y no siempre se pasa a este estado en forma planificada. Cosa que se debe evitar para evitar el impacto en los consumidores.
• Versionado
Los servicios tienen cierta funcionalidad que satisfacen una especificación funcional específica, por lo tanto el servicio puede cambiar por cambios funcionales, por errores detectados u otro motivo. Esta situación inevitable en todo software requrie ser adminstrado en forma correcta para evitar perjudicar a los consumidores. Lo que se debe hacer es versionar los servicios manteniendo las versiones antiguas disponibles hasta que por algún motivo se se consideren obsoletas.
Para versionar existen varias técnias y cada una tiene sus pro y contras y algunas de ellas son mandatorias cuando se implementan los servicios en determinada tecnología que solo utiliza determianda técnica. Como técnicas podemos mencionar:
- Cambio de nombre del servicio con un sufijo que indique la versión.
- Agregado de parámetros opcionales en la espcificación de la interface.
- Agregado de información de la versión en la cabecera de los mensajes.
- Enrutamiento dinámico por contenido, en donde el sistema envía el mensaje a la versión correspondientes.
• Migración
En muchas situaciones en que el servicio evoluciona de versión el consumir puede seguir usando alguna versión antigua, pero esto no siempre es así y necesariamente el cosumidor debe migrar de versión porque la nueva provee funcionalidad que justifican el esfuerzo , porque la versión actual se queda obsoleta etc. El proveedor del servicio no puede depender de la migración de los consumidores, a los sumo proporciona la mayor información para que estos migren en sus propios tiempos.
• Registros de servicios
Para que los consumidores puedan acceder a los servicios primero debe saber donde están ubicados y como acceder a ellos. Además permite administrar las versiones de los servicios.
Una vez que el consumidor comienza a invocar el servicios depende de él, por lo tanto no alcanza con publicar el servicios sino que debe existir un mecanismo para regitrar las dependencias entre lo servicios y los consumidores incluyendo notificaciones a los consumidores cuando hay cambios en el servicios publicado o cuando va a ser pasado al estado obsoleto.
• Modelos de mensajes de los servicios.
En una invocación de servicios el consumidor y el proveedore debene estar de acuerdo con el formato de los mensajes a intercambiar. Para evitar el caos que searía ponerse de acuerdo entre grupos de trabajo que separados, decenas de servicios y de consumidores se adopta utilizar un modelo de datos canónico.Un modelo de datos canónico es un grupo de formatos de datos que es independientes de cualquier aplicación y compartida por todas ellas. Dentro de los procesos de gobierno SOA debe haber uno que en forma neutral encargado de definir estos formatos de datos comunes.
• Monitoreo
Es un sistema SOA se debe garantizar un determina Nivel de Servicio Acordado (SLA), pues la caída de cualquier de ellos puede afectar el funcionamiento de los consumidores y de servicios asociados si el que falló por parte de una composición de servicios.
El sistema de monitoreo es el encargado de detectar y prevenir problemas antes que ocurran midiendo los recuros de lso servidores donde están implementados los servicios, si los tiempos de respuesta están dentro de los valores predeterminados etc.
• Propiedad del servicios
Cuando una aplicación usa un servicios, ¿quién es el responsable por el servicios?. La definición es ambigüa y se debe determinar en forma clara para evitar malos entendidos. En grandes empresas puede ser un área provea servicios para acceder a información referente a ella,pro lo tanto en ese caso el área de IT de esa área de negocio es la responsable por la diponibilidad y mantenimiento del servicio. En el caso de sistemas empresariales formado por composición de servicios esta responsabilidad se solapa, por lo tanto debe haber una cooperación entre analisistas de negocios, arquitectos empresariales, arquitectos de software, reponsables de tecnología y de áreas de desarrollo para alinear todo lo referente a los servicios al negocio de la empresa.
• Pruebas de los servicios
Como todo sistema software los servicios pasan por un estado de pruebas antes de implementar en un sistema productivo. Estas pruebas deben ser tanto funcionales como técnicas y las debe hacer el área proveedora de los servicios. Los consumidores lo único que debe probar es su propia funcionalidad y la conexión con los servicios consumidos, pues pueden asumir que los servicios publicados funcionan correctamente.
• Seguridad en los servicios
¿Cualquier usuarios puede acceder al servicios? ¿Todos los datos expuestos son públicos?, ¿La información compartida debe transmitirse por canales seguros? ¿Cómo se maneja el sistema de auditaría para evitar invocaciones no autorizadas?. Estas y muchas preguntas relacionadas con la intergradidad de los datos manejados y la disponibilidad de los servicios la maneja el área de seguridad y por lo tanto estos aspectos se deben considerar en la etapa de diseño de los servicios.
Conclusión:
SOA es un importante paradigma que si es bien aplicado puede ayudar en mucho a la integración de las áreas de negocio de la empresa, mejorar la reusabilidad de los desarrollos, tener un leguaje común de modelado etc. Los proveedores suelen poner como latigijo el tema de la mejora del ROI, este es un tema en donde no pude profundizar y no se que tan fácil es calcularlo.
Lo más importante para implementar SOA no es la técnología aplicada, productos y habilidades ténicas, sino procesos bien conformados, integración de las áreas y lo más importantes cambios cultural para pensar en "SOA" de los gerentes de negocios, de IT, analisistas y lideres de proyecto.
Luego de salvado este paso (nada fácil por cierto) pasamos las habilidades de la gente ténica de IT, deben pensar en el árbol pero tambien en el bosque para no plantar un eucalipto en un bosque de pinos, usar patrones de la industria para independizar los servicios de la plataformas del consumidor , diseñar pensando en la reutilización (en la medida de los posible) entre otroas cosas.
Por último, como los procesos de negocio cambian constantemente (como dice el famoso refrán "lo único constante es el cambio"), los sistemas que forman la solución SOA deben ser lo más flexibles posible para poder seguir ese cambio, ese también es una gran desafío.
Referencias
[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.
[W3C WS-Policy, 2007], Web Services Policy 1.5 – Framework,
http://www.w3.org/TR/ws-policy .
[Woolf Bobby, 2007], “Introduction to SOA governance, Governance: The official IBM definition, and why you need it”,
IBM SOA Governance
Suscribirse a:
Entradas (Atom)