1. No category

descrIPcIón detallada de la tecnología
red Hat JBoss BrMs
y JBoss BPM suIte
Prácticasrecomendadas
IntroduccIón
Másinformaciónacercade
RedHatJBossBPMSuite
Expertos empresariales y desarrolladores de aplicaciones en organizaciones de todos los
tamaños necesitan poder modelar, automatizar, medir y mejorar sus procesos y políticas
críticos. Esto es posible con Red Hat® JBoss® BRMS gracias a la integración total de
funciones de administración de reglas comerciales (BRM) y procesamiento de eventos
complejos (CEP).1
Red Hat JBoss BPM Suite es una plataforma integral para la gestión de procesos comerciales
(BPM) que se puede implementar en entornos físicos, virtuales, móviles y de nube. Incluye
todas las reglas empresariales y capacidades de procesamiento de eventos complejos (CEP)
de JBoss BRMS, junto con herramientas avanzadas y soporte de tiempo de ejecución para el
modelo de procesos empresariales y los procesos empresariales compatibles con Notation
v2.0 (BPMN2). 2
En el resto del documento solo se hará referencia a JBoss BPM Suite, ya que incluye todas las
funciones de JBoss BRMS, un "súper conjunto" que cuenta con todas las prestaciones que se
describen en el presente artículo (reglas, eventos y procesos).
Este artículo proporciona información sobre el proceso de creación de reglas. También
muestra cómo JBoss BPM Suite puede ayudarle a escalar aplicaciones basadas en reglas, a
fin de poder gestionar las necesidades de proyectos empresariales presentes y futuras. Se
analizarán tanto las aplicaciones basadas en procesos como las basadas en reglas.
Este documento presupone conocimientos prácticos de JBoss BPM Suite y no detalla los
conceptos básicos. Resulta útil contar con formación previa en arquitectura de software,
ya que este artículo describe las decisiones de diseño y los procesos para garantizar la
escalabilidad de los proyectos conforme avanza la creación de la arquitectura de empresa.
Procesos
Examinemos con más detalle un típico entorno empresarial. Podemos ir profundizando por
capas para comprender mejor cómo proporcionamos proyectos BPM aptos para escalar. La
Ilustración 1 muestra que existen varias capas de componentes:
•Capa de inicialización
•Capa de implementación
•Capa de interacción
facebook.com/redhatinc
@redhatnews
linkedin.com/company/red-hat
redhat.com
1 Red Hat JBoss BRMS, http://www.redhat.com/products/jbossenterprisemiddleware/business-rules
2 Red Hat JBoss BPM Suite, http://www.redhat.com/products/jbossenterprisemiddleware/business-process
En la capa de inicialización se recopilan datos y se introducen en los procesos. Se describirán algunas
prácticas recomendadas para usted y sus clientes, y cómo iniciar procesos de forma escalable.
La capa de implementación es donde se realiza el mantenimiento de los procesos, con la ayuda del
repositorio de procesos, de herramientas, de los usuarios empresariales y de los desarrolladores
que los diseñan. Además aquí encontrará detalles sobre diversas implementaciones, como las
ampliaciones específicas de dominios para determinados tipos de nodos en nuestros proyectos.
La capa de interacción es donde los procesos se conectan con todos los sistemas heredados,
sistemas de gestión interna, capas de servicios y sistemas de reglas, incluidos los sistemas y
servicios de terceros.
Arquitectura BPM
Capa de interacción
REGLAS
EJB/POJO
ESB
Servicios web
Capa de implementación del proceso
Tareas humanas
Informes de la
consola JBPM,
paneles BAM
EJB/POJO
Repositorio de procesos
Colas
Capa de
inicialización
de proceso
Creación de BPMN2
para usuarios
empresariales
Cliente
Creación de BPMN2
para desarrolladores
Desarrollador
JB0013
Ilustración 1. Capas de arquitectura BPM
caPa de InIcIalIzacIón
Durante los últimos diez años, hemos ido recopilando las prácticas recomendadas para la
inicialización de procesos de diferentes empresas de gran tamaño (financieras, minoristas,
logísticas, de seguros). Las empresas de éxito reúnen los datos de clientes, usuarios o del
sistema que necesitan para iniciar el proceso y, a continuación, introducen esos datos mediante
startProcess. Este paso se puede integrar en la aplicación utilizando la API de JBoss BPM Suite,
el servicio RESTful o una solicitud de servicio web de Java™ estándar.
Independientemente del modo en que recopile los datos necesarios para inicializar sus
procesos, querrá determinar cómo escalar la configuración de inicialización desde el principio.
Los proyectos en un principio y con bastante frecuencia, se inician sin pensar mucho en las
necesidades que puedan hacer falta en un futuro, lo que puede suponer problemas a la hora de
escalar.
redhat.com
Descripción DetallaDa De la tecnología Red Hat JBoss BRMS y JBoss BPM Suite
2
ClienteS
Cuando se habla del cliente, podemos estar refiriéndonos a una
persona, a un sistema o a un usuario que proporciona datos de inicio
para el proceso inicial. La Ilustración 2 ofrece un resumen general
sobre la forma en que los clientes proporcionan datos de procesos
que, a continuación, se empaquetan en una solicitud que se sitúa en
una de las colas de procesos. Desde las colas, podemos priorizar y
dejar que los diferentes mecanismos sean los que recopilen estas
solicitudes de procesos e inicien una instancia de proceso con los
datos de solicitud proporcionados. Aquí mostramos Enterprise
JavaBeans (EJB), beans controlados por mensajes (MDB) y nubes,
que representan algunas de las formas de programación que se
podrían utilizar para vaciar las colas de procesos.
EJB/POJO
Colas
Capa de
inicialización
de proceso
ColaS
JB0014
Ilustración 2: Inicialización
de proceso escalable.
Las colas pueden ser tan sencillas como las tablas de las bases
de datos o tan elaboradas como las colas de mensajes. Se pueden
configurar de la forma que mejor se ajuste al proyecto como, por
ejemplo, siguiendo el modelo LIFO (último en entrar, primero en
salir) o el modelo FIFO (primero en entrar, primero en salir). La
ventaja de utilizar colas de mensajes es que puede priorizarlos
siguiendo un mecanismo de sondeo.
El motivo para optar por esta configuración es doble. En primer
lugar, al no iniciar directamente el proceso desde la interfaz de cliente, se está garantizando la
continuidad de la solicitud, ya que no se perderá en su ruta al motor de procesos. En segundo
lugar, tendrá la opción de priorizar los procesos futuros que podrían no satisfacer los requisitos
del proyecto. Por ejemplo, piense en una nueva solicitud de proceso que deba iniciarse 10
segundos después del envío por parte del cliente. Si ese proceso de 10 segundos se coloca al final
de una cola de una hora, supondrá un problema. Con la priorización de las colas, podrá ajustar su
mecanismo de sondeo para activar las colas adecuadas en el orden adecuado cada vez.
JavaylanuBe
Los iconos de nube representan los servicios que puede utilizar el software para invocar al
método startProcess final con el fin de inicializar la instancia del proceso que se solicita y de
transferirle los datos iniciales. Centralizar esta interacción con la API principal de JBoss BPM
Suite resulta clave para crear un único servicio que garantice el mínimo trabajo en caso de que
se deba modificar la API, cuya versión podría desear cambiar por migraciones de versión o
proyectos de ampliación con el fin de ampliar la interacción del servicio con jBPM.
CaPadeiMPleMentaCión
Esta capa se centra en los diseños del proceso empresarial, las implementaciones de acciones
personalizadas en los procesos y las ampliaciones de las formas en que trabaja con los procesos.
La adopción del estándar BPMN2 para el diseño y la ejecución de procesos ha simplificado la
construcción en esta capa de la arquitectura BPM. Los motores de procesos se ven obligados
a cumplir el estándar BPMN2, lo cual impone limitaciones en lo que se puede hacer durante el
diseño de los procesos.
En JBoss BPM Suite, el concepto de sesiones con estado le ayudará a construir arquitecturas de
procesos altamente escalables. Las sesiones con estado mantienen la información de procesos,
tanto los datos como una instancia de la especificación del proceso.
Normalmente, al ejecutar aplicaciones basadas en reglas, se ejecuta una única sesión (pero
no una con estado) con todas las reglas y los datos que utiliza dicha sesión. Así que buscamos
utilizar una única sesión con estado por instancia de proceso también. Para ello, podemos ajustar
nuestras implementaciones para utilizar una única sesión con estado por instancia, permitiendo
así la simultaneidad y facilitando la gestión del ciclo de vida de la instancia del proceso.
redhat.com
Descripción DetallaDa De la tecnología Red Hat JBoss BRMS y JBoss BPM Suite
3
CaPadeinteRaCCión
Son muchas las ventajas que ofrece el contar con una buena estrategia de acceso a la lógica
empresarial, a los distintos sistemas (de backend o de gestión interna), las interfaces de usuario,
los servicios de terceros o a cualquier otra aplicación o recurso que precise de procesos
empresariales para realizar el trabajo.
Muchas empresas aíslan estas interacciones con una capa de servicios dentro de una
arquitectura orientada a servicios (SOA). Esta SOA aporta flexibilidad y permite el escalado en
las distintas cargas de trabajo que se pueda encontrar.
Nos gustaría analizar algunos sistemas de backend a modo de ejemplo para ver cómo optimizar
los proyectos de procesos en su empresa.
Por ejemplo, la arquitectura de JBoss BPM Suite incluye un servidor de tareas humanas
independiente que se ejecuta como un servicio y que implementa la especificación Web ServicesHuman Task (WS-HumanTask). Puede alojar otro servidor en su empresa exponiendo el ciclo de
vida de WS-HumanTask en un servicio.
El componente de supervisión de la actividad empresarial (BAM) está configurado para ser
autosuficiente y acceder a las fuentes de datos directamente, en función de la configuración del
usuario. Le permite diseñar y crear todo tipo de informes útiles, además de configurar colas o
productores de eventos de una forma sencilla.
reglas
A diferencia de BPM, que se centra en el modelado de secuencias de acciones con flujos bien
definidos, las tecnologías de gestión de reglas comerciales (BRM) son más adecuadas para las
acciones de modelado sin conexión directa y que se activan mediante escenarios. Para entender
mejor este concepto, basta con recordar que el caso de uso más común para la implementación
de reglas es la gestión de decisiones.
La gestión de decisiones consiste en la externalización y consolidación de todas las reglas
y variables (o datos) implicadas en la toma de decisiones para un dominio dado, así como
su gestión. Estas reglas consolidadas se ponen a disposición de las aplicaciones a través de
servicios de decisión y se puede gestionar, auditar y mantener de forma centralizada. Consolidar
reglas y variables de este modo supone atribuirles un ciclo de vida independiente de las
aplicaciones del usuario, además de disfrutar de otras ventajas.
oBJetivoS
Las organizaciones adoptan la gestión de reglas comerciales para aplicaciones a fin de lograr
numerosos y variados objetivos, entre otros:
laautomatizacióndelasdecisiones: la primera ventaja y la más obvia es la automatización de
las decisiones en la aplicación empresarial. Las decisiones operativas ocupan la mayor parte
del tiempo en cualquier entorno empresarial a diario. Y no nos estamos refiriendo a decisiones
estratégicas a largo plazo que requieren de la intervención humana. La realidad es que la inmensa
mayoría de las decisiones operativas de un entorno empresarial se pueden automatizar para
reducir así los tiempos de respuesta y mejorar el rendimiento empresarial. Así se logra mayor
calidad y coherencia, así como la posibilidad de auditar los procesos de toma de decisiones a lo
largo del tiempo.
expresividadyvisibilidad: por lo general, los motores de reglas empresariales (BRE)
proporcionan metáforas y lenguajes de nivel superior para la creación de reglas. Al utilizar estas
representaciones de alto nivel, las reglas son cada vez más concisas, lo cual facilita los procesos
de comprensión y validación de estas por parte de los usuarios empresariales. Además permite a
los usuarios empresariales crear ellos mismos las reglas.
Rendimientoyescalabilidad: BRE cuenta con algoritmos especializados para la compilación
y ejecución de reglas. Estos algoritmos funcionan mejor que las reglas codificadas de forma
manual y garantizan la optimización de la búsqueda de soluciones por parte del motor de reglas.
BRMS puede ejecutar y escalar cientos de miles de reglas sin problemas.
redhat.com
Descripción DetallaDa De la tecnología Red Hat JBoss BRMS y JBoss BPM Suite
4
Centralizacióndelconocimiento: al externalizar y consolidar las reglas, las empresas pueden
garantizar la correcta implementación de las mismas y su compatibilidad con todas las
aplicaciones que las utilizan. Esta arquitectura también promueve la clara separación entre
lógica, datos y tareas, lo que permite a la empresa aumentar la agilidad y reducir el tiempo
de comercialización. Por último, al tener centralizados los conocimientos empresariales, el
cumplimiento y la optimización se pueden auditar con más facilidad.
aPlIcacIones coMPatIBles con Bre
El desarrollo de aplicaciones compatibles con BRE no difiere en gran medida del desarrollo de
aplicaciones tradicionales. Pese a no ser tan distintos, existen algunas prácticas recomendadas que
se pueden seguir para aprovechar al máximo las ventajas que ofrecen las herramientas de BRMS.
aRquiteCtuRa
ParticióndelabaseKie
Una base Knowledge is everything (KIE), o KieBase, normalmente contiene recursos como reglas,
procesos y modelos de dominio relacionados con un tema, entidad de negocio o unidad de trabajo.
Saber realizar la partición de los activos de estas KieBase puede afectar en gran medida a la
solución. Las herramientas de BRMS funcionan mejor para la optimización de conjuntos de reglas
que para la optimización de reglas individuales. Cuanto mayor sea el conjunto de reglas, mejores
serán los resultados en comparación con los que tendría el mismo conjunto de reglas dividido en
varios conjuntos de reglas.
Aun así, aumentar el conjunto de reglas incluyendo reglas no relacionadas tiene el efecto
contrario: el motor no puede optimizar las reglas independientes y la aplicación debe hacer
frente a la sobrecarga de lógica adicional. La primera práctica recomendada es realizar la
partición de KieBases implementando solo las reglas relacionadas en una única KieBase. Evite
utilizar KieBases monolíticas y KieBases detalladas.
PaRtiCióndeSeSioneSKie
La creación de sesiones Knowledge is everything, o KieSessions, apenas supone rendimiento
adicional. Normalmente, los sistemas BRMS escalan mejor cuando aumenta el número de reglas
y peor si aumenta el volumen de datos (hechos). Es decir, las KieSessions de menor tamaño son
mejores para el rendimiento general del sistema.
Las sesiones individuales también son fáciles de realizarse en paralelo, por lo que un sistema con
varias sesiones escalará mejor en hardware con varios procesadores. Además, debemos reducir
al mínimo la fragmentación de datos o hechos. Incluya solo los hechos relacionados en la misma
sesión con las reglas relacionadas. Los datos suelen hacer referencia a una transacción, a un
servicio o a una unidad de trabajo. Al crear una sesión, es preferible agregar todos los hechos a
la sesión en un lote y, a continuación, activar las reglas, en lugar de agregar hechos individuales y
activar las reglas después de cada adición.
diSeñodeModelodedoMinio
Un BRE se asemeja en muchos aspectos a una base de datos, desde los algoritmos de relaciones
subyacentes hasta las optimizaciones como, por ejemplo, la indexación de datos. Esta es la razón
por la que muchas de las prácticas recomendadas para el uso de bases de datos también se
aplican a los BRE.
Una de las más importantes consiste en diseñar cuidadosamente el modelo de dominio. La
calidad del modelo de dominio es directamente proporcional al rendimiento y la facilidad de
mantenimiento de las reglas. Un modelo de dominio mal diseñado no solo afecta al tiempo de
ejecución del motor, sino que además incrementa el tiempo y los costes. Las reglas son mucho
más difíciles de crear y mantener a lo largo del tiempo.
Un buen modelo de dominio representa las relaciones entre varias entidades de la forma más simple
posible. Los modelos más planos, por lo general, facilitan la escritura de restricciones, mientras que
las entidades de menor tamaño (entidades con pocos atributos) ayudan a evitar los bucles.
redhat.com
Descripción DetallaDa De la tecnología Red Hat JBoss BRMS y JBoss BPM Suite
5
CReaCióndeReglaS
olvídesedelmicrocontrol
Las reglas deben ejecutar acciones basadas en escenarios; esta es la condición para las reglas.
Siguiendo este sencillo principio, las reglas se mantienen sin conexión directa. Esto permite a los
desarrolladores de reglas gestionarlas de forma individual.
Los motores de reglas optimizan aún más las reglas disociadas. Las estrategias de resolución
de conflictos como la prominencia, los grupos de agenda o los flujos de reglas solo se utilizan
cuando hay que organizar conjuntos de reglas, nunca reglas individuales.
nosobrecarguelasreglas
Cada regla debe describir una asignación entre un escenario y una lista de acciones. No intente
sobrecargar la reglas con varios escenarios, ya que esto dificultará su mantenimiento a largo
plazo. Aumentará además la complejidad de las pruebas y vinculará innecesariamente escenarios.
Utilice las capacidades de inferencia y encadenamiento del motor para modelar escenarios
complejos mediante la división en varias reglas. El motor compartirá las condiciones comunes
entre los diferentes escenarios y así el rendimiento no se verá afectado. Por ejemplo:
Regla "1: Los adolescentes y los jubilados obtienen un descuento"
si
La persona tiene entre 16 y 18 años o si tiene 65 años o más
entonces
Asignar un 25 % de descuento
fin
Regla "2: Los jubilados pueden comprar entradas para la zona A"
si
La persona tiene 65 años o más
entonces
Permitir la venta de entradas para la zona A
fin
Las anteriores reglas están sobrecargadas. Ambas definen políticas sobre lo que es un jubilado,
así como las acciones que se deben realizar para ellos. Suponga que la empresa cuenta con 1000
reglas que se aplican a personas jubiladas y que para cada regla es necesario activar la condición
"La persona tiene 65 años o más".
Imagine ahora que la política de la empresa para personas jubiladas o la legislación
gubernamental sobre dicha materia cambian, y se pasa a considerar como jubilado a una persona
a partir de los 60 años. Este simple cambio en la política implicaría una modificación en cada una
de las 1000 reglas existentes, por no mencionar los cambios en los escenarios de prueba o en los
informes, por citar alguno.
redhat.com
Descripción DetallaDa De la tecnología Red Hat JBoss BRMS y JBoss BPM Suite
6
Una forma mucho más práctica de crear las mismas reglas sería contar con una para definir lo
que es una persona jubilada y otra para definir lo que es un adolescente. Una vez hecho esto, se
utilizarían los datos inferidos en el resto de reglas que necesitaran seleccionar bien adolescentes
o bien jubilados Por ejemplo:
Regla "0: Los adolescentes tienen entre 16 y 18 años" Regla "0.b: Los
jubilados tienen más de 65 años"
si
La persona tiene entre 16 y 18 años de edad
entonces
Afirmación: La persona se considera adolescente
fin
regla "0.b: Los jubilados tienen más de 65 años"
si
La persona es mayor de 65 años
entonces
Afirmación: La persona se considera persona jubilada
fin
Regla "1: Los adolescentes y los jubilados obtienen un descuento"
si
Adolescente o jubilado
entonces
Asignar un 25 % de descuento
fin
Cuando se crean reglas como estas, el usuario se beneficia de las capacidades de inferencia del
motor, además de conseguir reglas más fáciles de entender y de mantener. Además, si en algún
momento la política sobre jubilados cambiara, la modificación simplemente afectaría a una regla,
y no a 1000. Es decir, se reducirían drásticamente los costes y la complejidad.
loshechosdecontrolnosoneficaces
Los hechos de control son hechos introducidos en el dominio y utilizados en las reglas con el
único fin de controlar explícitamente la ejecución de las reglas. Son arbitrarios, no representan
ninguna entidad en el dominio y normalmente se utilizan como la primera condición de la
regla. Los hechos de control se utilizan bastante en motores que no cuentan con estrategias de
resolución de conflictos tan sólidas y expresivas como JBoss BPM Suite. Los hechos de control
presentan muchos inconvenientes. Por ejemplo, pueden:
•Conllevar el microcontrol de ejecuciones de reglas
•Provocar enormes ráfagas de trabajo con activaciones y cancelaciones de reglas innecesarias.
•Degradar la visibilidad y expresividad de las reglas, lo que dificulta la comprensión y la
creación de dependencias entre reglas por parte de otros usuarios.
•No ser eficaces
Se debe evitar el uso de hechos de control. Existe un caso en el que su uso es aceptable
y es para evitar realizar una costosa operación conjunta que no debe suceder hasta que se
cumpla una condición determinada.
redhat.com
Descripción DetallaDa De la tecnología Red Hat JBoss BRMS y JBoss BPM Suite
7
descrIPcIón detallada de la tecnologíaRedHatJBossBRMSyJBossBPMSuite
lateCnologíaadeCuadaPaRaeltRaBaJoaPRoPiado
acerca de red Hat
Red Hat es el proveedor
líder de soluciones de código
abierto que utiliza un enfoque
impulsado por la comunidad
para proporcionar tecnologías
fiables y de alto rendimiento de
cloud computing, virtualización,
almacenamiento, Linux
y middleware. Red Hat también
ofrece servicios galardonados
de soporte, capacitación
y consultoría. Es una empresa
S&P con más de 80 oficinas
en todo el mundo que ayuda
a los clientes a impulsar sus
negocios.
NORTEAMÉRICA
1 888 REDHAT1
JBoss BPM Suite incluye numerosas características avanzadas que ayudan a los usuarios y
creadores de reglas a ir dando forma a su negocio. Por ejemplo, si alguien necesita consultar
datos de sesión para tomar una decisión o para devolver los datos a la aplicación, el usuario
puede utilizar consultas en lugar de reglas.
Las consultas son como reglas pero siempre se solicitan por el nombre, nunca ejecutan
acciones y siempre devuelven datos. Las reglas siempre las ejecuta el motor (que no se
puede solicitar), siempre deberían ejecutar acciones cuando coinciden y nunca devuelven
datos.
Otra característica que incluye JBoss BPM Suite son los modelos declarativos. Los
modelos declarativos son tipos de hechos declarados y definidos como parte de la base de
conocimientos. Por ejemplo:
declarar Persona
nombre: String
edad : int
fin
Los modelos declarativos son una forma perfecta para desarrollar prototipos rápidos y
modelar tipos de hechos auxiliares que solo utilizan las reglas y no las aplicaciones. JBoss
BPM Suite integra modelos de dominio desarrollados en objetos Java normales (POJO). El
uso de este modelo simplifica la prueba y la integración de aplicaciones y debe ser la opción
preferida siempre que las reglas y las aplicaciones utilicen las mismas entidades de dominio.
euRoPa,oRienteMedio
yÁFRiCa
00800 7334 2835
[email protected]
aSiayPaCíFiCo
+65 6490 4200
[email protected]
aMÉRiCalatina
+54 11 4329 7300
[email protected]
facebook.com/redhatinc
@redhatnews
linkedin.com/company/red-hat
redhat.com
#12286847_v1_0814
Copyright © 2014 Red Hat, Inc. Red Hat, Red Hat Enterprise Linux, el logotipo Shadowman y JBoss son marcas comerciales de
Red Hat, Inc. registradas en Estados Unidos y en otros países. Linux® es la marca comercial registrada de Linus Torvalds en
Estados Unidos y en otros países.