Tarea: Aplicar pruebas decisivas de servicio
Esta tarea describe el requisito de calificar servicios candidatos para garantizar que aquellos que se desarrollen posteriormente cumplan realmente con las necesidades de la empresa.
Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional: Externa:
  • Ninguno
Salidas
Descripción principal

Una vez que se hayan seleccionado y documentado los servicios candidatos en la Cartera de servicios (categorizada), tendremos que determinar cuáles de ellos se exponen como servicios. Aunque, en teoría, cualquier servicio candidato puede exponerse exportando su interfaz como descripción de servicio, no todos los servicios candidatos deberían estarlo. Puede que no resulta factible hacerlo desde el punto de vista económico y práctico (pueden ponerse en peligro requisitos no funcionales). En particular, la decisión ingenua de exponer "todos los métodos de todas las clases" produzca un número incontenible, y a menudo incontrolable, de servicios, lo que llevaría al "síndrome de proliferación de servicios". Esto crearía enormes problemas de rendimiento y gestión de servicios, por no mencionar el hecho de que podríamos entregar el capital intelectual de la empresa. Además, debemos recordar que existe un coste asociado con cada servicio que decidamos exponer: deben tenerse en cuenta la financiación, la dirección y la infraestructura subyacente (su seguridad, rendimiento, gestión) del servicio y los componentes que los implementarán.

Por tanto, son necesarios algunos criterios para ayudar a decidir si exponer un servicio y, lo que es más importante, si financiar la creación del componente de servicio que proporcionará la funcionalidad del servicio y el mantenimiento, la supervisión, la seguridad, el rendimiento y otros acuerdos a nivel de servicio del servicio. 

Pruebas decisivas de servicio

Las experiencias de proyecto señalan que un conjunto de criterios en forma de prueba decisiva de servicio pueden y deben utilizarse para filtrar las colecciones de servicios candidatos. Esta metáfora se utiliza para indicar un conjunto de pruebas que, cuando se aplican, determinan si un determinado servicio debe ser seleccionado para exposición utilizando una descripción de servicio. Estas pruebas se emplean juntas y ayudan a responder a preguntas como: de la lista de servicios candidatos, ¿cuáles deberían exponerse? Y entonces, ¿cuáles deberían financiarse? ¿Cuáles tienen valor empresarial?

Por un lado, cada guión de uso empresarial podría considerarse un servicio candidato. Por otro lado, sólo unos cuantos servicios se seleccionan para exposición. La aplicación de la prueba decisiva de servicio ofrece normalmente un término medio: un conjunto gestionable de servicios que la empresa desea exponer y que pueden posteriormente ser utilizados dentro de composiciones.

Los servicios candidatos que pasan todas las pruebas decisivas de servicio deberían exponerse como servicios en la arquitectura orientada a servicios. Puede haber servicios candidatos que no pasasen la prueba decisiva de servicio pero que se sigan implementando como servicios. La prueba decisiva de servicio es una ayuda para determinar qué servicios exponer; si una empresa decide exponer servicios candidatos que no pasasen la prueba decisiva de servicio, la implicación es que los beneficios asociados con una arquitectura orientada a servicios no se ejecutarían.

Los servicios candidatos que no pasen la prueba decisiva de servicio deberán implementarse de alguna forma ya que son necesarios para las necesidades empresariales. Se pueden implementar como métodos en componentes de servicios y no necesitarán la generación de WSDL u otras formas de definiciones de servicio; o podrán utilizarse como entidades no exponibles.

Consideraciones

La aplicación de pruebas decisivas de servicio es un proceso iterativo. Para la primera fase de elaboración, deberían tomarse las decisiones según los conocimientos actuales. Las pruebas decisivas de servicio deberían revisarse a medida que se obtiene más información en el proceso de diseño.

Las pruebas decisivas de servicio de cada servicio candidato deberían aplicarse y revisarse con los correspondientes interesados o los expertos en el tema.

La revisión de los resultados de las pruebas decisivas de servicio son una forma útil de realizar el seguimiento de la idoneidad de los criterios y la granularidad del servicio. Por ejemplo, si una determinada prueba la pasan muchos servicios candidatos, puede que dicha definición de prueba sea demasiado amplia o la granularidad de nivel de servicio sea adecuada.

