Directriz: Servicio
Esta directriz profundiza en la definición de servicio como recurso de software que se puede descubrir con una especificación de servicio externalizado.
Relaciones
Elementos relacionados
Descripción principal

Introducción

Un servicio es un artefacto clave en una arquitectura orientada a servicios pero, ¿qué es un servicio? A continuación se muestra la entrada del glosario de Rational Unified Process (RUP).

Un servicio es un recurso de software (descubrible) con una especificación de servicio externalizado. Esta especificación de servicio está disponible para búsquedas, enlaces e invocación por parte de un cliente de servicio. El proveedor de servicio realiza la implementación de la especificación de servicio y también ofrece los requisitos de calidad de servicio al cliente de servicio. Los servicios se regirán por políticas declarativas y, por tanto, darán soporte a un estilo de arquitectura reconfigurable dinámicamente.

Y, mientras la siguiente sección describe algunas de las sentencias clave de la entrada anterior, merece la pena contemplar un aspecto adicional de los servicios que realmente los diferencia de los elementos de diseño en tecnologías anteriores; los servicios a un nivel de granularidad que les permite identificarse a partir de un nivel empresarial. A continuación también trataremos la naturaleza de alineación empresarial de los servicios.

Descubribles

Los servicios no son parte de una arquitectura de aplicación monolítica. Existen independientemente en el tiempo de ejecución de cualquiera y todos los servicios de una determinada solución. Esto quiere decir que necesitamos un método para el registro y el descubrimiento de servicios basado en criterios como el Artefacto: especificación de servicio que realiza, su Artefacto: proveedor de servicios, así como otras clasificaciones empresariales y técnicas. Este proceso de descubrimiento puede tener lugar durante el período de desarrollo para hacer coincidir los servicios ofrecidos con los servicios de soporte o tener lugar durante el tiempo de ejecución para permitir el suministro dinámico de los servicios (invocación mediada). Para ser descubrible, un servicio debe proporcionar un conjunto de metadatos que permita la categorización. Estos metadatos son parte de la especificación externa.

Para obtener más información, consulte los apartados Concepto: cartera de clientes y Directriz: Mediación de servicios.

Especificados externamente

La especificación externa permite que un servicio publique sus detalles como interfaz, ubicación, políticas, clasificaciones, etc. sin necesidad de que el cliente tenga acceso al propio servicio. Normalmente dicha información se almacena entonces en una ubicación o registro de servicios especializado que de soporte a consultas de los metadatos. Actualmente en el mundo de los servicios web, el estándar aceptado para la descripción de interfaces de servicios es WSDL (Lenguaje de descripción de servicios web), que procede de World Wide Web Consortium.

El producto de trabajo de especificación de servicio es realmente una combinación de tres componentes: la interfaz, el comportamiento y la especificación de políticas. De esta forma, la realización de estos distintos aspectos requiere algo más que la definición de interfaz suministrada por WSDL.

Para obtener más información acerca de los registros de servicio, consulte el apartado Concepto: cartera de servicios.

Basado en contrato

En la definición anterior del glosario observamos que la especificación de servicio ofrece una vista del proveedor de servicio y del cliente de servicio. Estas vistas se corresponden con dos mitades de un contrato que permiten la separación clara de la especificación de la implementación.

La siguiente tabla describe cómo los distintos aspectos de una especificación de servicio afectan al proveedor y al cliente de la especificación.

Rol Especificación de interfaz Especificación de comportamiento Especificación de política
Proveedor Informa sobre el conjunto de operaciones y mensajes al que el servicio debe responder. Todas las operaciones deben responder con los mensajes correctos. Informa del comportamiento que este servicio debe soportar. Si tal especificación de comportamiento es formal y completa, se puede probar una implementación para el cumplimiento de la especificación. Informa sobre un conjunto de restricciones bajo el que puede trabajar la implementación, así como sobre un conjunto de calidades de servicio que deben ejecutarse.
Cliente Informa sobre el conjunto de operaciones que se pueden invocar. Informa sobre los requisitos de protocolo que el cliente debe ejecutar (ordenación de operaciones, flujos de datos, etc.). También indica las operaciones que el cliente debe implementar para dar soporte a colaboraciones. Informa sobre restricciones sobre las que el cliente debe ser consciente, caso de los requisitos de seguridad, en comunicaciones con este servicio. También identifica las calidades de servicio que un cliente puede obtener de un determinado proveedor.

Dicha especificación de servicio puede verse como una aplicación del diseño por contrato pero es un paso necesario a la hora de obtener servicios descubribles y reconfigurables dinámicamente.

Alineación empresarial

