Monitoreo y gestión de servicios durante el tiempo de ejecución

El monitoreo y la gestión de servicios le permite monitorear sus servicios, le ofrece métodos de gobernabilidad y gestión, le permite tomar el control de los servicios implementados y le permite contar con la flexibilidad necesaria en relación con la implementación de servicios y con las interacciones para poder cumplir con las necesidades del negocio.

YuChang Jiao, Software Engineer, IBM

YuChang Jiao es Software Engineer para el China SOA Design Center. Se especializa en el desarrollo de aplicaciones SOA, y trabaja con el equipo SOA Technical Sales con el objetivo de ofrecer una prueba de tecnología y una solución SOA que incluya marcas diferentes. Además de todo esto, YuChang es Senior Developer para SOADEE.



05-08-2011

Generalidades

El monitoreo y la gestión de servicios, lo que le permite monitorear sus servicios y le ofrece métodos de gobernabilidad y gestión, se está transformando en algo cada vez más importante durante el ciclo de vida de SOA. Esto hace que las organizaciones puedan tomar el control de los servicios que hayan implementado y que cuenten con la flexibilidad necesaria en relación con la implementación de servicios y con las interacciones para poder cumplir con las necesidades del negocio. La gestión efectiva de este ciclo de vida es el objetivo clave de la Gobernabilidad SOA. Este artículo describe un marco de monitoreo y gestión de servicios denominado IBM Services Monitoring and Management (o ISMM) y basado en los productos de IBM. También se incluyen las características nuevas de estos productos, entre las que podemos incluir las siguientes: IBM® WebSphere® Service Registry and Repository V6.2, IBM® Tivoli® Composite Application Manager for SOA V7.1.1, WebSphere® Application Server V7.0, Tivoli® Security Policy Manager V7.0 y WebSphere DataPower V3.7.3. Y lo que es todavía más importante, el ISMM soluciona los problemas de seguridad del servicio, que cada vez son más importantes.


Problemas identificados en nuestro ciclo de vida SOA y nuestra arquitectura de la solución ISMM

Debido a la vasta aplicación de la Arquitectura Orientada a Servicios (o SOA), los negocios están pasando a ser cada vez más flexibles, los procesos de negocios están pasando a ser cada vez más dinámicos, las integraciones son cada vez más fáciles y los costos son cada vez más bajos. Mientras tanto, han surgido problemas nuevos. Las empresas no están recibiendo todos los beneficios que esperaban de SOA.

Elprimer problema identificado es cómo gestionar y controlar los servicios al igual que se gestionan y controlan todos los demás recursos. Los servicios son activos muy valiosos dentro de las empresas. Por lo tanto, se los debe gestionar de la misma forma que se gestionan todos los demás recursos. Pero en la actualidad, el monitoreo y la gestión de servicios son tareas complicadas. Casi nadie sabe cuántos servicios se implementaron, dónde se encuentran o de qué se ocupan. La organización de TI no tiene información sobre el uso y el estado de los servicios. Además, no existe ninguna forma de visualizar qué servicios se están ejecutando. Por ende, muchos servicios se suelen duplicar una o varias veces. Es necesario identificar estos servicios web duplicados. Por lo tanto, se deben reunir y analizar datos estadísticos sobre el uso de los servicios. Recién luego de haber hecho esto, se podrán hacer realidad todas las promesas de menores costos de actualización con SOA.

Elsegundo problema es cómo monitorear y utilizar la Calidad de Servicio (QoS). Los servicios que se usan en los procesos de negocios no pueden ser estáticos. En algunas situaciones, los servicios se deben seleccionar durante el tiempo de ejecución desde un conjunto de servicios basados en QoS. Sólo se deberían usar los servicios web disponibles en dicho momento. No se debe intentar llamar a ningún servicio web offline. A veces, debemos descubrir los puntos finales de los servicios que tienen un bajo rendimiento y hacer que no estén disponibles basándose en los umbrales configurados. Por lo tanto, las llamadas de servicios se pueden rutear basándose en QoS.

