Directriz: Realización de servicio - Servicios de BPEL en una aplicación de SOA
Esta directriz describe una aplicación generada mediante coreografías basadas en BPEL en estilo de SOA.
Relaciones
Descripción principal

Introducción

Esta página describe una aplicación que se crea con coreografía basada en BPEL en un estilo de arquitectura orientada a servicios. Las lecciones aprendidas durante las fases de diseño y desarrollo de este proyecto proporcionan conocimiento general para otras que tengan en cuenta el uso de la coreografía basada en BPEL en una arquitectura orientada a servicios. La propuesta de diseño se evalúa aquí usando una comparación de pros y contras que tiene en cuenta los requisitos empresariales y los elementos de aplicación existentes. Esta página contiene recomendaciones de diseño e identifica características que sugieren el uso de un enfoque controlado por BPEL.

Lecciones aprendidas

  1. La selección de la segmentación correcta de la lógica empresarial entre el flujo de trabajo y los servicios de socio constituye a veces un reto y siempre es importante.

    La lógica empresarial se divide entre la coreografía basada en el flujo de trabajo y los servicios de socio. En última instancia los servicios de socio deberían ser responsables de una lógica compleja o con una gran carga computacional, mientras que la coreografía contendría la lógica que se anticipa al cambio en respuesta a requisitos empresariales en constante evolución.

    Como ésta no siempre es una separación clara, una estrategia de remediación útil es diseñar la aplicación para que crezca mediante la modificación del flujo de trabajo y la agregación de nuevos servicios de socio en lugar de mediante la modificación de los servicios de socio existentes.

    Se trata de un enfoque fundamentalmente iterativo. Los prototipos iniciales probablemente necesiten la refactorización de los servicios de socio para conseguir un diseño que crezca mediante la agregación de nuevos servicios de socio.

    Desde luego, en todos los casos debe conservar el código innecesario o que nunca cambia fuera del flujo de trabajo

  2. Aproveche las funciones únicas de BPEL

    La posibilidad de BPEL de orquestar los servicios de socio que exhiben una gran variedad de vínculos diferentes.

    Tenga cuidado de no crear dependencias en las características de una implementación de socio o un vínculo de servicio de socio específico. Si lo hace puede complicar o limitar futuros cambios en la coreografía o la aplicación general.

    Considere la posibilidad de conservar los resultados intermedios en variables BPEL como una estrategia para mejorar el rendimiento

  3. En las que sea posible diseñar servicios de socio de forma sin estado con operaciones idempotentes.

    En el contexto de este debate, la idempotencia simplemente significa que se puede llamar a un servicio, con los mismos datos de entrada, varias veces con la esperanza de que la respuesta sea correcta para cada llamada. Esta característica puede ofrecer una importante simplificación tanto para el interlocutor como para el servicio, ya que simplifica enormemente la interacción. La recuperación de errores, el reinicio tras anomalía y la escala de agrupaciones en clúster se simplifican. Para el interlocutor, la recuperación de errores desde la red y los problemas de cliente y servidor se simplifican. La idempotencia es un indicador clave para que se produzca una coincidencia potencialmente buena en la coreografía BPEL de los servicios de socio.

    Por supuesto, si se necesitan interacciones más complejas, los protocolos de servicios web incluyen funciones de compensación que se pueden emplear en dichos casos. Si no ocurre ningún imprevisto y puede evitar dichos requisitos en el diseño de la aplicación global, el resultado será más fácil de mantener y probar.

El caso de estudio

Este caso de estudio describe un proyecto de IBM para actualizar la tecnología de la información utilizada por su empresa ServicePac®. El objetivo de este proyecto era aliviar puntos de dolor específicos y colocar la empresa ServicePac® en continua expansión de volumen y funciones.