En general, la conexión entre modelos empresariales que representa las operaciones de la empresa y los modelos de diseño para dar soporte a aplicaciones de TI se ha, como mucho, realizado de manera más holgada. En la mayoría de los casos, se han desconectado completamente. Aunque el RUP no proporciona instrucciones sobre la transición de modelos empresariales a modelos de guiones de uso de sistema (consulte la directriz Ir de modelos empresariales a sistemas), la conexión requiere un número de transformaciones a medida que el nivel de granularidad y abstracción cambia de perspectivas empresariales a perspectivas de TI.

En general, está claro que los servicios se pueden clasificar en servicios empresariales o de infraestructura. Consulte el apartado Concepto: Cartera de servicios para obtener consideraciones sobre las clasificaciones de servicios.

Un aspecto importante de SOA es que el nivel de granularidad de los servicios descritos en una solución orientada a servicios es tal que las operaciones proporcionadas por los servicios a menudo se identifican en el nivel empresarial. Este aumento en el nivel de granularidad en TI de soporte significa que, en muchos casos, las tareas identificadas en los modelos de proceso empresarial se pueden ejecutar directamente como operaciones en servicios. Por tanto, los usuarios empresariales de las soluciones de TI se convierten cada vez más en parte de los procesos de análisis y diseño. También es interesante observar que esta estrecha conexión con el modelo de proceso empresarial también asocia más directamente los servicios como productos de trabajo de TI, con los objetivos empresariales modelados en la disciplina de modelado empresarial de RUP.

Para obtener más detalles sobre la conexión entre modelos empresariales y de servicio, consulte la Actividad: análisis de activos existentes.

Modelado de un servicio

En el modelado de servicio, utilice el Perfil Lenguaje de modelado unificado (UML) para servicios de software y las instrucciones que se proporcionan para cada elemento del perfil. En general, los elementos que crean la vista estática de servicios y especificaciones de servicio en un modelo de servicio aparecen en el siguiente diagrama.

El diagrama se describe en el contenido textual.

  • El proveedor de servicio "UpdateCustomerAddressLegacyProvider" proporciona un servicio "UpdateCustomerAddress".
  • El servicio "UpdateCustomerAddress" implementa la especificación de servicio "IUpdateCustomerAddress".
  • La especificación de servicio "IUpdateCustomerAddress" tiene una sola operación "execUpdateCustomerAddress".
  • La operación "execUpdateCustomerAddress" toma un solo mensaje de entrada, "UpdateCustomerRequest".
  • La operación "execUpdateCustomerAddress" devuelve un solo mensaje de salida, "UpdateCustomerResponse".

La vista de composición y estructura del modelo captura la comunicación entre servicios y el particionamiento de la solución. Esto se trata en el Concepto: Coreografía y composición de servicios y en el Concepto: Particionamiento de soluciones.

Métodos alternativos

Como ocurre a menudo en modelado, existen métodos alternativos para modelar la misma estructura lógica y en algunos casos las técnicas se pueden utilizar para representar detalles técnicos adicionales. Por ejemplo, al modelar la noción de funciones proporcionadas y necesarias para un servicio podemos elegir estereotipar las interfaces que describen estas funciones como especificaciones de servicio y utilizar una clase estereotipada para representar el tipo combinado, o estereotipar la propia clase y no la interfaz. Ambas opciones aparecen en la siguiente figura.

Normalmente deberíamos estereotipar las interfaces si éstas van a ser utilizadas por otros servicios en un contexto diferente, así que la regla es que cualquiera que sea el elemento considerado reutilizable, su descripción debería estereotiparse. Cuando se crea un servicio en un proveedor de servicios (en términos de UML un puerto en una clase o un componente), seleccione la clase ServiceType o MyService como tipo de puerto estereotipado, tal como aparece a continuación.

Tenga en cuenta que la estructura resultante será idéntica para ServiceType o MyService, el puerto indica una interfaz necesaria y una interfaz proporcionada (posiblemente una interfaz de devolución de llamada que el cliente debe proporcionar). Sin embargo, en algunos casos resulta útil separar explícitamente las funciones necesarias y proporcionadas en descripciones de servicio individuales. En este caso necesitamos dos clases que ejecuten las especificaciones de servicio que hemos introducido anteriormente. La siguiente figura muestra estas clases.

Ahora, cuando creamos nuestro proveedor de servicio necesitamos dos puertos estereotipados, tal como se muestra a continuación, uno para representar la llamada y otro para representar las funciones de devolución de llamada.

El hecho de necesitar esta flexibilidad adicional dependerá mucho de la tarea en mano y del nivel de formalidad necesario de incluir en sus modelos. El ejemplo al final es muy claro a la hora de recordarnos que existen nociones independientes de una interfaz de llamada y de devolución de llamada; no obstante, ¿qué ocurre si el mismo proveedor implementa un número de puntos finales de servicio? La proliferación de puertos puede hacer que el resultado final sea difícil de leer y entender.

Para obtener más información sobre el diseño y la implementación de servicios, consulte la Tarea: Documentar decisiones de realización de servicios.