Documentación: La actualización de RUP para la arquitectura orientada a servicios
Este documento describe una actualización a Rational Unified Process (RUP) con el objetivo de presentar instrucciones para el arquitecto y el diseñador de software en el desarrollo de un modelo de servicio, un modelo que representa una cartera de servicios que se puede utilizar como base para tareas de implementación que ya están en RUP.
Relaciones
Elementos relacionados
Descripción
Descripción principal

Por Ali Arsanjani, Simon Johnston, John Smith, IBM © Copyright 2005, 2006 de IBM Corporation. Reservados todos los derechos.

Temas

Introducción

Este documento describe la tercera actualización a Rational Unified Process (RUP) centrándose en la arquitectura orientada a servicios (SOA). Esta actualización representa un objetivo importante en las instrucciones de RUP sobre SOA ya que proporciona un método unificado que combina contenido anterior de RUP para SOA con contenido del método Arquitectura y modelado orientados a servicios (SOMA) de IBM Global Business Services (GBS). El método SOMA ha sido utilizado con gran éxito por IBM en un gran número de compromisos con el cliente, y aunque inicialmente de desarrolló aprovechando al máximo el método IBM Global Services (Método GS) existente, se sintió que en el área de la arquitectura orientada a servicios tanto IBM como nuestros clientes podrían beneficiarse más de un enfoque de método unificado en lugar de disponer de dos métodos independientes. Cuando observamos los dos métodos, resulta claro que los autores tenían objetivos similares en mente y que estructuraron los métodos de forma parecida (de hecho, los dos equipos se reunieron en 2004 e hicieron algunos cambios en ambos métodos para alinear la terminología). Aunque esta alineación no es del todo sorprendente, ya que ambos métodos se centran en actividades programáticas de desarrollo de una solución orientada a servicios, se observó que podría extraerse una infraestructura genérica que pudiese describir ambos métodos en un nivel alto.

Los clientes familiarizados con el RUP clásico puede que deseen revisar el Concepto: Desarrollo de soluciones orientadas a servicios.

El personal de IBM familiarizado con SOMA puede que desee revisar la Guía básica: Transición desde IBM SOMA.

Visión general de integración de método

El siguiente diagrama ilustra la infraestructura mencionada anteriormente. Representa un conjunto neutral metódico de actividades necesarias en todo proceso para el desarrollo de soluciones orientadas a servicios. Ahora, este diagrama se ha simplificado enormemente a partir del contenido de ambos métodos, pero representa nítidamente las actividades clave de los dos métodos: identificación de servicio, especificación de servicio y realización de servicio. En el área de los productos de trabajo, estaba claro que existía mucha alineación conceptual. Se necesitaban productos de trabajo parecidos con roles e interesados similares, pero en algunos casos se ejecutaban de forma distinta; por ejemplo, como modelo UML o como documento de Word. Esto se observaba como una simple alineación que debía hacerse. De nuevo, las influencias principales se corresponden en general con las actividades aunque, por supuesto, la realidad es que todos los requisitos tienen alguna relación con las actividades.

 Visión general del método

Figura: la infraestructura de método de SOA unificado

Se puede expandir un nivel mayor de la infraestructura ya que las actividades aquí identificadas son cubiertas por varias técnicas y es realmente en el área de las técnicas detalladas donde tiene lugar la integración de los métodos. Este documento no proporcionará detalles sobre la integración de técnicas, sin embargo, es importante observar que el desarrollo de un único método coherente introdujo algunos cambios en ambos métodos usados como puntos de partida para garantizar que el lector vea una coherencia en las definiciones de concepto, enfoque, tarea y producto de trabajo. Una decisión, por ejemplo, que proporciona un nivel de coherencia al contenido es utilizar el RUP existente para el producto de trabajo de SOA: el modelo de servicio como origen principal desde el que un gran número de tablas e informes textuales pueden generarse para ofrecer los productos de trabajo esperados por los expertos en SOMA. En general, este cambio suministra el valor de que el modelo de servicio UML tiene semántica adicional y se puede utilizar para desarrollar modelos de especificación y realización de servicio; sin embargo el modelo de servicio debe ampliarse para capturar información adicional necesaria para los productos de trabajo de SOMA existentes; por ejemplo, el Producto de trabajo: Especificación de servicio se ha ampliado con origen y estado de propiedades adicionales que capturan información habitualmente utilizada por las propiedades de SOMA.

Principios

El conector se basa de las siguientes ideas:

  1. Permitir un crecimiento posterior; minimizar o evitar restricciones en adiciones futuras de actividades, productos de trabajo, roles, etc.
  2. Mantener la posibilidad de agregar extensiones de propietario en los métodos comerciales actuales o futuros: por ejemplo, extensiones específicas del sector o activos en SOMA; el contenido de propietario también se puede añadir a la infraestructura para sacar el máximo partido al servicio.
  3. Hacer converger el cliente y la mensajería interna de IBM
  4. El método debe ser agnóstico con las herramientas pero ofrecer directrices de integración para mentores de herramientas, favoreciendo la cartera de IBM
  5. Permitir las funciones de las actividades del método en lugar de restringirlas según el método GS o RUP u otros métodos heredados.

