BPEL vs OSB (Oracle Service Bus)

A continuación voy a traducirles el artículo BPEL vs OSB de The SOA mythbusters blog:

Entonces, ¿trabajas con Oracle SOA Suite ?, eso es genial porque también lo hacemos, todos los días desde hace mucho tiempo. Como profesionales de Oracle, hemos visto a SOA crecer, cambiar, incorporando nuevos productos y tecnología con cada versión, desde la 10g a la 12c.

Somos Rolando Carrasco (Oracle ACE) y Arturo Viveros (Oracle ACE Associate), los SOA Myth Busters de México, y como vamos con esta serie pondremos a prueba una serie de preguntas, mitos y leyendas urbanas con respecto a SOA y la Plataforma SOA de Oracle, en busca de descubrir qué mitos son verdaderos y cuáles no.

BPEL vs OSB

En este episodio, nos sumergiremos en uno de los argumentos más candentes que los practicantes de SOA de Oracle han estado sosteniendo a lo largo de los años: BPEL contra Oracle Service Bus. ¿Pueden y deberían trabajar juntos? ¿Es uno de ellos mejor que el otro? ¿Hay alguna guía bien fundada en la que pueda confiar para decidir entre ellos? ¿Y qué hay de SOA Suite 12c? Alrededor de este tema parece haber un montón de mitos, malentendidos y conceptos erróneos, así que vamos a conseguirlo y descubrir la mayor cantidad de la verdad como sea posible.

Empecemos

En primer lugar, las dos cosas que estamos comparando son más o menos las normas antes que los productos.

BPEL – Business Process Execution Language. Es un estándar para la orquestación de servicios, entregado y mantenido por OASIS. Se hizo popular a principios de los años 2000. Muchas empresas de software, como IBM, Oracle, han estado trabajando activamente en la mejora del estándar. Muchas compañías de software ofrecen productos que soportan este estándar. Por ejemplo: Oracle BPEL PM.

Oracle Service Bus (también conocido como Enterprise Service Bus). Desde los viejos tiempos de integración y EAI, el concepto de tener algo en el medio para poder intercomunicar sistemas heterogéneos y servicios ha estado presente. Este ESB como estándar, debe apoyar: Enrutamiento dinámico, Mediación, Virtualización, Enriquecimiento de Contenido, Invocación de Servicio, etc. Una buena manera de empezar a aprender sobre el estándar de un Bus de Servicio, es el libro de David Chappell “Enterprise Service Bus” http://shop.oreilly.com/product/9780596006754.do ). Este libro ya tiene 10 años, pero David representó muy bien lo que es un Bus de servicio, y todos los conceptos son actuales a nuestros días.

Ahora, ocurre que Oracle tiene un producto con el nombre Oracle BPEL Process Manager y otro llamado Oracle Service Bus. Eso es lo que puede añadir un poco más de confusión a la comparación. Y esta pregunta: ¿debo usar BPEL o Oracle Service Bus? Es una duda común dentro de los profesionales de SOA de Oracle y pensamos en cualquier otra compañía de software que soporte estos dos estándares.

Un poquito de historia

Así que vamos a empezar a mirar esto desde una perspectiva histórica. Necesitaremos retroceder en el tiempo unos cuantos años, para intentar localizar la fuente de la controversia antes mencionada e identificar algunos mitos.

Recordamos nuestros primeros años con estas tecnologías, fue en 2003-2004, cuando Oracle lanzó Oracle BPEL PM. En esos días, Oracle tenía algo que ofrecer en el espacio de integración: Oracle Interconnect. Pero no era tan popular. Cuando Oracle lanzó BPEL PM, cambió todo. Cambió muchas carreras profesionales, así como cambió el mercado.

Oracle aún no tenía un producto muy parecido a un ESB, pero sí tenía Oracle BPEL PM. Con ese producto fue capaz de competir en la etapa de orquestación contra jugadores como BEA Weblogic Integration, TIBCO y Web Methods.

