Tarea: Especificación de componentes (SOA)
Esta tarea especifica los detalles de los componentes de servicio que ejecutan un subsistema de diseño.
Disciplinas: Análisis y diseño
Objetivo

Trabajar en uno o más Artefacto: Diseñar subsistema de los descritos durante la Tarea: Diseño de subsistema (SOA) y proporcionar diseños detallados del Artefacto: Componente de servicio .

Relaciones
RolesRealizador principal: Otras actividades adicionales que realiza:
EntradasObligatoria: Opcional:
Salidas
Uso del proceso
Descripción principal

Los servicios utilizados en una solución basada en arquitectura orientada a servicios se ejecutan a través del Artefacto: Componentes de servicio, que pertenece a un subsistema alineado de función empresarial específico. Cada componente de servicio tendrá la responsabilidad de garantizar la QoS de los servicios que ejecuta. Como activo a escala de la empresa, cada componente de servicio califica la financiación, la dirección y el mantenimiento asociados con él. La gestión de la infraestructura debe realizarse para garantizar la disponibilidad, el equilibrio de carga, la seguridad, el rendimiento, el mantenimiento de versiones y el buen funcionamiento global del componente de servicio que será responsable de implementar la funcionalidad de un conjunto de servicios y garantizar su calidad de servicio. Los componentes funcionales y los componentes técnicos se pueden utilizar en diversos componentes de servicio.

Pasos
Interfaces de componentes de modelo

Los componentes, y en particular los componentes de servicio, deberían no proporcionar operaciones directamente; en su lugar, deberían utilizar infraestructuras para describir un conjunto de operaciones y, a continuación, proporcionar/ejecutar la interfaz. Esto se describe a grandes rasgos en el RUP, véase la Tarea: Diseño de subsistema (SOA) y la Tarea: Identificar elementos de diseño.

Ejemplo

En nuestro ejemplo Alquiler de coche hemos identificado (a través del análisis del subsistema) la necesidad de un componente de servicio de reserva. Para garantizar un diseño reutilizable y flexible podemos también crear una interfaz de reserva correspondiente, o utilizar la Especificación de servicio (de Tarea: Especificación de servicio) para describir la interfaz en nuestro componente de servicio. El componente ejecutará (en términos de UML) cada interfaz suministrada y podrá también indicar su dependencia en otras interfaces de componente utilizando una relación de uso de UML, tal como se muestra en el siguiente diagrama.

Tenga en cuenta que hemos elidido los detalles de las propias interfaces para mayor claridad.

Atributos de componentes de modelo
En este paso, definiremos los detalles de cada componente de servicio, lo que incluye atributos, servicios, políticas y reglas. La plantilla que sirve para documentar la especificación de componente de servicio incluirá los siguientes atributos:
  1. Propiedades o atributos
  2. Reglas
  3. Variaciones
  4. Depende de <otros componentes>
  5. Composición de componentes funcionales y técnicos
  6. Servicios suministrados
  7. Servicios necesarios
Sucesos y mensajes de componentes de modelo
Durante esta actividad, identificamos los sucesos que el componente debe detectar y a los que debe responder cuando se desencadenan. Los mensajes de componente entrantes y salientes también se especifican. En el caso de los servicios dirigidos por cambios en los datos, se debe tomar una vista centrada en los datos y los procesos empresariales no incluidos en el ámbito de la solución basada en servicios deben identificarse y valorarse para la generación de sucesos y el suministro de datos a los servicios del cliente en la solución orientada a servicios. Por ejemplo, un nuevo cliente puede ser añadido por varios procesos empresariales dentro de un paquete ISV. En todos los casos, los mismos datos pueden no capturarse para el cliente, dependiendo del contexto específico del proceso empresarial. Los servicios de cliente que necesiten conocer los nuevos clientes a través de un servicio de proveedor deberán poder controlar la invocación del nuevo servicio de cliente independientemente del proceso empresarial que lo genere.
Estructura interna de componentes de modelo

Durante esta actividad, es importante crear al menos un diagrama de clase que muestre las relaciones entre los componentes técnicos y funcionales de cada componente de servicio. El modelado de UML estándar se aplica en esta etapa. Se recomienda el uso de patrones para estructurar el gráfico de objetos resultante de forma que sea extensible y esté abierto a cambios. Si se anticipa un grado mayor de cambios, es recomendable realizar un análisis de variabilidad en esta etapa.

Tal como describimos en la tarea anterior, cuando se diseñan cambios, o se anticipa un impacto importante en el diseño y la estructura del sistema de TI como consecuencia de cambios empresariales futuros, entonces sería inteligente emplear las técnicas de Análisis de variabilidad. Estas técnicas refactorizan los factores comunes y externalizan las variaciones mediante patrones de diseño. Los factores en común y las variaciones descubiertas previamente pueden utilizarse como punto de partida y pueden aumentar con el uso de patrones de diseño comunes como Estrategia, Estado [i], Objeto de regla [ii], Objeto de tipo, etc.

El análisis realizado durante el diseño detallado identifica factores comunes, se centra en la creación de variaciones conectables y entraña seis principios que ayudan a separar los aspectos más cambiantes de los menos de los sistemas de software, aislando y encapsulando los cambios:

  1. Separar y modelar los aspectos cambiantes de los no cambiantes del dominio: identificar, separar, encapsular y externalizar variaciones en aumento.
  2. Crear jerarquías de tipos para cada punto de variación.
  3. Asignar tipos de regla a cada tipo de variación.
  4. Implementar tres niveles de abstracción; utilizar metapatrón de herencia agregado
  5. Empezar a partir de niveles de reutilización superiores a los objetos y crear activos en cada nivel de reutilización; crear infraestructuras pequeñas alrededor de los puntos de variación. En general, cada infraestructura no debería tener más de 7+-2 clases.
  6. Cada elemento de reutilización tiene sus propios comportamientos. Externalizar el comportamiento como datos configurables que se puedan leer en la aplicación para permitir un cableado ligero.

