Modelado de SOA: Parte 1. Identificación del servicio

Este artículo es el primero de una serie de cinco sobre el desarrollo de software basado en la arquitectura orientada a servicios (SOA). El mismo muestra cómo usar los modelos UML ampliados con IBM® Software Service Profile para el diseño de una solución SOA que se conecte con los requerimientos de negocios y sea al mismo tiempo independiente de la implementación de la solución. El autor describe las metas y los objetivos de negocios así como los procesos implementados para cumplir con dichos objetivos, y luego explica la manera en que se deben usar los procesos para identificar los servicios de relevancia para el negocio que resulten necesarios para cumplir con los requerimientos que representan.

Jim Amsden, Senior Technical Staff Member, IBM

Jim AmsdenJim Amsden, miembro senior del personal técnico de IBM, tiene más de 20 años de experiencia en el diseño y desarrollo de aplicaciones y herramientas para la industria del desarrollo de software. Posee una Maestría en Ciencias de la Computación de la Universidad de Boston. Entre sus intereses se encuentran la arquitectura empresarial, el desarrollo basado en contratos, el desarrollo impulsado por contratos, la programación de agentes, el desarrollo impulsado por negocios, Java Enterprise Edition, UML, y la arquitectura orientada a servicios. Es coautor de =Enterprise Java Programming with IBM WebSphere [Programación de Java para empresas con IBM WebSphere] (IBM Press, 2003) y del estándar SoaML de OMG. Actualmente está dedicado a encontrar formas de integrar las herramientas con el fin de brindar un mejor soporte a procesos de desarrollo ágiles. Hoy Jim es responsable del desarrollo de la estrategia y las herramientas de soporte para la Gestión de Arquitectura Colaborativa del software IBM Rational.



29-07-2011

De qué manera el modelado mejora a SOA

El poder de una SOA reside en su capacidad para brindar agilidad al negocio a través de la integración y la reutilización de los procesos de negocios. SOA logra este objetivo de dos maneras: alentando soluciones organizadas en torno a servicios reutilizables que encapsulan capacidades funcionales independientemente de su implementación y brindando facilidades para gestionar el acoplamiento de las capacidades funcionales. El modelado puede server para cerrar la brecha que existe entre los requerimientos de negocios y la solución basada en servicios implementada. Los modelos de SOA eleven el nivel de abstracción para permitirle centrarse en los servicios de negocios. Se pueden usar enfoques de desarrollo impulsados por modelos para generar implementaciones de SOA, usando plataformas como por ejemplo Java™ 2 Platform, Enterprise Edition (J2EE) o IBM® CICS® que cumplen con objetivos funcionales y no funcionales al tiempo que permiten la agilidad de negocios.

El término Arquitectura Orientada a Servicios (SOA por su sigla en inglés) posee diversas connotaciones. Los profesionales a menudo usan SOA tanto para definir un estilo arquitectónico como para describir una infraestructura de TI común que habilita el funcionamiento de los sistemas de TI que se construyen usando ese estilo arquitectónico. Estas son útiles perspectivas centradas en la tecnología, pero en sí mismas, no resultan suficientes.

Para alcanzar su potencial, una infraestructura de TI basada en SOA (de aquí en más, denominada simplemente SOA) debe ser relevante para el negocio, y por ende impulsada por el negocio e implementada para brindar soporte al negocio. Necesitamos un modo para diseñar soluciones SOA que se conecten a los requerimientos de negocios que cumplen. Esto resulta difícil si los requerimientos de negocios son una simple lista de requerimientos y el nivel de abstracción de SOA se captura en numerosos documentos XML que describen una colección de servicios web.

Lo que necesitamos es una manera de formalizar los requerimientos de negocios y de elevar el nivel de abstracción de manera que SOA pueda asemejarse más a los servicios de negocios y al modo en que estos servicios pueden cumplir con las metas y los objetivos del mismo. Esto liga a la solución implementada con su valor de negocios esperado. Al mismo tiempo, necesitamos un modo de aislar los asuntos de negocios de las plataformas SOA en desarrollo que los soportan.

