Integrar programas WebSphere Business Modeler y Rational Data Architect

Opciones de documento Documento que requieren tener Javascript no serán mostradas. Evalúe está página Ayúdanos a mejorar este contenido

Nivel: Intermediaria

Mei Selvage, Data Architect, SOA Design Center, SOA Advanced Technologies, IBM Japón, Software Group
Ray W. Ellis, Senior Software Engineer, SOA Design Center, SOA Advanced Technologies, IBM
Daniel T. Chang, Senior Software Engineer, Information Management, Data Tools, IBM

29-11-2007
Actualizado 17-04-2009

Conozca las generalidades sobre®Rational®Data Architect y WebSphere®Business Modeler de IBM. Recorra tres escenarios para la integración de procesos de negocios y modelado de datos utilizando Rational Data Architect y WebSphere Business Modeler, y descubra en el trayecto recomendaciones y mejores prácticas para su uso.[17 de abril de 2009: Suplemento sobre el cambio de nombre del producto Rational Data Architect a InfoSphere Data Architect. --Ed.]

Introducción

En el mundo de SOA, los procesos de negocios y el modelado de datos se encuentran íntimamente relacionados. La mayor parte de los procesos de negocios exigen la manipulación de ciertos tipos de datos. Los datos proveen soporte a los procesos de negocios para lograr los resultados de negocios esperados. Cuando se utiliza un enfoque de Desarrollo impulsado por el modelo (Model-Driven Development o MDD), se pueden integrar con facilidad los procesos de negocios y el modelado de datos. Además, existe interoperabilidad entre las capas de arquitectura empresarial.

Cambio de nombre del producto El 16 de diciembre de 2008, IBM anunció que a partir de la versión 7.5.1, el producto Rational Data Architect pasa a llamarse InfoSphere Data Architect para describir su función dentro de las InfoSphere Foundation Tools.

IBM es la empresa líder en la provisión de herramientas para procesos de negocios y modelado de datos. Los usuarios pueden modelar procesos de negocios en WebSphere Business Modeler y realizar un modelado de datos lógico con Rational Data Architect. Debido a que IBM ha reconocido la importancia de integrar procesos y modelado de datos utilizando MDD, ha desarrollado un complemento de integración de WebSphere Business Modeler con Rational Data Architect (de aquí en más "complemento") para vincular ambas herramientas. Este complemento se instala sobre Rational Data Architect V7. La “Guía del usuario Recurso de integración para WebSphere Business Modeler y Rational Data Architect " brinda detalles paso a paso para la instalación y uso de este complemento (ver Recursos). El presente artículo ofrece generalidades sobre los programas WebSphere Business Modeler y Rational Data Architect, luego incluye recomendaciones y pasos de alto nivel para los tres escenarios de integración de WebSphere Business Modeler con Rational Data Architect: descendente, ascendente y convergente en el punto medio. Las siguientes secciones describen cada uno de estos escenarios en más detalle.

WebSphere Business Modeler y Rational Data Architect

WebSphere Business Modeler es una herramienta de modelado de procesos de negocios que permite a una organización modelar, diseñar, similar, analizar y generar informes sobre los procesos de negocios, además de definir organizaciones, recursos e información. WebSphere Business Modeler acorta la brecha existente entre el negocio y la tecnología de la información (IT) al ayudar a la organización no sólo a localizar y eliminar ineficiencias, costos y demoras que se ocultan en los procesos, sino también a capturar información importante para volcarla en las herramientas de sistemas descendentes tales como WebSphere Integration Developer, WebSphere Process Server y Rational Software Architect.

Un elemento de negocios en WebSphere Business Modeler puede ser cualquier cosa que se crea, arma, inspecciona, verifica, modifica o sobre la cual se trabaja en los procesos de negocios. La Figura 1, que aparece a continuación, muestra algunos ejemplos de elementos de negocios - Préstamos, Aplicación, etc. – del proyecto de muestra del WebSphere Business Modeler , QuickstartFinance, que se entrega como parte del instructivo sobre WebSphere Business Modeler.

Rational Data Architect es un entorno de desarrollo integral para el modelado de datos, que relaciona e integra recursos de datos, y desarrolla aplicaciones de bases de datos. Principalmente, Rational Data Architect es una ponderosa herramienta que le permite realizar un modelado de datos lógicos, físicos, de almacenamiento, de dominio y de integración. La Figura2, a continuación, muestra un ejemplo de Modelo de datos lógicos derivado del proyecto QuickstartFinance de Rational Data Architect. Obsérvese que las entidades corresponden a elementos de negocios en WebSphere Business Modeler.