Desde entonces, Oracle BPEL PM (se refiere a la herramienta, no al estándar) era capaz de: enrutar llamadas, enriquecer mensajes, virtualizar el acceso a otros servicios, modelar datos / transformar formatos a través de adaptadores a sistemas EIS como SAP, Oracle EBS, PeopleSoft, Siebel, Mainframe, etc. Oracle no había comenzado el alboroto de la compra de PeopleSoft, Siebel, etc. por lo que no había una estrecha integración con ellos. Fue sólo adaptadores y esta herramienta que fue capaz de comunicarse fácilmente con ellos.

A medida que pasaba el tiempo, una combinación de presión del mercado y tendencias del sector, hizo que Oracle incluyera en la versión 10g de SOA Suite (año 2007) algo llamado: Oracle Enterprise Service Bus (OESB). A continuación, Oracle pudo finalmente decir: nosotros tenemos como parte de nuestros productos un bus de servicios empresariales.

Tan extravagante como sonaba, esta versión anterior de la ESB de Oracle era de alguna manera limitada y nunca realmente calificada como un producto de la mejor-raza. Además, nunca se presentó bien con arquitectos, desarrolladores y administradores que lo encontraron un poco complicado y hostil.

Por lo tanto, parece que hemos identificado un primer hito en esta discusión BPEL vs OSB. Una versión temprana del SOA Suite que hemos llegado a conocer (10g), que incluye:

• Un producto ya robusto y muy querido basado en un estándar de la industria (BPEL)
• Un ESB por debajo de la media como un componente opcional de la suite

En ese momento, Oracle ESB (OESB) terminó sin ser muy utilizado en la mayoría de los proyectos de integración fuera de las implementaciones de AIA. Por el momento y el estado de los requisitos de la industria, BPEL podría existir y funcionar principalmente por cuenta propia.

Luego en 2008, Oracle compra BEA Systems, y con esta adquisición entramos en un segundo hito relevante: La liberación de Oracle SOA Suite 11g a mediados de 2009. Esta pila nueva y renovada introdujo algunos cambios muy relevantes:

1. Oracle WebLogic Server como plataforma de tiempo de ejecución para todas las herramientas incluidas en la Suite.
2. Oracle Service Bus (basado en el antiguo BEA AquaLogic Service Bus) viene como un verdadero ESB capaz de posicionarse como uno de los líderes del mercado.
3. 10g ESB (OESB), es renombrado como “Mediador” y permanece como un componente opcional de la Suite.

Esto demostró ser un gran paso de Oracle, y desde el punto de vista de tecnología / arquitectura dio a los componentes su peso específico. Ahora, los estándares / capacidades de Enterprise Service Bus estaban muy bien identificados dentro de Oracle Service Bus. Pero si su iniciativa SOA incluía orquestación, monitoreo de actividades empresariales, reglas de negocios, Oracle SOA Suite con el resto de los componentes, era una excelente opción.

Con esta nueva pila, OSB podría incluso ser licenciado por su cuenta para los clientes que querían tener el ESB solo como piedra angular para su implementación SOA, aunque el escenario más habitual es que los clientes tengan tanto la suite SOA como la OSB como parte De un multifacético y bien complementado SOA Toolkit.

Por otra parte, la rebranding de OESB despertó cierta confusión y de otro modo se sintió un poco como una degradación para un producto titular que no pegó y fue reemplazado por una herramienta más poderosa.

Por último, volviendo al presente nos encontramos meses fuera de un tercer gran hito: SOA Suite 12c. En esta nueva versión principal, la pila se ha realineado de acuerdo con las tendencias actuales de la industria (SOA industrial, Productividad de desarrolladores, Nube y Móvil). Las herramientas están ahora más integradas que nunca y la intención de Oracle es claramente revolucionar la forma en que nos acercamos e implementamos SOA.