Un servicio puede no superar una o más pruebas decisivas de servicio pero puede seguir expuesto debido a alguna decisión específica del proyecto (empresarial o de TI). Esto es aceptable. Puede que haya una decisión empresarial o arquitectónica de exponer un servicio a pesar de las pruebas decisivas de servicio.

Pasos
Garantizar que el servicio está alineado con la empresa

La primera prueba de un servicio es sobre su alineación con la empresa. Si el servicio no es rastreable a una tarea o a un objetivo de la empresa, puede que no produzca los beneficios necesarios para la implementación de la arquitectura orientada a servicios. Las siguientes preguntas, si todas se responden de forma positiva, indicarán que el servicio está alineado con la empresa.

  • ¿Ofrece el servicio una funcionalidad empresarial necesaria que de soporte a procesos y objetivos empresariales? (consulte la Tarea: Análisis de proceso empresarial )
  • ¿Desea la empresa financiar el servicio en todo su ciclo de vida: suministro, gestión, dirección y mantenimiento?
  • ¿Desea la empresa compartir el servicio interna o externamente con clientes o socios empresariales? Por ejemplo, las implicaciones pueden ser costes adicionales, secretos empresariales, seguridad, etc.
  • ¿Existen actualmente o en el futuro oportunidades dentro de la empresa para reutilizar el servicio?
Garantizar que el servicio es componible

La componibilidad se define como un atributo que permite que el servicio participe en una composición de servicios. Las aplicaciones se pueden crear utilizando ambos tipos de composición.

  • ¿Cumple el servicio con los atributos de Calidad de servicio necesarios, tal como se define en los Requisitos no funcionales de la composición?
  • ¿El servicio es sin estado? (consulte Directriz: Gestión de estado de servicios)
  • ¿Es el servicio independiente? ¿Puede el servicio desplegarse independientemente para cumplir un objetivo empresarial aunque pueda cooperar con otros servicios en el tiempo de ejecución para realizar procesos empresariales? No existen dependencias implícitas del servicio en otra funcionalidad incluida. Todos los servicios dependientes son sustituibles o independientes.
  • ¿Es la tecnología de implementación del servicio neutral? Tecnología neutral significa que el servicio no impone el soporte de protocolos o dispositivos no estándar (y desconocidos para el cliente), por ejemplo, el componente constituyente necesita intervención a través de una interfaz de aplicación no estándar.
    Esta prueba sólo se aplica cuando el servicio se despliega en el entorno del cliente. Por ejemplo: una empresa suministra un servicio de recuperación de imágenes a sus clientes. Puede proporcionar esta función a sus clientes suscritos a través de un servicio web. De forma alternativa, la empresa puede transferir a su cliente la función de recuperación de imágenes expuesta como servicio web, y una colección de imágenes. Aquí, el cliente se verá cargado por la implementación de la búsqueda de tecnología.
Garantizar que el servicio tiene descripción externa

La propiedad más básica de un servicio es que tenga una descripción de servicio externalizada. La descripción de servicio externalizada puede ser esa o estar generada automáticamente a través de herramientas o manualmente

  • ¿Tiene el servicio una descripción de servicio externalizada que sea distinta e independiente de la implementación física subyacente? Un ejemplo actual de esto es WSDL.
  • ¿Puede el servicio ser descubierto y enlazado con la descripción de servicio?
  • ¿Contiene la descripción de servicio metadatos sobre sí misma? Esto es, la descripción de servicio debe ser autosuficiente, contener o hacer referencia a toda la información necesaria para entender el intercambio de mensajes entre el cliente y el proveedor de un servicio.
Garantizar que el servicio es reutilizable

¿Puede este servicio ser utilizado por el interesado empresarial dentro de todos los procesos en los que se necesite su función?

Garantizar que el servicio es técnicamente viable

La viabilidad técnica garantiza que el servicio se puede ejecutar (implementar y desplegar) realmente según los requisitos funcionales y no funcionales utilizando tecnologías disponibles.

  • ¿Es el esfuerzo de implementación y gestión para el servicio razonable y fácilmente viable dados los requisitos o la infraestructura de la implementación?
    Esto se hace tras la exploración de viabilidad técnica de la realización
Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir