Contenido


Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios

Parte 5. Implementación de servicios

Comments

Contenido de la serie:

Este contenido es la parte # de # de la serie: Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios

Manténgase en contacto por contenidos adicionales de esta serie.

Este contenido es parte de la serie:Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios

Manténgase en contacto por contenidos adicionales de esta serie.

Acerca de esta serie

En los artículos anteriores de la serie (ir a "Ver otros contenidos de esta serie "), se presentó un enfoque para identificar servicios conectados con requisitos de negocios. Comenzamos capturando las metas y los objetivos necesarios para concretar la misión de negocios. Luego, modelamos las operaciones y procesos de negocios necesarios para alcanzar las metas y objetivos. Más adelante, usamos el proceso de negocios para identificar las capacidades y los servicios. Por último, concluimos la especificación de los servicios identificados, los asignamos a ciertos participantes e implementamos esos participantes.

En el primer artículo de la serie (parte 1: Identificación de servicios), se analizó cómo maximizar el potencial de una solución de arquitectura orientada a servicios (SOA) identificando servicios relevantes para los negocios. Se identificaron las capacidades necesarias en función de los requisitos de negocios y se expusieron esas capacidades a través de interfaces de servicio.

En el segundo artículo, (parte 2. Especificación de servicios), se modelaron los detalles de las interfaces de servicio. Una interfaz de servicio define todo lo aquello que deben saber los potenciales consumidores para decidir si están interesados en usar el servicio, así como la forma exacta de usarlo. También especifica todo aquello que debe saber un proveedor de servicios para implementar el servicio con éxito.

En la parte 3 ("Realización de servicios"), se modeló la realización de las interfaces de servicio, lo que se tradujo en los participantes Invoicer (Facturador), Productions (Producciones) y Shipper (Expedidor). Cada uno de ellos presta servicios y realiza capacidades en función de la interfaz de servicio. Y cada una de las operaciones de servicio proporcionadas tiene un método que describe de qué manera se implementa el servicio. El método puede ser cualquier comportamiento de UML, como Activity, Interaction, StateMachine u OpaqueBehavior. La elección queda a criterio del modelador.

En la parte 4. ("Composición de servicios"), se analizó cómo se pueden ensamblar los participantes conectando solicitudes y servicios compatibles mediante canales de servicios. Estos ensamblados representan la manera en que se agrupan los participantes de servicio para brindar soluciones, tales como implementaciones de otros servicios.

El este artículo, el último de la serie, usaremos la función de transformación de UML a SOA de IBM® Rational® Software Architect para crear una implementación de servicios web que se pueda usar directamente en IBM® WebSphere® Integration Developer para implementar, probar e implantar la solución completa IBM.

Contexto del artículo

Siguiendo los pasos incluidos en los artículos anteriores se creó un modelo de solución de SOA completo que cumple los requisitos de negocios. De esta forma, ya conocemos los requisitos que cumple esta arquitectura de la solución y qué podría cambiar cuando cambian los requisitos.

Para implementar y ejecutar esta solución, es necesario crear una implementación real que sea consistente con las decisiones arquitectónicas y de diseño capturadas en el modelo. Es posible crear la solución a mano, usando el modelo como guía. Pero el proceso sería largo, tedioso y propenso a errores, y sería necesaria la intervención de un desarrollador altamente calificado para asegurarse de que las decisiones arquitectónicas se implementen correctamente. Por supuesto que sería posible crear la solución a mano, para lo cual sería muy útil usar el modelo como guía. Sin embargo, un modelo completo, formal y comprobado nos da la oportunidad de explotar un desarrollo basado en modelos (MDD) a fin de crear uno o más esqueletos de soluciones a partir del modelo para luego completar la codificación detallada en un entorno de programación específico de la plataforma. Ese es el tema del presente artículo. Y usaremos la función de transformación de UML a SOA de Rational Software Architect para crear un servicio web que se pueda usar directamente en WebSphere Integration Developer para implementar, probar e implantar la solución completa.

Como en todos los artículos de esta serie, se usarán las herramientas existentes de IBM Rational para generar los artefactos de solución y vincularlos entre sí a fin de poder comprobar la solución en función de los requisitos y gestionar el cambio de una manera más eficaz. Asimismo, se extenderá el lenguaje unificado de modelado (UML) al modelado de servicios agregando el perfil SoaML de OMG a los modelos UML de IBM Rational Software Architect. La tabla 1 ofrece un resumen del proceso general que se usará en el desarrollo del ejemplo y las herramientas utilizadas para generar los artefactos.

Tabla 1. Roles, tareas y herramientas del proceso de desarrollo
RolTareaHerramientas
Ejecutivo de negociosTransmitir las metas y objetivos de negociosIBM® Rational® Requirements Composer
Analista de negociosAnalizar los requisitos de negociosIBM Rational Requirements Composer
Arquitecto de softwareDiseñar la arquitecturaIBM Rational Software Architect
Desarrollador de servicios webImplementar la soluciónIBM® Rational® Application Developer
Integración de servicios webImplementar un servicio webIBM WebSphere Integration Developer

Comencemos por revisar los servicios y los participantes de servicio que se crearon en el artículo "Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios, parte 1: Identificación de servicios" (ver "Más de esta serie ").

Especificación y realización de servicios

La figura 1 ofrece una visión general del ejemplo completo. El paquete ordermanagement contiene los principales elementos del modelo: la ServiceInterface "Purchasing" y los participantes "OrderProcessor" y "Manufacturer". El paquete ordermanagement importa elementos de modelo desde otros paquetes. El paquete de gestión de relaciones con el cliente (CRM) incluye el modelo de datos de dominio que define las entidades persistentes usadas para implementar los servicios, así como los datos de servicio MessageTypes usados para intercambiar información entre los participantes de servicio. Los datos de servicio son esencialmente una vista (selección y proyección) de los datos de dominio que apunta a satisfacer las necesidades de los servicios específicos.

Los paquetes credit (crédito), productions (producciones) y shipping (envío) definen los participantes Invoicer (Facturador), Productions (Producciones) y Shipper (Expedidor), respectivamente, así como sus interfaces de servicio proporcionadas. OrderProcessor es otro participante que ofrece un servicio de compras y utiliza servicios de facturación, planificación y envío.

El participante Manufacturer (Fabricante) es un ensamblado de referencias de instancias de otros participantes que se conectan en una cadena de valor de servicios. Es decir, las solicitudes de orderProcessor son cumplidas por las siguientes partes: invoicer, productions y shipper. Las interacciones de servicios, los eventos y los intercambios de datos tienen lugar en los canales que conectan las partes participantes. El participante Manufacturer también presta un servicio de compras, pero lo hace delegando en su parte interna orderProcessor. Todas las operaciones de servicio tienen métodos que indican cómo se llevan a cabo los servicios y cómo se usan los servicios consumidos.

Asimismo, el participante Manufacturer se ajusta a la arquitectura de servicio Process Purchase Order, definida en el primer artículo de esta serie, "Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios, parte 1: Identificación de servicios". Las partes del participante Manufacturer están enlazadas con los roles desempeñados en la arquitectura de servicio de manera de mostrar cómo se sigue y cómo se instancia el patrón arquitectónico. Esto garantiza que la solución se ajuste a los principios rectores de la arquitectura empresarial y proporciona rastreabilidad entre las partes de la arquitectura y las partes de la solución.

Figura 1. Procesamiento de pedidos de compra: esquema global
Procesamiento de pedidos de compra: esquema global
Procesamiento de pedidos de compra: esquema global

Mejores prácticas del modelado de servicios

El modelado UML 2 nos ayuda a comprender mejor los sistemas subyacentes al eliminar los detalles superfluos. Sin embargo, el modelado no es una panacea, y pueden ser necesarios conocimientos especializados para poder crear y comprender un diagrama de modelo significativo. Esta es una consecuencia natural de la necesidad de dar soporte a un modelo muy general de computación que se puede usar en una amplia gama de dominios de aplicación y de niveles de abstracción; además, representa la semántica de ciertos modelos de ejecución específicos de la plataforma. Asimismo, puede ser necesario restringir los tipos de acciones o estilos de modelos de actividad para permitir una transformación eficaz de esos modelos en la plataforma de ejecución de destino.

En este caso, la plataforma de destino consiste en servicios web implementados con el modelo de programación SOA de IBM y soportados por WebSphere Integration Developer. Aquí se incluyen objetos de negocios (XSD), interfaces (WSDL), ensamblados de módulo (SCDL, un predecesor de Open SCA de IBM, también conocido como "Classic SCA"), procesos (BPEL4WS: Business Process Execution Language for Web Services) y componentes de Java™. Para soportar transformaciones de modelos UML en esta plataforma de servicios web específica, es necesario seguir las mejores prácticas del modelado de servicios. Comenzamos por extender el UML al perfil estándar SoaML de Object Management Group (OMG) para modelar una arquitectura de solución SOA y luego usamos un estilo de modelado en particular para producir modelos que se puedan convertir en servicios web.

