Escribir una 'Singleton' Proceso de BPEL

Un caso de uso típico en BPEL se conecta a un recurso externo / sistema que sólo admiten una única conexión a la vez. En este caso tenemos que proteger contra casos paralelos BPEL presentar solicitudes simultáneas a ese recurso.

Esto implica que necesitamos alguna manera de serializar las solicitudes de ese recurso (probablemente el primero en una base, en primer lugar). Un patrón de diseño común para lograr esto es el Singleton, documentado por primera vez en la Banda de los Cuatro patrones de libro (donde se utiliza una cola de impresión como ejemplo).

Ahora BPEL no apoyaron explícitamente la noción de un Singleton, sin embargo, le permite para simular una, que, a efectos de lo que estamos tratando de lograr es lo suficientemente bueno.

La idea básica es tener una explícita initiateSingleton operación que se utiliza para crear instancias de una instancia de proceso único, y luego dejar separada invokeSingleton operación que se utiliza para presentar cada solicitud real. El invocar la operación se coloca en un bucle, tan pronto como se procesa una solicitud se realiza un bucle de vuelta redonda para la siguiente.

Para este ejemplo, he creado un proceso simple que no pierde de vista el número de veces que se le ha llamado . Se toma un único parámetro, el nombre y devuelve una cadena con el siguiente formato:

Hola . Usted es el número de llamadas de este producto único.

Bastante simple, pero ilustra el punto. El proceso básico se muestra en la siguiente imagen:

La primera actividad en el proceso es una actividad de recibir, InitiateSingleton , que se utiliza para crear una instancia del proceso. Entonces tenemos una asignación simple que sólo pone la cuenta a cero. El resto del proceso, que se encarga de lainvokeSingleton operación se encuentra dentro del ámbito de aplicación ProcessRequest, que a su vez se coloca dentro de un bucle while, que por los siglos de los bucles. Contiene las siguientes actividades:

1. InvokeSingleton - Este recibe la siguiente solicitud para ser procesados por el singleton.
2. Espera - Esta espera por un período de 5 segundos. Es sólo para simular salir a un sistema externo. También nos permite ver el número de solicitudes múltiples para el singleton se cola por el Oracle BPEL PM Server.
3. SetResult - Aquí se acaba de establecer el resultado y el incremento de la cuenta por uno.
4. CallbackClient - Por último que acabamos de enviar el resultado al cliente, antes de bucle de nuevo todo el proceso a la siguiente solicitud.

Mensaje de Correlación

A primera vista todo parece engañosamente simple, sin embargo la complejidad viene cuando tratas de llamar a lainvokeSingleton operación.

La razón es que cuando se invoca una operación en un proceso BPEL, el mensaje es recibido por el Oracle BPEL PM controlador de mensajes, en función de la operación o bien se invoca un nuevo proceso para manejarlo (como con el initiateSingletonoperación) o la vía a través de a la instancia adecuada de un proceso ya se está ejecutando.

Este es donde se pone un poco complicado, cuando recibimos el mensaje para el invokeSingleton operación, a pesar de que sólo tenemos una única instancia del proceso de ejecución BPEL BPEL PM ¿cómo sabemos que es la instancia correcta para dirigir el mensaje? La respuesta es no.

Ahora bajo "normales" las circunstancias, donde tenemos una interacción asincrónica entre dos procesos, Oracle BPEL PM por defecto a usar WS-Addressing para garantizar que los mensajes son enviados con éxito entre dos instancias del proceso. Sin embargo, en estos casos, lo normal es que la interacción entre los dos procesos (por ejemplo A y B) comenzó el proceso A iniciar y B proceso de pasarlo detalles A (utilizando WS-Addressing) sobre sí mismo para que cuando el proceso B devuelve una respuesta que contiene información suficiente para que se encaminen a la instancia adecuada del proceso de A.

Sin embargo, con nuestro proceso de Singleton, cualquier proceso que llama la invokeSingleton operación no tendrá un conocimiento previo de ese proceso, por lo que para nuestros propósitos, no podemos utilizar WS-Addressing para correlacionar el mensaje.

Afortunadamente para los casos en WS-Addressing no es apropiado o disponible BPEL proporciona el concepto de conjuntos de correlación. Básicamente establece correspondencias le permiten utilizar un regalo de valor único en el cuerpo del mensaje de todos los mensajes intercambiados (por ejemplo, idpedido ) para vincular que el intercambio de mensajes relacionados entre sí.