Eltercer problema es cómo informar sobre las alertas y la integridad de los servicios de manera dinámica. Los clientes necesitan monitorear las métricas de integridad de los servicios a nivel del negocio para ayudar a identificar las violaciones de los Acuerdos de Nivel de Servicio (o SLA) y las interrupciones temporales de los servicios. Además, también necesitan encontrar una forma de visualizar estas métricas. Además, las alertas se deben enviar automáticamente cuando se detectan violaciones para así notificar a los administradores y que estos puedan tomar todas la medidas necesarias.

Elcuarto problema es cómo solucionar los problemas de seguridad. Las empresas saben que los servicios no se usan internamente porque no se puede confiar en ellos. También existen muchas amenazas de seguridad provocadas por el acceso externo. No se pueden ofrecer servicios a clientes, socios y proveedores debido a la falta de seguridad. El uso de servicios resulta engorroso debido a la cantidad de sistemas de Autenticación y Autorización que son necesarios para brindar acceso a los socios. Por lo tanto, el problema de la seguridad de los servicios también resulta muy importante y se lo debe solucionar.

Para solucionar estos problemas, se cuenta con un IBM Services Monitoring and Management Framework basado en los productos y en las soluciones de IBM. A continuación, se incluye la arquitectura de la solución ISMM.

Figura 1. Arquitectura de la solución ISMM
Arquitectura de la solución ISMM

La Figura 1 es la arquitectura de diseño de la solución ISMM. A ésta la podemos dividir en tres niveles. El primero es el nivel del cliente. En este nivel, se pueden ofrecer servicios a los clientes y a los socios de negocios. Por razones de seguridad, requerimos la autorización y la autenticación de las solicitudes de servicio. Por ende, agregamos una DMZ (Zona Neutral) como segundo nivel para implementar la autorización y la autenticación.

Dentro de la empresa, está el Enterprise Layer (nivel empresarial), que es el más importante. El Directory Server (servidor de directorio) almacena perfiles de usuario y le ofrece una infraestructura de datos de identidad confiable para la autenticación. Los Process Servers (servidores de proceso) son un motor de automatización de procesos de negocios de alto rendimiento que lo ayudarán a formar procesos que cumplan con sus objetivos de negocios. El Bus de Servicios Empresariales (o ESB) lo ayuda a activar la integración rápida y flexible de la aplicación con un costo menor y favoreciendo una interconectividad de próxima generación. Los Process Servers y el ESB implementado aquí también lo pueden ayudar a determinar de manera dinámica cuál es el servicio que se debe usar basándose en QoS.

Service Registry & Repository le ofrece Gobernabilidad y visibilidad de servicios para los metadatos asociados, las políticas y los servicios SOA, con soporte para Gobernabilidad SOA. La Política de seguridad lo ayuda a fortalecer el acceso a la aplicación, facilita el cumplimiento y respalda la gobernabilidad operacional en toda la infraestructura de TI. Todos estos componentes se basan en IT Service Management (ITSM), que monitorea su ciclo de vida SOA para garantizar una alta disponibilidad y un alto rendimiento. ITSM le ofrece herramientas de gestión integrada que aceleran y simplifican la identificación y la resolución de los problemas SOA.

Figura 2. Mapeo de producto de la solución ISMM
Mapeo de producto de la solución ISMM

La Figura 2 es el mapeo de producto de la solución ISMM. Usted puede mapear cada producto en la Figura 2 hacia el componente correspondiente en la Figura 1. Se usa WebSphere® DataPower SOA Appliance como puerta de enlace de seguridad para autenticar y autorizar las solicitudes de servicio. Se usa Tivoli® Directory Server porque Directory Server almacena perfiles de usuario. Se usa WebSphere® ESB como ESB para implementar el ruteo y la selección de servicios basándose en QoS. Se usa el producto WebSphere® Service Registry and Repository como componente de Service Registry and Repository para implementar la gestión y el registro de servicios. Se usa Tivoli® Security Policy Manager como componente de Security Policy para gestionar la política de seguridad. Se usa Tivoli® Composite Application Manager for SOA Platform como ITSM para monitorear y gestionar los datos de QoS.

Nuestra solución ISMM se puede implementar usando estos productos de IBM, lo que le permite monitorear sus servicios y le ofrece métodos de gestión y gobernabilidad a lo largo del ciclo de vida de SOA.


Control y eliminación de "servicios ficticios"

Figura 3. Monitoreo y análisis de servicios ficticios
Monitoreo y análisis de servicios ficticios