Por lo general, UML se personaliza usando perfiles. Un perfil define un número de clases de estereotipos que pueden extender una o más metaclases de UML con propiedades y relaciones adicionales. Para que estas extensiones se encuentren disponibles, los perfiles se aplican a los modelos UML. Estos perfiles aplicados suelen soportar dos propósitos en arquitecturas basadas en modelos:

  • El primer propósito de los perfiles, y el más general, consiste en personalizar las abstracciones que se busca soportar. En este caso, se aplicó el perfil SoaML de OMG al modelo Purchase Order Process para extender el UML a fin de soportar el modelado de servicios. Muchos de los estereotipos de ese perfil simplemente aclaran cómo se usan las metaclases UML para modelar una solución SOA y restringir las cosas que se pueden hacer en UML a fin de garantizar que los modelos SOA reflejen los principios SOA. Por ejemplo, el estereotipo <<Participant>> se usa para identificar un componente UML que modela un consumidor o proveedor de servicios. En un ejemplo de restricción, SoaML requiere que todas las interfaces realizadas o usadas por un componente <<Participant>> se manipulen, no directamente, sino a través de puertos de servicio y de solicitud (puertos UML). Lo que se busca es reducir el acoplamiento entre los consumidores y proveedores conectados creando dependencias en los puertos, no en todo el componente. Por eso, cuando una interfaz cambia, solamente será necesario examinar ese puerto para responder al cambio, y no todo aquello que esté conectado al componente.
  • El segundo propósito de los perfiles en una arquitectura basada en modelos (MDA) consiste en soportar marcas específicas de la plataforma. Estas marcas son estereotipos y propiedades que marcan un modelo con información necesaria para convertir ese modelo en una determinada plataforma. Por ejemplo, puede ser necesario que un paquete UML cuente con un identificador uniforme de recursos (URI) al momento de convertirlo en un contenedor de servicios web.

Algunas veces, estos dos propósitos se combinan. Por ejemplo, las extensiones de UML para soportar el modelado de datos relacionales consisten en un único perfil que extiende UML al modelado de datos de atributos relacionales de entidades (ERA) y que además proporciona las marcas necesarias para convertir los modelos de dominio UML en modelos de datos lógicos de IBM® Info Sphere® Data Architect (Lames).

En otros casos, es posible usar un perfil para soportar el modelado y otro para impulsar la conversión. Por ejemplo, tomemos el caso de un modelado de diseños SOA que serán implementados en Java™ Platform, Enterprise Edition (JEE). Es posible ayudar a esta última aplicación aplicando tanto el perfil SoaML como el perfil de transformación Enterprise JavaBeans™ (EJB) al mismo modelo. Los estereotipos del perfil SoaML se aplicarían a los elementos del modelo para dar soporte al modelado de servicios, mientras que los estereotipos del perfil de transformación EJB se aplicarían a los elementos del modelo para guiar la ejecución de la transformación de UML a EJB de Rational Software Architect a medida que genera el código de implementación. Por supuesto que sería posible convertir el mismo modelo SOA a servicios web usando la transformación de UML a SOA de Rational Software Architect. La transformación de UML a SOA generaría servicios web a partir del marcado del perfil SoaML. Ignoraría las marcas de la transformación EJB.

En las siguientes secciones se describen algunas de las mejores prácticas de modelado para los modelos SOA que se pretende convertir en servicios web, particularmente, en servicios web implementados en el Modelo de programación SOA de IBM® y soportados por WebSphere Integration Developer.

Modelado de datos

El tipo de parámetro de una operación de servicio debería ser UML Primitive Type, DataType o SoaML <<MessageType>> DataType. El modelador no debe hacer suposiciones respecto de la ubicación de los datos, de la semántica de llamada por valor o de llamada por referencia ni de las instalaciones de gestión de concurrencia implícita. Debe suponer que las implementaciones del servicio funcionan en una copia transitoria de los datos que pueden haber sido transferidos, transformados, o ambas cosas, a partir de su fuente original. Esto asegura un acoplamiento de datos mínimo entre los consumidores y los proveedores del servicio.

SoaML soporta parámetros del estilo llamada a procedimiento remoto (RPC) y del estilo centrado en el documento para las operaciones de servicio. El estilo RPC soporta múltiples parámetros de entrada y de salida. El estilo centrado en el documento permite, como máximo, una entrada y una salida. Use parámetros SoaML MessageType para indicar el estilo centrado en el documento.

Modelado de servicios

Como se especifica en el perfil SoaML, los participantes del servicio deben realizar o usar todas las interfaces a través de puertos de servicio, pero nunca directamente. Esto asegura un desacoplamiento adecuado entre los participantes del servicio conectados al componente.

Modelado de actividades

Un proveedor de servicios concreto modela los métodos de sus operaciones de servicio proporcionando un comportamiento para cada operación.

Nota:
Un proveedor de servicios concreto es un componente que no es abstracto ni tampoco un componente <<specification>>.

