Modelado con SoaML , el lenguaje de modelado de arquitectura orientada a servicios: Parte 2. Especificación de los servicios

En éste, el segundo de esta serie de cinco artículos, continuamos definiendo la solución SOA mediante el modelado detallado de la especificación de cada uno de los servicios. Estas especificaciones definirán las interfaces de servicio entre los consumidores y los proveedores de servicios, que incluyen las interfaces provistas y requeridas, los roles que estas interfaces desempeñan en la especificación del servicio y las reglas o el protocolo que rige el modo en que interactúan estos roles.

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

Contexto del artículo

El primer artículo de esta serie, Modelado con SoaML , el lenguaje de modelado de arquitectura orientada a servicios: Parte 1. Identificación de los servicios, señaló un enfoque para identificar los servicios que se conectan con los requerimientos de negocios. Comenzamos con la captura de las metas y los objetivos de negocios necesarios para hacer realidad la misión de negocios. A continuación, modelamos las operaciones y los procesos de negocios que son necesarios para cumplir con estas metas y estos objetivos. Luego, usamos los requerimientos y procesos para identificar las capacidades requeridas y las potenciales relaciones entre ellas, lo cual brindó una estructura formal para identificar las capacidades de relevancia para el negocio que se vinculan con las metas y los objetivos que intentan cumplir.

En el artículo anterior, también analizamos cómo maximizar el potencial de una solución de arquitectura orientada a servicios (SOA) con la identificación de servicios de relevancia para el negocio. Examinamos cada una de las capacidades tratándolas como servicios potenciales. Las capacidades que pasaron la prueba determinante de servicios se usaron para identificar cuáles son las interfaces de servicio necesarias. Con esto se vuelven a vincular las interfaces de servicio con los requerimientos de negocios.

En este Segundo artículo, continuamos definiendo la solución SOA mediante el modelado detallado de la especificación de cada uno de los servicios. Estas especificaciones definirán las interfaces de servicio entre los consumidores y los productores de servicios. Estos contratos incluyen las interfaces provistas y requeridas, los roles que estas interfaces desempeñan en la especificación del servicio y las reglas o el protocolo que rige el modo en que interactúan estos roles.


Generalidades sobre las especificaciones de servicios

En este momento, estamos listos para comenzar a modelar los detalles de las interfaces de servicios. Una interfaz de servicios debe especificar todo lo que los potenciales consumidores del servicio deben saber para decidir si están interesados en usar el servicio, además de cómo usarlo exactamente. Debe especificar todo lo que debe saber un proveedor de servicios para implementar el servicio con éxito. En el corazón de SOA se encuentra la construcción de las cadenas de valor de los servicios que conectan las necesidades de los usuarios con las capacidades compatibles de los proveedores. Las interfaces de servicios definen las metas, las necesidades y las expectativas de los usuarios participantes, así como las proposiciones de valor, las capacidades y los compromisos asumidos por los proveedores participantes. En consecuencia, brindan la información necesaria para determinar las capacidades y las necesidades de compatibilidad.

Lo ideal sería que la información se ofreciera en un único lugar. Esto facilita la búsqueda de servicios reutilizables en los repositorios de activos así como la obtención de toda la información necesaria sin tener que navegar por numerosos documentos diferentes en busca de los elementos relacionados. Las interfaces de servicios incluyen, por lo menos, la siguiente información:

  • El nombre del servicio, que sugiera su propósito.
  • Las interfaces provistas y requeridas, definiendo así las capacidades funcionales que el servicio brinda y aquellas que requiere de los usuarios.
    Nota: No se trata de cómo se implementa el servicio, sino de la interacción entre los consumidores y los proveedores del mismo.
  • Cualquier protocolo que especifique reglas sobre el uso y el orden de uso de las capacidades funcionales.
  • Las restricciones que reflejen qué intenta lograr el uso exitoso del servicio y cómo será evaluado el mismo.
  • Las cualidades que deberán esperar los consumidores del servicio y que se espera que ofrezcan los proveedores de servicios, como por ejemplo costo, disponibilidad, rendimiento, espacio ocupado, adecuación a la tarea, información competitiva, etc.
  • Las políticas de uso del servicio, como por ejemplo el alcance de la seguridad y las transacciones para mantener la seguridad y la integridad o para recuperarse de la incapacidad de brindar ése o cualquier otro servicio con éxito.