Ámbito

Esta actualización a Rational Unified Process (RUP) tiene como objetivo presentar instrucciones para el arquitecto de software y el diseñador de software en el desarrollo de un modelo de servicio, un modelo que representa una cartera de servicios que puede utilizarse para la implementación de tareas ya existentes en RUP. Nuestro interés consiste también en describir la conexión entre el modelado empresarial y el modelo de servicios. Muchos proyectos de arquitectura orientada a servicios utilizan modelos de proceso empresarial a la hora de entender sus requisitos empresariales, funcionales y los servicios necesarios para dar soporte a un proceso.

El ámbito de esta actualización se trató brevemente en la introducción, pero he aquí un conjunto de requisitos y sentencias de ámbito utilizados para guiar el proyecto.

  • Aprovechar el RUP existente; en este caso esto quiere decir que allí donde sea posible, deberíamos describir los nuevos productos de trabajo y tareas en relación con los existentes en RUP y no añadir de forma innecesaria nuevos conceptos. Igualmente, deberían añadirse nuevos elementos para que coincidan con al flujo global de RUP.
  • Esperar futuras funciones de herramienta; aunque el RUP no depende de herramientas, debería entenderse que no hay ningún motivo para desarrollar contenido en áreas en las que no vayan a existir nunca herramientas y, por tanto, no hay necesidad de no escribir un tema porque la herramienta no está en el mercado aunque podamos esperar que salga pronto.
  • Integración de otra experiencia de IBM en SOA; queda claro que otros grupos dentro de IBM tienen experiencia que se puede aprovechar, sacar y añadir a los conceptos, directrices y prácticas que estamos presentando.
  • Cambios de ámbito en análisis y diseño; hemos observado la literatura que describe la aplicación de SOA en el diseño y la implementación empresarial de SOA en modelos empresariales, organización operacional e integración empresarial. También hemos estudiado las diferencias que SOA tiende a llevar a cabo en las fases de implementación, despliegue y gestión operativa. Se trata de un ámbito muy amplio para la primera iteración, así que sólo nos hemos centrado en los problemas de arquitectura y diseño.
  • Ofrecer una base; se trata de la primera iteración. Esperamos que se puedan añadir instrucciones adicionales en la infraestructura aquí presentada y la conexión realizada entre este contenido y el resto del RUP en iteraciones posteriores.
  • Observar los cambios que deben realizarse en la base pero cambian en futuros releases; sabemos que algunos de los conceptos presentados encajarían mejor con terminología u otros cambios menores del RUP básico. Aunque sería deseable cambiar el RUP, esto conllevaría mayores implicaciones y más tiempo.

Decisiones clave

Pretendemos que este contenido forme parte del RUP básico en el siguiente release comercial del producto. Mientras tanto, queremos poner el contenido a disposición de los clientes, así que el contenido aquí descrito se empaquetará como un conector de RUP y se pondrá a disposición del cliente en forma de descarga.

En paralelo, se realizarán cambios en la disciplina Modelado empresarial (BM) que realicen una mayor conexión entre BM y SOA; sin embargo, se tomó la decisión de esperar los cambios de BM antes de realizar el conector de SOA. La integración de ambos grupos de cambios se llevará a cabo en el release comercial.

Se incorporarán un número de ideas clave de la Arquitectura y modelado orientados a servicios (SOMA) de GBS. Aunque no es posible incorporar todas las ideas e instrucciones en SOMA, sobre todo allí donde queda fuera del ámbito establecido, ha sido útil para guiar nuestro trabajo.

Se han introducido algunos principios nuevos, como conceptos que han afectado a la forma de enfocar el resto del contenido, uno de los cuales es el concepto de cartera de servicios y una vista a nivel de toda la empresa de los servicios suministrados en la empresa.

Reconocimientos

Los autores quisieran dar las gracias a las siguientes personas por su valiosa contribución en este trabajo.A Alan Brown y Sky Matthews por su apoyo y por la revisión del contenido. A Eoin Lane, Steve Graham, Ed Kahan y Grant Larsen por ofrecer no sólo comentarios sobre el trabajo sino muchos ejemplos que nos ayudaron y, a veces, nos dejaron sin respuesta. Quisiéramos dar las gracias también a nuestros colegas que trabajan con esfuerzo en SOMA, Ali Arsanjani, Luba Cherbakov y Kerrie Holley. El material adicional fue incluido en revisión por Maryann Hondo, arquitecta de seguridad de servicios web en IBM.

Por último, nos gustaría dar las gracias a Claus Torp Jensen y a su equipo del Danske Bank por su abierto y franco diálogo sobre la experiencia del banco a la hora de aplicar SOA en el mundo real.