Se puede usar cualquier comportamiento, pero si la plataforma de destino del modelo consiste en servicios web, es conveniente utilizar una actividad que se pueda convertir fácilmente en BPEL4WS. Por ejemplo, el modelo de actividad del componente del proveedor de servicios Order Processor es el método de la operación processPurchaseOrder. Hay ciertos datos acerca de esta actividad que requieren una mayor explicación:

  • La firma de un comportamiento de método debe coincidir con su operación de especificación.
  • Las clavijas de entrada y de salida de las acciones se ordenan comenzando por el ángulo inferior derecho de la acción contenedora y siguiendo en sentido de las agujas del reloj hacia el lado inferior derecho. Este orden de las clavijas se corresponde con el orden de los parámetros de la operación llamada; la clavija de entrada de destino es la primera clavija y el tipo de operación (si corresponde) es la última clavija de salida correspondiente al resultado devuelto. La clavija de entrada de destino representa el objeto de destino al que se envía la solicitud de acción (por ejemplo, el clasificador propietario de la operación).
  • Por lo general, los tipos de clavijas de entrada y de salida no están establecidos, ya que es posible derivarlos del parámetro correspondiente.
  • Esta actividad no usa flujos de objetos para simplificar la creación del diagrama. Por el contrario, los nombres de las clavijas de entrada y de salida de las acciones son etiquetadas por un parámetro, variable o característica estructural en el clasificador de contexto (la clase propietaria de la actividad) dentro del ámbito. Como UML 2 soporta cualquiera de ellos, la decisión respecto de cuál usar es una cuestión de preferencia.
  • Los nodos de parámetros de actividad (en los bordes izquierdo y derecho de la actividad) no se usan. Por el contrario, se hace referencia a los parámetros de la actividad (que deben corresponderse con los parámetros de la operación específica) directamente en las clavijas de entrada y de salida cuando fuera necesario. Estos nodos de parámetros de actividad serían usados si se emplearan flujos de objetos.
  • Las particiones de la actividad se establecen para representar los puertos de servicio o las partes del componente que contengan la actividad. Todas las invocaciones se hacen y todos los eventos se aceptan por medio de estas partes. En este caso, las particiones no tienen nombre, ya que la propiedad representada ofrece suficiente información para su identificación.
  • No es necesario establecer las clavijas de entrada de destino de las acciones de la operación de llamada. De modo alternativo, la partición de la actividad representa el puerto de servicio donde se invocan las llamadas de esa partición. Se llaman particiones <<instance>> en UML 2 y tienen una semántica bien definida. Es posible establecer las clavijas de entrada de destino, pero sería redundante.
  • La clavija returnInformation de las acciones Accept Call (Aceptar llamada) se manipula igual que la clavija de entrada de destino de una acción de la operación de llamada. Es además el puerto representado por la partición de la actividad y representa el punto de interacción a través del cual se aceptará la llamada.
  • Las expresiones de asignación se muestran con acciones opacas, en las que el nombre de la acción contiene una expresión de asignación que hace referencia a variables, parámetros y características estructurales dentro del ámbito. El lvalue y el rvalue de la instrucción de asignación están separados por dos puntos y un igual (:=).
  • Las expresiones de protección en flujos de objetos y de control son expresiones booleanas de Java o XPath que hacen referencia a variables, parámetros y características estructurales dentro del ámbito de la actividad.
    • Se hace referencia a losdatosde un flujo de objetos a través del nombre del flujo.
    • Eltipode los datos de un flujo de objetos está determinado por su origen.

Estas convenciones se usan para simplificar el modelado de actividades y los diagramas de actividad y a efectos de una mejor correspondencia con el BPEL que se generará a partir de ellos.

Conversión a servicios web

Las transformaciones requieren el uso de una configuración de transformación.

Configuración de la transformación

Es posible crear una transformación seleccionando File (Archivo) > New (Nuevo) > Other (Más) > Transform Configuration (Configuración de transformación) (ver figura 2).

Figura 2. Creación de una nueva configuración de transformación
Creación de una nueva configuración de transformación
Creación de una nueva configuración de transformación

En este ejemplo se usará una transformación de UML a SOA, como se puede ver en la figura 3.

Figura 3. Selección de la transformación de UML a SOA
Selección de la transformación de UML a SOA
Selección de la transformación de UML a SOA

La configuración de la mayoría de las transformaciones consta de tres partes básicas:

  1. Selección de los elementos de origen de la transformación
  2. Selección (o creación y posterior selección) de los elementos de destino
  3. Configuración de las propiedades de la transformación

Los elementos de origen permitidos estarán definidos por la transformación que se seleccione. Por lo general, es mejor transformar únicamente modelos completos antes que partes aisladas de modelos. De esta forma se garantiza que los modelos, que representan recursos individuales con versiones, sean considerados unidades de compilación respecto de la transformación del modelo. Así se simplifica la gestión del modelo y el tratamiento de dependencias de transformación, garantizando que los cambios en los recursos del área de trabajo se correspondan con los deltas de generador y de transformación que se deban procesar para asegurar la sincronización de los artefactos derivados con sus elementos de origen. Por ejemplo, a nadie se le ocurriría seleccionar un método específico en una clase Java, compilar únicamente ese método y luego insertarlo en los códigos de bytes del resto de la clase. Esto sería imposible de gestionar en un entorno tan cambiante, y sería usted, no los generadores ni los compiladores, quien debe conocer todas las dependencias que habría que compilar como consecuencia del cambio.

En este ejemplo, el modelo PurchaseOrderProcess es el origen y el área de trabajo se selecciona como destino. Todos los elementos del modelo convertido se colocan en nuevos proyectos de WebSphere Integration Developer (figura 4).

Figura 4. Configuración de orígenes y destinos de la transformación
Configuración de orígenes y destinos de la transformación
Configuración de orígenes y destinos de la transformación

Haga clic para ver una versión ampliada de la figura 4.