Los servicios se deben gestionar al igual que todos los demás recursos. Sólo así se podrán monitorear los servicios y mediar los problemas. ITCAM for SOA Platform sólo puede monitorear los servicios invocados y reunir metadatos de uso, rendimiento y disponibilidad de estos servicios. WSRR es el Centro de servicios de repositorio y registro y todos los servicios se deberían registrar en WSRR. Discovery Library Adapters (o DLA), que es un programa especial que extrae datos desde una aplicación fuente y genera un archivo XML (denominado Discovery Library Adapter Book) usando el formato Identity Markup Language XML, se usa en este escenario para transferir dichos metadatos. Luego de que un DLA genera el archivo DLA Book, que incluye las relaciones entre los servicios, los puertos de servicio, las operaciones, los procesos de negocios y los servidores de aplicación y los sistemas de computadora en los que se implementan, los usuarios pueden cargar este tipo de archivo en TCORE y visualizarlo en Tivoli® Enterprise Portal. Se usan dos tipos de fuentes en ISMM: una es ITCAM for SOA, que incluye la ejecución de la información de servicios, y la otra es WSRR, que incluye la información de los servicios registrados. Vea el centro de información de ITCAM for SOA para mayor información.

Luego de cargar los DLA Books de manera exitosa, relaciones de servicio a servicio y topología se crearán automáticamente en ITCAM for SOA. El uso del servicio, el estado de registro, los flujos y las relaciones también se visualizarán en Tivoli® Enterprise Portal.

Como se puede observar en la Figura 4, los servicios ficticios son aquellos que están marcados con un rectángulo rojo. Se trata de servicios que ITSM observa pero que no están registrados en Service Registry and Repository. A este tipo de servicios se lo denomina servicio ficticio. Usted también puede identificar aquellos servicios que sólo se registraron en WSRR pero que no se invocaron en lo más mínimo. Estos servicios se encuentran marcados con un rectángulo amarillo en la Figura 4 y se los denomina servicios “shelfware” (software que acaba por no ser utilizado). Cuanto menor sea la cantidad de servicios shelfware, mejor se implementarán las soluciones SOA. También existe otro tipo de servicio que se observa pero no se registra. A estos servicios los podemos denominar servicios rígidos. Los servicios rígidos están fuera de control y destruyen la gestión de servicios. Por lo tanto, usted debería hacer todo lo posible para eliminar estos servicios.

Figura 4. Generalidades de los servicios en TEP
Generalidades de los servicios en TEP

Mediante el proceso anterior, es posible identificar los servicios web duplicados y se informará sobre los servicios no utilizados para así limitar la cantidad de shelfware. La organización de TI dispondrá de información sobre el uso de los servicios implementados y de una forma para visualizar qué servicios se están ejecutando. Sólo así es posible que la promesa de ahorrar costos de actualización con SOA se haga realidad.


Monitoreo y utilización de QoS de servicios

La Qualities of Services (o QoS), como el rendimiento y la disponibilidad, se puede reunir y utilizar para la resolución dinámica del punto final del servicio. Como nuestros negocios cada vez son más y más dinámicos, los servicios web que se usan en los procesos de negocios no pueden ser estáticos. Los servicios web se deben seleccionar durante el tiempo de ejecución desde un conjunto de servicios definidos en un registro externo de servicios. Además, también debemos contar con la gestión de la disponibilidad de los servicios. Sólo se deberían usar aquellos servicios web que estén disponibles. No se debe intentar llamar a ningún servicio web offline. Por lo tanto, los puntos finales de los servicios de bajo rendimiento se deben descubrir y hacer que no estén disponibles basándose en la configuración de los umbrales.

Gracias a la solución ISMM, usando WSRR, ITCAM for SOA Platform y un Enterprise Service Bus, el ESB puede usar una mediación para recuperar la información relativa a la integridad de los servicios de manera dinámica desde WSRR para rutear las solicitudes de servicio con el objetivo de garantizar las calidades de servicio adecuadas. E ITCAM for SOA Platform monitorea los servicios en ejecución y actualiza los metadatos de los servicios en WSRR para reflejar el estado actual del tiempo de ejecución en relación con el rendimiento, la disponibilidad, etc.

Figura 5. Generalidades de los servicios en TEP
Generalidades de los servicios en TEP