[i] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns, Addision-Wesley 1994.

[ii] Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules, Washington University Technical Report number:  wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000.

Flujo de componentes de modelo

Durante esta actividad, identificamos el flujo interno dentro del componente de servicio. Esto se puede representar como diagrama de actividades o secuencias.

Consideración de ISV: El flujo interno de componentes dentro de un componente de paquete ISV puede o no exponerse y/o configurarse dependiendo del paquete. Si los objetos del componente de ISV se exponen y configuran, su flujo podrá adaptarse y personalizarse para que se ajuste mejor a la solución. Sin embargo, uno debería ser consciente de los problemas de mantenimiento potenciales asociados con ello. En muchos casos, no será posible, ni siquiera necesario, identificar el flujo interno de componentes de un paquete ISV. En este caso, el componente ISV debería ser tenido en cuenta como "caja negra", con sólo servicios documentados expuestos y ejecutados.

Asignar componentes a capas

Las capas ofrecen los siguientes beneficios:

  • Las capas ayudan a aportar atributos de modificabilidad y portabilidad de calidad a un sistema de TI. Un cambio en una capa inferior que no afecte a su interfaz no necesitará cambios en una capa superior. Por ejemplo, cualquier servidor de aplicación compatible con J2EE™ que cumpla el estándar J2EE™ puede sustituirse libremente sin necesidad de cambiar a software de nivel de aplicación. Un cambio en una capa superior que no afecte a las facilidades que requiere de capas inferiores no afecta a ninguna capa inferior. En general, los cambios en un sistema de software con capas que no afecten a ninguna interfaz se confinan en una sola capa.
  • Las capas forman parte del patrón que la arquitectura desempeña en la construcción del sistema. Conocer las capas en las que reside su software, los desarrolladores saben en qué servicios pueden confiar en el entorno de codificación. Las capas pueden definir asignaciones de trabajo para equipos de desarrollo (aunque no siempre).
  • Las capas forman parte del rol de comunicación desempeñado por la arquitectura. En un sistema grande, el número de dependencias entre módulos se amplía rápidamente. La organización del software en capas con interfaces es una herramienta importante para gestionar la complejidad y comunicar la estructura a los desarrolladores.
  • Las capas ayudan con el rol de análisis desempeñado por la arquitectura. Se pueden utilizar para analizar el impacto de los cambios en el diseño.

Las capas pueden ser estrictas o no estrictas. Un esquema estricto de capas significa que los componentes sólo pueden utilizar componentes en la misma capa o en capas inmediatamente por debajo de ellas. Un esquema de capas no estricto significa que los componentes pueden utilizar componentes en la misma capa o en cualquier capa inferior. Observemos que como regla general, no obstante, los componentes deberían poder utilizar componentes en capas superiores. Si los componentes tienen dependencias en componentes de capas superiores, entonces se volverá difícil sustituir los componentes de capas superiores sin tener que cambiar los componentes de capas inferiores. Para obtener más información, incluidas las técnicas de modelado de capas, consulte Concepto: Particionamiento de soluciones.

Un punto importante que debe tenerse en cuenta es que las capas de software no son iguales a los niveles. La asignación a máquinas en un entorno distribuido, el flujo de datos entre elementos, y la presencia y utilización de canales de comunicación tienden todos a expresarse en imágenes de nivel que pueden ser indiscernibles de los diagramas de capas. Los diagramas de nivel tienden a mostrar flechas de dos direcciones que indican una comunicación bidireccional de algún tipo. La comunicación bidireccional (simétrica) no es una buena noticia en un diagrama de capas. Además, la asignación de un componente a un nivel se basa en las reglas de colocación que se tienen en cuenta al definir la arquitectura operativa y es definida por las características de nivel de servicio necesarias del sistema. La diferencia principal entre los diagramas de capas y las imágenes de niveles es que las primeras no tienen noción de colocación mientras las segundas sí lo tienen claro.

Reglas de miniatura para capas

  • Todos los componentes que proporcionan funcionalidad empresarial independiente de aplicación podrían ir en una capa. Las funciones empresariales independientes de aplicación son tipo "gestión de clientes" y "gestión de productos" y se aplican a aun rango de distintas aplicaciones.
  • Todos los componentes que ofrecen funciones técnicas, caso del manejo de errores, la autenticación, el registro y la auditoría podrían ir en otra capa (lógica). Estos componentes son independientes de la empresa y de la aplicación. En algunos casos, la proximidad a componentes funcionales puede requerir que se coloquen en una capa común. Se trata de decisiones arquitectónicas y deben documentarse como tales.
  • Los componentes de middleware como la cola de mensajes y el software DBMS relacional podrían ir en una capa más. Esto también se denomina "Tejido".

Ejemplo

A continuación se muestra una vista a capas de una SOA que muestra capas típicas (y verdaderamente recomendadas) de los distintos elementos presentes en una solución.

Ahora, en este esquema de capas, es relativamente simple ejecutar allí donde nuestros componentes residan, colocamos los componentes relevantes para nuestro ejemplo Alquiler de un coche en la capa Componentes de servicio, tal como se muestra a continuación. Observe que deseamos emplear capas estrictas en nuestro modelo y, por tanto, utilizamos la composición UML para contener nuestros componentes en la capa Componente de servicio y sólo exponer la funcionalidad de Componentes de servicio usando puertos delegados allí donde el puerto proporciona la misma interfaz que el propio componente de servicio.

Más información