El modelado y el desarrollo impulsado por modelos (model-driven development - MDD) puede ayudar a alcanzar estas metas. Los modelos nos permiten abstraernos de los detalles de la implementación y centrarnos en las cuestiones que impulsan las decisiones sobre arquitectura. En alguna medida, el enfoque que describiremos aplica uno de los principios fundamentales de SOA al desarrollo de soluciones SOA: separación de asuntos y acoplamiento holgad. En este caso, separamos claramente las tareas y responsabilidades de los analistas de negocios de aquellas de los miembros del personal de TI.

Por lo general, los analistas de negocios se centrarán en los requerimientos de negocios organizacionales y operacionales necesarios para cumplir con las metas y los objetivos de negocios que alcanzan cierta visión comercial. A menudo, no se preocupan (ni están suficientemente capacitados para ocuparse de ellos) por asuntos de TI tales como reutilización, cohesión y acoplamiento, distribución, seguridad, persistencia, integridad de datos, concurrencia, recuperación ante fallas, etc. Más aún, las herramientas de modelado de procesos de negocios no suelen contar con las capacidades necesarias para ocuparse de estos asuntos, y si las tuvieran, probablemente no resultarían herramientas eficientes para los analistas de negocios.

Acerca de esta serie sobre modelado de SOA

Esta serie de artículos muestra cómo usar los modelos de UML ampliados con el IBM® Software Service Profile para el diseño de una solución SOA que esté conectada con los requerimientos de negocios, y aún así sea independiente de la implementación de la solución. Por lo general, resulta más sencillo comprender los conceptos siguiendo un ejemplo concreto, típico y completo. Ese es precisamente el enfoque que tomaremos en esta ocasión. No dedicaremos demasiado tiempo a los detalles del UML sino que, en cambio, nos ocuparemos de cómo usar el UML para colaborar con el diseño y el desarrollo.

Si bien esta serie de artículos se ocupa de las soluciones Web a partir de modelos de SOA, comenzaremos por centrarnos en las metas y los objetivos de negocios que tratamos de alcanzar, de manera que nuestra solución genere valor para nuestro negocio. Luego, exploraremos un proceso de negocios que modele lo que se debe hacer en el negocio para alcanzar estas metas y estos objetivos, lo cual proporcionará los requerimientos funcionales de negocios que debe cumplir la solución de SOA. Finalmente, usaremos este proceso de negocios para ayudar a identificar los servicios que resulten de utilidad para la creación de una solución de SOA que cumpla con los requerimientos de negocios.

En los siguientes artículos de la serie, crearemos especificaciones e implementaciones de servicios que cumplan con estos requerimientos con una arquitectura que permita su futura reutilización y la agilidad de negocios. Por último, usaremos MDD para generar una solución de servicios web que se pueda implementar y ejecutar.

Para que este ejemplo sea aún más real, usaremos las herramientas existentes IBM® Rational® y IBM® WebSphere® para construir los artefactos de la solución y vincularlos entre sí, de manera que podamos probar la solución en función de los requerimientos y gestionar el cambio de manera más eficaz. La Tabla 1 ofrece un resumen del proceso general que usaremos al desarrollar el ejemplo y las herramientas usadas para construir los artefactos.

Tabla 1. Roles, tareas y herramientas del proceso de desarrollo
Role (Rol)Task (Tarea)Tools (Herramientas)
Business ExecutiveComunicación de metas y objetivos de negociosRational RequisitePro
Business AnalystAnálisis de los requerimientos de negociosWebSphere Business Modeler
Software ArchitectDiseño de la arquitectura de la soluciónRational Software Architect
Web Services DeveloperImplantación de la soluciónIBM® Rational® Application Developer e IBM® WebSphere® Integration Developer

