Tarea: Especificación de servicio
Esta tarea define y especifica los servicios y la estructura de una solución orientada a servicios desde el punto de vista de las colaboraciones de elementos de diseño contenidos y subsistemas/interfaces externos.
Disciplinas: Análisis y diseño
Objetivo
  • Definir los servicios y la estructura de una solución orientada a servicios desde el punto de vista de las colaboraciones de elementos de diseño contenidos y subsistemas/interfaces externos.
  • Analizar el servicio para encontrar puntos en común y variabilidad (consulte Directriz: Análisis de variabilidad).
  • Documentar la especificación de servicios.
  • Determinar las dependencias y la comunicación entre los servicios.
Relaciones
Descripción principal
Esta tarea ajusta el conjunto de Artefactos: Especificación de servicio identificados y calificados durante la Actividad: Identificar servicios y ofrece detalles y estructuras adicionales. Este detalle de nivel de diseño incluye servicios de interfaz, mensaje y composición, y la asignación de servicios a los proveedores.
Pasos
Reutilizar la cartera de servicios de empresa

Una de las ventajas a menudo comentadas sobre el uso de una arquitectura orientada a servicios es la posibilidad de que los servicios representen activos reutilizables en la empresa, en lugar del desarrollo de componentes sólo dentro del ámbito de una única aplicación. Esta vista de empresa es importante porque incorpora la noción de que una auténtica arquitectura orientada a servicios para TI ofrece toda la infraestructura y las funciones empresariales como servicios y de que las aplicaciones desarrolladas por la empresa reutilizan funciones de la cartera de servicios.

Por tanto, al iniciar un proyecto resulta importante saber si está desarrollando servicios como parte de la cartera o si está desarrollando funciones de aplicación que utilicen estos servicios. Por ejemplo, el desarrollo de un sitio de portal para que los clientes accedan a su información de cuentas es un proyecto de desarrollo de aplicaciones que utiliza servicios de la cartera para información del cliente, información de cuentas, ofertas, etc. En cada caso, el uso de la cartera tiene distintas implicaciones, el diseñador de servicio describe su especificación de servicio y la publica como parte de la cartera. Esta especificación permite a los desarrolladores de aplicaciones entender los requisitos de interacción para el servicio. El implementador de servicio puede ahora utilizar la misma especificación de servicio para desarrollar una o más implementaciones del servicio, garantizando que la implementación cumple con la especificación.  El siguiente diagrama muestra la relación entre la cartera de servicios de toda la empresa y la cartera del proyecto.

Para obtener más información, consulte el concepto Cartera de servicios.

Utilizar mecanismos y patrones de diseño

Utilice los mecanismos y patrones de diseño que se adapten al servicio diseñado y de acuerdo con las directrices de diseño del proyecto. La incorporación de un patrón o mecanismo significa realmente realizar muchos de los pasos posteriores de esta tarea, pero de acuerdo con las reglas definidas por el patrón o el mecanismo.

Tenga en cuenta que los patrones y los mecanismos se incorporan normalmente a medida que evoluciona el diseño, no sólo como el primer paso en esta tarea. También se aplican frecuentemente entre un conjunto de elementos de modelo, en lugar de sólo a un único elemento.

La transformación de un servicio en su realización a menudo entraña un conjunto de patrones, algunos de los cuales se describen en la Directriz: Patrones de componentes de servicio.

Describir la organización lógica de la solución

A menudo resulta útil organizar sus ideas desde el punto de vista de las distintas vistas de un sistema y de cómo los servicios que desarrolla encajan en dichas vistas. Al definir las vistas de organización lógicas, es importante que la asignación de un servicio a una vista no implique la propiedad desde un punto de vista de la contención o el Lenguaje de modelado unificado (UML); es decir, que el mismo servicio podrá participar en varias vistas lógicas. Merece la pena que las vistas organizativas se diseñen en el modelo antes del desarrollo de servicio o al menos de la primera iteración de estas vistas, para que los servicios se puedan asignar a las vistas según se vayan identificando. En el modelo de servicio, utilizamos un elemento de modelo Partición de servicio para representar un aspecto de una vista. Estas particiones se pueden utilizar para representar todas las distintas perspectivas de la solución, pero no implican la propiedad de los servicios a ellas asignados. Para obtener más información, consulte el concepto Particionamiento de soluciones.

También es posible que estas particiones, al menos aquellas que representan puntos de vista clave, residan en modelos separados de los propios servicios, lo que permite que los modelos de partición evolucionen por separado.

Describir elementos de servicio