Los Modelos de Datos Lógicos (Logical Data Models o LDM) eran a menudo pasados por alto en el ciclo de vida de desarrollo de sistemas. Sin embargo, éstos ganan cada vez más importancia en SOA por numerosas razones. Un LDM le permite obtener un rápido panorama general sobre las entidades de datos (en otras palabras, una unidad de datos que generalmente representa un objeto de la vida real o una idea abstracta) en una aplicación o empresa sin agobiantes detalles de implementación. También puede resultar especialmente útil cuando se trata con entornos de IT cada vez más complejos y heterogéneos. Un LDM crea una vista de los datos empresariales, ayuda a reducir la redundancia, mejora la calidad de los datos y acelera los proyectos Greenfield y de integración. Es posible rastrear semánticamente en los LDM otros artefactos de IT, como por ejemplo modelos de servicios, modelos de mensajes, modelos de objetos, y modelos de datos físicos, que a menudo se transforman directamente a partir de los LDM. No resulta exagerado decir que el LDM es el concentrador semántico de la arquitectura empresarial.

Al contar con las más modernas herramientas de MDD, como por ejemplo Rational Data Architect y Rational Software Architect, usted podrá generar con facilidad modelos descendentes e implementaciones físicas basadas en LDM. El presente artículo describe un análisis de caso de la vida real sobre el uso de un LDM como fuente semántica y su transformación en diversos artefactos de IT.

Volver arriba

Escenario de integración descendente

En un escenario descendente, los elementos de negocios de WebSphere Business Modeler se exportan como XSD, y luego son importados a Rational Data Architect como elementos de modelado (en otras palabras, entidades, atributos, y relaciones) en un LDM. Este escenario supone la participación de dos roles principales de IT el business analyst que realiza el modelado de negocios y el data modeler que lleva a cabo el modelado de datos lógicos.

A continuación se presentan los pasos para este escenario:

• El business analyst modela los procesos de negocios en WebSphere Business Modeler. Los datos de negocios se capturan como elementos de negocios (Business Items o BI).
• El business analyst exporta los elementos de negocios como XSD en WebSphere Business Modeler.
• El data modeler importa XSD y lo transforma en un LDM usando el complemento del Rational Data Architect.
• Como opción, el data modeler puede transformar un LDM en un esquema de base de datos físicos y DDL usando Rational Data Architect.

El siguiente diagrama (Figura 3), creado en WebSphere Business Modeler, muestra la interacción entre el business analyst y el data modeler en el escenario descendente:

Considere la aplicación del escenario descendente cuando se produce una combinación de las siguientes condiciones:

• El modelado de los procesos de negocios impulsa a la iniciativa del proyecto
• Los procesos de negocios impactan en silos de unidades de negocios
• LDM no está disponible, y se encuentra fuera del alcance de un proyecto
• El esquema de la base de datos físicos es demasiado complejo

No obstante, en ocasiones se adopta un escenario descendente por motivos erróneos. A continuación se presentan (entre comillas) algunos motivos no adecuados para la decisión de adoptar el escenario descendente:

• "Nunca hemos trabajado con LDM." Siempre hay una primera vez. Si su organización ha intentado en el pasado ahorrar tiempo con el uso de LDM, cuanto antes se inicie el esfuerzo de LDM, mejor posicionada se encontrará la organización en el largo plazo.
• "No tenemos aptitudes de LDM." Vale la pena invertir en un buen data modeler, de modo que usted deberá contratar a alguien o desarrollar internamente a su personal para adquirir las aptitudes de LDM.
• "Nuestra aplicación se ocupa solamente de mensajes." La mayoría de los mensajes tendrá, en algún momento, una continuación en otro lugar. Alguna otra persona deberá conocer la semántica de los mensajes para mapearlos a la implementación física de una base de datos y categorías Java. Un LDM ayuda a reducir el costo total de propiedad.

Por último, usted deberá considerar también las contras del uso de un enfoque “descendente” puro:

• Es posible que los modelos de datos se asocien tan íntimamente con determinados procesos de negocios que los proyectos futuros demanden la modificación de un LDM de manera significativa.
• Debido a que los elementos de negocios se encuentran altamente desestandarizados y centrados en documentos, la transformación directa de los elementos de negocios en un LDM sin un diseño y una estandarización cuidadosos puede generar un mal LDM.

Volver arriba

Escenario de integración ascendente