Esta serie de artículos se centra en cómo capturar los requerimientos de negocios, construir modelos de servicios que cumplan con dichos requerimientos, y crear e implementar soluciones que materialicen estos diseños. Además, destacaremos cuáles son las correspondientes herramientas de soporte. Los artículos representar el conjunto mínimo de capacidades de modelado de SOA que actualmente ofrecen las herramientas de IBM que se enumeran en la Tabla 1 y que se pueden usar para modelar las requisiciones del consumidor y los servicios del proveedor en cualquier capa de la arquitectura. Estos artículos no se centran demasiado en los métodos y las técnicas usadas para descubrir los requerimientos, en los enfoques de análisis y evaluación de las soluciones de servicios, ni en los enfoques de particionamiento de los servicios en varias capas arquitectónicas. Para obtener más información sobre estos importantes temas, consulte IBM® Rational Unified Process® (RUP®) para SOA y RUP para SOMA (ver Recursos donde se encuentran los vínculos). Estos complementos de IBM® Rational® Method Composer ofrecen procesos de desarrollo, orientación, mentores de las herramientas y artículos que explican maneras adicionales de desarrollar modelos y soluciones de servicios completos.

Ejemplo del Proceso de Órdenes de Compra

Este ejemplo se basa en el ejemplo de Purchase Order Process (proceso de Órdenes de Compra) tomado de la Solicitud de Oferta (RFP por su denominación en inglés) de Perfil UML y Metamodelo para Servicios (UML Profile and Metamodel for Services - UPMS) de OMG, y en un ejemplo de la especificación 1.1 de BPEL (ver Recursos). La especificación 1.1 de BPEL contiene solo una solución parcial, debido a que no están definidos los conjuntos de correlaciones, no están completes los datos de negocios y no existe manejo o compensación de errores. Esta versión del ejemplo incluye algunos datos inventados para lograr la integridad, especialmente, los datos necesarios para establecer la correlación.

El ejemplo se inicia con el uso de IBM® Rational® RequisitePro® para describir la motivación empresarial que establece las metas y los objetivos de negocios que se deben alcanzar. A continuación sigue un proceso de negocios de alto nivel capturado con IBM® WebSphere® Business Modeler que expresa los requerimientos de negocios organizacionales y operacionales necesarios para cumplir con las metas y los objetivos. Estas motivaciones y modelos de procesos establecen el contexto para identificar los servicios que se conectan con los requerimientos de negocios.

Después de comprender los requerimientos de negocios, podemos proceder al desarrollo de los servicios que cumplen con estos requerimientos. El primer paso de una solución de SOA consiste en identificar los servicios. Para ello, trataremos al proceso de negocios como un contrato de Requerimientos de Servicios. Luego, las especificaciones de servicio y los proveedores de servicios serán diseñados y conectados de un modo tal que se cumpla con los requerimientos de negocios al tiempo que se encaran los asuntos relativos a la arquitectura de software.

El proceso de identificar los servicios potencialmente útiles de un modelo de servicios también se conoce como descomposición de dominios. IBM® Rational Unified Process® (RUP®) SOMA describe la descomposición de dominios y otros numerosos enfoques que, usados conjuntamente, brindan la seguridad de poder identificar todos los servicios necesarios para el negocio.

Requerimientos de negocios

Escenario: Una coalición de empresas ha decidido colaborar para producir un servicio reutilizable para el procesamiento de órdenes de compra. Las metas de este proyecto son:

  • Establecer un medio común para procesar las órdenes de compra
  • Asegurar que las órdenes se procesen de manera puntual y que se entreguen los productos requeridos
  • Ayudar a minimizar el stock disponible y los costos de mantenimiento de inventario
  • Minimizar los costos de producción y envío.

La Figura 1 muestra los requerimientos capturados en RequisitePro. Observe que caso de uso de negocios Process Purchase Order (Procesar orden de compra) cumple con todas estas metas de negocios.

Figura 1. Requerimientos de negocios que se muestran en RequisitePro
Requerimientos de negocios que se muestran en RequisitePro

Además, creamos un indicador clave de desempeño (KPI) para la Meta Nº2: procesamiento oportuno de órdenes (ver Figura 2).

Figura 2. Indicador clave de desempeño
Indicador clave de desempeño

Este KPI es algo que será conveniente observar en el modelo de procesos de negocios que plasma el caso de uso de negocios, que se convertirá en una restricción para nuestra solución de SOA, y que será monitoreado en nuestro servicio web implementado. Esto permitirá el monitoreo y la gestión del servicio con el fin de asegurar que se cumplan verdaderamente las metas y los objetivos de negocios.

Procesos de negocios organizacionales

Los analistas de negocios de las compañías de la coalición analizaron los requerimientos y determinaron que el siguiente proceso de negocios de IBM® WebSphere® Business Modeler cumple con los objetivos de negocios, y se ocupa de las restricciones operacionales de negocios. Este proceso intenta ser lo suficientemente completo y detallado como para ser usado como base para un acuerdo formal de nivel de servicios (SLA) entre las partes. Por ende, la solución de SOA que cumpla con estos requerimientos de negocios deberá acatar estrictamente estos requerimientos de negocios. (Figura 3).

Figura 3. Modelo de proceso de negocios para el Proceso de Órdenes de Compra
Modelo de proceso de negocios para el Proceso de Órdenes de Compra

El Proceso de Órdenes de Compra da comienzo a tres actividades paralelas: una para la gestión de la producción y la elaboración de cronogramas de envío, otra para el cálculo de precios y facturación, y una tercera para el envío de los productos pedidos. El procesamiento comienza con un cálculo de precios basado en los productos que se piden. Sin embargo, este precio aún no está completo, debido a que la facturación total depende de dónde se producen los productos y del monto de los costos de envío. Al mismo tiempo, el pedido se envía a producción para determinar cuándo estarán listos los productos y desde qué lugares. Paralelamente, el proceso solicita el envío y aguarda la recepción de un cronograma de envíos desde un proveedor de cronogramas de producción. Una vez que se encuentra disponible el cronograma de producción, se puede completar la factura para devolverla al cliente.

Usamos WebSphere Business Modeler para crear una medida de negocios denominada Límite de tiempo para el procesamiento de órdenes para cumplir con el KPI Límite de tiempo para el procesamiento de órdenes de los requerimientos de negocios. Esta medida de negocios monitorea el tiempo de procesamiento del y eleva una alerta si el tiempo de procesamiento es superior a cinco (Figura 4).

Figura 4. Medidas de negocios para los KPI
Medidas de negocios para los KPI

Los analistas de negocios pueden usar WebSphere Business Modeler para similar el proceso de negocios, lo cual les serviría para una cantidad de propósitos importantes:

  • En primer lugar, se puede usar para representar el proceso de negocios con el fin de visualizar de qué manera funcionaría. Esto permitiría a los analistas de negocios validar operaciones con los diversos interesados. Los clientes, a menudo, no saben lo que quieren hasta que usted les muestra algo que no desean. La ejecución de un simulacro de proceso de negocios constituye una gran manera de obtener una validación temprana del proceso de negocios antes de invertir en una solución para los problemas equivocados. La visión del proceso de negocios a través de un simulacro puede ayudarlo también a descubrir nuevas oportunidades para pulir los procesos que son difíciles de encontrar cuando simplemente se los lee.
  • El Segundo propósito para el cual se puede usar el simulacro es para determinar cuánto costar la ejecución de un proceso y cuánto tiempo llevará la misma, problemas clave que se deben considerar al tomar decisiones de negocios. El analista de negocios puede asignar recursos y duraciones a cada una de las tareas del proceso. Los recursos pueden incluir información sobre disponibilidad, costos y ubicación. Los simulacros de WebSphere Business Modeler pueden entonces usarse para calcular cuánto tiempo llevará un proceso, cuánto costará y dónde puede haber cuellos de botella de recursos que se deben encarar. Las distintas ejecuciones de los simulacros que surjan de cambios a los procesos de negocios se pueden comparar fácilmente para determinar si el cambio tiene el efecto deseado.
  • Por último, los resultados de las ejecuciones del simulacro se pueden usar para obtener evaluaciones tempranas de los KPI de negocios a fin de asegurar que los procesos de negocios cumplen con las metas y los objetivos del mismo. Esto brinda al equipo de desarrollo la confianza de que están elaborando la solución adecuada para el problema adecuado en el momento adecuado.

