Embed Size (px)
Citation preview
¿CÓMO ACOPLAR UN PROCESO BPM A UN BUS DE SERVICIOS?:
BPM COMO ORQUESTADOR PRINCIPAL DE SERVICIOS DEL BUS
(CASO JBPM - BUS JBOSS ESB) ASIGNATURA: PROYECTO ESPECIAL SOA-BPM
PONTIFICIA UNIVERSIDAD JAVERIANA
ESTUDIANTES:
CRISTIAN DAVID ROMERO MELGAREJO, [email protected]
LAURA CRISTINA ARIAS PRADA, [email protected]
DIRECTOR:
MARÍA CONSUELO FRANKY DE TORO, [email protected]
TABLA DE CONTENIDO
1. Introducción .......................................................................................................... 2 2. Arquitectura .......................................................................................................... 2 3. Transformación de Datos con Smooks ........................................................................... 4
3.1 Java Binding ...................................................................................................... 4 3.2 Procesando datos Non-XML .................................................................................... 7 3.3 Otras funciones .................................................................................................. 9
4. Uso de reglas de negocio ......................................................................................... 11 4.1 Descripción General .......................................................................................... 11 4.2 Facilidades del Bus JBossESB ................................................................................ 11
5. Registro e Invocación a Servicios Web ......................................................................... 12 5.1 Introducción .................................................................................................... 12 5.2 Publicación de un servicio web ............................................................................. 12 5.3 Servicios e invocación ........................................................................................ 12 5.4 Mensajes ........................................................................................................ 13 5.5 Orquestando servicios web .................................................................................. 13 5.6 Ejemplo webservice_consumer2 ........................................................................... 13
6. Integración de BPM como orquestador de servicios del bus ............................................... 16 6.1 Introducción y Capacidades de BPM Como Orquestador Principal.................................... 16 6.2 La Consola jBPM ............................................................................................... 16 6.3 Soporte de Invocación de Servicios del Bus .............................................................. 18
7. Referencias ......................................................................................................... 20
1. INTRODUCCIÓN
Los buses de servicios empresariales son considerados la infraestructura de las arquitecturas orientadas
a servicios [9], por tal razón son tan importantes en las empresas y son tomados como una inversión de
la cual definitivamente se obtendrá un retorno; proveen además una base de integración de distintas
arquitecturas en el futuro [10].
Los beneficios de un bus de servicios desde la perspectiva de infraestructura son bastantes, entre ellos
se encuentran: la capacidad de registrar e invocar servicios web, la capacidad de aceptar mensajes en
diversos protocolos (JMS, SOAP, etc) y transformar los datos que vienen en los mensajes, etc [9].
En el presente documento se hablará sobre las facilidades que ofrece JBossESB un bus de servicios
empresariales desarrollado por el equipo de desarrollo de JBossESB, es considerada una tecnología
bastante robusta y libre, la cual se guía por los principios SOA [11]. Soporta múltiples
implementaciones y capacidades entre ellas: orquestación de procesos, traducción de protocolo,
adaptadores, gestión de cambios, calidad de servicio y protección, etc [11].
2. ARQUITECTURA
Los principios de SOA fueron utilizados por el equipo de desarrollo para realizar el diseño de la
arquitectura del Bus de Servicios Empresariales de JBoss, es decir, todo será un servicio lógico que
interactuará a través de mensajes [12].
¿Qué requerimientos son necesarios en una arquitectura ESB? Los servicios en primera instancia se
encuentran generalmente en ambientes distribuidos los cuales se comunican también a través de
diferentes protocolos (implementación MOM de JBossESB), por tanto uno de los requerimientos
arquitecturalmente significantes es el soporte de múltiples protocolos de comunicación [12].
Un componente importante es el Service Registry el cual permite publicar, descubrir y consumir
servicios, soporte para UDDI está por defecto en JBossESB. El bus actúa como middleware, por esta
razón es importante que soporte el concepto de sesión (correlación entre mensajes) [12].
Gracias a la arquitectura implementada JBossESB es capaz de soportar las siguientes funcionalidades:
Monitoreo de procesos de negocio, ambiente de desarrollo integrado, interfaz de usuario de flujos de
trabajo, conectores, gestor de transacciones, seguridad, contenedor de aplicaciones, servicio de
mensajería, repositorio de datos, servicio de directorio y nombramiento, arquitectura de computación
distribuida, etc [13].
En general los 4 componentes arquitecturales principales son [14]:
Escuchador de mensajes y Código de filtrado de mensajes: Los primero actúan como
enrutadores de mensajes entrantes (por ejemplo, en una Cola JMS) y presenta el mensaje al
pipeline que filtra el mensaje y lo enruta a otro endpoint.
Transformación de datos mediante el procesador SmooksTransformer.
El servicio de enrutamiento basado en contenidos
El repositorio de mensajes, para guardar mensajes o eventos cambiados con el bus de servicios
empresariales.
Esto ha sido implementado mediante un conjunto de clases de negocio, adaptadores y procesadores;
las interacciones entre los clientes y los servicios son soportados mediante un rango de diferentes
enfoques incluyendo JMS, email, etc [14].
3. TRANSFORMACIÓN DE DATOS CON SMOOKS
El Bus de Servicios de JBoss ésta en la capacidad de transformar datos según sea la necesidad. En este
documento presentamos un framework llamado Smooks, el cuál brinda el servicio de transformación
para varios tipos de archivos de entrada y salida, los cuales pueden ser XML o non XML (CSV, EDI, Java,
etc.) [1].
Smooks cuenta con características muy útiles que pueden ser usadas individualmente o combinadas.
Esta sección presenta sus funciones principales.
3.1 JAVA BINDING
Esta característica de Smooks permite vincular los archivos de tipo XML, EDI, CSV, entre otros, con
clases Java. Es importante resaltar que Smooks permite hacer el mapeo directo a Beans en Java, lo que
permite la integración con una aplicación JEE [1].
3.1.1 ¿CUÁNDO USAR JAVA BINDING?
Los casos en los que se recomienda usar Smooks, frente a otras herramientas, son los siguientes [1]:
1. Para vincular datos non XML a un modelo de objetos de Java. Por ejemplo: EDI, CSV, JSON,
entre otros.
2. Para vincular datos (XML u otros) cuyo modelo de datos (estructura jerárquica) no coincida con
la del modelo de destino de objetos de Java. Ésta funcionalidad también es implementada por
JiBX [5], sin embargo, esta herramienta solo soporta XML.
3. Cuando se deseen vincular datos de una estructura de datos XML la cual no tenga definida un
esquema (XSD).
4. Cuando requiera vincular datos de múltiples y diferentes formatos de datos en un solo modelo
de objetos de Java.
5. En caso de que se necesite ejecutar lógica paralelamente al proceso de vinculación. Por
ejemplo: Validación, generación de mensajes, enrutamiento de mensajes, persistencia de
fragmentos o cualquier lógica personalizada que desee implementar. A menudo esto es una
función muy poderosa, especialmente cuando se procesan grandes flujos de mensajes.
6. Para procesar grandes flujos de mensajes dividiéndolos en una serie de muchos modelos de
objetos pequeños y ruteandolos a otro sistema para procesamiento.
7. Cuando use otras características de Smooks que dependan de las capacidades de Java Binding
brindads también por Smooks.
3.1.2 ¿CUÁNDO NO TENDRÍA SENTIDO USAR JAVA BINDING?
Los casos en los que no se recomienda usar Smooks, son los siguientes [1]:
1. Cuando se cuenta con un modelo de datos bien definido (a través de esquemas/XSD) y lo único
que se requiere es enlazar los datos en un modelo de objetos (sin ningún tipo de requerimiento
sobre validación, lógica o persistencia).
2. Cuando el modelo de objetos está aislado de otros sistemas, reduciendo su acoplamiento y
facilitando su transformación sin afectar recursos externos.
3. Cuando se procesa XML y el rendimiento es de suma importancia para el sistema sobre
cualquier otra consideración, se recomienda el uso de otras herramientas como JiBX [5]. No
quiere decir que el rendimiento ofrecido por Smooks sea deficiente, simplemente las
características y forma de ejecución de JiBX le permiten brindar un mejor nivel para este
requerimiento no funcional.
3.1.3 EJEMPLO DE JAVA BINDING
Para ilustrar la funcionalidad de Smooks, se usará el ejemplo llamado transform_XML2POJO incluido en
la versión 4.9 del bus de JBoss [16]. Básicamente, entra un mensaje XML y éste se transforma en un
modelo de objetos de Java [1].
El ejemplo usado contará con una lista de órdenes, donde cada una tiene una propiedad orderId que
representa el ID de la orden, una propiedad shipTo que indica el lugar de entrega de la orden y una
lista de LineItem llamada LineItems. Cada LineItem tiene un id, un nombre y un precio.
El mensaje XML:
<orders>
<Order orderId="1" shipTo="Bogota">
<LineItems>
<LineItem id="1" name="Leche" price="100.00"></LineItem>
<LineItem id="2" name="Arroz" price="500.00"></LineItem>
</LineItems>
</Order>
<Order orderId="2" shipTo="Medellin">
<LineItems>
<LineItem id="4" name="Cerveza" price="150.00"></LineItem>
<LineItem id="9" name="Lentejas" price="300.00"></LineItem>
</LineItems>
</Order>
<Order orderId="3" shipTo="Cali">
<LineItems>
<LineItem id="7" name="Papas" price="100.00"></LineItem>
<LineItem id="2" name="Arroz" price="500.00"></LineItem>
</LineItems>
</Order>
</orders>
Los Beans en Java que corresponden a la orden serían los siguientes:
public class Order implements Serializable {
private Long orderId;
private ArrayList<LineItem> lineItems;
private String shipTo;
}
public class LineItem implements Serializable {
private Long id;
private Float price;
private String name;
}
El intermediario que se encargará de convertir el mensaje XML a los bean de Java, será Smooks. Existe
un archivo de configuración, por lo general llamado smooks-res.xml, que para éste ejemplo será de la
siguiente forma:
<?xml version='1.0' encoding='UTF-8'?>
<smooks-resource-list xmlns="http://www.milyn.org/xsd/smooks-1.1.xsd"
xmlns:jb="http://www.milyn.org/xsd/smooks/javabean-
1.2.xsd">
<!-- Relacionar la orden -->
<jb:bean beanId="order" class="org.jboss.soa.esb.dvdstore.Order"
createOnElement="order">
<jb:value property="orderId" data="order/@orderId" />
<jb:value property="shipTo" data="order/@shipTo" />
<jb:wiring property="lineItems" beanIdRef="lineItems"/>
</jb:bean>
<!-- Relacionar el ArrayList de LineItems -->
<jb:bean beanId="lineItems" class="java.util.ArrayList"
createOnElement="lineItems">
<jb:wiring beanIdRef="lineItem" />
</jb:bean>
<!-- Relacionar el LineItem -->
<jb:bean beanId="lineItem" class="org.jboss.soa.esb.dvdstore.LineItem"
createOnElement="lineItems/lineItem">
<jb:value property="id" data="lineItem/@id" />
<jb:value property="price" data="lineItem/@price" />
<jb:value property="name" data="lineItem/@name" />
</jb:bean>
</smooks-resource-list>
La sección resaltada en rojo es un ejemplo de la forma para indicar a que Java Bean debe ser atada la
información que se consigne dentro de ese tag. La propiedad beanId="order" le da un identificador
dentro de éste archivo a esa clase, class="org.jboss.soa.esb.dvdstore.Order" indica la clase
Java Bean correspondiente a la orden que se desea introducir y createOnElement="order" indica
el nombre del tag del archivo XML entrante.
Se deberán especificar todas las clases Java Bean por medio del tag <jb:bean>. Dentro de éste, se
podrán añadir values (atributos) o wirings (referencias). En el ejemplo, se encuentra resaltado en azul
oscuro la forma de inyectar un valor a un atributo de la clase Java Bean:
<jb:value property="orderId" data="order/@orderId" />
Cuando se desee agregar un atributo que sea representado un elemento o clase nativa, se podrá usar el
tag <jb:value>. La propiedad property de este tag se usa para especificar el nombre del atributo de
la clase Java Bean a la cual se le inyectará un valor proveniente del archivo XML.
La propiedad data se usa para especificar el nombre del tag o propiedad descrito en al archivo XML de
entrada que será ligado a la clase Java Bean. Para nuestro ejemplo, será orderId que proviene de la
siguiente línea del archivo XML: <Order orderId="1" shipTo="Bogota">.
En el caso de que deba agregar atributos que hacen referencia a otra clase, deberá usar
<jb:wiring>. Este tag tiene una propiedad property con la misma función que en el tag anterior, se
usará para definir el nombre del atributo que representa para la clase Java Bean. Sin embargo, para
especificar donde se encuentra esa información en el archivo XML deberá hacer una referencia al
beanId con la propiedad beanIdRef. Por ejemplo:
<jb:wiring property="lineItems" beanIdRef="lineItems"/>
En este caso se referencia un beanId que mapea un ArrayList, representando la lista de Items que
tendrá una orden. Sin embargo, en este tampoco se conoce de donde se extraerá la información de
cada lineItem. Por esta razón se hace una nueva referencia como se indica a continuación:
<jb:bean beanId="lineItems" class="java.util.ArrayList"
createOnElement="lineItems">
<jb:wiring beanIdRef="lineItem" />
</jb:bean>
Esta última si hará el enlace con el tag que contiene la forma de mapeo para un lineItem. Se hace esta
doble referencia ya que un ArrayList no es un elemento nativo. Es decir, si usted usa clases como
HashTable, ArrayList u otros tipos de lista deberá seguir el procedimiento descrito. Si por el contrario,
desea crear solo referenciar una clase, podrá hacerlo directamente sin pasar por tags <jb:bean>
intermediarios.
3.2 PROCESANDO DATOS NON-XML
El proceso de transformación entre datos Non-XML hacia XML es similar al descrito para la
transformación desde datos XML a clases Java Bean. Se debe establecer un mensaje de entrada,
especificando su estructura, y un formato de salida.
A continuación, se describe este tipo de transformación basado en el ejemplo transform_CSV2XML
encontrado en la versión 4.9 del bus de servicios de JBoss [16]. Se podría ejecutar antes del ejemplo
presentado en la sección 3.1 para convertir una orden que está en un archivo CSV hacia un XML y luego
hacia una clase java.
El mensaje de entrada, en formato CSV, sería el siguiente:
1,Bogota,1,100.00,Leche,2,500.00,Arroz
2,Medellin,4,150.00,Cerveza,9,300.00,Lentejas
3,Cali,7,100.00,Papas,2,500.00,Arroz
El archivo de configuración, por lo general llamado smooks-res.xml, sería el siguiente:
<?xml version='1.0' encoding='UTF-8'?>
<smooks-resource-list xmlns="http://www.milyn.org/xsd/smooks-1.1.xsd"
xmlns:csv="http://www.milyn.org/xsd/smooks/csv-1.1.xsd">
<profiles>
<profile base-profile="source-csv" />
<profile base-profile="canonical-xml" />
</profiles>
<csv:reader targetProfile="source-csv"
fields="orderId,shipTo,id1,price1,name1,id2,price2,name2" />
<resource-config target-profile="canonical-xml" selector="csv-set">
<resource type="xsl">
<![CDATA[
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:smooks-
bean="xalan://org.milyn.templating.xslt.XalanJavabeanExtension"
extension-element-prefixes="smooks-bean"
version="1.0">
<xsl:output method="xml" encoding="UTF-8" />
<xsl:template match="*" name="templatelet">
<orders>
<xsl:for-each select="csv-record">
<Order orderId="{orderId}"
shipTo="{shipTo}">
<LineItems>
<LineItem id="{id1}"
price="{price1}" name="{name1}">
</LineItem>
<LineItem id="{id2}"
price="{price2}" name="{name2}">
</LineItem>
</LineItems>
</Order>
</xsl:for-each>
</orders>
</xsl:template>
</xsl:stylesheet>
]]>
</resource>
<param name="is-xslt-templatelet">false</param>
</resource-config>
</smooks-resource-list>
Es importante aclarar que la sección de código en negrita y color rojo, indica cuales son los campos
(columnas si lo abre desde Microsoft Excel) que trae el archivo CSV. Deberá especificarlas en el archivo
de configuración para poder identificar luego los tags que deberán ir en el archivo XML resultante.
La sección de código en negrita y color azul, indica cómo se va a transformar el archivo CSV a un
archivo XML, usando la especificación de campos que se hizo previamente. Se enuncian los tags de XML
y se les asigna valor a través de los siguientes símbolos “{valor}”, donde el valor corresponde a un
campo del archivo CSV (nombrado en la sección de código en negrita y color rojo). Por ejemplo:
<LineItem id="{id2}" price="{price2}" name="{name2}">
Esta línea se usa para asignar valores a un LineItem. Éste tag en XML, tiene un ID, un precio y un
nombre. Así, para este caso, el ID del LineItem representado en XML será el valor del campo id2 del
archivo CSV.
Otro aspecto importante es el recorrido que se realiza para el archivo CSV. En este caso, cómo serán
varias las órdenes introducidas, se inicia el tag de orders y se hace el recorrido cómo se indica a
continuación:
<orders>
<xsl:for-each select="csv-record">
...
</xsl:for-each>
</orders>
La propiedad select=”csv-record”, irá por cada línea del csv llenado los datos en el archivo XML. Sin
embargo, si otro tipo de archivo de entrada es usado, tenga en cuenta que la propiedad select deberá
ir acorde a éste.
Luego de la transformación, el resultado será un archivo XML, descrito a continuación. Éste archivo
podrá ser usado cómo entrada para obtener una clase Java Bean:
<orders>
<Order orderId="1" shipTo="Bogota">
<LineItems>
<LineItem id="1" name="Leche" price="100.00"></LineItem>
<LineItem id="2" name="Arroz" price="500.00"></LineItem>
</LineItems>
</Order>
<Order orderId="2" shipTo="Medellín">
<LineItems>
<LineItem id="4" name="Cerveza" price="150.00"></LineItem>
<LineItem id="9" name="Lentejas" price="300.00"></LineItem>
</LineItems>
</Order>
<Order orderId="3" shipTo="Cali">
<LineItems>
<LineItem id="7" name="Papas" price="100.00"></LineItem>
<LineItem id="2" name="Arroz" price="500.00"></LineItem>
</LineItems>
</Order>
</orders>
3.3 OTRAS FUNCIONES En cuanto a transformación, Smooks provee también la funcionalidad de realizar transformaciones
desde Objetos Java hacia archivos XML o Non-XML. Esto lo logra incorporando un motor de plantillas
llamado FreeMarker Templating [17]. Ésta herramienta provee sus propios tags y archivos de
configuración para lograr la transformación.
Por otro lado, Smooks provee otras facilidades distintas a la transformación de datos. Se cuenta con el
procesamiento de mensajes grandes, enrutamiento hacia JMS, archivo, base de datos u otros destinos,
enriquecimiento de mensajes con datos de una base de datos y otras fuentes de datos, validación de
mensajes complejos y funcionalidades de persistencia [1].
4. USO DE REGLAS DE NEGOCIO
4.1 DESCRIPCIÓN GENERAL
JBossESB provee un servicio de reglas, el cual permite publicar reglas creadas en Drools como servicios
en el bus empresarial. Drools es una plataforma de integración de lógica de negocio, que permite la
gestión de flujos de trabajo y procesamiento de eventos [18]. La principal ventaja es que reduce el
desarrollo de código cliente para integrar reglas de negocio en el ambiente de aplicación, por otro lado
estas reglas pueden ser accedidas como parte de un proceso de negocio orquestado o una acción [6].
Adicionalmente es importante por 2 razones: la primera permite separar la lógica de la aplicación
empresarial, es decir, los especialistas en procesos de negocio se podrán centrar en esa parte y los
programadores en el código de la aplicación, y segundo, está comprobado que el rendimiento de la
aplicación con tal motor de reglas [19].
4.2 FACILIDADES DEL BUS JBOSSESB
4.2.2 CREACIÓN DE REGLAS DE NEGOCIO
El servicio de reglas soportando en el JBossESB usa Drools como el motor de reglas. La integración de
estas dos herramientas se da a través de [6]:
La clase de acción BusinessRulesProcessor
Reglas escritas en Drools drl, dsl, tablas de decisión o editor de reglas de negocio
Mensajes ESB
Cuando un mensaje es enviado al BusinessRulesProcessor, un cierto conjunto de reglas se ejecutará
sobre los objetos en el mensaje, y se actualizarán estos objetos o el mensaje. Sin embargo, a pesar de
que la mayoría de reglas puede ser escritas sin preocuparse por el despliegue en el ESB como un
servicio se deben considerar ciertos aspectos de configuración [6].
4.2.3 EJEMPLO
El ejemplo ilustrado en este documento está basado en bpm_orchestration4 provisto por la versión 4.9
bus de servicios de JBoss [16].
rule "Logging"
salience 20
when
order: OrderHeader()
customer: Customer()
then
System.out.println("Customer Status: " + customer.getStatus());
System.out.println("Order Total: " + order.getTotalAmount());
System.out.println("Order Priority: " + order.getOrderPriority());
end
Se usa el lenguaje propio de Drools relacionado con las reglas de negocio.
5. REGISTRO E INVOCACIÓN A SERVICIOS WEB
5.1 INTRODUCCIÓN
Los servicios web son servicios que se encuentran en la web, proporcionados por una entidad
proveedora y los cuales son expuestos para ser usados por otros programas u otros usuarios [3]. Con el
fin de mantener los principios de la arquitectura orientada a servicios (SOA), todo en JBossESB es un
servicio o un mensaje, los servicios encapsulan lógica de negocio o puntos de integración con otros
sistemas y los mensajes establecen la manera como los clientes y los servicios se comunican [4].
JBossESB soporta servicios web SOAP a través de diferentes mecanismos [2]:
● SOAPClient para invocar servicios web externos.
● SOAPProduces para invocar servicios web JBoss lanzados internamente.
● Servicios Web Basados en el Bus de servicios ESB (EBWS) como servicio de solicitud/respuesta
mediante SOAP.
● HttpRouter el cual puede ser usado manualmente para invocar un punto HTTP
● Soporte explícito para un servicio web proxy vía SOAPProxy.
5.2 PUBLICACIÓN DE UN SERVICIO WEB
Se deben tener en cuenta los siguientes aspectos al momento de publicar un servicio:
1. El contrato conceptual que es expuesto a los consumidores y el cual debe estar definido en
términos de mensajes, debe especificar el mensaje de tipo respuesta que generará [4]. La
definición del contrato puede ser especificada en un servicio por la inclusión de una definición
de un esquema XML representando la solicitud entrante, la respuesta saliente y mensajes de
fallo [4].
2. La información del contrato debe ser publicada en el Registry, en el momento JBossESB no
cuenta con una manera automática de hacerlo [4].
La declaración del contrato automaticamente habilitará la publicación del servicio ESB a través de un
Webservice endpoint.
5.3 SERVICIOS E INVOCACIÓN
Un servicio ESB se compone por una lista de clases Action, las cuales procesan el mensaje ESB de
manera secuencial (Action Pipeline) [4]. Cuando JBossESB lanza el servicio el usa los atributos del
servicio para ubicar los Listeners en el servicio de registro [4]. Los clientes pueden invocar el servicio
usando el ServiceInvoker de la siguiente manera:
ServiceInvoker invoker = new ServiceInvoker(attributes);
Message message = MessageFactory.getInstance().getMessage();
message.getBody().add(#...#);
invoker.deliverAsync(message);
El ServiceInvoker usa el servicio de registro para buscar las direcciones finales disponibles para un
servicio publicado; toma en cuenta todos los detalles de transporte de obtener el mensaje del Cliente a
uno de los servicios finales disponibles (JMS, FTP, HTTP, etc) [4].
JBoss soporta 2 tipos de Listeners:
● Gateway Listener Obtiene mensajes de un bus ESB. Se encarga de normalizar el mensaje
envolviendolo en un mensaje ESB antes de enviarlo al servicio Pipeline Action [4].
● ESB-Aware Listener: Son usados para intercambiar mensajes ESB en el bus, entre componentes
de tipo ESB Aware [4].
5.4 MENSAJES
Los mensajes son las interacciones que existen entre los clientes y los servicios con JBossESB. Se
recomienda mantener el bajo acoplamiento utilizando intercambio de mensajes en vez de mensajes de
tipo solicitud-respuesta [4]. La estructura del mensaje está compuesto de los siguientes elementos:
● Cuerpo
● Encabezado
● Adjuntos
● Propiedades
5.5 ORQUESTANDO SERVICIOS WEB
JBossESB provee WS-BPEL que contiene los componentes para soporte de servicios web [6]. Entre los
componentes se encuentran:
● SOAPProcessor: soporta la invocación de servicios web JBoss a través de Listeners alojados en
el bus de servicios. Estos servicios pueden ser invocados por cualquier medio de transporte
soportado por el bus (http, ftp, jms, etc) [7].
● ESB Listeners: Cualquier servicio web puede ser expuesto a través de ellos, los cuales incluyen
endpoints publicados desde adentro (.war) y desde afuera (.ear) [7].
● SOAPClient: construye mensajes para un servicio específico, este servicio enruta el mensaje a
dicho servicio [7].
5.6 EJEMPLO WEBSERVICE_CONSUMER2
5.6.1 DESCRIPCIÓN GENERAL DEL EJEMPLO
El ejemplo muestra como consumir un servicio web en una acción ESB. El ESB realizará una solicitud al
servicio web enviando una orden y un listado de ítems; el servicio web retornará el estado de la orden
[8].
5.6.2 ARCHIVOS Y CARACTERÍSTICAS NECESARIAS
5.6.2.1 JBOSS-ESB.XML
El cliente Java interactúa directamente con la cola ESB [8].
<jms-bus busid="quickstartEsbChannel">
<jms-message-filter dest-type="QUEUE"
dest-name="queue/quickstart_webservice_consumer2_esb" />
</jms-bus>
Las acciones en este archivo permiten convertir el mensaje ESB a un mapa de parámetros, hacer un
llamado al servicio web OrderProcessorWS e imprime la respuesta por consola [8].
<actions mep="OneWay">
<!--Conversión al mapa de parámetros-->
<action name="request-mapper" class="...MyRequestAction">
...
</action>
<!--Llamado al servicio web-->
<action name="soapui-client-action" ...>
<property name="wsdl" value=".../OrderProcessorWS?wsdl" />
<property name="responseAsOgnlMap" value="true" />
<property name="SOAPAction" value="processOrder"/>
</action>
<!--Respuesta-->
<action name="response-mapper"class="...MyResponseAction">
</action>
...
</actions>
5.6.2.2 JBOSSESB-PROPERTIES.XML
Se utiliza cuando se inicia el primer servicio para auto-registro basado en la categoría y el nombre que
se encuentra en el archivo jboss-esb.xml [8].
5.6.2.3 BUILD.XML
Incluye las propiedades del ant para poner a funcionar el ejemplo. Una de las más importantes es la
tarea RunTest que llama a la clase SendEsbMessage que pasa el mensaje mediante una cadena que
será puesto en la cola [8].
5.6.3 CLASES INVOLUCRADAS
5.6.3.1 SENDESBMESSAGE
Mediante el método sendMessage() envia el mensaje directamente al listener JMS al bus de servicios
[8].
5.6.3.2 MYREQUESTACTION
Convierte el cuerpo del mensaje (OrderProcessor) en un mapa de parámetros (request-params) que
corresponde a la solicitud del servicio web [8]. Cuenta con 2 métodos option1() y option2(), el tomará
el que sea configurado en el archivo jboss-esb.xml, que corresponden a diferentes tipos de mensajes
que se enviaran.
5.6.3.3 SOAPCLIENT
Es la encargada de hacer el llamado al servicio web. Toma los parámetros de la clase MyRequestAction,
luego hace el llamado y finalmente coloca la respuesta en la ubicación por defecto [8].
5.6.3.4 MYRESPONSEACTION
Mediante el método Message Process (Message message) se encarga de recuperar el mensaje e
imprimirlo por consola [8].
6. INTEGRACIÓN DE BPM COMO ORQUESTADOR DE SERVICIOS DEL BUS
6.1 INTRODUCCIÓN Y CAPACIDADES DE BPM COMO ORQUESTADOR PRINCIPAL
JBoss jBPM es un motor de gestión de procesos que incluye el manejo de flujos de trabajo. JBoss jBPM
combina el desarrollo sencillo de flujos de trabajo con un motor de procesos escalable y flexible [6].
JBossESB integrado con jBPM es usado para 2 propósitos:
1. Orquestación de servicios: los servicios ESB pueden ser orquestados usando jBPM. Se crean
definiciones de procesos en jBPM que pueden invocar servicios ESB [6].
2. Gestión de tareas humanas: jBPM permite incorporar la gestión de tareas humanas con una
maquina basada en servicios [6].
6.2 LA CONSOLA JBPM
La consola jBPM es una aplicación web disponible cuando se inicia el servidor, mediante el siguiente
enlace: http://localhost:8080/jbpm-console/. La consola puede ser utilizada para publicar y
monitorear procesos jBPM, también es usada para la gestión de tareas humanas. Las secciones a
continuación se explicarán mediante el ejemplo bpm_orquestation4, el cual muestra cómo incorporar
la gestión de tareas humanas y orquestación de servicios ESB en un único proceso de negocio de
extremo a extremo [6].
6.2.1 CREACIÓN Y PUBLICACIÓN DE LA DEFINICIÓN DE UN PROCESO
Para crear la definición del proceso es más sencillo utilizar el diseñador de procesos jBPM. La gráfica a
continuación muestra el proceso de negocio mediante el editor gráfico jBPM, el cual permite la
creación de nodos y transiciones de manera gráfica, automáticamente el guarda un XML con esa
información [6]:
En la imagen anterior se puede observar en la parte inferior 4 pestañas, correspondiente a las
diferentes vistas que ofrece el diseñador de procesos jBPM; para realizar la publicación del proceso
selecciona la pestaña 2 Deployment, le mostrará una ventana de la siguiente manera:
Para publicar el proceso primero valida la conexión mediante el botón Test Connection y luego oprime
Deploy Process Archive.
6.2.2 LANZAMIENTO Y MONITOREO DE UNA INSTANCIA DEL PROCESO
Una vez el proceso ha sido publicado, en la consola se puede hacer seguimiento de él, monitoreando
cada instancia que se lanza de dicho proceso.
¿Cómo se lanza una instancia del proceso? La forma más sencilla es mediante el comando startProcess
que ofrece Ant. Este comando inicia la nueva instancia del proceso con información de una orden, al
lanzarlo de esta manera la instancia cuando se revisa a través de la consola queda en la tarea Review
Order, la cual es una tarea humana, esto también indica que el sistema invocó al servicio ESB de Intake
Order. Los detalles de cada instancia se pueden observar a través de la consola jBPM, entre ellas la
imagen del proceso, oprimiendo examine a la instancia del proceso que desea consultar.
6.2.3 SOPORTE DE TAREAS HUMANAS
La consola jBPM permite completar las tareas humanas del proceso de negocio, cuando se selecciona la
instancia, el inmediatamente muestra los detalles del formulario, los cuales se deben modificar o
revisar para completar la tarea.
Para la revisión de la orden se modifica el estado del cliente y se oprime el botón de guardar y salir, de
esta manera se asegura que la tarea ha finalizado. El motor BPM pasa a la siguiente tarea
correspondiente a un servicio ESB que se ejecuta automaticamente y pasa a la siguiente tarea, la cual
es otra tarea humana denominada Review Discount.
Un problema que se encontró durante la ejecución del ejemplo, es que a pesar de que existen los
distintos roles todos pueden completar las tareas, no hay restricciones de protección de permisos
dependiendo de los roles.
6.3 SOPORTE DE INVOCACIÓN DE SERVICIOS DEL BUS
Esto es lo que se denomina orquestación de servicios. La interacción con JBossESB es de manera
asincrónica, es decir, no espera respuesta y por lo tanto no bloquea la instancia del proceso mientras el
servicio se ejecuta. Se pueden invocar servicios ESB que almacenan algunas acciones especiales en la
definición del proceso [6] [15]. La comunicación puede ser de 3 maneras:
1. Llamado en un solo sentido: Se envía la información de jBPM al bus, mediante la invocación de
la acción ESBNotifier cuando ocurre la transición de un nodo a otro. Como se pasa la
información del jBPM al ESB se utiliza la etiqueta bpmToEsbVars dentro de la acción [15]. En el
ejemplo dentro del archivo processDefinition.xml en la pestaña de Source se puede observar
que el último nodo correspondiente a ShipIt utiliza este tipo de comunicación:
<node name="Ship It">
<transition name="" to="end">
<action name="esbAction" class="...EsbNotifier">
<esbCategoryName>BPM_Orchestration4</esbCategoryName>
<esbServiceName>ShippingService</esbServiceName>
<bpmToEsbVars>
<mapping bpm="entireCustomerAsObject" esb="customer" />
…
</bpmToEsbVars>
</action>
</transition>
</node>
2. Llamado en dos sentidos: Si se requiere retornar información al proceso, se puede utilizar el
EsbActionHandler. Este está adjuntado a un nodo no a una transición, el EsbActionHandler se
ejecuta y deja al nodo esperando por la señal de transición [15]. En el ejemplo los 2 nodos de
Intake Order y Calculate Discount utilizan este tipo de comunicación, a continuación se ilustra
el primer nodo, en el atributo de clase se observa que utiliza el EsbActionHandler:
<node name="Intake Order">
<action name="esbAction" class="...EsbActionHandler">
<esbCategoryName>BPM_Orchestration4</esbCategoryName>
<esbServiceName>IntakeService</esbServiceName>
<!-- async call of IntakeService -->
<bpmToEsbVars>
<mapping bpm="entireOrderAsXML" esb="BODY_CONTENT" />
</bpmToEsbVars>
…
</action>
<transition name="" to="Review Order"></transition>
</node>
3. Llamado en dos sentidos con tiempo de espera: Cuando se usa el EsbActionHandler muchas
veces se necesita limitar cuanto tiempo esperar, para este escenario se agrega el nodo de
tiempo, denominado ExceptionHandling [15]. En el ejemplo de bpm_orquestation4 no se
representa este tipo de comunicación, sin embargo, es únicamente agregar la siguiente
etiqueta dentro del nodo:
<transition name="time-out-transition" to="ExceptionHandling"/>
7. REFERENCIAS
[1] Smooks V 1.2 User Guide.
http://www.smooks.org/mediawiki/index.php?title=V1.2:Smooks_v1.2_User_Guide#Overview
[2] Ward David. Proxying SOAP Web Services in JBossESB 4.7. JBoss ESB Team Blog.
http://jbossesb.blogspot.com/2009/11/proxying-soap-web-services-in-jbossesb.html
[3] Definición de servicios web; última consulta realizada mayo 18/2011;
http://searchsoa.techtarget.com/definition/Web-services
[4] JBossESB Development Team; Your guide to developing for the JBoss ESB; Programmers Guide.
[5] Página de descarga e información de JiBX. http://jibx.sourceforge.net/
[6] JBossESB Development Team; Your guide to services available in JBossESB; Services Guide.
[7] JBoss; Message Action Guide; August 29/2007.
[8]Descripción general del ejemplo webservice_consumer2, readme.txt sobre el directorio
/samples/webservice_consumer2.
[9] María Consuelo Franky; Buses de servicios para soportar aplicaciones SOA.
[10]PolarLake; Understanding the ESB white paper; descarga:
http://www.polarlake.com/files/esb.pdf.
[11]Información sobre JBossESB; última consulta realizada 23/05/2011;
http://www.jboss.org/jbossesb/resources/WhatIsAnESB.html
[12] JBossESB Requirements and Architecture, Version: 0.3; 2006.
[13] Información sobre arquitectura JBossESB; última consulta realizada 23/05/2011;
http://www.korecky.org/?p=420&langswitch_lang=en.
[14] Información sobre arquitectura JBossESB; última consulta realizada 23/05/2011;
http://docs.redhat.com/docs/en-
US/JBoss_Enterprise_SOA_Platform/4.2/html/SOA_ESB_Programmers_Guide/SOA_ESB_Programmers_G
uide-JBoss_ESB-_The_core_of_JBossESB_in_a_nutshell_.html
[15] Información sobre orquestación de servicios; última consulta realizada 26/05/2011;
http://www.mastertheboss.com/jboss-esb/120-esb-service-orchestration-with-jbpm.html
[16] JBoss ESB. Página de descarga. http://www.jboss.org/jbossesb
[17] Free Maker. Página de descarga y documentación. http://freemarker.sourceforge.net/
[18] Drools. Motor de reglas de negocio. http://www.jboss.org/drools
[19] DiMaggio Len. The JBoss ESB – Drools Integration in the JBoss SOA Plataform.
http://java.dzone.com/articles/jbossesb-drools-integration
