Nuevas características de Oracle SOA Suite 12.2.1

¡Hola!

A finales del pasado mes de Octubre, Oracle libero la versión 12.2.1 de la Suite de SOA. Tuve la oportunidad de verla en acción durante el OOW15 en San Francisco y puedo decir que tiene características muy agradables y que habíamos estado necesitando desde hace tiempo, sin duda estos cambios nos harán la vida más fácil, sobre todo en relación a las integraciones con cloud, uso de REST y en la localización de puntos de fallo en las instancias.

Estas son algunas de las que puedo recordar:

1.    Soporte de JavaScript en compuestos SOA y Pipelines OSB. Además del soporte de servicios REST en OSB y BPEL que ya se tenía desde la versión anterior, disponemos de una actividad de JavaScript en los flujos BPEL, y otra en los componentes Pipeline de OSB, para manipular el payload con funciones nativas y personalizadas de éste lenguaje sin necesidad de convertir de JSON a XML, es decir, podemos crear orquestaciones BPEL y flujos OSB de tipo REST usando JSON, y trabajar con esta estructura de manera natural con JavaScript.

En este blog pueden encontrar más detalle de cómo usar JavaScript en compuestos SOA, considero que el artículo está muy completo y bien explicado.

2.    Debug para Mapeos XSLT. Ahora las transformaciones XSLT cuentan con la funcionalidad de debug. Se pueden establecer breakpoints para verificar los datos de entrada y salida de las funciones en tiempo de ejecución. Esta funcionalidad está disponible para aplicaciones desplegadas en el servidor local y remoto y para componentes BPEL y Mediator, así como también para proyectos OSB.

3.    Oracle Integration Continuous Availability. Se trata de una solución completa que consta de un conjunto de funcionalidad operativa de la SOA Suite, incluye diagnóstico, performance, disponibilidad, escalabilidad y otros aspectos operativos. El objetivo es proveer herramientas y habilidades para resolver problemas derivados de fallos, y mejorar el desempeño de las arquitecturas que implementamos.  Las siguientes características forman parte de este grupo:

3.1.    In Memory SOA. Cuando creamos un BPEL en JDev aparece una nueva pestaña llamada In Memory SOA, en la cual podemos seleccionar tres opciones de persistencia; inmediate, deferred y faulted. Esta funcionalidad permite usar el caché de Coherence para ejecutar en memoria procesos BPEL no transaccionales y de corta duración. Esto por supuesto ayuda a mejorar el desempeño de estos procesos y libera carga de los recursos que éste pudiera usar, por ejemplo la base de datos. La información del estado de dichos procesos se almacena y se lee en el caché de Coherence de acuerdo a la opción que hayamos seleccionado:

Immediate: El estado del proceso, el flow trace y el audit trace son almacenados todo el tiempo en la base de datos, es decir, se comporta como si la opción In Memory SOA estuviera deshabilitada.
Deferred: El estado del proceso, el flow trace y el audit trace es almacenado inicialmente el caché de Coherence, mientras que un hilo independiente ejecuta la persistencia en la base de datos cada determinado intervalo de tiempo, el default es 5 minutos.
Faulted: El estado del proceso, el flow trace y el audit trace se guardan en la base de datos únicamente cuando ocurre una excepción, y una vez que se haya realizado la recuperación del fallo y la instancia terminó de manera exitosa, se eliminan los registros.

Es importante mencionar que esta opción no está habilitada por default, es necesario establecerla en la consola del Enterprise Manager, y para crear un BPEL con dicha característica, la transacción debe ser notSupported, además de elegir la opción deseada en la pestaña In Memory SOA.

3.2.    Circuit Breaker. Esta funcionalidad está dirigida a los servicios que constantemente no se están disponibles, ya sea por tener bajo desempeño, menores capacidades de recursos o procesamiento, o cualquier otro factor. Estos servicios problemáticos generalmente terminan afectando a los servicios que los consumen, provocando una gran cantidad de instancias con error que terminan en el hospital de errores en busca de recuperación, misma que implica tiempo, y en ocasiones, recuperación manual que no siempre es tan rápida como se desea. Para resolver este tema, Circuit Breaker se encarga de suspender de manera automática el servicio y envía los mensajes pendientes a una cola de mensajes o un archivo, para ser ejecutados más tarde, cuando el servicio se estabilice y sea capaz de procesarlos.

3.3.    Composite Running Instance Patching. Esta funcionalidad permite realizar cambios a un compuesto para crear una especie de parche, desplegar la nueva versión en el servidor, aplicarla a las instancias que aún están en ejecución y recuperar aquellas que hayan tenido error. Para poder crear la versión parche del compuesto es necesario usar el rol SOA Patch Developer del JDeveloper, esto deshabilita automáticamente los cambios que no puedan realizarse en el compuesto. Algunos ejemplos de cambios permitidos son: Cambios en el fault policy, datos de sensores y analíticos, actividades de transformaciones, operaciones Assign, propiedades de adaptadores JCA, entre otros.

3.4.    Integration Workload Statistics. Se refiere a una nueva herramienta que provee la capacidad de generar estadísticas enfocadas a mejorar el desempeño, tuneo y localización de problemas en los recursos del sistema, por ejemplo Datasources o WorkManagers. Toma snapshots periódicamente de las diferentes métricas, en intervalos definidos, y el resultado es almacenado en la base de datos para cada Managed Server del clúster. Con esta información genera reportes, personalizados en rangos de tiempo, y los entrega con formato XML, CSV o HTML.

3.5.    Automatic Service Migration. Esta característica es de utilidad cuando se tiene una infraestructura con varios Manged Servers en clúster y alguno de ellos por alguna razón se cae, lo que comúnmente ocurre en este escenario es que de manera automática se reinicia el servidor completo en otro nodo del clúster, lo cual puede ser lento y requiere un nodo de respaldo en modo pasivo, o bien, que los nodos funcionales asuman la carga de esta acción completa. Con esta funcionalidad se pretende evitar que el proceso de reinicio del nodo sea lento y afecte el desempeño del resto, por lo que se toma acción ante el fallo del nodo al únicamente migrar la función de los servicios singleton tales como JTA y JMS, hacia algún nodo en ejecución. Esto reduce el tiempo de recuperación de fallos y costos de infraestructura.

Bien, pues espero que con esto quede mejor entendida esta nueva versión. Pronto estaré realizando algunos ejercicios con ella para ver que tal está, sobre todo en relación a JavaScript.

Hasta pronto.


Si te interesa conocer más de ésta y otras tecnologías de Oracle, te recomiendo que visites la página de Oracle Technology Network Latinoamérica http://www.oracle.com/technetwork/es. Aquí podrás encontrar artículos, información, actividades y muchas otras cosas más, además de poder acercarte a los expertos en varios idiomas.