También vinculamos Purchase Order Process de WebSphere Business Modeler al caso de uso de negocios BUC1 Purchase Order Process (Proceso de Órdenes de Compra BUC1) para mostrar de qué manera el proceso materializa el caso de uso. "Materialización" es un término formal del modelado de casos de uso. Usted podrá ver que el caso de uso de negocios está vinculado a un proceso por la pequeña fleche en el ícono de BUC de la vista Requirement Explorer (Explorador de Requerimientos) de WebSphere Business Modeler (Figura 5).

Figura 5. Vinculación de procesos de negocios con los casos de uso de negocios que implementan
Vinculación de procesos de negocios con los casos de uso de negocios que implementan

Usted puede usar la perspectiva Requirements (Requerimientos) de WebSphere Business Modeler para navegar entre el proceso de negocios y el caso de uso de negocios que materializa en la vista Requirement Explorer de WebSphere Business Modeler, el cliente de RequisitePro, o el requerimiento de Microsoft® Word®.

La siguiente sección trata al proceso de negocios como un contrato de Requerimientos y muestra cómo identificar servicios en una solución de SOA para los requerimientos operacionales de negocios esperados.

Identificación de servicios

Algunos procesos de negocios pueden ejecutarse directamente sobre plataformas, como por ejemplo IBM® WebSphere® Process Server. Pero en algunas situaciones los procesos de negocios no tienen suficientes asuntos de IT encarados y se pueden refactorizar para usarlos de mejor manera y encarar requerimientos no funcionales, como por ejemplo desempeño, escalabilidad y seguridad. En este caso, se pueden considerar a los procesos de negocios como especificaciones de los requerimientos de lo que debe hacer una solución de SOA.

Requerimientos de servicios

Los requerimientos para el Purchase Order Process se pueden obtener del proceso de negocios de WebSphere Business Modeler. Estos requerimientos son vistos como un contrato de servicios, que indica los roles que participan en el proceso de negocios, las tareas que deben realizar y las reglas de interacción. Este contrato de servicios es una especificación formal, arquitectónicamente neutral de los requerimientos de negocios que son realizados por los consumidores de servicios y los proveedores interactuantes, sin encarar ninguna cuestión de implementación o arquitectura de TI. En este caso, el contrato de servicios contiene la misma información que el proceso de negocios original; es simplemente una vista de ese proceso de negocios creada al abrir el modelo de WebSphere Business Modeler con IBM® Rational® Software Modeler o IBM® Rational® Software Architect.

Los analistas de negocios a menudo usan WebSphere Business Modeler; mientras que los arquitectos de TI usan Rational Software Architect. Es poco probable que estas herramientas se usen juntas, y normalmente no se las usa para acceder al espacio de trabajo del mismo usuario. Para permitir que el arquitecto de TI se beneficie del trabajo del analista de negocios, se puede usar Rational Software Architect para importar modelos de negocios de WebSphere Business Modeler a un espacio de trabajo de Rational Software Architect, donde el arquitecto podrá abrirlo y ver el contenido incorporado por el analista de negocios en un UMLequivalente. La Figura 6 muestra las selecciones de nuestro modelo de WebSphere en un UML en Rational Software Architect.

Figura 6. Contrato de Requerimientos de servicios
Contrato de Requerimientos de servicios

Dediquemos algo de tiempo a comprender este diagrama, debido a que veremos diagramas similares a medida que desarrollemos la solución de SOA.

La colaboración <<serviceCollaboration>> de Purchase Order Process corresponde al proceso de negocios Process Purchase Order.

Nota:
La colaboración se muestra usando una notación clasificadora (rectángulo particionado), más que una notación de elipsis trazada. UML 2 permite ambas. Este ejemplo usa la notación del rectángulo porque tiene más espacio para los roles.

