Introducción a la gobernanza SOA

Gobernanza: la definición oficial de IBM y porqué la necesita

Descubra cómo define IBM la gobernanza— de la Arquitectura Orientada al Servicio (SOA) y aprenda qué es y porqué es importante para el éxito de su proyecto de SOA.

Bobby Woolf, Consultor ISSW WebSphere J2EE, IBM

Bobby WoolfBobby Woolf es un miembro de Servicios de Software de IBM para WebSphere, consultores que ayudan a los clientes a alcanzar el éxito con los productos WebSphere. Es el coautor de Enterprise Integration Patterns y The Design Patterns Smalltalk Companion. Bobby asiste a los clientes en el desarrollo de aplicaciones con arquitectura orientada al servicio para el Servidor del Proceso WebSphere de IBM mediante el Desarrollador de Integración WebSphere de IBM. Bobby también es un orador frecuente en varias conferencias. Leer más en el blog de Bobby en developerWorks.



03-12-2012

La necesidad de gobernanza y administración

Desarrolle habilidades de este tema

Este contenido es parte de un knowledge path progresivo para avanzar en sus habilidades. Vea Computación en la nube: Cree una política eficaz para la nube

La Arquitectura Orientada al Servicio (SOA) es una técnica impactante para el desarrollo de aplicaciones de software que mejor se alinean con los modelos comerciales. Sin embargo, la SOA aumenta el nivel de cooperación y de coordinación que se requiere entre las empresas y la tecnología de la información (TI), así como entre los departamentos y los equipos de TI. Esta cooperación y coordinación es proporcionada por la gobernanza de SOA, que abarca las tareas y los procesos para especificar y administrar cómo se soportan los servicios y las aplicaciones de la SOA.

En este artículo, descubra qué gobernanza y gestión son y por qué son importantes. Entonces, revisaremos los siguientes aspectos importantes de la gobernanza de SOA:

Con esta información, debería tener una buena idea de por qué sus esfuerzos con respecto a la SOA necesitan una gobernanza de SOA. También tendrá algunas ideas sobre cómo su organización puede crear su propio esquema de gobernanza de la SOA.

La vida sin gobernanza

Antes de que hablemos sobre qué es la gobernanza, pensemos sobre cómo funcionan generalmente las cosas en un departamento corporativo de TI; es decir, cómo funcionan las cosas cuando no hay gobernanza.

Entonces desea proveer un servicio

Supongamos que desarrolla un servicio pequeño para convertir una suma monetaria en una moneda en otra moneda. Lo necesita en un par de lugares diferentes en un programa de procesamiento de pedidos en el que está trabajando, entonces escribe un código como una función reutilizable que puede invocar desde cualquier lugar en su programa. Lo necesita en otro programa, entonces ingresa el código en un Java .jar que puede agregar a la clase de vía de cualquier programa que lo necesita. Pero un problema con el servicio es que lleva mucho tiempo iniciarse dado que necesita inicializarse con tarifas de cambio de divisas, como las que se publican en el sitio web conversor de divisas de Yahoo. Estos pasos llevan mucho tiempo para inicializar cada vez que necesita convertir una suma monetaria. Entonces, aloja su conversor en su propio programita que inicia, se inicializa y siempre está ejecutado y, siempre, puede llamarse desde uno de sus programas a través del API remoto. Tal vez, la API se implementa como un servicio web HTTP sobre SOAP o es simplemente una interfaz remota de Enterprise JavaBeans (EJB) que soporta RMI sobre IIOP.

Lo que tiene ahora es un servicio de conversión de divisas. No solo lo utilizan un par de sus programas, sino que le gusta a algunos de sus compañeros de trabajo en su departamento y comienza a invocarlo desde otros programas. Desde hace mucho, sin que usted lo sepa, existen programas en otros departamentos de su empresa que lo están usando y de los cuales usted nunca había oído hablar. El conversor está ejecutándose de tal manera que los tiempos de respuesta son lentos, entonces persuada a su gerente para que compre una máquina más poderosa para alojar su servicio. El gerente no está feliz de gastar dinero de su presupuesto en otra máquina que usted comentó que está realizando algo simple, pero logra convencerlo.

Una semana, la máquina se rompe y usted se entera porque alguien de su empresa que es desconocido para usted llama a su casa y le pide que venga a la oficina para hacer funcionar el conversor. Más tarde, su gerente dice que recibió quejas de otro departamento porque el conversor no está actualizándose a las tarifas de cambio actuales en tiempo y forma. Él quiere arreglarlo, pero no quiere que a usted le lleve tiempo real fuera de su horario de trabajo. ¿Cómo se responsabilizaría usted por todo esto?