En SOA Suite 12c se ha vuelto mucho más evidente dónde y cuándo usar BPEL o Service Bus, o cuándo usarlos juntos. Según Oracle, debería haber menos confusión en torno a esto. Y en la forma en que los IDE, los motores y el monitoreo están integrados en esta versión, las definiciones de la arquitectura deberían estar más claras que nunca.

Así que resumamos todo lo que acabamos de mencionar:

Mirando esta línea de tiempo, uno puede ver fácilmente dónde podría haber surgido mucha confusión a pesar de los mejores esfuerzos de Oracle, especialmente antes de 12c:

• Los desarrolladores de BPEL que han estado trabajando con la herramienta durante mucho tiempo simplemente la adoran, y han visto el producto crecer y evolucionar de manera ordenada y estandarizada, con un IDE constante. Esto a diferencia de un ESB que ha sufrido muchos cambios hasta ahora y no ha sido tan fácil de familiarizarse con él. Esto puede dar lugar a opiniones radicales como: “BPEL es sin duda mejor que el bus de servicio“, cuando un producto como OSB termina siendo descalificado por todas las razones equivocadas.
• Los profesionales de SOA que ya estaban acostumbrados a trabajar con BEA WebLogic Server, WLS Workbench, Aqua Logic, Fuego, etc. son mucho más propensos a OSB y entienden su potencial y capacidades. Incluso pueden encontrarlo más fácil y dinámico que BPEL PM debido a la familiaridad con el IDE y la consola web. “OSB es más amigable que BPEL y Eclipse es un IDE mucho mejor que JDev“. No sería extraño oír una evaluación como esta de un desarrollador realizado con un fondo en la tecnología de BEA.
• Las personas que son más recientes en la pila de Oracle FMW, siempre parecen estar preguntándose cuál de los productos es la mejor alternativa, si están tomando la decisión correcta e incluso si están sobreutilizando o subutilizando uno de ellos. En este caso, en lugar de entender los productos como complementarios entre sí, estaríamos estresando innecesariamente y nos preguntamos sobre cuál elegir.
• Arquitectos y programadores que solían trabajar con las herramientas de un proveedor diferente (IBM, Software AG, TIBCO, etc.) y que ahora están trabajando con Oracle FMW, suelen tener problemas para identificar la pila a primera vista, por lo que tienden a gravitar hacia el Producto que parece ser más familiar y menos problemático para ellos y alejarse del resto sobre la base de su pasado buenas / malas experiencias. Este tipo de escenario a menudo conduce a las opiniones más dispares, tales como: “BPEL simplemente no funciona en absoluto y su uso implica un grave peligro para el cliente, estaremos en mejor situación, utilizando exclusivamente un bus de servicio“. Imagínense la agitación que una declaración como ésta puede producir, especialmente cuando es pronunciada por un “experto” con un largo historial en proyectos de integración.

Pero, ¿es esta controversia realmente sólo una cuestión de percepción, experiencia pasada o incluso trastorno de estrés postraumático? Ya nos hemos hundido lo suficiente en la historia, así que echemos un vistazo ahora a algún otro tipo de hechos.

Patrones de diseño SOA

Vimos en la sección anterior cuánto han madurado los productos con el tiempo. Al mismo tiempo, SOA como una metodología también ha estado evolucionando y madurando a través de una serie de contribuciones de los líderes de la industria, organizaciones de estándares, académicos, profesionales, arquitectos y entusiastas de la tecnología.

Como resultado de estas contribuciones, tenemos un conjunto bien identificado de patrones de diseño SOA: soluciones probadas para problemas comunes.

NOTA:

* Si desea saber más sobre los patrones de diseño SOA, asegúrese de visitar el siguiente sitio para una explicación detallada:

http://www.soapatterns.org/

Aquí vamos a echar un vistazo a algunos de estos patrones y si son más adecuados para ser aplicados por la utilización de BPEL y / o Service Bus:

Sobre la base de la información que acabamos de analizar, definitivamente podemos llegar a una colección de guías bastante precisas con respecto al uso de un producto u otro para ciertos escenarios: Como podemos ver en la tabla, cada herramienta tiene su propio conjunto de capacidades relevantes, algunas de ellas compartidas por ambos. Los adaptadores JCA también pueden ayudarnos a ampliar la funcionalidad nativa de los productos, especialmente en el caso de BPEL.