Al modelar los requerimientos de servicios o derivar requerimientos de servicios de procesos de negocios, la colaboración responde a estas preguntas:

  • ¿Cuál es el efecto esperado del requerimiento? Este es el nombre de colaboración que corresponde al proceso de negocios si la colaboración deriva de un proceso de negocios. Con frecuencia estos nombres son frases verbales que indican qué es lo que los roles en colaboración intentan lograr.
  • ¿Quién participa para que se realice? Los roles de la colaboración indican quiénes participan en la colaboración. Estos roles pueden corresponder a los carriles de nado dentro de un proceso de negocios.
  • ¿De qué son responsables los roles? (Nota: Son los proveedores de servicios, y no necesariamente personas, los que desempeñan estos roles.) Los tipos de roles de la colaboración son generalmente interfaces. Las responsabilidades de los roles se establecen como operaciones de la interfaz. Todo lo incluido en nuestra solución de servicios que desempeñe un rol debe ser capaz de cumplir con estas responsabilidades. Es decir, debe implementar estas operaciones. En un proceso de negocios, los roles son responsables de las tareas que se encuentran en sus carriles de nado. Estas interfaces podrían derivarse mediante la creación de listas de tareas asignadas a los roles del proceso de negocios.
  • ¿Cuáles son los roles que interactúan? Es decir, ¿cuáles son los roles que tienen que comunicarse con otros roles? Esto establece dependencias entre los roles. Esta interacción se muestra por medio de conectores entre los roles de la colaboración. Estos conectores indican que existe cierto control o datos que fluyen entre los carriles de nado en el proceso de negocios.
  • ¿Cuáles son las reglas para la manera en que interactúan los roles? Esta es la conducta propia de la colaboración. La conducta podría ser una actividad, una interacción, una máquina de estado, o una conducta opaca (por ejemplo, un código). Esta conducta dice cuándo se solicitan las responsabilidades de los roles y puede indicar la información intercambiada entre ellos. La actividad corresponde a la vista UML del proceso de negocios.
  • ¿Cómo evaluamos si se ha cumplido con los requerimientos? Una colaboración puede tener restricciones que especifican las condiciones que deben ser reales para que se puedan satisfacer los requerimientos. Estas restricciones corresponden a las medidas de negocios de los KPI dentro de un proceso de negocios.

El Purchase Order Process es una colaboración de servicios con cuatro roles, incluyendo uno que desempeña el proceso mismo. Estos roles se derivan del proceso de negocios mediante el examen de las tareas asignadas a los roles en los carriles de nado del proceso de negocios. WebSphere Business Modeler usa una vista de los requerimientos de negocios centrada en los procesos, mientras que el contrato de servicios toma una vista centrada en los roles. Esto brinda una vista de los contraltos de negocios más orientada a los servicios, lo cual facilita el cierre de la brecha entre los requerimientos del proceso y la arquitectura de las soluciones orientadas a los servicios.

El contrato de servicios puede tener restricciones derivadas de las métricas y medidas del modelo de motivación de negocios. Estas restricciones indican qué es lo que el contrato de servicios debería lograr y cómo se debe medir el éxito.

La colaboración de servicios puede también realizar casos de uso que capturen información adicional sobre los requerimientos funcionales y no funcionales de alto nivel para el proceso de negocios desde las perspectivas de actores o partes interesadas clave externas. Estos casos de uso se pueden visualizar en los diagramas de casos de uso de Rational Software Architect y se pueden vincular con los casos de uso de negocios de RequisitePro., manteniendo así el vínculo entre el contrato de requerimientos de servicios, los procesos de negocios, el caso de uso de negocios, y las metas y objetivos de negocios.

El contrato de colaboración de servicios que se muestra en la Figura 6 podría haber sido una vista de un modelo de procesos de negocios de WebSphere Business Modeler, o podría haber sido desarrollado directamente en Rational Software Architect. Cuál es el enfoque a usar depende de la preferencia personal de quién realiza el modelado, al igual que si el simulacro se usa para validar los procesos de negocios. En cada caso, se mantiene una total rastreabilidad. Por supuesto, la calidad de los contraltos de colaboración de servicios de los procesos de negocios de WebSphere Business Modeler dependerá del nivel de detalle de dichos procesos. Puede verse un tratamiento más completo sobre la relación entre el modelado de procesos de negocios y el modelado de servicios en el artículo de developerWorks, Business services modeling (Modelado de servicios de negocios).

