Oracle Cloud Integration: "Seleccin de Patrones de Diseo"

Por Joel Prez

& Arturo Viveros

Publicado en Febrero 2015

ndice de artculos de esta serie:

Parte 1: "Introduccion"
Parte 2: "Cloud to Cloud"
Parte 3: "On Premise to Cloud"
Parte 4: "Seleccin de Patrones de Diseo"

Amigos de la comunidad OTN, reciban un cordial saludo. En esta cuarta y ltima entrega de la serie "Oracle
Cloud Integration", revisaremos una seleccin de patrones de diseo, los cuales nos facilitarn la
implementacin de los escenarios expuestos en los dos artculos anteriores:

Cloud 2 Cloud
On-Premise 2 Cloud

Estos patrones son soluciones comprobadas ya sea para resolver o mitigar la problemtica derivada de la
integracin Cloud. Adems de describirlos, tambin vamos a relacionarlos con herramientas apropiadas
dentro del Stack de Oracle, las cuales deberan permitirnos trabajar en funcin de dichas tcnicas. La lista
de patrones a revisar en este artculo es la siguiente:

Arquitectura de Broker Multi-Canal

Arquitectura de Manejo de Estados en BD

Arquitectura de Agentes de Servicio

A continuacin el detalle de cada una de estas Arquitecturas:
Arquitectura de Broker Multi-Canal
La integracin con servicios Cloud, puede conllevar en muchas ocasiones la interaccin entre dispositivos,
componentes y/o protocolos ampliamente diversos. Esto provoca incompatibilidad entre los participantes de
dichos escenarios, creando la necesidad de incluir lgica de transformacin/conversin de la informacin que
es transmitida al ejecutar los servicios involucrados.
Una forma de resolver este tipo de problemtica es mediante la codificacin de interfaces que van a hacer
las funciones de intrpretes y nos van a permitir comunicar servicios al estilo de una Arquitectura EAI
(Enterprise Application Integration) a la antigua:

Sin embargo, adems de que esto probablemente nos hara caer en un tema de integracin punto a punto, del
cual ya hemos visto las desventajas en artculos anteriores, estaramos obligados a hacer un esfuerzo
adicional grande cada vez que se integra un nuevo jugador a esta arquitectura. Este ltimo punto puede
implicar tiempos, costos y riesgos que nuestra organizacin no est dispuesta a correr tratndose de una
Arquitectura Cloud.
Bajo estas necesidades, nuestra estrategia de integracin no puede ser tomada a la ligera y debera
corresponder a un paradigma mucho ms moderno, que nos permita ser flexibles y dinmicos en cuanto a la
forma en la cual nuestras aplicaciones se comunican.

Es aqu donde encaja el patrn de diseo del que estamos hablando (Multi-Device Broker), el cual lo vamos a
implementar a partir de un componente especfico que al incorporarlo a nuestra Arquitectura ya traiga consigo
de forma inherente las capacidades que vamos a necesitar.

En este caso, necesitamos una herramienta que cuente con al menos un subconjunto de las siguientes
capacidades out-of-the-box:

Traduccin de tipos de datos

Traduccin de esquemas

Traduccin de protocolos

Capacidad de comunicacin asncrona

Enrutamiento dinmico

Soporte a estndares WS* (Security, Reliable Messaging, Addressing)

Composicin de servicios

Etc.
La Arquitectura de Broker Multi-Canal, que vamos a implementar a partir de dicha herramienta, facilitar y
simplificar la transformacin de mensajes en tiempo de ejecucin, haciendo nuestros servicios accesibles a
un amplio rango de consumidores.
Arquitectura de Manejo de Estados en BD
Es bastante comn que los servicios involucrados en Arquitecturas Cloud, participen en transacciones de
larga duracin, dentro de las cuales los tiempos de espera para poder continuar con alguna actividad pueden
ser impredecibles pues dependen de algn componente que est fuera del entorno controlado en el cual se
encuentra nuestro servicio.
Lo anterior puede provocar que tengamos la necesidad de almacenar gran cantidad de informacin en
memoria, consumiendo y bloqueando recursos de cmputo valiosos. Bajo estas condiciones, diramos que
nuestro servicio es stateful, es decir, que mantiene su estado en memoria durante todo el transcurso de su
ejecucin:

