Tarea: Decisiones de realización de servicio de documentos
Esta tarea se centra en la realización de un modelo de servicio desde el punto de vista de los componentes de software que se ejecutan en los entornos de middleware existentes.
Objetivo

El objetivo de esta tarea es proporcionar un modelo de diseño para implementación que pueda ser utilizado por los desarrolladores para implementar componentes de servicio para ofrecer los servicios necesarios.

Relaciones
Descripción principal

El objetivo del modelo de servicio es fundamentalmente identificar servicios, su organización, colaboración y su especificación detallada y completa. El rol de la implementación es delegado al modelo de diseño de Rational Unified Process (RUP) existente y, en concreto, al elemento de modelo Componente de servicio. En general, el modelo de servicio es ejecutado por un modelo de diseño. Sin embargo, sería posible generar artefactos directamente desde el modelo de servicio en el que simplemente se necesiten especificaciones. También puede ser útil crear un modelo de guión de uso a partir del modelo de servicio que permita una mayor descripción de los servicios antes de su construcción.

Pasos
Determinar enfoque de origen

Existe un determinado número de alternativas que deben considerarse en relación con la decisión de cómo ejecutar los servicios (véase la siguiente figura). No se trata de una simple decisión de creación frente a compra; en la imagen aparecen otras opciones interesantes. La "Transform"-ación utiliza una combinación de técnicas, entre las que se incluye la extracción de reglas empresariales para sacar un segmento de funciones que se utilicen de forma independiente en la ejecución del servicio del componente. "Integrar" es la "derivación" de funciones heredadas para conseguir funcionalidad; la integración se basa en invocaciones. La suscripción se basa en la disponibilidad de un modelo de publicación-suscripción (en un contexto de middleware orientado a mensajes) en el que el cliente se suscribe a los servicios suministrados por el proveedor. Una de las opciones es subcontratar (por ejemplo, Nómina) las funciones en alguna otra empresa. A medida que los servicios web y la integración de empresa a empresa se vuelva más importante, deberá también tenerse en cuenta el uso de manera más amplia.

  • Construir: por diversas razones, la decisión es ir hacia adelante y desarrollar el servicio en la empresa.
  • Comprar: comprar un servicio que se puede desarrollar y alojar internamente.
  • Transformar: utiliza una combinación de técnicas que incluyen la extracción de reglas empresariales para sacar un segmento de funciones que se utilicen independientemente en la ejecución del servicio del componente.
  • Suscribir: se basa en la disponibilidad de un modelo de publicación-suscripción (en un contexto de middleware orientado a mensajes) en el que un cliente se suscribe a los servicios suministrados por el proveedor de servicio.
  • Integrar: es la derivación de funciones heredadas para conseguir funcionalidad; la integración se basa en invocaciones.
  • Subcontratar: a medida que los servicios web y la integración de empresa a empresa se vuelven más importantes, esta opción también puede tenerse en cuenta para su uso de manera más amplia.

Las decisiones de realización de servicio están asociadas con componentes de servicio. Cada componente de servicio puede ser considerado un contenedor de funcionalidad que es necesario para realizar un servicio. Se compone de o utiliza componentes funcionales y técnicos. Es importante decidir cómo se ejecutarán estos componentes de servicio. No es una simple decisión de "comprar o construir". Hay otras consideraciones que deben tenerse en cuenta, por ejemplo:

  • La transformación que implica la extracción de reglas o la creación de un clon del código existente y su reescritura para que funcione como componente con una interfaz definida.
  • La integración con mensajería o derivadores.

Ejemplo

Deseamos capturar las decisiones de realización para el ejemplo Alquiler de coche, aunque resulta difícil hacerlo en el modelo de UML que hemos utilizado en diversos ejemplos. Para ayudarnos en este proceso, la plantilla Matriz de realización puede utilizarse para documentar el resultado de estas decisiones, tal como se muestra en la siguiente figura.

Determinar enfoque de desarrollo

La ventaja de las opciones descritas son que haga la elección que haga, existe una conexión entre cada una desde el punto de vista de la rastreabilidad del modelo de guiones de uso a un modelo de diseño y, posteriormente, a la implementación.

El diagrama se describe en el contenido textual.

Es recomendable que el modelo de servicio se ejecute utilizando un modelo de diseño. Éste proporciona la posibilidad de que el diseñador y el implementador apliquen patrones al modelo de diseño y modelen unciones y estructuras adicionales antes de generar artefactos de implementación.

Correlación detallada de activos existentes