Organización del proyecto de servicio

En este momento, estamos preparados para modelar un servicio que cumpla con estos requerimientos. Nuestra solución cumplirá con estos requerimientos, pero no necesariamente estará restringida por los mismos. Cuando diseñamos una solución de SOA, debemos identificar los servicios, diseñar sus interfaces y decidir cómo se implementarán: Cuáles son los proveedores de servicios que brindarán cada servicio y de qué manera lo harán. Así se establecen las dependencias entre los consumidores del servicio y los proveedores, y se establece el acoplamiento en el sistema. La gestión de este acoplamiento es una parte importante del diseño de servicios basados en SOA. Al separar los requerimientos de negocios de los servicios, tendremos la flexibilidad para diseñar la SOA que cumpla con los requerimientos tanto del negocio como del sistema de TI. Esto evita que los requerimientos de negocios restrinjan abiertamente a la solución de SOA, lo cual podría provocar una menor reutilización y una menor agilidad de negocios.

Rn primer lugar, creamos un proyecto de modelado de servicios en Rational Software Architect denominado PurchaseOrderProcessModel. Ese proyecto contiene un modelo de servicios denominado PurchaseOrderProcess. Este modelo consiste en un modelo de información para los servicios, los datos de los servicios, las especificaciones sobre las interfaces provistas y requeridas, y los componentes que brindan los servicios requeridos. Pero por ahora nos ocuparemos principalmente de la identificación de los servicios.

Como muestra la Figura 7, existen cinco paquetes principales en el modelo PurchaseOrderProcess:

  • org::ordermanagement contiene elementos relativos a la gestión de órdenes.
  • org::crm contiene el modelo de datos y las interfaces comunes para la norma conceptualizada de Gestión de Relaciones con el Cliente que los consumidores de los servicios y los proveedores de los servicios han acordado para el desarrollo de servicios compartidos.
  • com::acme::credit contiene elementos relativos a la gestión de facturación y créditos.
  • com::acme::productions contiene elementos relativos a la producción y los cronogramas.
  • com::acme::shipping contiene elementos relativos al envío.

Estos paquetes dividen el dominio del problema en distintas áreas funcionales, lo cual ayuda a gestionar la complejidad, establece los espacios de nombre requeridos, facilita la reutilización y mantiene asuntos separados en distintos paquetes. (Ver Figura 7).

Figura 7. Diagrama de dependencias de paquetes
Diagrama de dependencias de paquetes

Esta organización podría denominarse la organización dominante del modelo de servicios. Las particiones se pueden usar para documentar otras clasificaciones para la organización de los elementos del mismo modelo.

Topología de los servicios

Comenzamos el modelo de servicios con la identificación de los servicios involucrados en el procesamiento de una orden de compra. En este momento, no buscamos un detalles sobre qué hacen los servicios ni sobre cómo interactúan. Sólo deseamos crear un bosquejo de qué son los servicios y una idea de alto nivel sobre cómo podrían llegar a interactuar.

La Figura 8 es un simple diagrama de clases (o diagrama de forma libre) de Rational Software Architect que muestra los paquetes que representan las áreas de negocios funcionales anteriormente descriptas y los servicios clave que se definirán en esos paquetes. La única información dada sobre el servicio en este momento es el nombre del mismo.

Las dependencias de uso del diagrama tienen la intención de mostrar cómo se espera que estos servicios se relacionen entre sí. En este momento, no contamos con especificaciones de servicio completas, ni sabemos qué participantes en el servicio serán los que soliciten o brinden los servicios. Tampoco hemos modelado ninguna implementación de estos servicios. Por lo tanto, todavía no se ha formalizado el significado de estas dependencias de uso. Son simplemente una indicación de implementaciones anticipadas que pueden o no convertirse en realidad cuando completemos las especificaciones y las implementaciones del servicio. No obstante, estas dependencias son valiosas en este alto nivel debido a que comienzan a identificar los usos y el acoplamiento entre sistemas que se deberá gestionar cuidadosamente.