• Para las actividades de virtualización y corretaje de servicios, utilice OSB
• Para tareas largas y orquestadas con estado, utilice Oracle BPEL
• Para automatizar actividades empresariales basadas en una definición de proceso, utilice Oracle BPEL
• Para incorporar Human Workflow y / o Oracle Business Rules, utilice Oracle BPEL PM
• Para aplicar la centralización de políticas y técnicas de mensajería confiables en los servicios web, utilice OSB
• Para las orquestación de servicios web sin estado y de corta duración utilice OSB
• Para servicios basados en entidades síncronas o operaciones de paso utilice OSB

Esto nos da más claridad, proporcionando la separación apropiada de las preocupaciones sin significar que no podemos usar OSB y BPEL en conjunción para resolver escenarios sofisticados de integración:

• Virtualización de servicios BPEL mediante OSB 
• OSB realiza tareas de mediación en una Composición de Servicio
• Escenario de colas asíncronas con invocación unidireccional de un proceso BPEL a través de OSB

¿Y cómo se ve esto en Oracle SOA Suite 12c?

Después de mirar la perspectiva histórica, algunas de las grandes ventajas de SOA Suite 12c tienen que ver con:

• Estabilidad
• Continuidad
• Madurez

A diferencia de versiones anteriores, no hay un cambio importante en el motor de ejecución, ni en el conjunto de productos que conforman la suite. Esto ha permitido a Oracle concentrarse en mejorar sustancialmente cada una de las herramientas, teniendo en cuenta la retroalimentación de clientes / desarrolladores, así como las tendencias y requerimientos del sector.

Oracle SOA Suite 12c, si acaso, alienta a los profesionales de SOA a usar BPEL y OSB juntos para diseñar e implementar soluciones robustas con la capacidad de proporcionar la flexibilidad requerida, el cumplimiento de SLA y la capacidad de transacción que busca la industria.

Las siguientes mejoras (entre muchas otras) parecen ser las más relevantes a este respecto:

• IDE unificado para BPEL y OSB (JDeveloper)
• Unified Monitoring Console con capacidades de rastreo de extremo a extremo (EM)
• Inicio rápido Paquete de instalación de SOA Suite para desarrolladores incluyendo OSB
• Depurador integrado para BPEL / OSB
• Error Hospital
• MDS integración más estrecha
• Integración continua a través de artefactos de Maven
• Perfiles de modularidad

Conclusión

• Si bien efectivamente hubo un momento en que un producto era más robusto y maduro que el otro en Oracle FMW Stack (BPEL > Service Bus), esto ya no es cierto. Incluso en 11g este punto fue discutible hasta cierto punto, pero en 12c ambas herramientas han sido igualmente mejoradas y alineadas con las tendencias de la industria mencionadas de antemano.
• Algunas de las controversias entre estas herramientas, especialmente entre los desarrolladores, tenían que ver con la presencia de diferentes IDE para BPEL PM y OSB. Esto resultó ser una situación muy poco práctica que ya ha sido atendida en 12c. JDev es ahora el IDE de elección para el desarrollo de componentes Oracle SOA Suite, ya sea con BPEL o Service Bus.
• Aunque BPEL + Service Bus siempre ha sido capaz de trabajar juntos, en el pasado no había necesidad urgente de diseñar soluciones basadas en esta combinación. Por otra parte, la separación de las preocupaciones entre las herramientas no era tan clara como lo es ahora, gracias a la maduración de la metodología SOA. Hoy en día, especialmente con SOA Suite 12c, BPEL & OSB constituyen una combinación excelente y necesaria. Un dúo dinámico cuyas capacidades combinadas nos permitirán afrontar y resolver con éxito los múltiples retos de la SOA industrial, así como aprovechar sus importantes beneficios.