Uno nunca debe olvidar que muy pocas soluciones se construyen sin tener en cuenta aplicaciones existentes que proporcionarán funcionalidad para dar soporte a la solución o con las que la solución debe interactuar. Por eso resulta vital que las aplicaciones heredadas existentes que sean reutilizadas como parte de alguna solución se cataloguen y sus funciones sean identificadas. Con una solución orientada a servicios, podemos tomar un número de rutas para integrar nuevos servicios con funciones existentes. Éstas se muestran en la siguiente figura:

  • Recortar la función existente como servicio. En este caso, buscamos dejar la función tal cual, pero utilizar herramientas o middleware para exponer la función existente como servicio. Por ejemplo, IBM ofrece funciones para exponer transacciones de CICS heredadas como servicios web de SOAP.
  • Recortar y sustituir la función existente por un servicio. En este caso, recortamos una función tal como lo hicimos anteriormente, pero utilizamos la especificación de servicio resultante para volver a desarrollar el servicio posteriormente, sustituyendo el servicio original y redireccionando los clientes a la nueva implementación.
  • Usar un adaptador más dócil para invocaciones de servicio. En algunos casos, no se puede recortar una función y exponerla como servicio, pero podemos recortar la función en algo más fácil de integrar, caso de una interfaz de cola de mensajes o la Arquitectura de conector Java (JCA). Esto permite que los nuevos servicios accedan a las funciones in situ.
  • Integrar la función en el servicio. En algunos casos, obviamente, es posible que el nuevo servicio acceda a la función heredada in situ, simplemente utilizando la función como un componente lógico dentro de la implementación del servicio.

El diagrama se describe en el contenido textual.

Debería tenerse en cuenta que las opciones tercera y cuarta ofrecen la mayor flexibilidad porque utilizan la función existente pero no siguen exponiendo la función tal cual a los clientes. Por otro lado, las opciones primera y segunda pueden presentar problemas con el recorte de funciones existentes como servicios ya que el rendimiento de protocolos de servicio web y las no coincidencias entre formatos de datos nativos y XML pueden presentar problemas de rendimiento.

Los activos de software existentes y sus dependencias e interfaces serán analizadas para determinar se requieren cambios para dar soporte a la funcionalidad empresarial.  Por ejemplo, para crear una interfaz de servicios web para una implementación heredada de una función empresarial, el análisis puede entrañar el examen de la composición y el flujo de transacciones en línea o trabajos de lotes, o almacenamientos de datos persistentes que ayudan a ejecutar dicha función.  El diseño actual de estas aplicaciones existentes puede que tenga que cambiar para dar soporte a la funcionalidd.  También existe la necesidad de identificar las barreras potenciales para crear una interfaz de servicios web con la calidad de servicio deseada.  Por ejemplo, una implementación por lotes monolítica de una función empresarial puede necesitar un tiempo de respuesta posterior cuando se invoque como servicio.  

Recorte de activos existentes como patrón de servicios

En algunos casos, sin embargo, resulta conveniente desarrollar una partición de servicio heredado en la que un conjunto de funciones heredadas de nivel inferior estén expuestas individualmente como servicios. Esta partición sólo es accesible para servicios de nivel superior que los utilizan en presentaciones a los clientes de una especificación alineada con la empresa más detallada. Esta encapsulación de las funciones heredadas debería verse como una solución temporal y sólo debería llevarse a cabo si las características de rendimiento de la tecnología de recorte se entienden bien. Para obtener más información, consulte el concepto Particionamiento de soluciones.

Una forma de observar el recorte de una función heredada es una forma muy simplificada del elemento de modelo Proveedor de servicio, con un único servicio que ejecute una única especificación con sólo una única operación. El siguiente diagrama muestra este patrón para la función heredada "UpdateCustomerAddress".

 El diagrama se describe en el contenido textual.

Al adaptar este patrón, puede que desee hacer lo siguiente:

  • Es probable que un conjunto de funciones existentes sean suministradas por el mismo componente para que se utilice el mismo proveedor de servicio.
  • El patrón anterior se generó automáticamente; puede que sea preferible renombrar el nombre de operación predeterminado de "exec${service}".
  • Igualmente, sería válido renombrar los mensajes generados predeterminados; también en este punto, deberían modelarse las estructuras de mensaje.
  • El patrón predeterminado da por supuesto que la operación toma una entrada de mensaje y devuelve un mensaje; puede ser que la función heredada no devuelva ningún mensaje o sea sólo una notificación y la firma de la operación generada deba corregirse.
  • El arquitecto/diseñador debería garantizar que se especifican los valores correctos para la propiedad "allowedBindings" del proveedor de servicio.
Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información