Esto se realiza en BPEL, en primer lugar la definición de una propiedad que se corresponde con el valor único, y a continuación, definir un alias de la propiedad para cada mensaje en el intercambio, que define cuando esta propiedad se encuentra dentro del mensaje. A continuación, definir un conjunto de correspondencias que puede constar de una o más propiedades (ver la documentación del producto o de la SOA Suite de Oracle Developer's Guide para más información sobre cómo crear conjuntos de correspondencias).

Para nuestro propósito, he definido un elemento simple llamado singletonId que figura tanto en el initiateSingleton yinvokeSingleton operaciones.

A continuación se ha definido un conjunto de correspondencias SingletonCS que se utiliza en el InitiateSingleton yInvokeSingelton operaciones.

En el initiateSingleton operación que ha definido este para iniciar el conjunto de correlaciones (ver imagen abajo), este medio que sea, el valor se encuentra con la singletonId en la operación de inicio debe estar presente en el invokeSingletonoperación para que pueda ser enviada a través de la presente instancia de proceso.

La siguiente parte del problema es la respuesta para volver de nuevo a la persona que llama adecuada del proceso. Esto al principio puede parecer extraño, pero recuerdo que pueden tener varios procesos de llamar al singleton, al mismo tiempo, por lo que todos esperan una respuesta. Necesitamos asegurarnos de que cada respuesta se devuelve a la instancia adecuada.

Ahora usted probablemente ya habrá adivinado que tenemos que utilizar los conjuntos de correlación de nuevo (como hemos inhabilitado WS-Addressing para este Link Partner). Esta vez el proceso de llamada tendrá que generar una clave única que pasa en la solicitud ( RequestIP ) del singleton. El singleton entonces devolver esta en la respuesta al solicitante.

Si nos fijamos en la SingeltonAccessor proceso, utilizamos el operador XPath generateGUID para generar este valor.

Especificación de la Dirección de respuesta

Así que ahora todo se ve bien, así que podemos seguir adelante y ejecutar el proceso no; así bastante! Si lo hace, se dará cuenta de esta petición del SingeltonAccessor éxito llega a nuestro proceso de Singleton. Pero alguna razón la respuesta de la Singleton nunca para llegar al SingeltonAccessor, de hecho, si usted toma un examen más detenido de la pista de auditoría Singleton para la actividad de devolución de llamada, verá que en realidad omite la devolución de llamada!

Ahora resulta que se trata de un buen comportamiento racional por la sencilla razón de que el Singleton en realidad no sabe donde enviar sus mensajes de devolución de llamada. Esto es porque en tiempo de diseño el que llama a un proceso asíncrono por lo general no se conoce, y por lo tanto la dirección de devolución de llamada es necesario especificar en el momento de Porra. De hecho si inicia una sesión en la consola de BPEL y examinar el WSDL para devolver la llamada operación, podrás ver que el jabón: ubicación de la dirección de la variable se define como:

http://set.by.caller

Ahora por defecto de Oracle BPEL PM utiliza WS-Addressing para manejar esto, así, cuando invoco un proceso asíncrono, que forma parte de la carga útil SOAP contiene una dirección de retorno para el proceso asíncrono, sin embargo acabamos de discapacitados WS-Addressing para este intercambio de mensajes ya que estamos utilizando conjuntos de correlación.

Así que, ¿cómo garantizaremos la respuesta a la dirección? Bueno una solución sería pasar esto en el marco del mensaje de solicitud y, a continuación parejas el uso de enlaces dinámicos a establecer el replytoaddress .

Sin embargo una manera más simple es definir los replytoaddress propiedad en la PartnerLink para que apunte a la dirección de respuesta. Esto tiene el siguiente formato:

/ PartnerLinkTypeName /] rollName [

Así que en nuestro caso:

http://server:port/orabpel/default/SingletonAccessor/1.0/Singleton/SingletonRequester

Ahora bien, si finalmente implementar esta debería funcionar. Para ejecutar el ejemplo, primero ir a la consola de BPEL e iniciar el proceso Singleton (juego de Id Singleton "Singleton/1.0" ).

Desde la consola de incoar el SingletonAccessor entrar en cualquier valor que desee para la denominación . Usted podría poner en marcha una serie de ellas para ver qué pasa.

Loose Ends

Así que todas las obras, sin embargo hay dos problemas básicos con este enfoque:

• En primer lugar para invocar el Singleton lo que necesita saber el valor de la SingletonId. Esto en nuestro caso se fija en el proceso de SingltonAccessor.
• En segundo lugar, el proceso de Singleton referida solamente devolver un resultado al proceso SingletonAccessor (ya que esto se soluciona mediante la especificación de la replytoaddress). ¿Qué pasa si queremos llamarlo desde otro proceso o cliente de servicios web?

En realidad, la solución a esto es muy sencillo; se utiliza el SingletonAccessor como punto de entrada para acceder al Singleton. Así, el cliente real siempre llamar a la SingletonAccessor .

Así, el cliente nunca tiene que saber la SingletonId , y en segundo lugar como WS-Addressing permanece encendida entre la"real" del cliente y el SingletonAccesor el cliente no necesita preocuparse acerca de los conjuntos de correlación o de especificar unreplytoaddress .

Una última pregunta que usted pueda tener es ¿cómo puedo evitar varias instancias del proceso de Singleton se inició con una equivocación? Pues por qué no intentarlo? Usted verá que todo el tiempo que especifique el mismo valor para la SingletonId , BPEL PM lanzará un "conflicto recibir" la culpa como un equivalente de recibir la actividad ya ha sido habilitado por el original Singleton.

Conclusión

Como podemos ver, la aplicación de un Singleton en BPEL es relativamente sencillo. Si bien esto no es una solución totalmente limpia, se logra el efecto deseado.

Haga clic aquí para descargar ejemplo de trabajo