Al igual que con los demás artículos de esta serie, usaremos las herramientas existentes de IBM® Rational® para construir y vincular los artefactos de la solución, de manera que podamos verificar la solución contra los requerimientos y podamos gestionar el cambio con mayor eficacia. Además, extendemos el lenguaje unificado de modelado (UML por su denominación en inglés) para el modelado de servicios mediante el agregado de un Perfil de SoaML (Services-Oriented Architecture Modeling Language) de Object Management Group (OMB) a los modelos UML de IBM® Rational® Software Architect. La Tabla 1 brinda un resumen del proceso general que usaremos en el desarrollo del ejemplo y las herramientas utilizadas para construir los artefactos.

Tabla 1. Desarrollo de los roles, las tareas y las herramientas del proceso
Role (Rol)Task (Tarea)Tools (Herramientas)
Business executiveComunicar las metas y los objetivos de negociosIBM® Rational® Requirements Composer
Business analystAnalizar los requerimientos de negociosIBM Rational Requirements Composer
Software ArchitectDiseñar la arquitectura de la soluciónIBM® Rational® Software Architect
Web services developerImplementar la soluciónIBM® Rational® Application Developer

Revisión de la identificación del servicio

Comencemos por revisar las interfaces de servicio que expusieron las capacidades de negocios necesarias para cumplir con las metas y estrategias de negocios que describimos en detalle en “Modelado con SoaML , el lenguaje de modelado de arquitectura orientada a servicios: Parte 1. Identificación de los servicios." La Figura 1muestra las interfaces de servicio que exponen las capacidades requeridas para el procesamiento de órdenes de compra

Figura 1. Capacidades para el procesamiento de órdenes de compra
Capacidades para el procesamiento de órdenes de compra

El resto de este artículo explica cómo modelar los detalles de las interfaces del servicio. Estas interfaces de servicio son una elaboración de las interfaces que se muestran en la Figura 1. Brindan muchos de los detalles enumerados en las Generalidades.

Cuando las interfaces están completas, usted todavía no sabrá cuáles son los participantes del servicio que proveen o requieren los servicios descriptos por las interfaces, ni cómo se implementan las capacidades del servicio, posiblemente con el uso de otros servicios. Esta información se ofrece en el siguiente artículo, cuando se trata la materialización del servicio.


Tipos de especificaciones de servicios

Una interfaz de servicios debe proporcionar esta información:

  • El nombre del servicio, que indica de qué se trata o qué es lo que hace.
  • Las interfaces provistas y requeridas, que describen las capacidades funcionales del servicio. Cada capacidad funcional incluye:
    • Su nombre, que a menudo es una frase verbal que indica qué es lo que hace
    • Cualquier entrada o salida de datos del servicio obligatoria u opcional
    • Cualquier precondición que se espera que cumplan los consumidores antes de usar la capacidad
    • Cualquier condición posterior que los consumidores puedan esperar y que los proveedores deben proporcionar para el uso exitoso de la capacidad
    • Cualquier excepción o condición de falla que pueda surgir si no se puede proveer la capacidad por cualquier motive, incluso cuando se hayan cumplido las precondiciones
  • Cualquier protocolo o reglas de comunicación que determinen cuándo o en qué orden se pueden usar las capacidades.
  • Cualquier capacidad que se espera que brinden los consumidores para poder usar o interactuar con el servicio.
  • Los requerimientos que debe cumplir un implementador cuando brinda el servicio,
  • Las restricciones que reflejan cuál es el uso exitoso del servicio que se intenta lograr y cómo será evaluado el mismo.
  • Las calidades de servicio que deberán esperar los consumidores y que se espera que brinden los proveedores, como por ejemplo costo, disponibilidad, rendimiento, espacio usado, adecuación a la tarea, información competitiva, etc.
  • Las políticas de uso del servicio, como por ejemplo los alcances de la seguridad y las transacciones para mantener la integridad o recuperarse de la incapacidad de brindar éste o cualquier otro servicio con éxito.

Resulta claro que se trata de mucha información, y este artículo no la abarcará por completo. Particularmente no analizaremos las calidades del servicio ni las políticas, ya que su complejidad amerita su discusión en artículos independientes. Más aún, pueden ser específicas para ciertos proveedores particulares de un servicio, y no para la interfaz de un servicio en particular. En cambio, nos ocuparemos de los fundamentos necesarios para definir y usar un servicio.