La Figura 5 le muestra la recuperación de las estadísticas del servicio candidato y la selección dinámica y la posterior vinculación con un punto final de un servicio. Como se puede observar en la Figura 5, ITCAM for SOA Platform, WebSphere® Enterprise Service Bus y WebSphere® Service Registry and Repository se usan en este escenario. El servicio proveedor se selecciona de manera dinámica basándose en la solicitud de los clientes. A continuación, se detalla todo el procedimiento a seguir:

  1. ITCAM for SOA Platform reúne los datos QoS de los servicios (como, por ejemplo, la disponibilidad y el rendimiento de estos servicios).
  2. Todos los datos QoS reunidos se sincronizarán con WSRR para actualizar los metadatos del servicio mediante el uso de ITCAM for SOA Integration Module. Vea ftp://ftp.software.ibm.com/software/integration/support/supportpacs/individual/sa04_UserGuide_6.0.2.pdf para mayor información sobre ITCAM for SOA Integration Module.
  3. WESB recibirá la solicitud de servicio del cliente. Un token de identidad del cliente y otra información relacionada se encapsulará en el mensaje de solicitud del cliente.
  4. Cuando se recibe un mensaje, el ESB lee los atributos y la información de la política desde WSRR, ejecuta un algoritmo coincidente y selecciona el servicio apropiado que se usará basándose en la calidad de servicio observada en el entorno. Usted puede agregar una primitiva denominada "Custom Mediation" (Mediación personalizada) inmediatamente después de la primitiva Endpoint Lookup (Búsqueda de punto final) de WESB. La "Custom Mediation" analizará los resultados de la Endpoint Lookup de WSRR y seleccionará el punto final "más rápido". Al seleccionar el punto final "más rápido", el código Java™ en la primitiva denominada "Custom Mediation" ordena los resultados de la Endpoint Lookup en el orden ascendente de la propiedad "ResponseTime" (Tiempo de respuesta) de WSRR y configura el objetivo de ruteo (url destino) como la URL con el menor "ResponseTime". Esta "Custom Primitive" también cuenta con una propiedad promovible denominada "ResponseLimit" (Límite de respuesta). En el código Java anterior, si el "ResponseTime" de WSRR es superior que la propiedad promovible ("ResponseLimit"), el código Java debería rechazar este punto final.
  5. El solicitador estará vinculado por el punto final del servicio seleccionado y, luego de esto, lo invocará. Los clientes con una prioridad baja se rutearán hacia el primer punto final del servicio mientras que los clientes con una prioridad alta se rutearán hacia el segundo punto final del servicio.
  6. Los clientes con una prioridad alta se rutearán hacia el segundo punto final del servicio.

Información dinámica de las alertas y la integridad del servicio

Un acuerdo de nivel de servicio (o SLA) es un contrato formal entre un proveedor de servicios y un cliente que garantiza un rendimiento cuantificable de la red a niveles definidos. Sin embargo, el bajo rendimiento de los puntos finales del servicio suelen provocar el incumplimiento de los SLA. Los servicios que están en producción se deben monitorear y gestionar con el objetivo de garantizar que cumplan con sus respectivos acuerdos de nivel de servicio.

En ISMM, la plataforma IBM Tivoli® Composite Application Manager for SOA (o ITCAM for SOA) también se puede usar para que los operadores puedan monitorear los grupos de servicio a nivel de los negocios con el objetivo de ayudar a priorizar las violaciones de los SLA y las interrupciones temporales del servicio. Usted puede usar Tivoli® Enterprise Portal (o TEP) para visualizar la información provista por ITCAM for SOA y determinar la causa raíz de los problemas de tiempo de ejecución del servicio.

En primer lugar, se crearán muchos grupos de servicio (como se puede observar en la Figura 6). Un grupo de servicios es un conjunto de operaciones de servicio relacionadas que, conjuntamente, pueden llegar a representar o abarcar una función de negocios o una aplicación en su empresa. Esto puede ser un flujo de servicio, un subgrupo de un flujo o una colección de agregados de operaciones que representan algo significativo para usted dentro de su entorno monitoreado.

Figura 6. Vista del cliente de la Integridad del servicio
Vista del cliente de la Integridad del servicio