Un día dice: "Al diablo con esto". No se hará más responsable por el conversor y lo apaga. Comienzan a circular cientos de mensajes de correo electrónico con quejas de personas que están intentando descubrir quién es el responsable del conversor y por qué dejó de funcionar. Muchos en los correos electrónicos se quejan porque programas importantes dejaron de funcionar sin el conversor. Los clientes están enojados, la empresa está perdiendo dinero y, con suerte, cuando alguien se dé cuenta de que usted era el responsable, lo despedirán. ¿Cómo sucedió esto?

Entonces desea consumir un servicio

Ahora consideremos la otra cara de la moneda. Es un empleado diferente en esta empresa y trabaja con una aplicación de catálogos de productos. Usuarios de diferentes países quieren poder ver cuánto cuestan los productos en su moneda. Un compañero de trabajo le cuenta a usted sobre este servicio que puede solicitar que convierte los precios de los productos a la moneda del usuario. Lo prueba y comprueba que funciona, entonces lo implementa en su aplicación. Su gerente está feliz de que obtuvo una nueva función que funciona en tiempo récord, los clientes adoran esta función y las ventas en su sitio web aumentan de forma notable.

Entonces, un fin de semana, su sitio web deja de funcionar: no puede mostrar los precios en otras divisas. Su gerente lo llama a su casa y le ordena que arregle el programa pronto. Usted llama a su compañero de trabajo a su casa, aquel que le había contado que un amigo de un amigo le había hablado del servicio. Mientras tanto, el asistente del vicepresidente de ventas llama para informarle que los clientes se están quejando. Usted le cuenta del amigo del otro amigo que aparentemente diseño el servicio. El asistente los llama y los cita en la oficina para que nuevamente pongan en funcionamiento el programa. Mientras tanto, usted está en problemas porque la aplicación del catálogo dejó de funcionar aunque no había ningún problema con ella, sino con el servicio que había solicitado. ¿Cómo pasó a ser su culpa?

Bienvenido al mundo de la gobernanza de la SOA. O, en este caso, la falta de una gobernanza efectiva. Tanto el proveedor del servicio como el consumidor son responsables de mucho más de lo que suponen. ¿Cómo utiliza servicios sin que se descontrolen de esa forma?


¿Qué es la gobernanza de la SOA?

Acabamos de ver qué sucede cuando la gobernanza es inefectiva. Entonces, ¿de qué manera funcionaría mejor la TI si su gobernanza fuera mejor? En primer lugar, necesitamos saber qué es la gobernanza y cómo impacta en la TI y en los servicios.

En general, gobernanza significa establecer y exigir cómo acuerda trabajar un grupo en equipo. Específicamente, la gobernanza es el establecimiento de:

  • Cadenas de responsabilidad para facultar a las personas
  • Medición de la efectividad de los calibradores
  • Políticas para guiar la organización con el fin de que cumpla sus objetivos
  • Mecanismos de control para garantizar el cumplimiento
  • Comunicación para mantener todas las partes informadas

La gobernanza determina quién es responsable de tomar decisiones, qué decisiones deben tomarse y las políticas para tomar decisiones de forma consistente.

La gobernanza es diferente de la gestión. La gobernanza planea qué decisiones se necesitarán realizar, mientras que la administración es el proceso de tomar e implementar decisiones. La gobernanza establece políticas, mientras que la administración las respeta.

La gobernanza de TI es gobernanza para la TI, es decir: La aplicación de la gobernanza para una organización de TI, su gente, los procesos y la información para guiar la forma en la que esos bienes soportan las necesidades de la empresa. La gobernanza de SOA es una especialización de la gobernanza de TI que coloca las decisiones clave de gobernanza de TI dentro del contexto del ciclo de vida de los componentes, los servicios y los procesos comerciales. Es la gestión efectiva de este ciclo de vida que es la meta clave de la gobernanza de la SOA.

La gobernanza de la TI es más amplia que la gobernanza de la SOA. La gobernanza de TI cubre todos los aspectos de TI, incluidas las cuestiones que afectan la SOA, como los modelos de datos y la seguridad, así como cuestiones más allá de SOA como el almacenamiento de datos y el soporte de escritorio. La gobernanza de SOA abarca aspectos del ciclo de vida del servicio como: planeamiento, publicaciones, descubrimientos, control de versiones, gestión y seguridad.

La gobernanza se hace más importante en la SOA que en la TI general. En la SOA, los consumidores del servicio y los proveedores del servicio ejecutan diferentes procesos, son desarrollados y gestionados por diferentes departamentos y requieren de mucha coordinación para trabajar juntos de forma exitosa. Para que la SOA tenga éxito, varias aplicaciones necesitan compartir servicios comunes, lo que significa que necesitan coordinar para que esos servicios sean comunes y reutilizables. Estas son cuestiones de gobernanza y son mucho más completas que en los días de las aplicaciones monolíticas o incluso en los días de códigos y componentes reutilizables.