Como muchas empresas de éxito, ServicePac® de IBM ha pasado por una secuencia de transiciones incrementales, empezando con la combinación de muchos programas de garantía distintos hasta llegar a tres empresas organizadas según el sector geográfico. Posteriormente, se combinaron operaciones geográficamente distintas en una sola operación mundial. A lo largo de los años, la empresa ServicePac® ha agregado continuamente nuevas ofertas como, por ejemplo, servicios de instalación y ofertas para dar soporte a nuevo hardware de IBM. Aunque la empresa ServicePac® sea de por sí una sola operación mundial, su producto, ServicePacs®, se vende en numerosos Business Partners y líneas de empresa de IBM. Cada organización de venta tiene sus propios sistemas de entrada de pedidos adaptados a su línea específica de empresa (y no a ServicePacs®). Estos sistemas representan un auténtico catálogo de tecnologías diferentes creadas en distintas épocas por distintos equipos.

Los sistemas de entrada de pedidos que controlan los ServicePacs® deben realizar validaciones durante el tiempo de entrada de los pedidos según los requisitos desarrollados por la empresa ServicePac®. La validación de ServicePac puede ser compleja. ServicePacs® se ofrece en más de 100 países y las ofertas no son las mismas en todos sitios. Las ofertas de ServicePac® varían dependiendo del modelo de producto, el país en el que se entregan, el canal de ventas, el sistema de entrada de pedidos y la información específica del cliente, como los ServicePacs® que actualmente posee.

Tradicionalmente, la validación de pedidos de ServicePac® se ha llevado a cabo en el sistema de entrada de pedidos, implementando sólo aquellos requisitos de validación que fuesen necesarios para los canales de ventas a los que de soporte el sistema en cuestión. Como la empresa ServicePac® ha crecido, el coste de comunicar los requisitos de validación y coordinar su desarrollo, prueba y despliegue se ha vuelto prohibitivamente caro. Además, la organización de una validación de pedidos correcta en los sistemas de pedidos ha aumentado el plazo de comercialización de nuevas ofertas.

La imagen muestra un enfoque orientado a servicios de la validación de pedidos.

Figura 1: enfoque orientado a servicios de la validación de pedidos de ServicePac®. El enfoque consiste en poner a disposición de todos los sistemas de entrada de pedidos que procesen ServicePacs® un único servicio, en lugar de colocar una lógica de validación específica en cada sistema de pedidos.

Un enfoque orientado a servicios para la validación

Pronto se hizo patente que la validación debía ser responsabilidad de la empresa ServicePac® y no de cada sistema de ventas individual a través del cual se solicitasen los pedidos de ServicePacs®. Las dos opciones que se tuvieron en cuenta fueron distribuir código que encapsulara los requisitos de validación de pedidos a todos los sistemas de pedidos o proporcionar un servicio de validación de pedidos centralizado. Impedir problemas de administración asociados con el enfoque de código distribuido era un importante controlador para seleccionar el enfoque de servicio centralizado.

La mayor y única ventaja de incluir la validación de pedidos como un servicio para sistemas de entrada de pedidos es que éstos ya no necesitarán implementar, probar o ejecutar localmente su propia lógica de validación de pedidos de ServicePac®. Quizás la mayor preocupación (o miedo) proceda de los muchos propietarios de sistemas de entrada de pedidos que tienen ahora una nueva dependencia de tiempo de ejecución en un sistema externo usado por otra organización. Tal como verá a continuación, el beneficio neto de ofrecer la lógica de validación como servicio supera en este caso a los problemas.

A continuación encontrará un rápido resumen de los objetivos de arquitectura del proyecto:

  1. Diseño de interfaz: La interfaz de validación debe estar diseñada para controlar correctamente la evolución anticipada de la empresa (por ejemplo, las nuevas ofertas de productos no deberían normalmente requerir modificaciones de interfaz)

  2. Independencia del protocolo de mensajería: El servicio de validación debería ser accesible independientemente de la plataforma de llamada, el modelo de programación, la capa de transporte de red o las opciones de hardware.

  3. Agilidad empresarial: La lógica de validación se implementó para hacer que los cambios empresariales anticipados fuesen seguros, baratos y rápidos, sin por ello sacrificar el rendimiento y la fiabilidad ni poner en peligro las reglas de diseño fundamentales.

  4. Escalabilidad: La escala a rendimientos más altos debería no implicar reprogramación o pruebas funcionales importantes.