Esto se vuelve especialmente peligroso en escenarios que involucran gran nmero de instancias en ejecucin
de manera concurrente.
Lo que necesitaramos para prevenirnos de una circunstancia de esta magnitud, sera tener algn tipo de
mecanismo para almacenar el estado de las instancias mientras estas se encuentran en espera. Dicho
mecanismo bien podra ser una base de datos tradicional, o incluso una grilla de memoria que nos permita
depositar y recuperar de forma dinmica la informacin almacenada:

La idea es que nuestro servicio pueda hacer transicin hacia un estado stateless y recuperar dicho estado
en cualquier momento a lo largo de su participacin en las actividades requeridas por la integracin cloud.
A esta tcnica se le puede llamar comnmente deshidratacin o bien serializacin de objetos.
Arquitectura de Agentes de Servicio
Los agentes de servicio son programas dirigidos por eventos, los cuales no tienen un contrato en particular ni
estn expuestos para ser invocados directamente, y estn diseados para interceptar mensajes en tiempo de
ejecucin.
Existen dos tipos bsicos de agentes de servicio:

Activos: Estn configurados para realizar acciones despus de interceptar y leer los contenidos de
un mensaje. Dichas acciones pueden incluir hacer cambios tanto en los encabezados como en el contenido
del mensaje, o bien re direccionar el mismo.
Pasivos: Este tipo de agentes no transforman el mensaje o alteran su contenido de forma alguna,
simplemente lo interceptan y leen parte de su contenido. Normalmente realizan funciones de monitoreo,
registro o reporting.
Los agentes son importantes para la integracin cloud, ya que constituyen componentes muy ligeros, seguros
e invisibles para los consumidores de un servicio cloud, a los cuales se les pueden delegar funciones
altamente especializadas tales como:

Enrutamiento

Monitoreo

Validacin

Seguridad

Balanceo de Carga

Etc.

La imagen anterior nos muestra una serie de agentes, los cuales pueden residir tanto en el entorno de nuestro

servicio como fuera de l, y a los cuales se le ha designado para realizar una serie de tareas importantsimas
pero que nada tienen que ver con el propsito funcional del servicio en cuestin.
Al ocupar este tipo de arquitectura, tambin estamos promoviendo el desacoplamiento y abstraccin de
nuestros servicios.
Conclusiones
Finalmente, la pregunta es, existen herramientas en el Stack de Oracle que puedan proveer este tipo de
funcionalidades?
La respuesta es: si, definitivamente a continuacin analizaremos algunas herramientas que bien podran
proveer las caractersticas que buscaramos para implementar los patrones ya descritos:
Oracle Service Bus (Broker Multi-Canal)
El Bus de Servicios de Oracle es un componente fundamental para la implementacin de Arquitecturas
Orientadas a Servicios (SOA), por lo que est equipado para realizar transformaciones simples o complejas
entre distintos esquemas de datos (XSD), as como para mapear distintos tipos o bien traducir entre los
diversos protocolos soportados (SOAP, JMS, FTP, etc.). Adicionalmente, nos permite virtual-izar y
orquestacin de servicios, incluyendo la comunicacin asncrona y soporte para la mayora de estndares
WS*.

Al incluir OSB como parte de nuestra Arquitectura de Integracin Cloud, nos aseguramos de que los mensajes
puedan ser procesados, en-rutados y resueltos correctamente a pesar de que provengan de diversas fuentes
y/o dispositivos.
BPEL Process Manager (Arquitectura de Manejo de Estados en BD)
Otro componente de Oracle SOA Suite que se acopla perfectamente a la Arquitectura de Integracin Cloud, es
BPEL Process Manager. Esta herramienta nos permite la composicin de servicios bajo el estndar SCA, y es
especialmente apropiada para escenarios que incluyen transacciones asncronas de larga duracin con
esperas prolongadas e impredecibles en el transcurso de la ejecucin.

BPEL ocupa, justamente como el patrn de diseo revisado lo indica, una base de datos para deshidratacin
de sus instancias. En este caso, el dehydration store forma parte integral del repositorio de producto, y los
mecanismos que BPEL utiliza y dispara para llevar a cabo esta tcnica son automticos, lo que nos liberara
de cualquier tipo de programacin adicional para lograr este comportamiento.