Dado que las empresas utilizan la SOA para alinear mejor la TI con las empresas, pueden utilizar la gobernanza de la SOA para mejorar la gobernanza general de la TI. La implementación de la gobernanza de SOA es clave si las empresas van a darse cuenta de los beneficios de la SOA. Para que la SOA sea exitosa, la gobernanza técnica y comercial de la SOA no es opcional, es una necesidad.

gobernanza de la SOA en práctica

En la práctica, la gobernanza de la SOA guía el desarrollo de servicios reutilizables, lo que establece cómo se diseñarán y se desarrollarán los servicios y cómo cambiarán con el tiempo. Establece acuerdos entre los proveedores de servicios y los consumidores de esos servicios y es cuenta a los consumidores lo que esperan y lo que los proveedores están obligados a proporcionar.

La gobernanza de SOA no diseña los servicios, pero proporciona una guía acerca de cómo los servicios se diseñarán. Ayuda a responde muchas preguntas espinosas relacionadas con la SOA: ¿Qué servicios se encuentran disponibles? ¿Quiénes los pueden usar? ¿Cuán confiables son? ¿Cuánto tiempo se los soportará? ¿Puede depender de ello para no cambiar? ¿Qué pasa si los quiere cambiar, por ejemplo, para solucionar un error lógico? ¿O agregar una nueva función? ¿Qué pasa si los consumidores quieren que el mismo servicio funcione de manera diferente? Simplemente porque decidió exponer un servicio, ¿eso significa que está obligado a sustentarlo para siempre? Si decide consumir un servicio, ¿tiene la certeza de que no dejará de funcionar mañana?

La gobernanza de SOA crea las prácticas y las técnicas de gobernanza de TI existentes. Un aspecto clave de la gobernanza de TI cuando se utilizan tecnologías orientadas al objeto como Java 2 Platform, Enterprise Edition (J2EE) es la reutilización del código. La reutilización del código ilustra las dificultades de la gobernanza de TI. Todos piensan que los bienes reutilizables son buenos, pero es difícil hacerlos funcionar en la práctica: ¿Quién va a pagar para desarrollarlos? ¿Realmente los equipos de desarrollo intentarán volver a utilizarlos? ¿Pueden todos acordar realmente sobre un solo conjunto de comportamientos para un bien reutilizable, o todos tendrán su propia versión personalizada que en realidad no se la está utilizando después de todo? La SOA y los servicios hacen que estas cuestiones de la gobernanza sean aún más importantes y, por lo tanto, sus consecuencias son más significativas.

La gobernanza es más un problema político que uno tecnológico o comercial. La tecnología se concentra en unir las interfaces y los protocolos de invocación. Las empresas se focalizan en la funcionalidad para los clientes. La tecnología y las empresas se focalizan en los requisitos. Mientras que la gobernanza se involucra con estos aspectos, se centra más en garantizar que todos trabajen juntos y que los esfuerzos individuales no sean contradictorios entre sí. La gobernanza no determina cuáles son los resultados de las decisiones, pero qué decisiones deben tomarse y quienes deben tomarlas.

Las dos partes, los consumidores y los proveedores, tienen que acordar cómo van a trabajar juntos. Gran parte de este conocimiento puede capturarse en un acuerdo de nivel de servicios (ANS), metas medibles que un proveedor de servicios acuerda alcanzar y con el que acuerda convivir un consumidor de los servicios. Este acuerdo es como un contrato entre las partes y puede, de hecho, ser un contrato legal. En el mejor de los casos, el ANS articula lo que el proveedor debe hacer y lo que espera el consumidor.

La gobernanza de la SOA está decretada por un centro de excelencia la SOA (COE), un panel de profesionales cualificados de la SOA que establecen y supervisan las políticas para ayudar a garantizar el éxito de la empresa con la SOA. El COE establece políticas para la identificación y el desarrollo de los servicios, el establecimiento de los ANS, la gestión de registros y otros esfuerzos que proporcionan una gobernanza efectiva. Entonces, los miembros del COE ponen esas políticas en práctica, al tutelar y asistir a los equipos con el desarrollo de servicios y aplicaciones combinadas.

Una vez que el CEO de la gobernanza aplica las políticas, puede utilizarse tecnología para gestionar esas políticas. La tecnología no define un ANS, pero puede utilizarse para exigir y medir el cumplimiento. Por ejemplo, la tecnología puede limitar qué consumidores pueden invocar un servicio y cuándo pueden hacerlo. Puede advertir a un consumidor que ese servicio ya no se utiliza. Puede medir la disponibilidad del servicio y el tiempo de respuesta.