Diseño de la interfaz

Trabajando con el propietario de la empresa y los arquitectos empresariales de todas las partes que gestionan la nomenclatura del producto, se desarrolló una taxonomía autoconsistente y bien documentada para los productos actuales y anticipados. Según la taxonomía, se desarrolló un modelo de datos XML descrito en el lenguaje de esquema XML que expresa todos los tipos de producto necesarios junto con sus atributos. Cuando se ofrecen los nuevos productos, la taxonomía puede cambiar; junto con los cambios de esquema potenciales, no obstante, se espera que el formato de mensaje real permanezca sin cambiar mientras las nuevas ofertas caen con el ámbito de la taxonomía definida.

Este enfoque ofrece a la empresa la flexibilidad deseada para introducir de forma rápida y barata nuevas ofertas. Por supuesto, no cubre todos los casos posibles. Por ejemplo, si una nueva oferta de producto tiene una condición previa que no se ha anticipado en las definiciones de mensaje existentes, las nuevas definiciones de mensaje deberán colocarse en su sitio.

En el listado 1, se muestra la carga de un mensaje de solicitud de validación simple que incluye un único pedido de un solo ServicePac® para un sistema propiedad del cliente identificado por su número de pieza y su número de serie. El formato de mensaje da soporte a varios pedidos para varios ServicePacs® que podrían estar asociados con hardware nuevo y hardware existente. En algunos casos, los mensajes pueden tener miles de elementos anidados.

Independencia del protocolo de mensajería

Una de las grandes ventajas de usar BPEL es que las relaciones de mensajería entre los servicios se describen de forma abstracta en WSDL, lo que proporciona un grado de independencia del protocolo de mensajería. Para aprovechar al máximo este dispositivo, uno debe evitar totalmente crear implementaciones que dependan de características específicas del protocolo de mensajería que se utiliza durante el desarrollo. Por ejemplo, si se utilizan vínculos de EJB durante el desarrollo, el estilo de programación puede producir pequeños intercambios de mensajes disparejos (por ejemplo, intercambio frecuente de pequeños mensajes). Si, posteriormente, el vínculo se cambia a JMS o SOAP sobre HTTP, es probable que se produzca un grave atasco de rendimiento como resultado de una mayor sobrecarga por mensaje en estos protocolos. En este caso, el impacto de moverse entre vínculos se puede reducir siguiendo un estilo de programación en el que los intercambios de mensajes tengan mayor granularidad (por ejemplo, intercambios relativamente infrecuentes de cuerpos de mensaje más grandes), para que la sobrecarga de creación y recepción de mensajes se pueda amortizar con más datos.


<?xml version="1.0" encoding="UTF-8"?>
 <spkOrderDataList>
  <header>
   <orderReference>1040-5124-001</orderReference>
   <orderDate>2004-08-15</orderDate>
   <orderingSystem>WEB</orderingSystem>
   <country>US</country>
   <distributionChannel>A</distributionChannel>
   <headerReturnCode/>
  </header>
 <spkSegmentList>
   <orderItemReference>102</orderItemReference>
   <spkPartNumber>69P9921</spkPartNumber>
   <spkType>WMAINTOPT</spkType>
   <spkQuantity>1</spkQuantity>
   <hardwareQuantity>1</hardwareQuantity>
   <spkReturnCode/>
   <hardwareSegment>
    <serialNumber>77X9182</serialNumber>
    <hardwareIdentifier>8676M2X</hardwareIdentifier>
    <hardwareReturnCode/>
   </hardwareSegment>
 </spkSegmentList>
 </spkOrderDataList>
</ServicePacData:validationRequest>