Como siempre es el caso cuando se observa el modelado de sistemas de software, existe un gran número de puntos de entrada a dichos modelos, gran variedad de representaciones que podemos utilizar y, por supuesto, muchas metodologías que se pueden aplicar. En la mayoría de los casos, estos puntos de entrada se deben a problemas específicos, en dominios tanto tecnológicos como empresariales, que deben solucionarse. Estos problemas son lo suficientemente importantes como para actuar de puntos de partida, porque entenderlos y la interacción entre ellos resulta fundamental para obtener éxito.

Observamos que había pocos problemas en el desarrollo de soluciones orientadas a servicios, el siguiente diagrama representa estos problemas principales como tareas de diseño específicas. Aunque observemos que cada uno de estos problemas puede actuar como punto de partida para el diseño de servicios, y que cada enfoque tiende a optimizarse bien para una determinada clase de servicios, es muy probable que los proyectos grandes utilicen una combinación de enfoques en la identificación y el diseño de servicios.

El diagrama se describe en el contenido textual.

Para obtener más información, consulte la Actividad: Análisis de activos existentes, que presenta un conjunto de técnicas detalladas que dan soporte a estos enfoques.

Diseño de mensajes

En este enfoque, el enfoque es mucho mayor en el dominio de servicio. Técnicas como la ingeniería de dominios o el análisis y el diseño orientados a objetos proporcionan un conocimiento más profundo del desarrollo de modelos de dominio abstractos. Este foco normalmente produce modelos altamente reutilizables para el esquema de mensajes. El diseño de servicio es normalmente una actividad secundaria aunque a veces se realiza en paralelo. En el Intercambio de datos electrónicos (EDI), por ejemplo, no existe noción real de una interfaz de servicio porque los sistemas EDI normalmente tienen una única bandeja de entrada y salida global para mensajes.

Un ejemplo de tal enfoque podría estar en el campo tradicional de empresa a empresa, tipificado por la estandarización EDI. En este caso, el foco de la actividad de diseño es el desarrollo del esquema de mensaje acordado en algún sector u otro ámbito y se considera representativo del esquema de una clase de mensajes, por ejemplo, estándares de la industria como ACORD, SWIFT y RosettaNet (consulte Tarea: Diseño de mensaje).

Diseño de servicio

En este enfoque, el diseñador está preocupado de exponer, como servicio o conjunto de servicios, las funciones esperadas de la empresa o la aplicación. En este caso, no conocemos necesariamente lo que el cliente de los servicios decidirá hacer con nuestro servicio, pero sabemos los tipos de interacciones que dichos clientes esperan. Por tanto, los mensajes tienden a ser secundarios y a desarrollarse en respuesta a los requisitos de una operación.

Un ejemplo de este enfoque serían los servicios web presentados por empresas como Amazon y eBay. Tales interfaces de servicio no imponen un proceso empresarial al cliente. En la mayoría de los casos ni siquiera imponen interfaces necesarias al cliente, pero exponen las operaciones de sus respectivos proveedores de servicio de forma clara e intuitiva a otros desarrolladores.

Tal como mencionábamos antes, un modelado centrado en servicios a menudo se presta bien a un enfoque dirigido por guiones de uso mediante la comprensión de la necesidad de los actores, los clientes externos del servicio y el suministro de operaciones que dan soporte a estas necesidades, operaciones como el examen de catálogos, la adición de elementos al carro de la compra, la extracción, etc.

Diseño de colaboración

En un diseño de colaboración, el foco está en la colaboración de dos o más servicios; se trata sobre todo de una vista de proceso de los servicios y está relacionada con un modelado empresarial más tradicional que con una actividad de desarrollo de software. En este enfoque, los servicios se ven como roles que cumplen en la colaboración y la especificación de servicio es por tanto el conjunto de responsabilidades definido para el rol a través de una o más colaboraciones.

Dicho enfoque debería ser reconocible para aquellos que se han involucrado en el desarrollo de los procesos de intercambio de socios (PIP) de RosettaNet o en el desarrollo de los estándares OAGIS, aunque las colaboraciones sean menos que completas en tales casos. Tal enfoque sería común dentro de una empresa desde el punto de vista del diseño de proceso empresarial o en actividades de integración empresarial en los que los componentes de un sistema de TI se expongan como servicios.

En este caso, se da normalmente el caso de que la especificación de servicio se pueda derivar directamente de la colaboración, pero este enfoque tiende a centrarse menos en el contenido de mensaje que lleva a un requisito de enfoque híbrido para su finalización.

Identificación de política y captura

Política es un término amplio que utilizamos aquí para cubrir sentencias o restricciones que pueden considerarse requisitos no funcionales. En el nivel de este modelo, debemos darnos cuenta de que no queremos que el modelo se rellene con sentencias detalladas sobre información técnica sino que de forma más realista, capturamos el intento del sistema respecto a estos requisitos. Por ejemplo, podemos saber que determinado mensaje debe transmitirse y mantenerse en privado a medida que se incluyen los detalles personales sobre nuestros clientes; queremos capturar el intento de que el mensaje sea privado, no que necesitemos cifrado de datos mediante cifrado de AES de 128 bits a través de un conjunto de datos XML canónicos con cifrado clave, principalmente porque muy poca gente sabrá lo que esto significa, podremos especificarlo en un modelo en este nivel de abstracción (consulte Tarea: Identificar patrones de seguridad).