Los parámetros de configuración de la transformación representan opciones que no están incluidas en las marcas del modelo. Por lo general, se usan para controlar opciones generales en vez de opciones que se aplican a un elemento particular del modelo. La transformación de UML a SOA tiene pocas opciones de transformación, como se puede ver en la figura 5.

Figura 5. Configuración de propiedades de la transformación
Configuración de propiedades de la transformación
Configuración de propiedades de la transformación

Process UML elements without stereotypes (Procesar elementos UML sin estereotipos) con un valor True significa que el perfil SoaML es, en realidad, opcional. Los tipos de datos, los componentes y las actividades se convierten a la solución de servicios web sin requerir ningún estereotipo, o es posible que los estereotipos queden excluidos de determinados elementos del modelo que no necesitan sus propiedades adicionales. Sin embargo, es una buena práctica de modelado aplicar los estereotipos SoaML para simplificar el modelo de servicios.

Así se completa la configuración de la transformación del modelo PurchaseOrderProcess en una solución de servicios web. Los proyectos se colocarán en el área de trabajo.

Ejecución de la transformación

La ejecución de la transformación PurchaseOrderProcess2WebServices es muy sencilla:

  1. Seleccione el archivo de configuración de la transformación PurchaseOrderProcess2WebServices.tc que se creó en la sección anterior.
  2. En el menú emergente, seleccione Transform (Transformar) > UML to SOA (UML a SOA).

Así se ejecutará la transformación seleccionada en la configuración de transformación, transformando el modelo de origen en los artefactos de servicios web y colocando los proyectos WebSphere Integration Developer resultantes en el área de trabajo. De esta manera será posible iniciar WebSphere Integration Developer e importar estos proyectos existentes al área de trabajo de WebSphere Integration Developer workspace para completar, implementar y probar los resultados.

Sugerencia:
Si el modelo cambia, será necesario volver a ejecutar la transformación.

Los resultados de la transformación se pueden ver en la figura 6 a través de la perspectiva Modeling (Modelado) en Project Explorer.

Figura 6. Resultados de la transformación
Resultados de la transformación
Resultados de la transformación

Examen del resultado

La configuración de la transformación de UML a SOA coloca los elementos resultantes en una serie de proyectos Eclipse. Estos proyectos pueden ser proyectos de biblioteca o de módulo de WebSphere Integration Developer, como se describe en las siguientes subsecciones.

  • Los proyectos de biblioteca contienen los objetos de negocios, las interfaces y las exportaciones de módulos que se comparten con otros proyectos.
  • Los proyectos de módulo contienen una implementación de módulos para cada participante del modelo de servicios UML.

Es posible importar estos proyectos al área de trabajo de WebSphere Integration Developer.

Sugerencia:
Para acelerar las importaciones, puede ser útil desactivar Automatic Build (Compilación automática) hasta que todos los proyectos hayan sido importados.

Modelo y bibliotecas

Cada modelo del origen seleccionado en la configuración de transformación se convierte en una biblioteca de WebSphere Integration Developer con el mismo nombre que el modelo. Esta biblioteca contiene un elemento XSD para cada tipo de datos y clase de los modelos de origen y una definición WSDL para cada interfaz UML. Estas bibliotecas definen los objetos de negocios y las interfaces usados por todos los módulos de WebSphere generados a partir de los componentes en el origen seleccionado de la configuración de transformación.

La figura 7 muestra los proyectos importados de biblioteca y de módulo generados en WebSphere Integration Developer; se ha expandido PurchaseOrderProcess para mostrar los objetos de negocios e interfaces generados. Observe que las carpetas y el espacio de nombres en WebSphere se corresponden directamente con la estructura de paquetes en el modelo de servicios UML. Esto garantiza una gestión de espacios de nombres consistente y un soporte de reutilización en todos los recursos y herramientas.

Figura 7. Biblioteca ProcessPurchaseOrder y sus interfaces y objetos de negocios
Biblioteca ProcessPurchaseOrder y sus interfaces y objetos de negocios
Biblioteca ProcessPurchaseOrder y sus interfaces y objetos de negocios

Observemos los objetos de negocios e interfaces más detenidamente y comparémoslos con sus elementos de origen UML. En la figura 8 se puede ver el editor de objetos de negocios de WebSphere Integration Developer abierto en el objeto PurchaseOrder para mostrar los XSD generados a partir del modelo de datos de servicio creado en el artículo "Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios, parte 3: Realización de servicios". Como se puede ver, los XSD guardan una estrecha correspondencia con sus tipos de datos de origen. Haga clic en la figura para ver el origen generado.

Figura 8. XSD generados a partir del modelo de datos de servicio
XSD generados a partir del modelo de datos de servicio
XSD generados a partir del modelo de datos de servicio

Cada interfaz UML es transformada en un elemento WSDL portType. El WSDL generado para la interfaz Invoicing de la figura 8 se puede ver en la figura 9. Haga clic en la figura para ver el origen WSDL generado. Una vez más, la apariencia del WSDL es muy similar a la interfaz UML.