Un buen lugar para la tecnología con el fin de exigir el cumplimiento de las políticas de gobernanza es mediante una combinación de un bus de servicios empresariales (ESB) y un registro de servicios. Puede exponerse un servicio con el fin de que solo ciertos ESB pueden invocarlo. Entonces, la combinación ESB/registro puede controlar el acceso de los consumidores, supervisar y medir el uso, medir el cumplimiento del ANS y demás. De esta forma, los servicios se concentran en la proporción de funcionalidad comercial y el ESB/registro se centra en los aspectos de la gobernanza.

La gobernanza puede convertirse en un chivo expiatorio para cualquier mal en la SOA. En lo que respecta al desempeño, la gobernanza podría convertirse en una preocupación y una excusa para cualquier problema y justificación para cualquier solución cuestionable. Todo lo que genera es un único comentario cargado que se lanza en cualquier discusión sobre la SOA (lo que luego se convierte en una granada de mano retórica), y usted puede paralizar todas las conversaciones útiles. Un desafío para la SOA consiste en utilizar la gobernanza con un buen criterio para hacer que la SOA funcione mejor sin dejar que las preocupaciones sobre la gobernanza sobrepasen todo lo demás.


Ciclo de vida de la gobernanza y metodología

El desarrollo del servicio sigue un ciclo de vida que IBM denomina el ciclo de vida de la SOA. La gobernanza de la SOA también sigue un ciclo de vida, el ciclo de vida de la gobernanza de SOA. Estos dos ciclos de vida funcionan juntos, se ejecutan juntos y se utilizan de forma conjunta para producir aplicaciones combinadas de la SOA y sus servicios. El ciclo de vida de la gobernanza produce un modelo de gobernanza que se utiliza para gestionar el ciclo de vida de la SOA. El ciclo de vida de la SOA se muestra en la Ilustración 1.

Ilustración 1 Ciclo de vida de la gobernanza de la SOA
SOA gov

La gobernanza de la SOA de IBM y el Método de Administración (SGMM) es un proceso completo para llevar a cabo el ciclo de vida de la gobernanza de la SOA, entonces esa gobernanza puede aplicarse al ciclo de vida de la SOA. Las cuatro etapas de SGMM son:

  • Planear y determinar el enfoque de la gobernanza
  • Definir el modelo de gobernanza de SOA
  • Permitir e implementar el modelo de gobernanza de SOA
  • Medir y refinar el modelo de gobernanza de SOA

Un producto para ayudar a llevar a cabo el ciclo de vida de la gobernanza de SOA en general y de SGMM, específicamente, es el complemento de gobernanza de SOA para el Compositor del Método Racional de IBM. Los servicios comerciales internacionales (GBS) de IBM pueden generar el accionar de un Centro de Servicios web/SOA de IBM de excelencia para ayudar a su organización a establecer un centro de excelencia de SOA y desarrollar prácticas de gobernanza.


Aspectos de la gobernanza de SOA

La gobernanza de SOA no es solo un junto único de prácticas, sino muchos conjuntos de prácticas coordinados en conjunto. Cada uno de estos aspectos de la SOA merece una discusión en mayor detalle en los artículos subsiguientes. La discusión es simplemente una breve visión general. Más información sobre algunos de estos aspectos puede encontrarse en la sección Referencias en la conclusión del artículo.

Definición del servicio

El aspecto más fundamental de la gobernanza de SOA es supervisar la creación de servicios. Los servicios deben identificarse, su funcionalidad debe describirse, su comportamiento debe definirse y las interfaces deben diseñarse. El COE (Centro de Excelencia) de la gobernanza podría no realizar estas tareas, pero se asegura de que se lleven a cabo las tareas. El COE coordina los equipos que crean y requieren servicios para asegurarse de que se satisfacen sus necesidades y se evita un esfuerzo duplicado.

A menudo, no es obvio lo que debería ser un servicio. La función debería coincidir con un conjunto de tareas comerciales repetitivas. Las limitaciones del servicio deberían encapsular una capacidad reutilizable libre de contexto. La interfaz debería exponer qué hace el servicio, pero ocultar cómo se implementa dicho servicio y permitir que cambie la implementación o implementaciones alternativas. Cuando los servicios se diseñan desde lo reutilizable, pueden diseñarse para modelar la empresa; cuando incluyen una función existente, puede ser más difícil crear e implementar una buena interfaz comercial.

Un ejemplo existente de las dificultades posibles en la definición de los límites del servicio es dónde establecer límites transaccionales. Generalmente, un servicio funciona en su propia transacción al asegurarse de que su funcionalidad funcione completamente o que se revoque en su totalidad. Sin embargo, un coordinador del servicio (también conocido como, maestro compositor o coreógrafo) podría querer invocar servicios múltiples en una sola transacción (preferentemente mediante una interacción específica como las WS-AtomicTransactions). Esta tarea requiere que la interfaz del servicio exponga su soporte de transacción, entonces puede participar en la transacción del llamador. Pero dicha exposición requiere confianza en el llamador y puede ser riesgoso para el proveedor. Por ejemplo, el proveedor podría bloquear los recursos para llevar a cabo el servicio, pero si el llamador nunca termina la transacción (falla en la confirmación o la revocación), el proveedor tendrá la dificultad de lanzar los bloqueos de recursos de manera correcta. Como lo muestra este escenario, el alcance de un servicio y quien tiene el control a veces no es una decisión fácil.