Las siguientes sub-secciones explican en detalle cada una de las especificaciones de servicio identificadas que se mostraron anteriormente en la Figura 1.. El orden de presentación va desde una interfaz simple de servicio que no posee protocolo hasta una interfaz de servicios que representa un protocolo simple de respuesta a solicitudes o a un servicio más complejo que involucra un protocolo de pasos múltiples y la interacción entre el usuario y el proveedor.

Programación del servicio

La interfaz de Programación del servicio que se muestra en la Figura 2 es muy simple. El servicio brinda dos operaciones: la capacidad de responder a una solicitud al cronograma de producción y la habilidad de crear un cronograma de envíos. Estas operaciones fueron creadas examinando las funciones que exponen las capacidades de la interfaz del servicio. Por lo que sabemos, en esta situación no existe un protocolo para usar estas operaciones. Se puede usar cualquiera y en cualquier orden.

Interfaz del servicio Scheduling (Planificación)
Interfaz del servicio Scheduling (Planificación)

La interfaz del servicio Scheduling es una interfaz UML simple definida en el paquete de producción. Ofrece dos operaciones de servicio, cada una de las cuales puede tener condiciones previas y posteriores, y puede hacer surgir excepciones. Los parámetros de las operaciones de servicio deben ser datos de servicios (DataType o MessageType) o tipos primitivos. Así se asegura que los parámetros no hagan supuestos sobre call-by-reference o call-by-value, sobre dónde se encuentran los datos del servicio (en qué espacio de dirección), sobre si el usuario o el proveedor del servicio opera sobre una copia de los datos o sobre una fuente de datos persistentes, etc. Todo esto es necesario para garantizar que el servicio no esté restringido por el lugar donde se lo puede implementar en relación con otros servicios. Los datos del servicio se definen en la sección Modelo de datos del servicio que aparece a continuación en este artículo.

Servicio de envíos

La interfaz del servicio Shipping (Envíos) es un poco más complicada. El usuario que desea enviar productos deberá solicitar el servicio de envíos. Sin embargo, el despachante podría demorar en determinar dónde se encuentran los productos, si los mismos se encuentran en el inventario disponible o se deben fabricar, y el modo más económico para enviar los productos. Por lo tanto, podría pasar un tiempo antes de que el cronograma de envíos esté disponible. Por lo general, el usuario no desea esperar hasta que el cronograma esté complete, debido a que esto podría evitar la realización de otros trabajos paralelos o podría atar a los recursos del sistema a procesos extensos..

En consecuencia, el IT Architect ha decidido usar una respuesta simple a una solicitud o un protocolo callback (devolución de llamada) entre el usuario y el proveedor. El usuario solicita el envío y luego, más tarde, responde a la solicitud del despachante para procesar el cronograma completo. Para modelar este protocolo, necesitamos especificar los roles del productor y del usuario, sus responsabilidades y el protocolo o las reglas de interacción entre ellos. Esto último resulta importante, porque los despachantes no podrán enviar un cronograma si nunca han recibido las solicitudes de envío.

