Oracle Service Bus 12c. Split-Join

Desde versiones pasadas de Oracle Service Bus, ha existido la funcionalidad de Split-Join.

La funcionalidad está enfocada a poder realizar orquestaciones adentro del Bus, con el afán de ofrecer procesamiento en paralelo y que esto derive en mejores tiempos de ejecución, performance, etc.

Imaginemos un ejemplo tradicional en una empresa de telecomunicaciones, en donde es necesario manejar información de las órdenes. Si la info tiene que ir a diferentes sistemas, y este trabajo lo hacemos de manera secuencial, el servicio tardará la suma de tiempos de cada uno de los sistemas en cuestión. El Split Join viene a ayudar en situaciones de esta naturaleza, donde los datos pueden ser entregados en paralelo a cada uno de los sistemas, de manera que el tiempo de ejecución se reduce al tiempo máximo de respuesta de alguno de los sistemas en cuestión.

La siguiente imagen describe muy bien el procesamiento en paralelo al que me refiero:

El ejemplo es que la orden debe activar tanto el DSL como la línea telefónica. Esto lo realiza en paralelo, y puede ser implementado como parte de un Split Join de Service Bus.

A partir de que Oracle adquirió a BEA Systems, se dieron varias discusiones sobre que era mejor: usar BPEL o bien Service Bus. ¿Cuándo usar BPEL y cuándo al BUS? Incluso en ese entonces Oracle contaba con un producto llamado Oracle Enterprise Service Bus, lo cual hacía aun mas confusa la situación.

Con el paso del tiempo nos fuimos acomodando cada vez mas a las capacidades del Service Bus, si embargo aun puedes encontrar esos puntos de intersección entre funcionalidades entre herramientas. La idea de esta entrada en Oracle Radio no es clarificar ni establecer reglamentos de cuándo usar uno u otro. Si tienes una buena metodología, podrás y sabrás identificar cuándo usar al Bus y cuando a la SOA-INFRA.

La intención de esta entrada es resaltar el uso del Split-Join, que, en definitiva,  nos puede servir para realizar orquestaciones adentro del Service Bus, sin tener que ir hasta la SOA Infra (BPEL) a realizarlas. Esto tiene impactos en varios sentidos:

1. El propio viaje entre el BUS y la SOA Infra. Esto se marca mas en 11g, pues en 12c todo está muchísimo mas integrado. Incluso el engine del BUS y de la SOA-INFRA están montados en el mismo managed server.
2. Evitar instancias innecesarias del lado de la Base de Datos de la SOA-INFRA. Pues ya no estaremos ejecutando compuestos para estas pequeñas orquestaciones. Esto es un ejemplo claro en muchas implementaciones
3. Velocidad de procesamiento

Veamos un poco de esto ya en la herramienta.

Imaginemos este Proxy que contiene a un Split Join, que a su vez manda a llamar a un Business Service:

El Business Service es un compuesto que contiene un BPEL que realiza ciertas actividades.

La idea es que el Split Join, mande llamar en paralelo a dicho Business Service:

Podemos ver que es un flujo muy simple con una actividad en paralelo:

La actividad en paralelo simplemente manda a llamar a nuestro Business Service. Después junta la ejecución de las tres y ahí termina.

Esto puede sonar familiar para quienes llevan trabajando con BPEL. Pues finalmente la capacidad de procesamiento en paralelo existes desde varias versiones atrás del estándar BPEL, representado con un FlowN y en versiones mas recientes, con un ForEach.

Incluso, para sorpresa de algunos, este flujo de Split Join tiene BPEL por abajo. Mira:

Ese es el source del flujo de Split-Join. No es mas que BPEL. Esto quiere decir que el engine del OSB, ejecuta BPEL en este tipo de situaciones. Esto no es algo nuevo, desde la versión 10g y la 11g  lo hace así.

Si ejecutamos nuestro ejemplo, veremos cómo el Servicio está expuesto como un Proxy, después pasa por el Split Join y finalmente llega en paralelo a un BPEL. Por lo que en el Enterprise Manager vamos a ver tres instancias nuevas del compuesto, con la gran diferencia que en 12g, podemos ver la relación de la invocación del Proxy; dando así la traza completa de ejecución.

Para los que recién están incursionando en la versión 12c, verán que los engines de OSB y SOA-INFRA pueden ser vistos desde el EM:

Si vamos a la carpeta del Service Bus veremos a nuestros proyectos:

Ahí podemos probar directamente a nuestro Proxy:

Damos click en Probar:

Ahora vamos a ver las instancias generadas en el compuesto, debemos ver tres al mismo tiempo:

Si abrimos cualquiera de las tres, las debemos ver ligadas pues las tres se originaron desde el mismo consumidor, en esta caso: el Split Join:

Otra cosa muy relevante en esta versión, es que vemos cómo se originó desde el Service Bus, y además existe en la parte superior derecha un nuevo identificador de instancia, llamado: Identificador de Flujo. Este es constante desde el Service Bus, hasta la SOA-INFRA.

El Split Join sigue existiendo en 12c, es incluso una funcionalidad principal, cuando tú generas un proyecto de OSB, una de las opciones mas claras y principales que te muestra el JDEV, es la del Split Join:

Quizás es una opción que no le ponemos mucha atención, o no se la poníamos, pero en definitiva tiene grandes bondades y puede ayudarte a mejorar la construcción de servicios así como el performance de los mismos.