Ciclo de vida de implementación del servicio

Los servicios no aparecen de forma instantánea y después existen para siempre. Como cualquier software, necesitan ser planificados, diseñados, implementados, desplegados, mantenidos y, finalmente, retirados del servicio. La aplicación del ciclo de vida puede ser pública y afectar muchas partes de una organización, pero un ciclo de vida del servicio puede tener un impacto más grande porque muchas aplicaciones dependen de un solo servicio.

El ciclo de vida de los servicios se hace más evidente cuando considera el uso de un registro. ¿Cuándo debe agregarse un nuevo servicio al registro? ¿Todos los servicios en un registro se encuentran necesariamente disponibles y preparados para su uso? ¿Un servicio retirado debería eliminarse del registro?

Mientras que no hay un ciclo de vida uniforme que se adecue a todos los servicios y todas las organizaciones, un ciclo de vida para el desarrollo de un servicio típico tiene cinco etapas principales:

  1. Planificación Un nuevo servicio que se identifica y está siendo diseñado, pero que aún no se implemento o se está implementando.
  2. Prueba Una vez implementado, debe probarse el servicio (más sobre pruebas en un momento). Algunas pruebas podrían necesitar realizarse en sistemas de producción, que utilizan el servicio como si fuese activo.
  3. Activo Esta es la etapa para un servicio disponible para su uso y lo que generalmente pensamos de un servicio. Es un servicio, está disponible, realmente funciona y aún no ha sido retirado.
  4. Desaprobado Esta etapa describe un servicio que aún está activo, pero que no lo estará por mucho más tiempo. Es una preocupación para los consumidores detener el uso del servicio
  5. Caducidad Esta es la etapa final de un servicio, una que ya no se proporciona. Los registros podrían querer registrar los servicios que alguna vez estuvieron activos, pero que ya no se encuentran disponibles. Esta etapa es inevitable y, con frecuencia, los proveedores o los consumidores no la planifican.

Efectivamente, la caducidad corta la versión del servicio y la fecha de caducidad debería planificarse y anunciarse con anticipación. Un servicio debería desaprobarse dentro de un periodo de tiempo adecuado antes de su caducidad con el propósito de alertar a los consumidores de forma programática para que puedan planificar según el caso. El programa de desaprobación y de caducidad debería especificarse en el ANS.

Una etapa que parece faltar en la lista es el "mantenimiento". El mantenimiento tiene lugar cuando un servicio se encuentra en estado activo; puede volver el servicio a la etapa de prueba para volver a confirmar la funcionalidad adecuada, aunque esto puede ser un problema para los usuarios existentes según el proveedor activo del servicio.

El mantenimiento tiene lugar muchos menos servicios de lo que le parece; a menudo, el mantenimiento de un servicio implica no cambiar el servicio actual, pero producir una nueva versión del servicio.

Control de versiones del servicio

Tan pronto como un servicio se encuentra disponible, los usuarios de esos servicios comienzan a necesitar cambios. Se necesita solucionar los errores lógicos, agregarse nuevas funcionalidad, rediseñar interfaces y eliminar la funcionalidad innecesaria. El servicio refleja la empresa, entonces a medida que cambia la empresa, el servicio necesita cambiar según corresponda.

Sin embargo, con los usuarios existentes del servicio, se necesita realizar los cambios con un buen criterio con el fin de no interrumpir su operación exitosa. Al mismo tiempo, las necesidades de los usuarios existentes para la estabilidad no pueden permitirse para impedir las necesidades de los usuarios que anhelan una funcionalidad adicional.

El control de las versiones del servicio cumple estas metas contradictorias. Permite a los usuarios estar satisfechos con un servicio existente para continuar utilizándolo sin cambios y permite que evolucione el servicio para satisfacer las necesidades de los usuarios con nuevos requisitos. La interfaz del servicio actual y el comportamiento se preservan como una versión, mientras que el servicio más nuevo se presenta como otra versión. La compatibilidad de versiones puede permitir al consumidor esperar que una versión invoque una versión diferente, pero compatible.

Mientras que la versión ayuda a resolver estos problemas, también introduce otros nuevos, como la necesidad de migrar.

Migración del servicio