En el escenario ascendente, el LDM del Rational Data Architect se exporta como un XSD, el cual es luego importado como elementos de negocios en WebSphere Business Modeler. En general, es preferible utilizar el enfoque ascendente más que el descendente, debido a los numerosos beneficios que ofrece el LDM, como se mencionó al inicio del artículo. Más aún, el enfoque ascendente permite la separación de intereses: el business analyst se concentra en el modelado y la mejora de los procesos de negocios y el data modeler se concentra en el desarrollo de un vocabulario para utilizar en toda la empresa y en entidades de datos lógicos y consistentes.

A continuación se presentan los pasos para este escenario:

• El data modeler modela los datos en un LDM de Rational Data Architect. Como opción, el data modeler puede derivar un LDM basado en el esquema de la base de datos existente, como visio, etc.
• El data modeler transforma el LDM en XSD utilizando el complemento de Rational Data Architect.
• El business analyst importa el XSD generado como elementos de negocios.
• Como opción, el business analyst puede importar un XSD como un Objeto de servicios de negocios (Business Service Object o BSO). El objeto de servicios de negocios es similar al elemento de negocios y se utiliza para definir los datos del negocio que se requieren cuando se invoca una operación de servicios de negocios. Esta opción solo resulta adecuada si el business analyst no tiene necesidad de realizar modificaciones al BSO, ya que este elemento es sólo de lectura en WebSphere Business Modeler.

La siguiente figura, creada en WebSphere Business Modeler, muestra la interacción entre el business analyst y el data modeler en el escenario ascendente:

Considere el uso del escenario ascendente cuando se produce la combinación de las siguientes condiciones:

• LDM se encuentra disponible.
• Las organizaciones desean desasociar datos de los procesos de negocios y gestionar los datos desde el nivel empresarial (por ejemplo, gestión de datos maestros).
• Las organizaciones desean crear servicios de información reutilizable en toda la empresa.
• Se involucran múltiples iniciativas (por ejemplo, la sobreescritura de una aplicación de negocios y la necesidad de asociación a un almacén de datos). El costo adicional de LDM puede compartirse con más facilidad.
• Los procesos de negocios son demasiado complejos y frecuentemente se encuentran en proceso de cambio. LDM puede brindarle un panorama más estable.
• La aplicación está centrada en los datos.
• El proyecto debe considerar, al menos en parte, las fuentes de datos existentes. Esto puede ocurrir si usted tiene aplicaciones de legado, aplicaciones de terceros o intefaces con socios de negocios basadas en normas.

Por último, el enfoque ‘puramente’ ascendente tiene su precio:

• Es posible que se pierdan algunas semánticas durante la transformación de LDM a elementos de negocios, debido a que LDM incluye semánticas más ricas que los elementos de negocios.
• Debido a que los LDM tienden a ser más completos que los elementos de negocios, con más campos o entidades adecuadamente normalizadas, si usted simplemente fuerza a los LDM dentro de los modelos de procesos sin una comunicación adecuada, los detalles pueden resultar agobiantes para los business analysts. Si el business analyst no comprende los LDM, puede terminar repitiendo información y definiendo entidades o atributos que ya están en los LDM. Por lo tanto, resultará fundamental contar con buena capacitación y una buena comunicación entre el data modeler y el business analyst.
• LDM debe evitar quedar atado a una base de datos físicos, una aplicación o una unidad de negocios para que pueda ser un verdadero concentrador semántico en toda la empresa.

Volver arriba

Escenario de integración de convergencia en el punto medio

El artículo describió previamente los escenarios descendente y ascendente, que se centran principalmente en desarrollos Greenfield. Sin embargo, en SOA la única constante es el cambio. El modelado de un proceso de negocios y de modelos de datos casi nunca debería ser una tarea realizada por única vez. Es más probable que sea una tarea única cuando los modelos no se utilizan y se desactualizan con rapidez. Para evitar esta obsolescencia, el proceso de negocios y el modelado de datos deben ser iterativos y deben entregar rápidamente valor al negocio. En consecuencia, las herramientas de procesos de negocios y modelado de datos deben brindar soporte a capacidades de ida y vuelta. Por ejemplo, los cambios en los elementos de negocios del modelo de procesos pueden actualizarse y quedar reflejados en un LDM ya sea a través de métodos automáticos (para cambios simples) o manuales (cuando se requiera una heurística compleja) de convergencia de modelos.

En realidad, no resulta tarea fácil gestionar la sincronización y modificar la gestión de los elementos de negocios en los modelos de procesos y modelos de datos lógicos, ya que residen en diferentes herramientas y a menudo son realizados por diferentes roles: el business analyst y el data modeler. A pesar de esto, la planificación cuidadosa, la excelente comunicación y la gestión de cambios disciplinada pueden obtener los mejores resultados de las características de las herramientas para lograr un control de los datos de extremo a extremo.