El siguiente diagrama muestra la asociación de políticas con los elementos del modelo de servicio. Tenga en cuenta que la información sobre políticas se puede adjuntar a información distinta de los componentes de especificación identificados a continuación, aunque ésta es el área principal de interés.

El diagrama se describe en el contenido textual.

Para obtener información sobre modelado de políticas de seguridad, consulte la documentación técnica Modelado de problemas de seguridad en arquitectura orientada a servicios.

Dependencias de servicio del modelo

Otro aspecto clave del Artefacto: Modelo de servicio que debe desarrollarse durante la especificación es la captura de las dependencias entre servicios. Como parte del modelo de servicio, se capturan de forma natural una serie de dependencias. Éstas pueden ser tan obvias como la relación entre un servicio y su especificación, o más complejas, como la relación lógica entre dos servicios independientes ya que ambos implementan la misma especificación. Estas dependencias (descritas en Artefacto: Modelo de servicio e Informe: Dependencias de servicio) son importantes para entender la posibilidad de desplegar un servicio como unidad autónoma y afectará a su evolución en el tiempo a medida que las dependencias se vuelvan restricciones en posibilidad del servicio de cambiar.

Las dependencias de servicio describen las relaciones entre servicios que surgen en el contexto más amplio de cómo se utilizarán. Cuando un servicio se forma a partir de una composición de otros servicios, el servicio componente depende de los servicios compuestos. Cuando se utilizan servicios en el contexto de un proceso empresarial, existe una dependencia relacionada con el proceso que surge de la secuencia inherente de pasos en el proceso empresarial que dicta el orden en que se utilizarán los servicios.

  • Dependencia compuesta/dependencias funcionales que surgen de la composición de varios servicios.
    • Ejemplo: Reservar vehículo dependerá de Comprobar tarifas y Realizar reserva para su funcionalidad
  • Dependencia temporal en la que hay una condición previa o posterior o o un requisito de proceso que deberá tenerse en cuenta en composiciones o coreografías.
    • Dependencia de condición previa: por ejemplo, otra invocación de servicio debe haberse ejecutado correctamente antes de que la invocación actual pueda iniciar su ejecución.
    • Dependencia de procesos: por ejemplo, se necesita otra invocación de servicio para llevar a cabo la ejecución correcta del servicio actual.
    • Dependencia de condición posterior: aparece en casos en los que un servicio necesita otra invocación de servicio tras su ejecución.

Estas dependencias a menudo pueden formar parte del proceso de decisiones que un cliente de servicio debe atravesar en la elección de reutilización de un servicio, particularmente si hay varias implementaciones entre las que elegir.

Los tipos de dependencias/asociaciones en el modelo de servicio que son importantes se enumeran a continuación.

  • La relación entre un servicio y los proveedores de servicio que implementa.
  • La relación entre un servicio y la especificación de servicio que implementa.
  • La relación entre un servicio y las especificaciones de servicio que necesita.
  • La relación entre un servicio y cualquier canal de servicio que lo conecte con otros servicios y, por lo tanto, el servicio en el otro extremo del canal.
  • La relación entre un servicio y cualquier partición de servicio en la que aparezca el servicio.

Es por tanto importante que todas las especificaciones de servicio sean completas, no sólo con respecto a las operaciones y los mensajes que proporciona sino también con dependencias como las interfaces necesarias para operaciones de devolución de llamada. El informe Dependencias de servicio proporciona una visión general de las dependencias importantes para el modelo de servicio.

Composición y flujos de servicios del modelo

Los servicios a menudo se componen de otros servicios existentes y en algunos casos tecnología como la coreografía pueden permitir que el servicio se desarrolle sin código explícito puramente como composición de servicios existentes. Durante la especificación, los servicios que reutilizan elementos que ya están en la cartera de empresa, y han documentado sus dependencias en estos servicios, pueden considerarse servicios compuestos si su funcionalidad depende del funcionamiento de un servicio compuesto y si el compuesto no puede desplegarse sin acceso a los servicios compuestos.

En algunas infraestructuras de arquitectura orientada a servicios, se piensa en una capa de proceso empresarial para gestionar sólo los servicios compuestos coreografiados en los que se proporcionan procesos complejos como coreografías gestionadas de servicios más detallados. En este caso, se puede utilizar el Lenguaje de ejecución de procesos empresariales para servicios web (BPEL4WS) como herramienta para el desarrollo de servicios compuestos, flujos de servicios y capas de proceso empresarial.