Unainterfaz de serviciole dice todo lo que usted debe saber sobre un servicio. Esto incluye los requerimientos que debe cumplir para usar el servicio (a veces denominados el Uso o el Contrato de utilización (consulte el artículo escrito por Daniels y Cheesman que figura en Recursos), más los requerimientos que debe cumplir el implementador del servicio (denominados a veces el Contrato de materialización). Este es el mismo tipo de información que usted debía capturar para los requerimientos de negocios, excepto por el área de asunto y el nivel de detalle. Esto es de esperar, debido a que usted define la especificación sobre el modo de interacción entre el usuario y el proveedor del servicio en una interfaz de servicio.

En este caso, usamos una clase abstracta para definir la interfaz de servicio y las operaciones de las capacidades expuestas, como se muestra en la Figura 3.

Figura 3. Interfaz del servicio de envíos
Interfaz del servicio de envíos

La interfaz ShippingService ServiceInterface involucra dos roles:

  • El rol del shipper (despachante) es un rol de proveedor, responsable del cumplimiento de las responsabilidades del envío que están dadas por su tipo, la interfaz de envío.
  • El rol del orderer (ordenante) es responsible del procesamiento del cronograma de envíos. Esto se muestra por su tipo de ScheduleProcessing.

No es necesario designar estos roles como proveedor y usuario. Estas son distinciones arbitrarias en una conversación potencialmente larga, que posiblemente involucres a varias partes. Además, resulta sencillo ver quiénes son el usuario y el proveedor, por el hecho de que la especificación del Servicio hace realidad la interfaz de envío provista y usa la interfaz ScheduleProcessing requerida.

Existe un conector entre el rol del despachante y el del ordenante. Esto indica que el protocolo involucra cierto grado de interacción entre ambos roles. La interacción del shippingService propiedad de la clase ShippingService muestra qué es esta interacción.

La interacción del shippingService especifica el comportamiento o los aspectos dinámicos de la interacción entre los roles del ordenante y del despachante. Muestra que el ordenante en primer lugar envía un mensaje de requestShipping (o invoca la operación requestShipping del despachante), y luego, más tarde, debe responder a un mensaje processSchedule del despachante. La interacción involucra a dos líneas de vida: una para el ordenante y otra para el despachante. Estas instancias de objeto son las propiedades del ordenante y el despachante que se encuentran en la ServiceInterface. Es decir, estos roles intercambian los mensajes por medio del conector existente entre ellos. Este simple patrón asincrónico de solicitud/respuesta o devolución de llamada es típico de muchos protocolos de servicios.

El protocolo shippingService se podría haber especificado con cualquier comportamiento de y UML 2: una actividad, interacción, máquina de estado, máquina de estado de protocolos, o comportamiento opaco (código). Los modeladores decidirán la opción a utilizar, en función de sus estilos preferidos o de la aplicabilidad de los dominios del problema.

Servicio de facturación

La capacidad de facturación muestra que se deben exponer las dos operaciones para calcular la factura total. El cálculo del precio inicial y final de una facture involucra un protocolo más complejo entre el ordenante y el facturador (invoicer). Obviamente, se debe invocar initiatePriceCalculation antes que completePriceCalculation. Luego, el ordenante debe estar preparado para procesar la factura resultante.

Podemos capturar este protocolo usando una ServiceInterface que especifique los roles del facturador y del ordenante, sus responsabilidades, y el protocolo (conversación o reglas) del modo de interacción. Esto es igual que con la especificación ShippingService, excepto por el hecho de que la interacción es más que una simple solicitud – respuesta. Existe una secuencia en la cual se debe invocar a las capacidades funcionales del servicio para lograr el uso válido del servicio.

La especificación de servicio InvoicingService que se muestra en la Figura 4 captura este protocolo. Observe que esta interfaz de servicio también implementa el caso de uso de Facturación. Se puede usar un caso de uso para representar los requerimientos específicos del servicio. La interfaz de servicio consiste en dos roles: facturador (invoicer) y ordenante. Los tipos de estos roles son los de la interfaz Invoicing materializada y la interfaz InvoiceProcessing usada, respectivamente. Estas interfaces encapsulan las responsabilidades de los roles. La actividad InvoicingService de la especificación del servicio especifica el protocolo de uso de las operaciones del servicio, la comunicación real que puede producirse entre los roles del ordenante y el facturador.

Figura 4. Interfaz InvoicingService
Interfaz InvoicingService

InvoicingService es una ServiceInterface que especifica la conversación, el protocolo de comunicación o las reglas de interacción entre el ordenante y el facturador. Los detalles del protocolo son capturados en un UML ownedBehavior (que se muestra usando la notación círculo-plus) de la clase, que se usa para especificar los patrones de interacción válidos para el uso de este servicio. En este caso, el protocolo se expresa como una actividad UML.

El protocolo indica que el ordenante debe iniciar un cálculo de precios antes de intentar obtener el cálculo completo de los precios reales. El ordenante debe, luego, responder a la solicitud (en este caso, devolución de llamada) para procesar la factura final. Algunos de los consumidores que solicitan el servicio de facturación están en condiciones de hacer más que estas acciones, pero el secuenciamiento de estas acciones específicas se encuentra restringido por el protocolo. Observe que el UML ActivityPartitions de la actividad InvoicingService representa los roles o propiedades de la clase InvoicingService. Una acción de invocación a una operación perteneciente a una partición indica que la invocación se da en el rol representado por dicha partición (el pin de entrada de datos objetivo de la acción es el rol representado por la partición de la actividad).

En este caso, existe solo una interacción entre el ordenante y el servicio de facturación, de modo que la clase de la especificación del servicio tiene sólo un ownedBehavor. En otras situaciones, podría haber más de una interacción entre el usuario y el proveedor, cada una de las cuales usa un protocolo diferente. La especificación del servicio tendría un ownedBehavior que especifique los patrones de interacción válidos para cada una de estas conversaciones.

En este momento, usted no sabe cuál es el proveedor de servicios que implementa un InvoicingService. Ni cuáles son los consumidores de servicios que lo usarán. Usted solo sabe qué es lo que cualquier usuario debe hacer para usar el servicio y qué es lo que cualquier proveedor debe hacer al implementarlo.

Servicio de compras

Por último, existe la interfaz de servicios para procesar las órdenes de compra (ver Figura 5).

Figura 5. Interfaz de servicios Purchasing (de compras)
Interfaz de servicios Purchasing (de compras)

Al igual que la interfaz del servicio de programación, Purchasing es una interfaz simple que tiene una única operación que brinda la capacidad de procesar órdenes de compra de un cliente que devuelve una factura completa. Como efecto secundario, los artículos pedidos se producen (si es necesario) y se envían al cliente.

Esta interfaz de servicios representa la capacidad funcional especificada en el proceso de negocios original Process Purchase Order (Procesar órdenes de compra). Representa a un servicio identificado y diseñado para ese proceso de negocios.


Modelo de datos del servicio

El modelo de datos de la Gestión de Relaciones con el Cliente (CRM por su denominación en inglés) definido en package org::crm define todos los datos usados por todas las operaciones de servicios en las interfaces de servicios ya definidas. El paquete CRM representa el diseño de un modelo de datos de servicio de Gestión de Relaciones con el Cliente que puede ser reutilizado en una cantidad de servicios, incluso en servicios provistos por otras organizaciones. El modo en que se descubren y normalizan los datos del servicio y el modo en que estos datos se relacionan con entidades persistentes o Fuentes de datos físicos se encuentran fuera del alcance de este artículo. Lo que aquí discutimos es la apariencia de los datos de servicio y cómo se captura el modelo.

Figura 6. Modelo de datos de servicios de CRM
Modelo de datos de servicios de CRM

Cada tipo de datos que se muestra en la Figura 6 representa datos de servicios. Los Datos de servicios son datos que se intercambian los consumidores y los proveedores del servicio. Los tipos de datos de los parámetros par a las operaciones de los servicios se tipifican mediante un DataType (tipo de datos), PrimitiveType (tipo primitivo), o MessageType (tipo de mensaje).

Nota:
Los mensajes de datos de servicios no son iguales a los mensajes de Web Services Description Language (WSDL). Una operación de servicio puede contar con cualquier cantidad de entradas y salidas de datos con tipos de mensajes o tipos primitivos. Las operaciones de servicio pueden estar diseñadas para usar una única entrada o salida de datos y mensajes de falla, pero esto no es necesario y puede originar un acoplamiento de datos de marca indeseable.

Los datos del servicio se refieren a los objetos de transferencia de datos (DTO por su sigla en inglés) que se pueden intercambiar fácilmente entre los espacios de dirección de los entornos distribuidos. Los consumidores y proveedores de servicios no realizan supuestos sobre dónde se ubican en realidad los datos, y en consecuencia, suponen que cuentan con una copia de alguna vista de los datos reales del dominio persistente. Los UML DataTypes no tienen identidad. Son objetos de valor, en el sentido que su igualdad se basa en el valor de su contenido, y no en su identidad.

Los datos de servicio representan los datos intercambiados entre los consumidores y los proveedores del servicio en un entorno posiblemente distribuido. Los proveedores del servicio también deben accede a datos persistentes para usarlos en los diseños de sus implementaciones. La relación entre los datos de servicio y los datos del dominio persistente usados en los diseños de la implementación del servicio es responsabilidad del proveedor del servicio y de la implementación que haga de las capacidades funcionales del servicio. A menudo, los datos del servicio son una selección y una proyección (vista) de los datos del dominio. Sin embargo, el modo en que los datos del servicio actualizan o derivan de los datos del dominio depende de la implementación del servicio. Los Objetos de datos de servicios (SDO) constituyen un mecanismo muy útil para los mensajes de datos del servicio. También cuentan con capacidades para gestionar los conjuntos de cambios y comprometer los cambios a los almacenes persistentes. Las implementaciones de los participantes en el servicio pueden usar estas capacidades, aunque no es necesario ocuparnos de ellas en el modelo.

El modelo de datos usa un estereotipo de <<id>> para identificar los atributos que identifican de manera única las instancias de la clase que los contienen. Este será un tema recurrente en todo el modelo de servicios, debido a que los servicios web y el BPEL (Business Process Execution Language for Web Services – Lenguaje de ejecución de procesos de negocios para servicios web), en particular, dependen de los datos de negocios para la correlación de instancias o la identidad de objetos basados en el valor.

Comparación de datos de servicios RPC y centrados en documentos

Existen numerosos paradigmas de interacción SOA de uso común que incluyen la mensajería centrada en documentos, las llamadas de procedimientos remotos (RPC), y los de publicación-suscripción. La discusión de las distintas características de cada uno de estos paradigmas, los estilos de interacción o las circunstancias en las cuales cada uno resulta más adecuado se encuentran fuera del alcance de este artículo. Es suficiente decir que la decisión depende de la cohesión y el acoplamiento, la gestión de estado, las transacciones distribuidas, el rendimiento, de la granularidad, la sincronización, la facilidad de desarrollo y mantenimiento y las mejores prácticas.

SoaML soporta datos tanto de servicio de estilo RCP como de mensajería centrada en documentos.La Figura 7 muestra las interfaces del servicio de Compras y Facturación con un detalle de sus operaciones. La interfaz del servicio de Compras usa datos de servicio del estilo de mensajería de documentos. Sus parámetros de operación se encuentran tipificados por los SoaML MessageTypes POMessage y InvoiceMessage. La interfaz del servicio de Facturación, por el contrario, usa los tipos de datos definidos en la Figura 6.

La diferencia entre ambos es el modo en que se empaquetan los datos para una operación. Para las operaciones con parámetros que están tipificadas con MessageTypes, la operación puede tener como máximo un parámetro in (entrante) o out (saliente). Las operaciones que usan parámetros DataType pueden tener numerosos parámetros In (entrada), Out (salida), y return (devolución). Esto permite a SoaML modelar los datos intercambiados entre los consumidores y los proveedores del servicio de manera tal que se cumpla con los principios guía de la arquitectura elegida.

Figura 7. Datos de servicios centrados en mensajes y de estilo RPC
Datos de servicios centrados en mensajes y de estilo RPC

Vista más amplia de la Figura 7.


Qué sigue

En este artículo, modelamos detalladamente la interfaz de servicio para cada uno de los servicios identificados. Estas interfaces indican las interfaces provistas y requeridas, los roles que desempeñan estas interfaces en la interfaz del servicio y las reglas o el protocolo de interacción de estos roles durante la provisión del servicio. Las Interfaces de servicio definen un contrato entre las solicitudes del usuario y los servicios del proveedor que permiten buscar la correspondencia entre las necesidades y las capacidades compatibles.

El siguiente artículo de esta serie de cinco partes, "Parte 3. Materialización de los servicios," explica de qué manera se implementan realmente los servicios. La implementación del servicio se inicia al decidir qué participante proveerá cada uno de los servicios. Esta decisión tiene importantes implicancias en la disponibilidad, la distribución, la seguridad, el alcance de las transacciones y el acoplamiento de los servicios. Luego de tomar estas decisiones, podemos modelar cómo se implementará la capacidad funcional de cada servicio y, en consecuencia, cómo se usarán realmente los servicios requeridos. Luego, usaremos la característica de transformación UML a SOA incluida en Rational Software Architect para crear una solución de servicios web que se pueda usar directamente en Rational Application Developer o IBM® WebSphere® Integration Developer con el fin de implementar, comprobar e implantar la solución completa.

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 se registra en developerWorks, se crea un perfil para usted. Información sobre su perfil (nombre, país/región y compañia) estará disponible al público y acompañará cualquiera de sus publicaciones. Puede actualizar su cuenta 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=468370
ArticleTitle=Modelado con SoaML , el lenguaje de modelado de arquitectura orientada a servicios: Parte 2. Especificación de los servicios
publish-date=07292011