Existen dos casos de uso en el escenario de convergencia en el punto medio, según usted desee actualizar sus elementos de negocios o sus modelos de datos lógicos.

Primer caso de uso: Actualizar elementos de negocios: Una vez que se importa el LDM a WebSphere Business Modeler como elementos de negocios, los business analysts realizan algunos cambios en los elementos de negocios (por ejemplo, agregan nuevos atributos). Es conveniente actualizar Rational Data Architect para que refleje en WebSphere Business Modeler las modificaciones realizadas en los elementos de negocios. Este caso de uso es muy similar al escenario descendente, excepto por el agregado de la complejidad de la sincronización de los LDM existentes en Rational Data Architect debido a la información nueva/modificada. A continuación se presentan los pasos para el primer caso de uso:

• El data modeler importa la versión uno de XSD, que se exporta desde los elementos de negocios de WebSphere Business Modeler, y se transforma como un LDM (línea de base uno) utilizando el complemento de Rational Data Architect.
• El business analyst modifica los elementos de negocios en WebSphere Business Modeler, y luego exporta los elementos de negocios actualizados como la versión dos de XSD.
• El data modeler importa la versión dos de XSD y crea un LDM (línea de base dos) basado en el mismo.
• El data modeler compara y fusiona las líneas de base uno y dos de LDM en Rational Data Architect.

Segundo caso de uso: actualización de modelos de datos lógicos: Una vez que los elementos de negocios de WebSphere Business Modeler pasan al Rational Data Architect, los modeladores de datos realizan algunas modificaciones en Rational Data Architect (por ejemplo, el agregado de nuevas columnas). Entonces, será conveniente actualizar WebSphere Business Modeler para que refleje estas modificaciones. Este caso de uso es muy similar al escenario ascendente, excepto por el agregado de la complejidad de la sincronización de los elementos de negocios existentes en WebSphere Business Modeler debido a la información nueva/modificada. A continuación se presentan los pasos para el segundo caso de uso:

• El business analyst importa la versión uno del XSD generado, la cual se exporta desde el LDM de Rational Data Architect, como elementos de negocios de WebSphere Business Modeler (base uno).
• El data modeler modifica el LDM en Rational Data Architect, y luego exporta el LDM actualizado como la versión dos de XSD.
• El business analyst importa la versión dos de XSD como elementos de negocios en WebSphere Business Modeler.
• Para las entidades que tienen igual nombre, WebSphere Business Modeler creará nuevos elementos de negocios agregando el sufijo "_1"; para las nuevas entidades, WebSphere Business Modeler simplemente creará las nuevas entidades.
• El business analyst deberá determinar cuál es la versión que desea guardar.

La pantalla de captura que aparece en la Figura 5 muestra los elementos de negocios como sufijos con _1 luego de su importación desde Rational Data Architect mediante XSD.

Volver arriba

Análisis de caso sobre MDD basado en LDM

SOA exige una arquitectura de capas y la interconexión entre diversas capas. La arquitectura de capas permite la separación de intereses, y la interconexión habilita el análisis y la rastreabilidad de impactos. El enfoque manual que depende de documentos desestructurados, descubrimiento manual y comunicaciones redundantes ya no resulta suficiente para seguir el ritmo de los rápidos desarrollos de aplicaciones y requerimientos de negocios. En consecuencia, resulta cada vez más importante utilizar el Desarrollo impulsado por modelos (Model-Driven Development o MDD) para acelerar el desarrollo de software en SOA.

El IBM SOA Advanced Technologies Design Center en los Estados Unidos recientemente ha realizado una prueba de concepto de SOA para un cliente de servicios financieros utilizando ESB para permitir el ruteo y la transformación de mensajes de empresa a empresa. MDD se encuentra en el corazón de esta prueba de concepto de SOA. El cliente no cuenta con un modelo bien formado de datos lógicos empresariales. El esquema de base de datos existente, que refleja fundamentalmente una estructura de mensajes, se encuentra altamente desestandarizado. Esta falta genera dificultad en la recuperación, el análisis y el control de calidad de los datos. Afortunadamente, la industria en la cual trabaja el cliente cuenta con un conjunto de esquemas de mensajes estándar relativamente bien formados. El equipo de IBM desarrolló en primer lugar un LDM adecuado para los fines de la prueba de concepto utilizando las mejores prácticas en modelado de datos que existen en el esquema de mensajes estándar de la industria. Luego, el equipo revisó el LDM junto con los business analysts y equipos de desarrollo a fin de asegurar que la definición y las normas de este LDM resultaran consistentes con el resto de la organización. La Figura 6 muestra el modelo y los pasos para la transformación de códigos con Rational Data Architect, WebSphere Business Modeler, y Rational Software Architect.