Oracle API Gateway (Arquitectura de Agentes de Servicio)

Oracle API Gateway (OAG), es la primera lnea de defensa hacia las aplicaciones y servicios web
desplegados, ofreciendo:

Conversin de REST a SOAP

Conversin de XML a JSON

Soporte para protocolos FTP, SFTP, TIBCO, JMS.

Aplicacin de reglas de seguridad:

Autenticacin: OAuth, HTTP Auth, Certificate Auth, WSS

Filtrado: SQL Injection, Virus, XSS

Monitoreo del uso

Cache y manejo de trfico

Este producto funciona en base a una serie de Agentes, los cuales se configuran, controlan y monitorean a
travs de una consola central de administracin, y proporciona los siguientes servicios de seguridad al
establecerse en el permetro de la DMZ:

Proteccin contra ataques de Denial of Service (DoS), entre estos, Flooding, Payloads Recursivos,
Memory Leaks.

Proteccin contra Inyecciones, como SQL Injection, XPATH Injection, XSS

Confidencialidad e Integridad, es decir proteccin contra sniffing, Tampering, Poisoning.

Ataques de Elevacin de Privilegios, como ataques de fuerza bruta, por diccionarios, overflows.

Debido a su Arquitectura y caractersticas, Oracle API Gateway corresponde muy bien con el patrn de diseo
de Arquitectura de Agentes de Servicio. A este componente le podemos delegar toda una serie de actividades
relacionadas con seguridad, polticas, conversin, reglas y dems, dentro de nuestra Arquitectura de
Integracin Cloud.
A final de cuentas, los patrones de diseo revisados nos ayudarn a que nuestras integraciones Cloud sean
mucho ms dinmicas, robustas y confiables. Afortunadamente, en el stack de Oracle podemos encontrar una
serie de opciones que nos permiten aplicar dichas tcnicas con efectividad y mnimo esfuerzo
Sin ms por el momento, esperamos que esta serie de artculos haya sido de inters y sobre todo utilidad
para usted apreciado lector. Muy pronto estaremos publicando una variedad de artculos adicionales sobre el
tema de Cloud Computing.
Hasta la prxima!

Joel Prez es un experto DBA (Oracle ACE Director, OCM Cloud Admin. & OCM11g) con ms de 14 aos de
experiencia real en el mundo de tecnologa Oracle, especializado en diseo e implementacin de soluciones
de: Cloud, Alta disponibilidad, Recuperacin contra desastres, Upgrades, Replicacin y toda rea relacionada
con bases de datos Oracle. Consultor Internacional con trabajos, conferencias y actividades relacionadas en
ms de 50 pases alrededor del mundo. Habitual Orador en eventos Oracle alrededor del mundo como: OTN
LAD, OTN MENA, OTN APAC y ms. Joel se ha caracterizado siempre por ser un pionero en materia de
tecnologa Oracle desde los inicios de su carrera siendo el primer latinoamericano en ser nombrado "OTN
Expert" en el ao 2003, uno de los primeros Oracle ACE en el programa ACE en el ao 2004, unos de los
primeros OCP Cloud en el mercado en el ano 2013 y como uno de los mayores logros de su carrera,
recientemente en el 2014 fue honorificado como uno de los primeros "OCM Database Cloud Administrator" del
mundo.
Arturo Viveros es un profesional destacado en las reas de Arquitectura Cloud, SOA y JEE. Actualmente
radica en la Ciudad de Mxico y labora como Socio / Arquitecto TI Senior en S&P Solutions. Con ms de 10
aos de experiencia en la industria de TI, Arturo es conferencista regular en eventos organizados por: OPN,
OTN, as como Universidades pblicas y privadas en Mxico. Es el nico instructor de habla hispana
certificado por Cloud School (Arcitura Inc.) para impartir el curso de Arquitectura Cloud en Latinoamrica.

Este artculo ha sido revisado por el equipo de productos Oracle y se encuentra en cumplimiento de las
normas y prcticas para el uso de los productos Oracle.