Por tanto, se pueden identificar dos tipos de servicios compuestos:

  • Servicios compuestos conectados estrechamente: se caracterizan por una baja flexibilidad, debido a un flujo y a un control de servicios predefinidos en los que no se externalicen el flujo y el control. Estos tipos de servicios tienen atributos de calidades de servicio atractivos como el rendimiento.
  • Servicios compuestos conectados no estrechamente: se trata de servicios caracterizados por una alta flexibilidad en los que la composición de servicios en procesos empresariales se lleva a cabo externalizando el flujo y el control. La descripción de flujo de la composición se externaliza. Este tipo de composición explota el modelado de herramientas, la variabilidad dinámica a través de reglas, y la variabilidad estática a través de modelado. La composición que utiliza BPEL es un ejemplo.

Para obtener más información, consulte Concepto: Composición y coreografía de servicios así como Directriz: Realización de servicio - Servicios BPEL en una aplicación de arquitectura orientada a servicios para obtener un ejemplo específico de proyecto.

Documentar requisitos no funcionales

El uso de la arquitectura orientada a servicios ofrece la oportunidad de elegir un Artefacto: Proveedor de servicios basado no sólo en la funcionalidad que proporciona sino en las Calidades de servicio (QoS) que puede garantizar. Uno de los motivos para cambiar un proveedor de servicio puede a menudo ser resultado de un cambio en los requisitos no funcionales, necesitándose un nuevo nivel de QoS no actualmente soportado por un proveedor existente. También puede derivar de la degradación de la QoS esperada por el cliente de servicio. Una arquitectura orientada a servicios permite esta agilidad a menor coste, en general, que otros estilos arquitectónicos.

La calidad de servicio se puede observar desde dos perspectivas: la del proveedor y la del cliente. El proveedor de servicios garantiza proporcionar y mantener una calidad de servicio para cada uno de sus servicios o grupo de servicios. El cliente de servicio, por otro lado, "compara" las calidades de servicio deseadas y elige un proveedor según éstas. También es importante observar que en valores comerciales en los que el cliente y el proveedor entran en un contrato legal sobre el uso del servicio, estas garantías de calidad de servicio se ejemplifican en acuerdos de nivel de servicio, frecuentemente con penas asociadas con el no cumplimiento de un proveedor de dichos acuerdos.

Por tanto, es muy importante especificar claramente los requisitos no funcionales necesarios para el cliente (por ejemplo, coste de transacción, rendimiento, disponibilidad, seguridad, etc.) de un servicio o un conjunto de servicios. En esta tarea de Especificación de servicio, identificamos requisitos no funcionales para la QoS deseada. Los requisitos no funcionales se utilizarán para asignar recursos para componentes de servicio que ofrecen los servicios y para financiar la realización y el mantenimiento de componentes de servicio que garanticen la entrega de la QoS a lo largo del tiempo. Deberán tomarse decisiones clave sobre arquitectura para garantizar que se conseguirá la calidad de servicio prometida basada en requisitos no funcionales.

La forma en que los requisitos no funcionales se relacionan con el Artefacto: Especificación de servicio no se define en esta directriz. No hay límites establecidos en lo que constituye dicho requisito, obviamente QoS, la seguridad se ha mencionado anteriormente, entre los ejemplos están:

  • Disponibilidad (por ejemplo, tiempo medio entre anomalías)
  • Ventana operativa (¿hay algún tiempo en el que no espere utilizar este servicio?)
  • Tiempo de respuesta (¿con qué rapidez responde el servicio a una solicitud?)
  • Rendimiento en hora punta (¿cuántas solicitudes de servicio pueden producirse por unidad de tiempo, por ejemplo , por segundo, por minuto, por hora?)
Documentar requisitos de gestión de estado

Aunque los servicios individuales se consideran sin estado, las composiciones a menudo tienen requisitos para mantener la información de estado a través de la invocación de los servicios compuestos. El coreógrafo de estos servicios es a menudo responsable de la gestión del estado. De forma alternativa, un componente que implemente y ejecute varios servicios u operaciones relacionados en los servicio puede necesitar mantener el estado entre invocaciones por motivos de rendimiento.

La gestión de estado en un entorno de arquitectura orientada a servicios puede dividirse en tres categorías principales:

  • Estado de transacción: en el que un servicio tiene una transacción abierta durante una conversación con un cliente.
  • Estado de seguridad: en el que se mantiene abierto un contexto de seguridad durante una conversación con un cliente.
  • Estado funcional: en el que la conversación con un cliente implica un número de operaciones relacionadas.

Para obtener más información, consulte la Directriz: Gestión de estado para servicios.

Más información