Figura 9. WSDL generado para la interfaz Invoicing
WSDL generado para la interfaz Invoicing
WSDL generado para la interfaz Invoicing

Componentes y ensamblados de módulo

Cada uno de los componentes del proveedor de servicios del modelo de servicios UML se transforma en un módulo de WebSphere Integration Developer. Todavía no existe un estándar de servicios web para ensamblar consumidores (a veces llamados usuarios) y proveedores de servicios. Por eso, WebSphere Integration Developer usa su propia versión embrionaria de la Arquitectura de componentes de servicio (SCA). Los ensamblados de módulo son capturados en archivos .component que usan el lenguaje de descripción de componentes de servicio (SCDL), un lenguaje de documentos XML para ensamblados de componentes de servicio. En la actualidad hay diversas empresas que están colaborando para crear un estándar para SCA. Si desea obtener más información, visite el sitio Web de Open SOA.

La transformación de UML a SOA crea módulos de WebSphere Integration Developer para cada participante a fin de maximizar la reutilización. Los módulos SCA no se pueden ensamblar a partir de otros módulos. Sin embargo, pueden importar servicios de otros módulos y usarlos indirectamente. Por lo tanto, las conexiones entre los participantes de UML se implementan como enlaces entre importaciones y exportaciones de módulos en WebSphere Integration Developer. Por ejemplo, observe el proveedor de servicios Invoicer que se puede ver en la figura 1.

La figura 10 muestra el correspondiente ensamblado de módulo de WebSphere Integration Developer. Se crean importaciones y exportaciones de módulos para cada puerto de servicio y de solicitud. Como SCA no puede soportar interfaces proporcionadas y requeridas para el mismo punto de interacción, se crean elementos de importación y de exportación separados para los puertos de servicio y de solicitud que proporcionan y requieren interfaces. El servicio invoicingExport exporta la interfaz proporcionada, mientras que invoicingImport importa la interfaz InvoiceProcessing requerida del puerto de servicio invoicing del proveedor de servicios Invoicer.

Figura 10. Ensamblado de módulo Invoicer
Ensamblado de módulo Invoicer
Ensamblado de módulo Invoicer

Observe el nombre del módulo. Un módulo es un proyecto Eclipse, pero como también es un elemento reutilizable, debe gestionar las colisiones de nombres como cualquier otro elemento de este tipo. La convención usada por la transformación de UML a SOA consiste en crear nombres de proyectos de módulo basándose en el nombre completo del componente del proveedor de servicios, según su paquete contenedor. Esto genera largos nombres de módulo que pueden causar ciertos problemas de tiempo de ejecución en las plataformas Windows debido a las restricciones en la longitud de las URL. Es muy fácil refactorizar estos nombres y crear nombres más cortos siempre y cuando los conflictos de nombres se gestionen adecuadamente en el contexto en el cual se reutilizan.

El componente Productions da lugar a otro ensamblado de módulo, que se puede ver en la figura 11. Este módulo no tiene importación, ya que el puerto de servicio no requiere ninguna interfaz.

Figura 11. Ensamblado de módulo Productions
Ensamblado de módulo Productions
Ensamblado de módulo Productions

Ambos módulos usan un proceso BPEL para implementar los servicios proporcionados por sus correspondientes componentes del proveedor de servicios. En la siguiente sección se muestran los detalles de este funcionamiento.

En la figura 12 podrá observar el ensamblado de módulo creado para el componente OrderProcessor.

Figure 12. Ensamblado de módulo OrderProcessor
Figure 12. Ensamblado de módulo OrderProcessor
Figure 12. Ensamblado de módulo OrderProcessor

El proveedor de servicios OrderProcessor presta un servicio de compras y ha solicitado servicios de facturación, planificación y envío. Los canales de servicio que conectan los componentes de consumidor y de proveedor en la figura 1 se implementan como importaciones en el módulo OrderProcessor enlazadas con las exportaciones de los correspondientes proveedores de servicios. Esto permite una reutilización de módulos eficaz en WebSphere Integration Developer y mantiene los modelos de servicios UML independientes de la evolución de SCA. Cuando la SCA se estandarice, no será necesario que los modelos de servicios UML cambien; solamente se deberá actualizar la transformación.

Actividades y procesos BPEL

Cada capacidad (operación) funcional proporcionada por un proveedor de servicios debe ser implementada de alguna manera u otra. Las implementaciones son diseñadas en UML usando un comportamiento de método para cada operación o bien acciones Accept Call en algún otro comportamiento. Este último método ofrece un desacoplamiento adicional entre consumidores y proveedores permitiendo al proveedor determinar cuándo es capaz y está dispuesto a responder a una solicitud en vez de estar obligado a responder inmediatamente cuando la operación es invocada por el consumidor del servicio.

La SCA de WebSphere Integration Developer adopta un enfoque diferente. Cada exportación debe estar conectada a un componente del ensamblado que proporcione una implementación para las operaciones de esa interfaz. Los componentes en SCA tienen diferentes tipos de implementación:

  • Tarea humana
  • Java
  • Proceso
  • Grupo de reglas
  • Máquina de estado

