Metrópolis y Gobierno de SOA - Willy .Net

Tecnologías de Integración
Basadas en Servicios
El proceso que se utiliza en i-MATE es similar a aquellos descriptos
en [2,3]. Define una serie de pasos que se realizan en i-MATE,
y las decisiones tomadas y objetos producidos en cada etapa.
Ellos se describen en la figura 1 y se explican brevemente a continuación:
Elaborar requerimientos del cliente. Este primer paso produce
un documento que captura los requerimientos del cliente.
Debido a que los problemas de aplicación y la tecnología son
complejos, por lo general nos encontramos con que los requerimientos
globales no se comprenden en su totalidad. Por consiguiente,
se llevan a cabo varios seminarios con los interesados
en la aplicación para obtener estos requerimientos. Los interesados
involucrados en el mejor de los casos incluyen los grupos
empresariales e IT. El documento resultante detalla los requerimientos
técnicos y empresariales que son específicos para la
necesidad de tecnología de integración en este entorno de integración
basada en el servicio. Cada requisito se expresa como un
único ítem que puede ser evaluado contra una tecnología de integración
específica.
Aumentar los requerimientos genéricos. Esto presenta la
base de conocimientos de i-MATE de casi 200 requerimientos
aplicables amplios y genéricos para tecnologías de integración.
Esto aumenta el conjunto de requerimientos específicos de aplicación
con requerimientos de integración genéricos. El resultado
22
Requerimientos específicos SOI
• El producto debe admitir el conjunto de especificaciones de
Web Service Basic Profile (por ejemplo, WSDI, SOAP, UDDI,
XML)
• El producto debe admitir las especificaciones WS-* avanzadas
(incluidas WS-Security, WS-Coordination, WS-
ReliableMessaging, etc.)
• El proveedor debe implementar el conjunto de especificaciones
WS-* por medio de descargas de cajas de herramientas
dentro de los seis meses de la fecha de información de la especificación.
• El producto debe admitir el soporte del Servicio Web personalizado
al exponerlo a SDK APIs o proporcionar mecanismos
de intercepción
• El producto debe tener soporte del Servicio Web inherente,
en vez de ser un producto añadido.
• Debe admitirse el acceso a las diversas características de
Servicios Web (por ejemplo, Seguridad, garantías transaccionales)
a través de APIs sistemáticos así como también medios
declarativos
• El producto debe admitir una "implementación del Servicio
Web" fácil de las interfaces de servicio empresarial existentes.
• El producto debe interoperar con todas las aplicaciones que
exponen los servicios a través de las interfaces estándar de
Servicios Web.
• El producto debe contar con extensiones de propiedad
exclusiva que puedan dividir los requerimientos de interoperabilidad
basados en los Servicios Web.
• La caja de herramientas de los Servicios Web debe haber
experimentado la evaluación rigurosa del seminario de interoperabilidad
de WS para demostrar su interoperabilidad con los
otros Servicios Web.
• El proveedor debe ser miembro activo de la organización
WS-I
de este representa los requerimientos de aplicación global para la
tecnología de integración basada en el servicio, que se representan
como puntos de requisitos identificados individualmente.
Clasificar los requerimientos globales. El conjunto general
de requerimientos globales se clasifica trabajando en conjunto
con los usuarios principales y otras partes interesadas de la aplicación.
En un basto nivel, cada requisito es considerado como
obligatorio, conveniente, de baja prioridad/no aplicable. Dentro
de cada una de estas categorías, se asignan ponderaciones
importantes para realizar un control de textura fina sobre la clasificación
de requerimientos, de una forma similar a [4,5]. Resulta
de este paso un conjunto de requisitos ponderados que se almacenan
en la herramienta de análisis de requerimientos de i-
MATE.
Identificar posibles productos. Este paso identifica de tres a
cinco productos de integración que son los que muy probablemente
sean aplicados a los requerimientos de aplicación global.
En algunos casos, el cliente ya ha identificado una preselección
basada en razones empresariales y técnicas. En otros casos, utilizamos
nuestra experiencia para trabajar con el cliente en la identificación
de las opciones más probables.
Evaluación del producto. Hemos evaluado cada uno de los productos
posibles en comparación con los requisitos globales en seminarios
realizados con los clientes interesados claves y los representantes
de proveedores del producto. Se asignaron puntuaciones en
comparación con cada punto de requisito para cada producto y se
capturaron en la herramienta de análisis de requerimientos. Esto
implica análisis técnicos en profundidad, así como también pasar por
escenarios de aplicación relevante para comprender de manera precisa
la forma en la que los productos de integración se comportan en
la actualidad. En algunos casos, las capacidades y características del
producto pueden causar que el proceso repita y depure las clasificaciones
de requerimientos. Una vez que se han evaluado todos los
productos, la herramienta de análisis de los requerimientos calcula
automáticamente un resumen de las puntuaciones ponderadas en
base a los puntos de los requerimientos individuales y las ponderaciones.
Se crean también de manera automática cuadros sintéticos
para permitir presentaciones e informes eficaces.
Análisis del contexto. Al variar las ponderaciones de requerimientos,
la herramienta de análisis de requerimientos considera trivial
explorar diversos contextos "Qué pasaría si..." ["what-if"] y relaciones
de intercambio [trade-offs]. Esto puede utilizarse para diferenciar aún
más entre productos posibles, o confirmar la idoneidad de ciertos
productos sujetos a diversos requerimientos. El resultado de este
paso es la recomendación de uno o más productos que pueden cumplir
con los requerimientos de aplicación.
Creación de un prototipo
Prototipo de Prueba de Tecnología. Cuando el resultado de la
evaluación del producto no está 100% completo, se desarrolla un
Prototipo de Prueba de Tecnología. El prototipo por lo general implementa
un contexto crítico que ejercitará y/o destacará los requerimientos
que se considera que poseen la más alta prioridad. Aún los
más simples prototipos son herramientas muy eficaces que proporcionan
una evidencia indiscutible y concreta de las posibilidades del
producto. En varios proyectos i-MATE, los resultados de los prototipos
han proporcionado la diferenciación final requerida para ultimar
la selección del producto. De hecho, siempre se recomienda una
etapa de creación de prototipos en I-MATE, aún cuando surge del
proceso un producto como líder claro. Sin embargo, cuando se considera
sólo un producto, la tarea de creación de prototipos no es
competitiva y puede ser definida y estructurada más hacia la validación
de requerimientos claves de aplicación.
• Journal 5 • www.microsoft.com /architecture