Incluso con el control de versiones del servicio, un consumidor no puede depender de un servicio (o, más específicamente, una versión deseada de ese servicio) para que esté disponible y que sea compatible para siempre. Finalmente, el proveedor de un servicio está obligado a dejar de proporcionarlo. La compatibilidad de la versión puede ayudar a retrasar la "hora de la verdad", pero no suprimirla. El control de las versiones no obsoleta el ciclo de vida del desarrollo del servicio, pero permite que el ciclo de vida afecte generaciones sucesivas.

Cuando un consumidor comienza a utilizar un servicio, está creando dependencia en ese servicio, una dependencia que debe ser manejada. Una técnica de gestión es para la migración planificada y periódica para las versiones más nuevas del servicio. Este enfoque también permite al consumidor aprovechar la ventaja de funciones adicionales agregadas al servicio.

Sin embargo, incluso en empresas con la mejor gobernanza, los proveedores de servicios no pueden depender solo de la migración del consumidor. Por varias razones (código de legado, mano de obra, presupuesto, prioridades), algunos consumidores podrían migrar a tiempo. ¿Eso significa que el proveedor debe sustentar la versión del servicio para siempre? ¿Puede el proveedor simplemente deshabilitar la versión del servicio un día después de que todos hayan migrado?

Ninguno de estos dos extremos es conveniente. Un buen compromiso es un programa de desaprobación y caducidad planificado para cada versión del servicio, como se lo describe en el ciclo de vida de implementación del servicio.

Registros del servicio

¿Cómo hacen los proveedores de servicios para tener disponibles sus servicios y que sean conocidos? ¿Cómo hacen los consumidores de servicios para ubicar los servicios que quieren invocar? Estas son responsabilidades del registro de servicio. Actúa como una lista de servicios disponibles y apunta a invocarlos.

El registro de servicio también ayuda a coordinar versiones de un servicio. Los consumidores y los proveedores pueden especificar qué versión necesitan o tienen y, entonces, el registro se asegura de solamente enumerar los proveedores de una versión deseada por el consumidor. El registro puede administrar la compatibilidad de la versión, rastrear la compatibilidad entre versiones y enumerar los proveedores de una versión deseada por el consumidor o versiones compatibles. El registro también puede soportar estados de servicio, como pruebas y (como se mencionó antes) desaprobaciones, y hacer que solo estén disponibles los servicios con estos estados para los consumidores que los quieren.

Cuando un consumidor comienza a utilizar un servicio, se genera una dependencia a ese servicio. Mientras que cada consumidor sabe claramente de qué servicios depende, generalmente en una empresa, estas dependencias pueden ser difíciles de detectar y mucho menos de administrar. Un registro no solo puede generar una lista de servicio y proveedores, sino que también puede rastrear dependencias entre los consumidores y los servicios. Este rastreo puede ayudar a responder la pregunta secular: ¿Quién utiliza el servicio? Entonces el conocimiento del registro de dependencias puede notificar a los consumidores sobre los cambios en los proveedores, por ejemplo, cuándo un servicio es desaprobado.

El Repositorio y el Registro de Servicio WebSphere de IBM es un producto para implementar los registros de servicios. Funciona como un repositorio para las definiciones del servicio y es un registro para los proveedores de esos servicios. Proporciona un directorio centralizado para los desarrolladores con el propósito de encontrar servicios disponibles para su reutilización, así como el uso de un tiempo de ejecución para los buses del servicio a consumidores y a empresas (ESB) para encontrar proveedores y las direcciones para invocarlos.

Modelo de mensajes del servicio

En una invocación al servicio, el consumidor y el proveedor deben acordar los formatos del mensaje. Cuando equipos de desarrollo independiente diseñan las dos partes, pueden tener la dificultad de encontrar fácilmente un acuerdo sobre los formatos de mensajes comunes. Multiplique eso por docenas de aplicaciones con un servicio típico y una aplicación típica que utilice docenas de servicios y podrá ver cómo los formatos de mensajes de negociación simple pueden convertirse en una tarea a tiempo completo.

Un enfoque común para evitar el caos en el formato del mensaje consiste en utilizar un modelo de datos canónicos. Un modelo de datos canónicos es un conjunto de formatos de datos que es independiente de cualquier aplicación y lo comparten todas las aplicaciones. De esta forma, las aplicaciones no tienen que acordar en los formatos de los mensajes, simplemente pueden acordar utilizar formatos de datos canónicos existentes. Un modelo de datos canónicos abarca el formato de los datos en el mensaje, entonces necesita un acuerdo en torno al resto del formato del mensaje (como por ejemplo, campos de encabezado, qué datos contiene la carga útil de los mensajes y cómo se disponen los datos), pero el modelo canónico de datos es sumamente útil para alcanzar el acuerdo.

Un panel central de gobernanza puede actuar como una parte neutral para desarrollar un modelo de datos canónicos. Como parte de la inspección de las aplicaciones y del diseño de servicios, también puede diseñar formatos comunes de datos para utilizarlos en las invocaciones del servicio.

