Descripción principal |
Por Ali Arsanjani, Simon Johnston, John Smith, IBM © Copyright 2005, 2006 de IBM Corporation. Reservados todos
los derechos.
Temas
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.
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.
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.
El conector se basa de las siguientes ideas:
-
Permitir un crecimiento posterior; minimizar o evitar restricciones en adiciones futuras de actividades,
productos de trabajo, roles, etc.
-
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.
-
Hacer converger el cliente y la mensajería interna de IBM
-
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
-
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.
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.
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.
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.
|