Listado 1 - Ejemplo de mensaje sencillo recibido por el servicio de validación compuesto de un único pedido de un solo ServicePac® que se aplicará a un sistema existente identificado mediante su número de pieza y su número de serie. El servicio de validación devuelve el mensaje recibido anotado con códigos de verificación o códigos de error. El componente de la invocación puede proporcionar sus propios números de referencia para permitirle correlacionar la solicitud y la respuesta.

Otro hecho que debe tenerse en cuenta en la independencia del protocolo es el estilo de mensaje. En este proyecto las necesidades futuras de mensajería asíncrona se solucionan creando definiciones de mensaje de validación con un campo (actualmente sin explotar) para correlacionar mensajes de solicitud y respuesta, aunque todo el uso actual sea síncrono y, por lo tanto, no necesite correlación. La solución de tales problemas abarca normalmente el diseño de mensajes y el diseño de aplicaciones.

Agilidad empresarial

Fundamentalmente, el servicio de validación de ServicePac® acepta un pedido y devuelve información sobre si el pedido es válido o no, y si no es válido, por qué no lo es. Sin embargo, la clave consiste en minimizar el impacto de volver a diseñar, probar y ejecutar cuando se necesita hacer modificaciones en respuesta a nuevos requisitos empresariales. Por supuesto, resulta útil tener una idea de cuáles serán probablemente los nuevos requisitos al diseñar la implementación inicial.

Detalles iniciales de implementación:

El servicio de validación extrae la información detallada del pedido de ServicePac®, consistente en: tipos de ServicePac®, hardware al que debe aplicarse, ubicación de entrega (país) del ServicePac®, canal de ventas y datos del cliente. La lógica empresarial coteja entonces la información del pedido con un conjunto de declaraciones suministradas por la empresa ServicePac®. El conjunto de pruebas que debe aplicarse a un pedido depende de los detalles del pedido. Algunas pruebas requieren acceso a datos adicionales que sólo están disponibles desde sistemas remotos.

Existen tres tipos de datos necesarios para validar un pedido: datos de referencia propiedad de esta aplicación, datos de referencia almacenados en la memoria caché propiedad de otros sistemas, y datos reales que deben obtenerse de otros sistemas cada vez que se valida un pedido.

A los datos de referencia propiedad de esta aplicación se accede a través de un servicio de socio creado como parte de esta aplicación. Este servicio también se encuentra disponible en otras aplicaciones que necesitan acceder a los datos de referencia propiedad de esta aplicación.

Los datos de referencia propiedad de otras aplicaciones se suministran accediendo a un servicio de socio creado como parte de esta aplicación. Siempre que puede, el servicio de socio almacena en la memoria caché los datos obtenidos de la otra aplicación para minimizar el número de accesos de red. Al ubicar la estrategia de almacenado en memoria caché dentro del servicio de socio, podrá cambiarse cuando sea necesario y en cualquier momento sin que sea necesario realizar ningún cambio en el resto de la aplicación.

Los datos y los resultados intermedios que sólo deben almacenarse durante el ciclo vital de una solicitud de validación se almacenan en variables BPEL. El uso de variables BPEL elimina la sobrecarga de accesos evitables a servicios de socio y, por lo tanto, puede mejorar el rendimiento global.

La imagen ilustra una vista topológica de la implementación controlada por flujo de trabajo de la lógica empresarial.

Figura 2: vista topológica de la implementación controlada por flujo de trabajo de la lógica empresarial que selecciona cuáles de las pruebas con gran carga computacional o datos intensivos deben realizarse para validar un determinado pedido. Todos los sistemas de entrada de pedidos que necesiten validar pedidos usan la misma interfaz de servicio.

En este punto pasamos a investigar la naturaleza de los nuevos requisitos que se pueden anticipar a partir de discusiones con la empresa y observando las tendencias históricas.

A medida que la empresa ServicePac® se expande, se crean nuevas pruebas empresariales de validación de ServicePac®; no obstante, no se espera que las pruebas existentes cambien. La validación de nuevos productos requiere la evaluación de una nueva agrupación de pruebas existentes y posiblemente nuevas.