Supervisión del servicio

¿Si un proveedor del servicio deja de trabajar, cómo lo sabrá? ¿Espera hasta que las aplicaciones que usan esos servicios dejan de funcionar y las personas que los usan comienzan a quejarse?

Una aplicación combinada, una que combina varios servicios, es tan confiable como los servicios de los que depende. Dado que varias aplicaciones combinadas pueden compartir un servicio, una sola falla en el servicio puede afectar muchas aplicaciones. Debe definirse el ANS para describir la confiabilidad y el desempeño en el que pueden depender los consumidores. Dado que los consumidores deben ser supervisados para garantizar que cumplen con el ANS definido.

Una cuestión relacionada es la determinación de un problema. ¿Por qué deja de funcionar una aplicación combinada? Podría ser que la parte principal de la aplicación, la interfaz de usuario con la que interactúan los usuarios, haya dejado de funcionar. Pero también puede pasar que la parte principal funcione bien, pero que algunos de los servicios que utiliza o algunos de los servicios que esos servicios utilizan no estén funcionando correctamente. Por lo tanto, es importante supervisar no solo cómo cada aplicación está funcionando, sino también cómo funciona cada servicio (como una colección de proveedores) y los proveedores individuales. Es de suma importancia la correlación de eventos entre servicios en una sola transacción comercial.

Dicha supervisión puede ayudar a detectar y a evitar problemas antes de que sucedan. Puede detectar desequilibrios de carga y cortes, al proporcionar alertas antes de que la situación sea crítica, y también puede intentar corregir los problemas de forma automática. Puede medir el uso a través del tiempo para ayudar a predecir los servicios que están siendo cada vez más populares, entonces pueden funcionar con una capacidad en aumento.

Propiedad del servicio

Cuando varias aplicaciones combinadas utilizan un servicio, ¿quién es responsable de ese servicio? ¿Esa persona u organización es responsable de todas ellas? Una de ellas; si es así, ¿cuál? ¿Otros piensan que son propietarios del servicio? Bienvenido al mundo ambiguo de la propiedad del servicio.

Es difícil de adquirir cualquier recurso compartido y cuidarlo, ya sea un parque de un vecindario, un marco de trabajo Java reutilizable o un proveedor de servicio. Además, un recurso de agrupación necesitado proporciona un valor más allá de cualquier costo del participante: Piense en un sistema de caminos públicos.

A menudo, una empresa organiza su la estructura informativa de su personal y las finanzas entorno a las operaciones comerciales. En la medida en que una SOA organiza la TI de la empresa entorno a las mismas operaciones, el departamento responsable por algunas operaciones también puede ser responsable del desarrollo y el tiempo de ejecución de la TI para esas operaciones. El departamento posee esos servicios. Dado que los servicios y las aplicaciones combinadas en un SOA a menudo no siguen una estructura financiera e informativa estrictamente jerárquica, lo que genera brecas y solapamiento en las responsabilidades de TI.

Una cuestión relacionada en los roles de los usuarios. Dado que un enfoque de la SOA consiste en alinear la TI y la empresa, y otro enfoque es la reutilización de la empresa, muchas personas diferentes en una organización tienen voz y voto en lo que serán los servicios, cómo funcionarán y cómo los utilizarán. Estos roles incluyen: analistas comerciales, arquitectos empresariales, arquitectos de software, desarrolladores de software y administradores del TI. Todos estos roles tienen un interés en asegurarse de que los servicios cumplan con las necesidades de la empresa y funcionen bien.

Una SOA debe reflejar su empresa. Generalmente, esto implica cambiar la SOA para ajustarse a la empresa, pero en casos como este, podría ser necesario cambiar la empresa para coincidir con la SOA. Cuando esto no es posible, se necesitan niveles de cooperación en aumento entre varios departamentos para compartir la complicación de desarrollar servicios comunes. Esta cooperación puede alcanzarse mediante un comité vigente de organización cruzada que, en efecto, posea los servicios y los administre.

Pruebas del servicio

El ciclo de vida de implementación del servicio incluye la etapa de prueba, durante la cual el equipo confirma que un servicio funciona adecuadamente antes de activarlo. Si se prueba un proveedor del servicio y muestra funcionar correctamente, ¿el consumidor necesita volver a probarlo? ¿Todos los proveedores de un servicio se prueban con el mismo rigor? Si un servicio cambia, ¿necesita volver a probarse?

La SOA aumenta la oportunidad de probar la funcionalidad en aislamiento y aumenta la expectativa de que funciona como se debe. Sin embargo, la SOA también introduce la oportunidad de volver a probar la misma funcionalidad de forma repetida por cada nuevo consumidor que necesariamente no cree que los servicios que usa funcionan de forma adecuada y consistente. Mientras tanto, dado que las aplicaciones combinadas comparten servicios, un solo servicio de errores lógicos puede afectar de forma adversa un rango de aplicaciones aparentemente no relacionadas de esos errores de programación.