El estado predeterminado del grupo de servicios es saludable, lo que significa que no hay ningún problema con ninguno de los servicios del grupo. Por lo tanto, se lo marcará con un signo de verificación de color verde. El objeto del grupo de servicios incluye acusadores de integridad como, por ejemplo, datos de rendimiento (Tiempo de respuesta en segundos) y volumen (conteos de mensajes), que se calcularán cada 2,5 minutos (de manera predeterminada) y se visualizarán en las vistas del grupo de servicios. Si estos acusadores exceden el umbral definido por los operadores, ciertas situaciones se desencadenarán y se activarán todas las alertas correspondientes.

La falta de disponibilidad de un grupo de servicios se basa en este tipo de situaciones que se relacionan con los servicios de front-end del grupo de servicios. Generalmente, estas situaciones personalizadas usan las métricas y los atributos de falta de disponibilidad del servicio que brinda ITCAM for SOA.

Figura 7. Alera de Grupo de servicios no saludables
Alera de Grupo de servicios no saludables

Ya hemos definido exitosamente los grupos de servicios. Todos los datos de volumen y rendimiento de los servicios se pueden visualizar en esta vista. Cuando se registra alguna anormalidad con el grupo de servicios monitoreado, se activan las alertas correspondientes y se las puede visualizar en esta vista. Como se puede observar en la Figura 7, se marcó un grupo de servicios denominado VerifyCreditServiceGroup con una cruz roja grande. Esto significa que algunos servicios dentro del grupo tienen un bajo rendimiento y ocasionan situaciones críticas. Usted puede obtener más detalles (haciendo doble clic sobre el nodo con la cruz roja) en la vista Interaction Detail (Detalles de interacción) para verificar el estado detallado de cada servicio del grupo y descubrir qué ocurrió con ellos.

ISMM le puede ofrecer una mejor gestión y el monitoreo proactivo de los acuerdos de nivel de servicio antes de que se incumpla con ellos para alertar a los administradores sobre todos los problemas posibles. ISMM también le puede permitir usar las métricas del tiempo de ejecución para seleccionar servicios más adelante en el caso de escenarios avanzados.


Gestión de seguridad del servicio basada en la política

En el proceso de implementación de SOA, los problemas relacionados con la seguridad ocurren todo el tiempo, en cualquier lugar y afectan a todo el mundo. Los servicios no se usan internamente porque no se puede confiar en ellos. Las amenazas de seguridad que resultan del acceso externo pueden ocasionar la pérdida de inversiones y provocar grandes daños al negocio. Usted no puede ofrecer servicios a clientes, socios y proveedores debido a la falta de seguridad. Si usted solucionó estos problemas de una forma tradicional, el uso del servicio puede resultar engorroso debido a los diversos sistemas de Autenticación y Autorización necesarios para brindar acceso a los socios. Al potenciar tantos servicios para lograr el máximo valor de negocios en todos los diferentes contextos de negocios, la gestión de la política de seguridad es un concepto al que se debe prestar mucha atención. ISMM es la mejor opción para usted. ISMM lo puede ayudar a solucionar estos problemas.

Figura 8. Gestión de seguridad del servicio basada en la política
Gestión de seguridad del servicio basada en la política

En ISMM, la política se crea y gestiona para controlar la autenticación y la protección a nivel del mensaje de los servicios web. También se ofrece el control del acceso seguro a los servicios usando políticas. Uno de los procesos típicos de gestión de seguridad del servicio basada en la política se puede dividir en los cinco pasos que se describen a continuación:

  1. El SOA Architect (Arquitecto SOA) define y registra los servicios en WSRR.
  2. El Security Architect (Arquitecto de seguridad) crea la política de seguridad por medio de Tivoli® Security Policy Manager (o TSPM). Tivoli® Security Policy Manager es un producto de IBM que lo ayuda a fortalecer el acceso a la aplicación, facilita el cumplimiento y respalda la gobernabilidad operacional en toda la infraestructura de TI. Además, funciona como un Policy Administration Point (o PAP). El Security Architect recupera la definición del servicio desde WSRR y vincula la política con el servicio.
  3. Luego de esto, el Security Architect puede distribuir estos servicios y adjuntar políticas a WSRR. WSRR funciona como un Policy Distribute Target (o PDT).
  4. El Security Architect también puede distribuir estos servicios y políticas adjuntas directamente en DataPower. Luego de esto, DataPower será un PDT.
  5. No importa qué componente se desempeña como PDT, ya que DataPower siempre debe suscribir todos los servicios y las políticas adjuntas. DataPower funciona como un Policy Enforcement Point (o PEP). Se crea un Web Service Proxy en DataPower para este tipo de servicios. También se configuran parámetros de configuración WS-Policy y configuraciones WS-Proxy en DataPower.
  6. Los clientes presentan una solicitud a los servicios provistos por esta organización. Esta solicitud se ruteará al Web Service Proxy en primer lugar y debe aprobar la autenticación y cumplir con la política definida por el Security Architect. En este momento, se exigirá el cumplimiento de la política predefinida en DataPower.