Figura 8. Diagrama de la topología de los servicios
Diagrama de la topología de los servicios

Nota:
El modo en que esta topología de servicios fue descubierta y diseñada se encuentra fuera del alcance de este artículo. IBM RUP para SOMA (ver Recursos) ofrece un proceso, métodos y orientación para descubrir los servicios a partir de las áreas funcionales de negocios.

Una manera simple de descubrir los servicios requeridos es analizar los requerimientos del negocio identificados como colaboración de servicios y pensar en qué proveedor de servicios será necesario para desempeñar los roles de las colaboraciones. Esta es la técnica usada en este simple ejemplo. En realidad, podemos formalizarla mediante la creación de un diagrama que muestre cómo se usarían las especificaciones de los servicios para cumplir con el contrato de Colaboración de Servicios.

La Figura 9 muestra un componente abstracto que modela el contexto para el procesamiento de órdenes de compra. Cuenta con varias partes que constituyen las especificaciones de servicios que anteriormente se trataron. El diagrama muestra un uso potencial de cada una de estas especificaciones de servicios en un contexto particular. Todavía no sabemos qué participante en el servicio brinda o utiliza los servicios, sólo sabemos que un participante lo hace. Estas partes también son abstractas, debido a que son instancias de las especificaciones de los servicios, más que instancias de los proveedores de servicios que proveen estos servicios.

Figura 9. Cumplimiento del contrato de Requerimientos de Servicios
Cumplimiento del contrato de Requerimientos de Servicios

Lo que muestra este diagrama, sin embargo, es cómo estos servicios cumplen con el contrato de requerimientos de Colaboración de Servicios. El contrato es un uso de colaboración, una instancia de la colaboración de servicios de Process Purchase Order. TLas partes del componente Processing Purchase Orders están ligadas a los roles que desempeñan en el contrato. Esto brinda un vínculo formal a los requerimientos de negocios y muestra la importancia que tiene para el negocio cada una de las interfaces de servicios que intentamos especificar e implementar. El comportamiento de la colaboración de servicios de Process Purchase Order especifica la manera en que estas partes deben interactuar en la implementación de los servicios. Volveremos a este tema cuando especifiquemos e implementemos los servicios para asegurar que la solución cumpla con los requerimientos del contrato.

Qué sigue

En este artículo, delineamos una técnica a seguir para identificar servicios que se conecten con requerimientos de negocios. Comenzamos por capturar las metas y los objetivos de negocios necesarios para materializar la misión de negocios. Luego, modelamos las operaciones y los procesos de negocios que son necesarios para cumplir con estas netas y estos objetivos. Más tarde, visualizamos el proceso de negocios como una colaboración de servicios que representa un contrato de Requerimientos de Servicios de negocios que debe ser cumplido por nuestra eventual solución. Usamos este contrato de requerimientos para ayudar a identificar los servicios requeridos y las potenciales relaciones entre ellos, lo cual brinda una manera formal de identificar los servicios relevantes para el negocio que se vinculan con las metas y los objetivos de negocios que intentan cumplir.

El siguiente artículo de esta serie, "Modelado de SOA: Parte 2. Especificación de servicios," modelará detalladamente la especificación de servicio de cada uno de estos servicios. Estas especificaciones indicarán cuáles son las interfaces provistas y requeridas, los roles que estas interfaces desempeñan en la especificación del servicio, y las reglas o el protocolo aplicables a cómo estos roles interactúan durante la provisión del servicio.


Descargar

DescripciónNombretamaño
RSM sample modelRSM_sample_model.zip60KB

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=468358
ArticleTitle=Modelado de SOA: Parte 1. Identificación del servicio
publish-date=07292011