Este conjunto de requisitos es un hallazgo para sistemas controlados por flujo de trabajo en los que el flujo de trabajo se utilice para unir conjuntos de pruebas necesarios para cada tipo de producto. Los aspectos de las pruebas con gran carga computacional o de datos intensivos podrán desarrollarse en tecnología menos flexible pero más eficaz y presentarse como servicios de socio disponibles para el motor de flujo de trabajo central, tal como se muestra en la figura 2.

Cuando se agregan nuevas ofertas empresariales al sistema de validación, se modifica el flujo de trabajo para poder acceder a los servicios de socio existentes (y a los servicios de socio posiblemente nuevos necesarios para dar soporte a la nueva oferta). Suponiendo que los servicios de socio se hayan segmentado correctamente al principio, esta arquitectura exhibe un modo aditivo muy atractivo en el que los nuevos requisitos no necesitarán mucha reaprobación ni recodificación de la función anteriormente implementada.

Escalabilidad

Como la aplicación BPEL se despliega en una pila de middleware madura que ofrece agrupación en clúster como opción de configuración, resultaba sencillo mover el proyecto de validación de ServicePac® a una base que se pueda fácilmente escalar agregando nuevo hardware cuando sea necesario. Por supuesto, la arquitectura global de invocación a los servicios de socio desde un motor de flujo de trabajo encaja perfectamente en el modelo de agrupación en clúster.

Como punto característico, este servicio es idempotente ya que las llamadas a este servicio no tienen efectos colaterales detectables por el interlocutor. Por consiguiente, si una llamada de servicio devuelve un error o no se puede realizar, no será necesario que el cliente de servicio tome ninguna acción de recuperación de errores. En realidad, el cliente de servicio puede, de forma segura, reintentar hacer una llamada en cualquier momento. El hecho de que los servicios de socio también sean idempotentes simplifica enormemente los factores asociados con la escala del proceso mediante agrupación en clúster, ya que la recuperación de errores es relativamente simple y la recuperación y el reinicio tras una anomalía sencillos. Además, no será necesaria la "afinidad del interlocutor", ya que cada interacción es atómica y no existe ningún almacenamiento en caché específico del interlocutor asociado con el procesamiento de una solicitud.

La aplicación de flujo de trabajo y BPEL

BPEL4WS (Business Process Execution Language for Web Services) es un modelo de lenguaje y programación específicamente diseñado para ejecutar lógica empresarial basada en flujo de trabajo que implique coreografía de los servicios web. BPEL es un estándar abierto para muchas implementaciones de proveedor de herramientas de montaje y tiempos de trabajo.

La posibilidad de describir el proceso empresarial de ServicePac® a través de un diagrama de proceso esquemático y, a continuación, representar la lógica de la implementación usando los estándares basados en constructos BPEL4WS suponía la combinación perfecta de flexibilidad y aislamiento para implementar una lógica empresarial de ServicePac® flexible.

Para este proyecto, elegimos IBM WebSphere Application Developer Integration Edition (WSADIE) como entorno de montaje. Los artefactos de código desarrollados estaban destinados a ejecutarse en el tiempo de ejecución de IBM WebSphere® Business Integration Server Foundation v5.1.1, que proporciona un motor de ejecución de procesos empresariales para ejecutar posteriormente el flujo de trabajo. Los datos se alojan en un servidor DB2 (v8.1).

Las pruebas individuales necesarias para la validación de ServicePac® se implementaban como Enterprise Java Beans, en concreto como beans de sesión sin estado, que se ejecutaban en el contenedor EJB de WebSphere® Application Server. Las herramientas de WSADIE facilitaban la integración de estos EJB como servicios web a través de la generación automática de archivos WSDL. Como consecuencia, las pruebas individuales se pueden desplegar dentro del mismo contenedor como proceso BPEL, o en contenedores dedicados de otras instancias de servidor.