El proveedor de servicios de la figura 12 ofrece una única capacidad funcional, a través de su servicio de compras, de procesar un pedido de compra. La implementación de esta operación es una actividad en el modelo de servicios UML. La transformación de UML a SOA crea un proceso BPEL a partir de esa actividad y lo usa como la implementación de la operación exportada.

El proceso BPEL de la figura 13 es muy similar a la actividad processPurchaseOrder del participante OrderProcessor. En la sección Help (Ayuda) de Rational Software Architect encontrará detalles sobre la manera en que la actividad UML se transforma en un proceso BPEL.

Figura 13. Implementación de componentes del proceso OrderProcessor
Implementación de componentes del proceso OrderProcessor
Implementación de componentes del proceso OrderProcessor

Haga clic para ver una versión ampliada de la figura 13.

Desacoplamiento de interfaces e implementaciones

Como ya se describió, la SCA de WebSphere Integration Developer implementa las capacidades proporcionadas conectando una exportación, lo cual proporciona las interfaces con un componente que implementa las operaciones proporcionadas. Como el componente tiene un tipo de implementación, todas las operaciones proporcionadas por todas las interfaces de esa exportación deben ser implementadas de la misma manera. Así se acopla el tipo de implementación a todas las interfaces de una exportación (una exportación puede ser conectada con un solo componente e implementada por un solo componente). Si el desarrollador desea cambiar el tipo de implementación de una determinada operación (por ejemplo, de una tarea humana a un servicio automatizado implementado en Java), las interfaces deben ser refactorizadas para permitir que las diferentes exportaciones se conecten con los diferentes tipos de implementación de componentes. Esto, a su vez, requeriría cambios en todos los consumidores de esas interfaces. Este acoplamiento entre diseño de interfaz y tipo de implementación podría inhibir la propia agilidad de negocios que se las soluciones SOA pretenden soportar.

UML no tiene este acoplamiento de especificación e implementación. Cada operación proporcionada puede tener un comportamiento de método que sea una actividad, una interacción, una máquina de estado o un comportamiento opaco (código). El modelador diseña la implementación de cada operación de forma independiente. Esto puede generar situaciones en que el mismo proveedor de servicios use diferentes tipos de comportamiento para diferentes operaciones proporcionadas a través de la misma interfaz. Es necesaria una manera de convertir estos proveedores de servicios en servicios web.

Existe otro factor que hay que tener en cuenta. En UML, se crean instancias de los componentes, y no de los comportamientos que poseen. Por lo tanto, la identificación y la duración de las instancias son iguales para todos los comportamientos del mismo componente. Además, el componente establece un contexto o ámbito para todos los comportamientos que posee, permitiendo que esos comportamientos compartan acceso al estado del componente (propiedades y puertos). Así, en la conversión a servicios web, es necesaria una forma de gestionar esta identidad, duración y estado compartido en la que se pueda implementar la semántica UML. Este es el momento en que entran en juego los procesos del lenguaje de ejecución de procesos de negocios (BPEL) (para obtener más información acerca de BPEL, ver Recursos ).

En vez de crear un componente SCA que implemente cada comportamiento de un participante en el ensamblado de módulo, se crea un único proceso BPEL que se corresponda con el propio componente. Observe que el nombre del proceso BPEL en la figura 13 es OrderProcessor, el mismo que el proveedor de servicios OrderProcessor, y no processPurchaseOrder, el nombre de la operación proporcionada.

Observemos la figura 14 más detenidamente para analizar de qué manera el componente Productions se convierte en servicios de WebSphere Integration Developer Web.

Figura 14. Participante Productions
Participante Productions
Participante Productions

Observe que el diseño de implementación de requestProductionScheduling usa una Activity (Actividad) (los detalles no se muestran), pero sendShippingSchedule usa un OpaqueBehavior con la implementación proporcionada en el código Java. El ensamblado de módulo de este proveedor de servicios se puede ver en la figura 15.

Figura 15. Implementación del proveedor de servicios Productions
Implementación del proveedor de servicios Productions
Implementación del proveedor de servicios Productions

Se crea un proceso BPEL para el componente del proveedor de servicios Productions. Las propiedades de identidad del proveedor de servicios se usan para definir la correlación de todas las actividades Invoke (Invocar), Receive (Recibir) y Reply (Responder) en este proceso. Cada operación proporcionada por el componente es implementada por un fragmento del proceso. El proceso se inicia con un elemento de selección que se utiliza para despachar cada solicitud de operación. Luego se crea un ámbito para cada operación a fin de proporcionar una ubicación para las variables definidas en el comportamiento UML. El ámbito contiene el resultado del comportamiento convertido. Si el comportamiento es una actividad UML, el ámbito contendrá el BPEL generado a partir de esa actividad. A su vez, si el comportamiento es un OpaqueBehavior con lenguaje Java, el cuerpo del comportamiento se copiará en una actividad de fragmentos de código Java dentro del ámbito. Por último, si el comportamiento es un OpaqueBehavior con lenguaje HTML o JavaServer™ Pages (JSP), se agregaría al ámbito una actividad de tarea humana.