Para apalancar los beneficios de la reutilización de la SOA, los consumidores del servicio y los proveedores necesitan acordar en un nivel adecuado de evaluación de los proveedores y necesitan asegurarse de que la evaluación se realice como se acordó. Entonces, un consumidor de servicios solo necesita probar su propia funcionalidad y las conexiones con el servicio y puede asumir que el servicio funciona como se lo promocionó.

Seguridad del servicio

¿Se le permitirá a alguien invocar un servicio? ¿Debería un servicio con un rango de usuarios permitir a todos los usuarios acceder a todos los datos? ¿Necesitan protegerse los datos intercambiados entre los consumidores del servicio y los proveedores? ¿Un servicio necesita ser tan seguro como las necesidades en sus usuarios más paranoicos o como aquellos de sus usuarios más indolentes?

La seguridad es una proposición difícil, pero necesaria para cualquier aplicación. La funcionalidad necesita limitarse a los usuarios autorizados y los datos necesitan protegerse desde la intercepción. Al proporcionar más puntos de acceso para la funcionalidad (es decir, servicios), la SOA tiene el potencial de aumentar en gran medida la vulnerabilidad en las aplicaciones combinadas.

La SOA crea servicios que son fáciles de reutilizar, incluso por los consumidores que no ayudarán a volver a utilizarlos. Incluso entre los usuarios autorizados, no todos los usuarios deberían tener acceso a todos los datos a los que tiene que acceder el servicio. Por ejemplo, un servicio para acceder a las cuentas bancarias debería solo hacer que las cuentas de usuarios particulares se encuentren disponibles, aunque el código también tenga acceso a otras cuentas para otros usuarios. Algunos consumidores de un servicio tienen más necesidades que otros consumidores del mismo servicio para la confidencialidad de los datos, la integridad y el no repudio.

Las tecnologías de invocación de servicio debe ser capaz de proporcionar todas esas capacidades de seguridad. El acceso a los servicios tiene que controlarse y limitarse a los consumidores autorizados. La identidad del usuario debe propagarse en servicios y utilizarse para autorizar el acceso a datos. Las calidades de la protección de los datos deben ser representadas como políticas dentro de rangos. Esto permite a los consumidores expresar niveles mínimos de protección y capacidades máximas y de unirse con proveedores adecuados que podrían, de hecho, incluir protecciones adicionales.


Resumen: gobernanza importante para el éxito de la SOA

Este artículo le muestra porque la gobernanza es muy importante para el éxito de una empresa con SOA. La gobernanza implica establecer responsabilidades y fortalecer las partes responsables, mientras que la administración implica asegurarse de que las políticas de gobernanza realmente tengan efecto. Puede utilizarse tecnología no para establecer la gobernanza, sino para llevar a cabo la administración. La gobernanza que se gestiona durante la invocación del servicio puede manejarse de forma efectiva por un ESB, al simplificar las responsabilidades de ambos proveedores y consumidores.

La gobernanza de SOA tiene muchos aspectos, por ejemplo:

  • Definición del servicio (el alcance, la interfaz y los límites de un servicio)
  • El ciclo de vida de la implementación del servicio (las etapas del ciclo de vida)
  • El control de las versiones del servicio (incluida la compatibilidad)
  • Migración del servicio (desaprobación y caducidad)
  • Registros del servicio (dependencias)
  • Modelo de gestión del servicio (modelos de datos canónicos)
  • Supervisión del servicio (determinación del problema)
  • Propiedad del servicio (organización corporativa)
  • Pruebas del servicio (pruebas duplicadas)
  • Seguridad del servicio (incluidos los rangos de protección aceptables)

El tratamiento adecuado de cada uno de estos aspectos podría convertir los artículos para sí mismos.

Reconocimientos: Al autor le gustaría extender sus agradecimientos a los colegas de IBM por sus aportes en este artículo: Steve Graham, Arnauld Desprets, Randy Langel, Kerrie Holley, Ali Arsanjani, Emily Plachy, Bob Vanorsdale, Jon Richter, Mandy Chessell, Mark Cocker, Mark Ernest, Steven Adler y Fill Bowen.

Referencias:

La siguiente es una lista de algunas referencias y recursos útiles.

gobernanza de SOA

Definición del servicio

Control de versiones del servicio

Registros del servicio

Modelo de mensajes del servicio

Supervisión del servicio

Propiedad del servicio

Pruebas del servicio

Seguridad del servicio

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=848172
ArticleTitle=Introducción a la gobernanza SOA
publish-date=12032012