La imagen ilustra el flujo de trabajo según lo descrito por un editor BPEL gráfico.

La figura 3 muestra una vista del editor BPEL de gráficos del flujo de trabajo de validación. La herramienta da soporte a la contracción de subprocesos y bucles para simplificar el trabajo en la información detallada de piezas individuales del flujo de trabajo global.

La figura 3 muestra el proceso BPEL completamente ampliado que se utiliza para controlar los servicios de validación de ServicePac® tal como aparece en la herramienta de creación y edición WSADIE BPEL.

Se realizaron importantes mejoras de rendimiento cuando se modificó una implementación anterior del proceso de flujo de trabajo de validación de ServicePac® para aprovechar el uso de variables BPEL y mantener los resultados intermediarios en lugar de realizar llamadas adicionales al servicio de socio. Puede ver un ejemplo de este enfoque en la figura 3; en él, la lista de pruebas que se vaya a realizar en cada elemento de un pedido se conserva en una variable BPEL.

Pros y contras globales del diseño

Pros
Contras
1. Agregación de nuevas ofertas de forma más rápida y menos cara

2. La agregación de nuevos sistemas de pedidos es menos cara

3. Validación global coherente

4. El uso del servicio de validación se puede realizar escalonadamente a medida que se actualizan los sistemas de pedidos

5. La nueva lógica de validación sólo necesita implementarse y probarse en un sitio.

6. La lógica de validación es propiedad de la empresa ServicePac® y no se distribuye en varios sistemas extranjeros.
1. Dependencias entre organizaciones de tiempos de ejecución adicionales

2. Sobrecarga de rendimiento en forma de latencia de red adicional

3. Necesita transformación de los sistemas existentes

4. Se ha creado un nuevo componente centralizado que puede actuar potencialmente como único punto de anomalía para varias aplicaciones.

En el caso de la aplicación ServicePac®, las ventajas descritas anteriormente parecieron ofrecer un valor significativo y los contras eran todos contenibles. Como a los interlocutores individuales se les permite la validación privada continua hasta que pasan a una actualización programada que cubra muchos problemas, el trabajo de programación adicional de empaquetar los datos para una llamada de validación es un pequeño incremento que se puede contener en el ámbito global del proyecto de la aplicación de llamada. Con aquellos servicios en línea que tienen requisitos de tiempo de respuesta que no pueden ser satisfechos por el servicio de validación, el interlocutor puede realizar validación preliminar en línea (con un único acceso de validación final al servicio de validación). Esta estrategia conserva los factores humanos de la aplicación de llamada mientras, al mismo tiempo, conserva la integridad de todo el proceso de solicitud de pedidos de ServicePac®. En algunos sistemas existentes que no albergan la posibilidad de protocolo de servicios web internos, se creó un convertidor que acepta un protocolo privado y lo convierte en una llamada de servicios web (se creó un documento específico del proveedor en el adaptador de servicios web para uno de los interlocutores de este proyecto). La prueba y demostración de la solidez del servicio ha disipado el miedo a atascos de rendimiento presentados por el servicio de validación. Mediante el uso de tecnología de agrupación en clúster, se puede aumentar el rendimiento del servicio muy rápidamente en casos necesarios. Por último, si no ocurre ningún imprevisto, la concentración de la lógica de validación en una sola implementación significa que el dinero que se gastaría en desplegar y probar varias implementaciones independientes se puede gastar en probar y desplegar una sola implementación que pensamos que hará más por compensar los problemas asociados con tener un solo punto de anomalía adicional para muchos sistemas de entrada de pedidos distintos.

Por último, la posibilidad de que la empresa se apropie realmente de los requisitos de validación y de su implementación, para extender rápidamente nuevas ofertas, y para asegurar la validación de pedidos coherente y correcta al principio del proceso de solicitud de pedidos, ha conferido poderes a la empresa para que se enfrente a nuevas oportunidades que anteriormente resultaban técnicamente irrealizables o prohibitivamente caras.