De esta forma se proporciona un desacoplamiento completo de las interfaces y sus implementaciones. Por ejemplo, si el modelador o el desarrollador decidieran cambiar la implementación de una operación de servicio de una tarea humana en un servicio Java automatizado, solamente sería necesario cambiar el elemento de tarea humana en el ámbito. Los clientes detectarían el cambio operado en la implementación únicamente cuando perciban que el servicio se ejecuta más rápidamente y que el trabajo no es tanto.

Finalización de la solución

La transformación de UML a SOA no genera soluciones completas (todavía). Esto se debe a que el esfuerzo para colocar el detalle de implementación en los modelos sería mayor que ponerlo en los artefactos específicos de la plataforma usando editores creados a tal efecto. Además, existen ciertas características de UML 2 Activities que todavía no han sido convertidas a BPEL, pero que se agregarán en versiones futuras. Los detalles acerca de qué se soporta en una versión determinada están disponibles en Help (Ayuda) de Rational Software Architect.

Por lo general, WebSphere Integration Developer tendrá que realizar algunas de las siguientes actividades de desarrollo (o todas).

  1. Agregar el código Java en los comportamientos opacos si no fue proporcionado en el modelo. Incluso si el código Java está presente en el cuerpo del comportamiento opaco, es propenso a contener errores, porque la característica Content Assist (Asistencia de contenido) y la compilación de Java (o un lenguaje de acción) todavía no están integradas en las capacidades de modelado de Rational Software Architect.
  2. Agregar correlación en los procesos de negocios. La correlación especifica la información necesaria para identificar las instancias de un componente. Todavía no está soportada en la transformación de UML a SOA, pero se agregará en una futura versión.
  3. Crear una interfaz de usuario (UI) para las tareas humanas. Es posible que el modelador de UML haya incluido JSP o HTML en el cuerpo de un comportamiento opaco. Sin embargo, como en el caso del código fuente de Java, esto puede estar incompleto o ser incorrecto. Tal vez el desarrollador de integración opte por usar el editor de tareas humanas, el diseñador de páginas, el portal u otras herramientas para crear tareas humanas completas con el aspecto adecuado para completar la UI de la aplicación.
  4. Configurar el modelo de supervisión. Actualmente, la transformación de UML a SOA no crea ninguna información de supervisión para evaluar indicadores clave de rendimiento (KPI) de negocios que puedan haber sido modelados como restricciones en servicios o en proveedores de servicios. El desarrollador de integración puede usar la herramienta Monitor Model Editor en WebSphere Integration Developer para configurar los datos que se deben recopilar para las actualizaciones de simulación y para las mediciones y métricas de negocios.

Resumen de la serie

De esta manera concluye la serie de servicios de modelado en Rational Software Architect a través del perfil de IBM Software Services (ver "Más de esta serie " para consultar los cuatro artículos anteriores). En el primer artículo, Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios, parte 1: Identificación de servicios se analizó cómo usar modelos de procesos de negocios y arquitecturas de servicios para especificar los requisitos para conectar y coreografiar un conjunto de servicios a fin de alcanzar ciertos objetivos. Por lo general, estos requisitos se usan para especificar qué es lo que se debe realizar para alcanzar objetivos de negocios. Las arquitecturas de servicio pueden ser útiles para identificar servicios que generen un valor de negocios real.

Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios, parte 2: Especificación de servicios demostró cómo modelar los detalles de las interfaces de servicio. Una interfaz de servicio define la información necesaria para que los potenciales consumidores determinen si un determinado servicio es aplicable a sus problemas y, si esto es así, la manera de usarlo. También define todo aquello que debe hacer un proveedor de servicios para implementar el servicio.

En los siguientes artículos, la parte 3: Realización de servicios y la parte 4: Composición de servicios, se mostró la forma de diseñar y modelar participantes que presta o requiere servicios y la forma de implementar las operaciones de servicio. Asimismo se describió cómo los proveedores de servicios indican las arquitecturas y los contratos de servicio que cumplen para vincular a los proveedores de servicios con las metas, objetivos y procesos de negocios, así como con los requisitos y los principios rectores de la arquitectura.

Este último artículo se describió cómo implementar los servicios en una plataforma de servicios web soportada por IBM WebSphere Integration Developer usando la transformación de UML a SOA de IBM. WebSphere Integration Developer soporta un modelo de programación SOA consistente con los diseños de identificación, especificación y realización de servicios capturados en Rational Software Architect. Con WebSphere Integration Developer, es posible completar la programación de los servicios, generar una UI para las tareas humanas, e implementar y probar la aplicación.


Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=479815
ArticleTitle=Modelado con SoaML, el lenguaje de modelado de arquitectura orientada a servicios: Parte 5. Implementación de servicios
publish-date=07292011