Volver arriba

Resumen

Este artículo brindó generalidades de alto nivel sobre WebSphere Business Modeler y Rational Data Architect. Ahora, usted sabe cuándo adoptar cada uno de los escenarios de integración en base a las recomendaciones de este artículo. Usted conoce también cuáles son los pasos involucrados en tres escenarios de integración de WebSphere Business Modeler a Rational Data Architect.

WebSphere Business Modeler captura información de negocios clave como elementos de negocios durante el modelado de los procesos. Los elementos de negocios pueden ser un documento de negocios, un producto de trabajo o un artículo producido por una tarea o proceso (como por ejemplo, una factura), o que hace que se inicie un proceso (como por ejemplo, una consulta de cliente). Los elementos de negocios pueden convertirse en la base de la definición de los Modelos de datos lógicos (Logical Data Models o LDM), si no existe un LDM para ese dominio del negocio. Mientras tanto, un LDM captura las entidades de negocios, sus relaciones y las reglas de negocios. Un LDM bien formado puede brindar un rápido panorama sobre la información de negocios clave en un entorno complejo de IT, que refleja los requerimientos de información de negocios. Podría sobrevivir a numerosas aplicaciones, procesos y fuentes de datos físicos. La semántica precisa, completa y exacta del LDM constituye el cimiento perfecto para los elementos de negocios cuando una organización emprende la tarea de modelar sus procesos de negocios.

Por último pero no menos importante, no será suficiente solamente saber cómo se utilizan las herramientas para crear procesos de negocios y modelos de datos lógicos bien formados. Será igualmente importante conocer las razones detrás de la adopción de un cierto escenario, para diseñar una gestión de cambios repetible y robusta y crear una estrategia para aprovechar al máximo la sinergia del proceso de negocios y el modelado de datos. Los procesos de negocios y el modelado de datos lógicos exitosos a menudo exigen cambios organizacionales y culturales. La “Guía del usuario: Recurso de integración para WebSphere Business Modeler y Rational Data Architect” resume, además, algunas de las mejores prácticas de integración de procesos de negocios y modelado de datos (ver Recursos). Este artículo, junto con la guía del usuario, lo ayudarán a poner en marcha su esfuerzo de integración de procesos de negocios y modelado de datos.

Recursos

• "Interoperabilidad de AchieveSemantic en SOA" (developerWorks, junio de 2006): Este artículo revela los misterios de la interoperabilidad semántica en un contexto SOA. Transite el espectro semántico y luego descubra los patrones, los antipatrones, y las mejores prácticas de interoperabilidad semántica.
  
  
• "Integración de Rational Software Architect con Rational Data Architect" (developerWorks, agosto de 2007): Obtenga un rápido panorama general sobre Rational Software Architect y Rational Data Architect. Este artículo presenta los pasos de alto nivel en tres escenarios de integración de Rational Software Architect con Rational Data Architect, y discute las transformaciones UML- LDM y LDM- UML así como el perfil del Modelo de datos lógicos de UML.
  
  
• Zona de Gestión de la información en developerWorks: Aprenda más sobre la Gestión de la información. Encuentre documentación técnica, artículos de “cómo se hace”, capacitación, descargas, información sobre productos, y mucho más.
  
  
• Manténgase actualizado con los Eventos técnicos y noticias web de developerWorks.
  
  
• Librería tecnológica: Navegue en busca de los libros sobre éste y otros temas técnicos.

• Construya su próximo proyecto de desarrollo con el Software de prueba de IBM, que puede descargar directamente de developerWorks.
  
  

• Participe en los Blogs de developerWorks y forme parte de la comunidad developerWorks.
  
  

Sobre los autores

		Mei Selvage es un SOA data architect con amplia experiencia en diversas áreas de gestión de información y SOA. A menudo participa en conferencias como oradora y ha escrito numerosos artículos.

		Ray Ellis es senior software engineer en el SOA Design Center de IBM en Austin. Ha participado de numerosos desarrollos de productos Rational, WebSphere y de Gestión de la Información de IBM.

		Daniel T. Chang es Senior Software Engineer en IBM Silicon Valley Lab. Trabaja en el equipo principal de RDA desde el año 2006.

Evalúe esta pagina

Por favor, completar este formulario para ayudarnos a servirle mejor. ¿La información le ayudó a alcanzar su meta? Si No No sé   Por favor, sus comentarios nos ayuda a mejorar esta página:   ¿Qué tan útil es la información? 1 2 3 4 5 Nada útil Sumamente útil

Volver arriba