Tres tipos de política de seguridad se inspeccionan y verifican en ISMM: la protección a nivel del mensaje, la autorización basada en el rol y la autorización basada en la regla.

En primer lugar, para la protección a nivel del mensaje, El SOA Architect intenta exigir el cumplimiento de la protección a nivel del mensaje en mensajes específicos que fluyen dentro de la empresa. El Security Architect iniciará sesión en la Interfaz de Usuario de TSPM y creará una política que requiere que los mensajes estén encriptados y autenticados con una aserción SAML. Luego, el Security Architect adjuntará esta política al servicio provisto, configurará la política de seguridad en TSPM y la distribuirá desde TSPM hasta WSRR. DataPower estará configurado para sincronizar la subscripción WSRR con el objetivo de recuperar WSDL con la política desde WSRR. El Security Architect crea un proxy de servicios web simple en DataPower. Las solicitudes de los clientes se rutean hacia el proxy de servicios web para que se ejerza el cumplimiento del mensaje del servicio y se agregue la protección del mensaje por política de seguridad durante la llamada de transacción del servicio. Los consumidores de este servicio deben usar un flujo de mensaje de solicitud de servicio que haya sido encriptado y un token SAML agregado al flujo para acceder al proveedor de servicios. En este escenario, el dispositivo IBM WebSphere® DataPower se potenciará como Policy Decision Point (o PDP) y Policy Enforcement Point (o PEP).

En segundo lugar, para la autorización basada en el rol, el Security Architect descubre e importa servicios desde el registro, mapea el rol hacia el sistema de identidad existente (IBM Tivoli® Directory Server) y, luego de esto, crea, configura y distribuye las políticas de seguridad desde TSPM hasta DataPower. Se rechazarán todas las solicitudes de servicios de los clientes si ellos no forman parte del rol en cuestión. El Security Architect puede modificar los requisitos de membrecía del rol para otorgar dicho rol a ciertos clientes. Recién después de haber hecho esto, los clientes podrán acceder a estos servicios. Por ejemplo, el servicio UpdateEmployeeSalary es un servicio que se usa para actualizar el salario base de los empleados y sólo aquellas personas que cuentan con el Rol de gerente pueden acceder a él. Jack es uno de los empleados de esta compañía. Él no puede acceder al servicio UpdateEmployeeSalary ya que no es "gerente". En este escenario, se potenciará el dispositivo IBM WebSphere® DataPower como Policy Decision Point (PDP) y Policy Enforcement Point (PEP).

En tercer lugar, para la autorización basada en la regla, la regla requerirá privilegios específicos. El Security Architect puede crear una regla con expresiones de condición y privilegios específicos para acceder a los servicios provistos.


Conclusión

La Gestión y el monitoreo de servicios implementados por ISMM demuestra las decisiones de gobernabilidad dentro del contexto del ciclo de vida de los componentes del servicio (por ejemplo, los servicios y los procesos de negocios). ISMM nos ayuda a comprender los aspectos clave de la Gobernabilidad SOA, la seguridad y la gestión. ISMM también nos ayuda a describir los productos IBM SOA Foundation, que nos ofrecen una solución integrada para Service Governance at Runtime for SOA. Usted puede comprender cómo diversos aspectos de la gobernabilidad se pueden hacer cumplir durante el tiempo de ejecución usando ISMM. ISMM le permite monitorear sus servicios y le ofrece métodos de gestión y gobernabilidad durante todo el ciclo de vida de SOA.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

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=475728
ArticleTitle=Monitoreo y gestión de servicios durante el tiempo de ejecución
publish-date=08052011