Guía

Modelado e implementacin de un
proceso de negocio BPM mediante

herramientas SOA de software libre.
Gua prctica
Trabajo de grado: Modelado e implementacin de un proceso de negocio BPM mediante herramientas SOA
de software libre.
Caso: Seleccin y Contratacin de profesores de ctedra de la Pontificia Universidad Javeriana
Estudiante: Cristian David Romero Melgarejo, cristian.romero@javeriana.edu.co
Directora: Ing. Mara Consuelo Franky de Toro, lfranky@javeriana.edu.co
Bogot D.C. Segundo semestre del ao 2011
2|Gua Prctica. BPM - SOA

ndice
Tabla de ilustraciones......................................................................................................................................... 4
1. Introduccin................................................................................................................................................ 6
1.1. Acerca de la gua............................................................................................................................... 6
1.2. Acerca del demo................................................................................................................................ 6
1.2.1. Descripcin del Proceso de seleccin........................................................................................ 6
1.2.2. Descripcin del Proceso de contratacin...................................................................................8
1.2.3. Descripcin del Demo................................................................................................................ 9
2. Conceptos de BPM y su implantacin con herramientas SOA.................................................................10
2.1. Procesos de negocio........................................................................................................................ 10
2.2. Gestin de Procesos de negocio (BPM)........................................................................................... 11
2.2.1. Definicin.................................................................................................................................. 11
2.2.2. Qu hace BPM?..................................................................................................................... 12
2.3. Arquitectura orientada a servicios (SOA)......................................................................................... 13
2.4. Bus de servicios empresariales (ESB)............................................................................................. 16
3. Instalacin de herramientas..................................................................................................................... 18
3.1. Eclipse.............................................................................................................................................. 18
3.2. Plugins.............................................................................................................................................. 18
3.3. JBoss AS.......................................................................................................................................... 19
3.4. JBoss ESB....................................................................................................................................... 19
4. Modelacin de procesos en BPMN.......................................................................................................... 20
4.1. Introduccin...................................................................................................................................... 20
4.2. Demo................................................................................................................................................ 21
4.2.1. Proceso de seleccin................................................................................................................... 22
4.2.2. Proceso de contratacin............................................................................................................... 23
5. Modelacin de procesos en jBPM............................................................................................................ 25
5.1. Introduccin...................................................................................................................................... 25
5.2. Qu permite modelar el editor grfico de jBPM?............................................................................26
5.2.1. Descripcin general.................................................................................................................. 26
5.2.2. Nodos....................................................................................................................................... 27
A. Responsabilidad de los Nodos..................................................................................................... 27
B. Tipo de Nodo: Tarea..................................................................................................................... 27
C. Tipo de Nodo: Estado................................................................................................................... 27
D. Tipo de Nodo: Decisin................................................................................................................. 27
E. Tipo de Nodo: Fork....................................................................................................................... 28
F. Tipo de Nodo: Join....................................................................................................................... 28
G. Tipo de Nodo: Nodo...................................................................................................................... 28

H. Tipo de Nodo: Start-State............................................................................................................. 29
I. Tipo de Nodo: End-State.............................................................................................................. 29
J. Tipo de Nodo: Mail-Node.............................................................................................................. 29
K. Tipo de Nodo: ESB-Service.......................................................................................................... 29
5.2.3. Transiciones............................................................................................................................. 29
5.3. Adaptacin a partir de un modelo BPMN.........................................................................................31
5.4. Demo................................................................................................................................................ 35
5.4.1. Archivo XML generado............................................................................................................. 39
6. Implantacin del proceso de negocio usando la consola de JBoss.........................................................42
6.1. Introduccin...................................................................................................................................... 42
6.2. Demo................................................................................................................................................ 43
6.2.1. Alcance..................................................................................................................................... 43
6.2.2. Formularios............................................................................................................................... 43
A. Complemento de cdigo en el nodo............................................................................................43
B. Creacin de la forma................................................................................................................... 44
C. Integracin del nodo con la forma................................................................................................46
6.2.3. Creacin de usuarios................................................................................................................ 46
6.2.4. Nodo de correo electrnico...................................................................................................... 48
6.2.5. Nodo de decisin...................................................................................................................... 49
6.2.6. Nodos para llamar servicios web.............................................................................................. 50
6.2.7. Uso del bus de servicios........................................................................................................... 53
7. Integracin de una aplicacin JEE5 con el bus de servicios de JBoss....................................................58
7.1. Introduccin...................................................................................................................................... 58
7.1.1. Anotacin @CreateProcess..................................................................................................... 58
7.1.2. Anotacin @ResumeProcess................................................................................................... 58
7.1.3. Anotacin @StartTask.............................................................................................................. 58
7.1.4. Anotacin @BeginTask............................................................................................................ 59
7.1.5. Anotacin @EndTask............................................................................................................... 59
7.1.6. Relacin Entre Anotaciones...................................................................................................... 60
8. Referencias.............................................................................................................................................. 61

Tabla de ilustraciones
Ilustracin 1. Relacin entre servicios de negocio y procesos en SOA [18].....................................................10
Ilustracin 2. Ejemplo de un modelo en notacin BPMN [19]..........................................................................12
Ilustracin 3. Elementos arquitecturales de SOA [18]......................................................................................14
Ilustracin 4. Perspectiva empresarial de SOA [18].........................................................................................15
Ilustracin 5. Arquitectura del bus de servicios empresariales.........................................................................16
Ilustracin 6. Ejemplo de proceso en BPMN [19]............................................................................................. 20
Ilustracin 7. Proceso de seleccin de profesores de ctedra de la Pontificia Universidad Javeriana.............23
Ilustracin 8. Proceso de contratacin de profesores de ctedra de la Pontificia Universidad Javeriana........24
Ilustracin 9. Ejemplo inicial de un modelo desarrollado con jBPM.................................................................26
Ilustracin 10. Creacin de un nuevo proyecto................................................................................................35
Ilustracin 11. Asignando nombre a un nuevo proyecto...................................................................................35
Ilustracin 12. Creacin de un nuevo elemento............................................................................................... 36
Ilustracin 13. Creacin del elemento Process Definition................................................................................36
Ilustracin 14. Nombrando el proceso.............................................................................................................. 37
Ilustracin 15. Partes importantes para la realizacin de diagramas...............................................................37
Ilustracin 16. Demo en notacin BPMN......................................................................................................... 38
Ilustracin 17. Demo jBPM............................................................................................................................... 39
Ilustracin 18. Pestaas de navegacin en Eclipse......................................................................................... 39
Ilustracin 19. Estructura del cdigo jpdl generado por el grafo.......................................................................41
Ilustracin 20. Vista general de los componentes de la consola [27]...............................................................42
Ilustracin 21. Alcance del desarrollo del demo utilizando la Consola.............................................................43
Ilustracin 22. Cdigo en jPDL asociado al formulario de una tarea humana..................................................44
Ilustracin 23. Cdigo xhtml del formulario de la tarea humana.......................................................................46
Ilustracin 24. Estructura de cdigo en forms.xml............................................................................................ 46
Ilustracin 25. Cdigo SQL para insercin de usuarios....................................................................................47
Ilustracin 26. Relacin de la creacin de usuario con el proceso...................................................................47
Ilustracin 27. Cdigo SQL para insercin de grupos......................................................................................47
Ilustracin 28. Cdigo SQL para relacin de usuarios con grupos...................................................................48
Ilustracin 29. Estructura del nodo para enviar un correo electrnico..............................................................48
Ilustracin 30. Mtodo para el envo de un correo electrnico.........................................................................49
Ilustracin 31. Estructura del nodo de decisin................................................................................................50
Ilustracin 32. Estructura de la celda para el checkbox de aprobacin............................................................50
Ilustracin 33. Ruta de creacin del servicio web............................................................................................ 51
Ilustracin 34. Estructura de la clase que contiene el servicio web..................................................................51
Ilustracin 35. Muestra de la bsqueda del .wsdl.............................................................................................52
Ilustracin 36. Estructura de la celda para el checkbox de aprobacin............................................................53
Ilustracin 37. Cambio de tipo de nodos.......................................................................................................... 53
Ilustracin 38. Creacin de la cola para el servicio de correo electrnico en el descriptor hornetq-jms.xml....53
Ilustracin 39. Creacin de la cola para el servicio de invocacin de un servicio web en el descriptor hornetq-
jms.xml............................................................................................................................................................. 53
Ilustracin 40. Creacin del mbean para el servicio de correo electrnico en el servidor JMS en el descriptor
jbm-queue-service.xml..................................................................................................................................... 54
Ilustracin 41. Creacin del mbean para el servicio de invocacin de un servicio web en el servidor JMS en el
descriptor jbm-queue-service.xml.................................................................................................................... 54

Ilustracin 42. Creacin del mbean para el servicio de correo electrnico en el servidor JMX en el descriptor
jbmq-queue-service.xml................................................................................................................................... 54
Ilustracin 43. Creacin del mbean para el servicio de invocacin de un servicio web en el servidor JMX en el
descriptor jbmq-queue-service.xml.................................................................................................................. 54
Ilustracin 44. Creacin de los canales de correo electrnico e invocacin de servicio web en el descriptor
jboss-esb.xml................................................................................................................................................... 55
Ilustracin 45. Estructura de los servicios registrados en el bus en el descriptor jboss-esb.xml......................56
Ilustracin 46. Lneas a insertar en el descriptor de despliegue de colas del bus en el descriptor
deployment.xml................................................................................................................................................ 56
Ilustracin 47. Cambio en las clases................................................................................................................ 57
Ilustracin 48. Solicitud de materia prima........................................................................................................ 60

1. Introduccin
1.1. Acerca de la gua
Este documento pretende ser una gua para las Pymes que busquen implementar sus procesos de negocio
bajo la filosofa de BPM (Gestin de procesos de negocio), apoyados en una arquitectura orientada a
servicios (SOA).
Es importante anotar que con cualquiera de las suites o conjunto de herramientas SOA la curva de
aprendizaje es elevada, es decir, el tiempo que toma aprender y desarrollar un manejo intermedio de stas
suele ser extenso. Por esta complejidad, surge la motivacin de elaborar la presente gua con el nimo de
facilitar el camino a las Pymes.
Por otro lado, las suites SOA son herramientas muy costosas y en general fuera del alcance del presupuesto
disponible por empresas Pymes. Por esta razn, esta gua fue elaborada pensando en esa situacin, dando
todas las definiciones y ejemplos a partir de las herramientas libres provistas por el proveedor RedHat-Jboss.
1.2. Acerca del demo

Dos de los procesos ms comunes a los que se enfrenta una empresa son los de seleccin y contratacin de
los recursos humanos que harn posible la operacin y el desarrollo de funciones dentro de ella. Por sta
razn, se escogieron como casos de estudio, los procesos de seleccin y contratacin de profesores de
ctedra de la Pontificia Universidad Javeriana.
1.2.1. Descripcin del Proceso de seleccin

El proceso de seleccin consiste en los siguientes pasos:
1. El director de departamento o instituto crea una vacante para un profesor de ctedra dentro del
sistema.
2. El profesional de compensacin de la oficina de relaciones laborales de la Universidad revisa la

apertura de la vacante y las caractersticas con las que es solicitada.
3. Luego de efectuarse la revisin, la misma persona del paso anterior, evala si la vacante es o no
aprobada, para continuar o examinar el proceso hasta ste punto.
4. Si la vacante fue rechazada, el profesional de compensacin notifica va correo electrnico al director

de departamento o instituto sobre esta situacin.
a. Luego de la notificacin del rechazo, se procede a eliminar la vacante creada en el sistema,

para que sea creada de nuevo con las correcciones impuestas.

5. Si el director de departamento o instituto solicito la publicacin de la vacante en los medios externos
dispuestos por la Universidad, se ejecutar esta accin.
6. Independientemente de si se solicit publicacin externa, se publica la vacante en el sistema interno

de la Universidad.
7. En este punto, los candidatos pueden ingresar a llenar su hoja de vida y adjuntar la documentacin
de soporte.
8. El director de departamento o instituto puede asociar los candidatos inscritos a las vacantes
disponibles.
9. El director de departamento o instituto hace una preseleccin de las hojas de vida, dados los perfiles
de los postulantes.
10. Si en la preseleccin se solicit la realizacin de una entrevista con el Decano Acadmico para
asegurar algn punto del perfil de la persona, se ejecutar esta accin.
11. El director de departamento o instituto prepara la oferta e ingresa el salario sugerido en el sistema
ERP e inicia el proceso de aprobacin a travs del workflow al decano acadmico.
12. El decano acadmico recibe y revisa la solicitud y documentacin de soporte sobre la oferta
econmica.
13. Luego de revisarla, el decano deber aprobar o rechazar la solicitud.
14. Si la solicitud fue rechazada, el decano acadmico le notifica al director de departamento o instituto,
va correo electrnico, para que realice los ajustes respectivos.
15. Si la solicitud fue aprobada, se le notifica va correo electrnico al asistente para asuntos
profesorales.
16. El asistente para asuntos profesorales recibe y revisa la solicitud y documentacin de soporte sobre
la oferta econmica.
17. El asistente para asuntos profesorales debe aprobar o rechazar la solicitud.
18. Si la solicitud fue aprobada, se le notifica va correo electrnico al vicerrector acadmico.
19. Si la solicitud fue rechazada, el asistente para asuntos profesorales le notifica va correo electrnico
al decano acadmico para la realizacin de los ajustes respectivos.
a. El decano acadmico realizar los ajustes a la oferta econmica realizada, si as se lo indica

el asistente para asuntos profesorales.
20. El vicerrector acadmico recibe y revisa la solicitud y documentacin de soporte sobre la oferta
econmica.
21. El vicerrector debe aprobar, devolver o rechazar la solicitud.

22. Si la solicitud fue rechazada, el vicerrector acadmico le notifica, va correo electrnico, al decano
acadmico y el proceso vuelve a comenzar desde el numeral 2.
23. Si la solicitud fue devuelta, el vicerrector acadmico le notifica va correo electrnico al asistente para
asuntos profesorales.
a. El asistente para asuntos profesorales revisa las razones por las cuales la oferta fue
devuelta. l decide si devuelve o no la oferta al decano acadmico.
b. Si no la devuelve, se realiza la gestin indicada con el decano acadmico para pasar a

revisin directa con el vicerrector acadmico.
c. Si es devuelta al decano acadmico y despus de que sea realizada la gestin de

correccin, el decano acadmico le notifica al vicerrector acadmico.
24. Si la solicitud fue aceptada, el vicerrector acadmico le notifica va correo electrnico al Jefe de la
oficina de relaciones laborales.
25. El jefe de la oficina de relaciones laborales le realiza la oferta econmica al candidato, con copia al
analista de nmina, profesional de induccin y secretario de facultad.
26. El analista de nmina de la oficina de relaciones laborales prepara el contrato para el candidato.
27. Se realiza la vinculacin laboral en el ERP, la asociacin de la clase y genera el contrato en el

Sistema de administracin de estudiantes (SAE). Esta tarea est a cargo del secretario de facultad.
28. El candidato revisa los trminos de su contrato y la oferta econmica realizada.
29. El candidato deber evaluar si acepta o no el contrato con la Universidad.
30. Si el candidato no acepto, se le solicita al analista de nmina la terminacin del contrato por
inconsistencia.
31. Si el candidato acepta, se procede a realizar el proceso de contratacin.
1.2.2. Descripcin del Proceso de contratacin

El proceso de contratacin consiste en los siguientes pasos:
1. Dados los recursos de informacin se define si el profesor es nuevo.
2. En caso de que un profesor sea nuevo:
a. Verifica el nombramiento y realiza la solicitud de una apertura bancaria para el pago de la

nmina.
b. Se realiza el proceso del examen mdico.
c. Se realiza el proceso de la carnetizacin institucional.

d. Se realizan las afiliaciones a seguridad social AHC: Se solicitan los datos respectivos para
los trmites de afiliacin a seguridad social
e. Se le asigna una cuenta de correo electrnico al profesor.
f. Se genera el contrato en el sistema ERP con la firma digital del director de recursos
humanos y se notifica a la facultad.
g. El secretario de facultad le notifica al candidato que debe acercarse a la facultad para firmar
el contrato.
3. Se firma el contrato y es remitido a la direccin de recursos humanos de la Universidad. Posterior a

esto, se archiva con los documentos de soporte del mismo.
1.2.3. Descripcin del Demo

A partir de la descripcin de los procesos, se modelarn en BPMN, en jBPM y luego se implantar un
subconjunto utilizando las herramientas SOA de JBoss. Esta gua ilustrar todos los pasos tanto de
modelaje como de implantacin con el nimo de que las Pymes puedan realizar implantaciones similares
de sus procesos de negocio.
Para observar todas las caractersticas del demo, debe incluir la carpeta dentro del IDE que haya
escogido para desarrollo, preferiblemente Eclipse Ganymede. Luego, podr ejecutarlo registrado el
buildfile en el plugin de Ant, y corriendo la funcin deploy.
10 | G u a P r c t i c a . B P M - S O A
2. Conceptos de BPM y su implantacin
con herramientas SOA
2.1. Procesos de negocio
Las tcticas de negocio y los objetivos son definidos tpicamente para unos procesos de negocio particulares.
Un proceso de negocio es un grupo de actividades lgicas relacionadas (y generalmente secuenciales) que
usan los recursos de la organizacin para proveer resultados definidos. Los procesos de negocio entregan
valor en forma de productos o de servicios, frecuentemente a una entidad externa como un consumidor o un
asociado [18].
Generalmente los procesos de negocio cuentan con dos niveles de detalle. Esto se hace para que logre
existir un acuerdo entre los ejecutivos de la compaa y los dueos del proceso de negocio. Un modelo,
para ejecutivos, contiene un conjunto de escenarios de algo nivel de negocio que muestran el propsito de la
organizacin. El otro modelo, que es para los dueos del proceso de negocio, contiene un conjunto detallado
de casos de uso que definen como se suplen las necesidades de la organizacin. Para cada escenario de
negocio de alto nivel, usted puede definir uno, o varios, casos de uso de negocio detallados representando
las mismas actividades en la organizacin (IBMs Rational Unified Process [RUP] for SOMA) [18].
Los escenarios de negocio creados junto con una primera definicin de los procesos de negocio son tiles a
la hora de descomponer y detallar los procesos desarrollados en la empresa. Por ejemplo, si tomamos el
caso de contratacin de profesores de una universidad podramos definirlo a grandes rasgos en una primera
instancia, sin embargo, a medida que detallemos este proceso de negocio podramos tener nuevos sub-
procesos o actividades agregadas al macro-proceso, cmo por ejemplo la realizacin de la evaluacin
mdica, la carnetizacin o la inclusin en determinado software que requiera de varios pasos para el uso del
nuevo profesor [18].
Cmo se vio en la seccin anterior, una arquitectura orientada a servicios entra a jugar un papel muy
importante con los procesos de negocio. Precisamente su objetivo es reconocer y exponer los activos de
computacin de la organizacin como servicios de negocio reusables que implementen ciertas
funcionalidades bsicas, las cuales al ser combinadas permitan el apoyo a la ejecucin de complejos
procesos de negocio. En este punto vemos una relacin directa entre lo llamado procesos de negocio y
servicios de negocio. A continuacin se detalla esta relacin [18].
Ilustracin 1. Relacin entre servicios de negocio y procesos en SOA [18]
Los servicios de negocio se encargan de dar apoyo a los procesos de negocio a travs de la
exhibicin de las funcionalidades que se han implementado. Es muy comn que la implementacin
de los servicios de negocio cambien, precisamente porque a medida que cambia el negocio, puede
que deban ofrecer unas nuevas o mejoradas funcionalidades. Sin embargo, las reglas con las cuales
se publicaron las interfaces muy rara vez cambian, es decir, que la forma de llamar al servicio no
tendr variacin as la forma en que ejecuta las rdenes pedidas si haya cambiado [18].
Los procesos de negocio se valen de los servicios de negocio para alcanzar los objetivos de la
empresa. Cambian debido a cambios en la estrategia de la organizacin. En estos procesos se
contemplan procedimientos y reglas que sirven a determinados aspectos dentro del negocio [18].
La interaccin entre los procesos de negocio y los servicios de negocio se basa en la semntica
definida, como se hablaba en la seccin anterior sobre SOA. Tener un estndar y un acuerdo para
lograr la comunicacin entre estos dos aspectos es vital para reducir el impacto que puede generar
un cambio en cualquiera de las partes y para simplificar el proceso de construccin de los servicios
de negocio que finalmente apoyaran los procesos de negocio [18].
Es importante separar estos dos aspectos para permitir que por un lado los arquitectos de la seccin de
tecnologas de informacin tengan el conocimiento sobre los servicios de negocio y cmo estos pueden ser
re-usados y configurados de tal forma que sirvan a los procesos de negocio definidos por los analistas de
negocio. A travs de esta separacin, se simplifica la creacin de nuevos procesos y la optimizacin de los
existentes. Y ms importante an, con los continuos cambios que se presentan en el mercado y dados
nuevos factores de competitividad, una empresa puede ser flexible y mantener sus ventajas con bajos costos
a la hora de realizar soportar estos cambios con la re-configuracin de sus procesos de negocio y a su vez
de los servicios de negocio con los que cuente dentro de la organizacin [18].
2.2. Gestin de Procesos de negocio (BPM)

2.2.1. Definicin
Luego de ver la definicin y las caractersticas de los procesos de negocio, aparece la pregunta sobre cmo
lograr una gestin efectiva de estos procesos de negocio? Para dar respuesta a ella, surgi una filosofa
llamada BPM.
As como las personas entienden mejor los objetos o fenmenos a travs de modelos, las organizaciones,
compuestas de personas, tambin lo hacen. Gracias a los modelos, se tiene la capacidad de identificar
visualmente los problemas, y como pueden ser sealados como punto de mejora en una situacin dada. Y
los procesos de negocio no son la excepcin cuando se habla de modelos. La modelacin de procesos
pertenecientes a una organizacin, o inclusive a travs de varias organizaciones, puede resaltar
instantneamente problemas y es una herramienta importante para la simulacin de la eficiencia de ciertos
procesos [20].
La gestin de procesos de negocio (BPM) es un conjunto de mtodos, herramientas y tecnologas usadas

para disear, modelar, analizar y controlar los procesos operacionales de un negocio. BPM pretende tener
una visin de stos procesos desde dos ngulos: tecnologas de informacin y el provisto por los analistas de
negocio. De esta forma se busca llegar a conformar procesos efectivos, agiles y transparentes [23].
La tecnologa de BPM debe incluir todo lo necesario para disear, representar, analizar y controlar los
procesos operacionales del negocio [23]:
El modelamiento de procesos y diseo hacen posible que se plasme de una forma rpida y rigurosa
la forma en que los procesos entregan valor a la organizacin y sus clientes. Adems, se ilustra que
recursos son necesarios y que rol juegan dentro del proceso.
Ilustracin 2. Ejemplo de un modelo en notacin BPMN [19]
La integracin se relaciona con aspectos de sistemas de control, sistemas de informacin, fuentes de

datos y otras tecnologas que puedan ser re-utilizadas y re-configuradas de tal forma que se pueda
adaptar a los cambios impulsados por el mercado, cumpliendo detalladamente con las necesidades
de un proceso determinado.
La ejecucin es necesaria para que un modelo no se quede solo en diseo, sino que tambin se
permita ejecutar el modelo planteado.
Monitoreo de las actividades de negocio: Un seguimiento a las actividades dentro del proceso de
negocio es fundamental para obtener retroalimentacin a travs de mtricas, monitoreo, indicadores
y tendencias.
El control le permite responder a ciertos eventos o circunstancias que ocurran en la ejecucin del
proceso. Por ejemplo, un cambio de reglas, notificaciones, excepciones y aumento de la capacidad.
Retomando la definicin y las funciones que provee SOA, en este punto se puede observar como la filosofa
BPM encaja con la tecnologa provista por la arquitectura orientada a servicios. Esta es una de las razones
por las cuales se elabor la gua bajo el enfoque de BPM SOA, para ilustrar cmo se integra el modelo de
negocio con el modelo tecnolgico dentro de la empresa.
2.2.2. Qu hace BPM?

BPM es una disciplina amplia, pero tiene un propsito funcional especfico. Igualmente, los componentes
tecnolgicos necesarios para usar la filosofa BPM tendrn unas especificaciones precisas [23]:
Centralidad del proceso: BPM unifica el negocio y las actividades de TI, y coordina las acciones y
comportamientos de las personas y los sistemas alrededor de un contexto comn de procesos de
negocio. Usando convenciones y notaciones de modelacin de procesos estndar, un gerente de
operacin puede, por ejemplo, ver el proceso desde la perspectiva de negocio mientras que el
gerente de IT puede ver los sistemas y elementos de informacin.
Alineacin entre el negocio y TI: BPM facilita la colaboracin directa y la responsabilidad conjunta
tanto de los gerentes de operacin como de los profesionales de TI a la hora de disear, implementar
y optimizar los procesos de negocio.
Mejora continua del proceso: Se busca que se pueda obtener retroalimentacin de las actividades
del proceso a travs de su monitoreo y comparacin con mtricas e indicadores.
Composicin de soluciones: BPM facilita el diseo rpido, montaje y despliegue de procesos de

negocio. Un profesional de TI debe estar en la capacidad de conectar sistemas y servicios al modelo
diseado y aprobado por el analista de negocio. Adems, cada vez que haya un cambio sobre el
proceso, se debe tener la flexibilidad para que la solucin sea adaptada rpidamente.
Transparencia: BPM provee un entendimiento de las actividades para todos los participantes.
Adems, ellos deben ser capaces de ver las mtricas de negocio en tiempo real y el rendimiento de
los sistemas y servicios disponibles.
Interfaces: BPM debe proveer a los gerentes de interfaces que le permitan usar servicios tanto internos como
externos, y que estos sean re-usables y adaptables a cualquier configuracin requerida. La interface de estos
servicios tendr la informacin sobre las funciones que cumple, lo cual muy rara vez cambiar, a pesar de
que puede que su implementacin cambie continuamente.
2.3. Arquitectura orientada a servicios (SOA)

Concretamente, una arquitectura orientada a servicios es un estilo arquitectural para construir soluciones
empresariales basadas en servicios. SOA tiene que ver con la construccin independiente de servicios
alineados con el negocio que puedan ser combinados en procesos significativos, de alto nivel de negocio y
con soluciones en el contexto de la empresa. Cualquiera puede crear un servicio, ese no es el reto de SOA.
El valor real de SOA se encuentra cuando servicios reusables son combinados para crear procesos de
negocio agiles y flexibles. Desafortunadamente, esto no pasa por s solo. Lograr esto puede ser fcil si una
sola organizacin crea todos sus servicios, pero ste no es el caso de las grandes organizaciones. As que,
parte de la arquitectura de SOA es responsable de proveer el ambiente necesario para crear y usar servicios
compuestos a lo largo de la empresa [18].
En otras palabras, la arquitectura SOA permite que diferentes organizaciones desarrollen

independientemente los servicios que atiendan a sus necesidades. Sin embargo, a mediano o largo plazo,
estos servicios se pueden integrar para dar ms valor a las soluciones creadas y que estas tengan mayor
impacto en los procesos de negocio [18]. Para lograr la integracin, se requiere que los servicios:
Sean similares en cuanto a: tamao, forma, funcin y otras caractersticas.
Se adecuen a los estndares de la empresa.
Se comuniquen a un nivel tcnico.
Se comuniquen a un nivel semntico.
No tengan huecos ni solapamientos en sus responsabilidades [18].
La siguiente figura muestra las capas bajo las cuales se desempea una arquitectura orientada a servicios,
incluyendo dos capas de conceptos. Las descripciones que se encuentran en la parte izquierda hacen
referencia a los conceptos funcionales que se usan para construir sistemas y procesos. En la parte derecha,
estn los conceptos de informacin que se usan para pasar, describir o manipular datos en los diferentes
niveles funcionales. Aqu se puede ver como las organizaciones son una combinacin de procesos con
informacin ya que cada capa necesita de ambas abstracciones. Las conexiones entre las capas
representan las relaciones entre las funciones [18].
Ilustracin 3. Elementos arquitecturales de SOA [18]
De abajo hacia arriba las capas son [18]:
Recursos de la empresa y datos operacionales: Esta capa se compone de aplicaciones existentes,

legacy y sistemas COTS (aplicaciones comerciales fuera de la plataforma), incluyendo aplicaciones
CRM (Customer Relationship Management) y ERP (Enterprise Resource Planning) e
implementaciones antiguas orientadas a objetos. Estas aplicaciones proveen operaciones de
negocio: transacciones que representan unidades lgicas de trabajo en los sistemas de operacin de
la empresa. Estas operaciones al ser ejecutadas, por lo general, causaran uno o ms registros de
datos persistentes para ser ledos, escritos o modificados en un sistema de almacenamiento (SOR).
Servicios de integracin: Los servicios de integracin proveen este servicio entre las aplicaciones
existentes. Un aspecto muy importante es separar la capa de integracin de servicios con la de
servicios de negocio para estar en la capacidad de mantener un ambiente empresarial flexible.
Comnmente, esto involucra la transformacin de datos y funciones de lo que es deseado en el nivel
de servicios de negocio a lo que es posible en los sistemas existentes.
Servicios de negocio: Proveen servicios de negocio de alto nivel a la empresa. Esta capa se
relaciona con la anterior para romper la dependencia directa entre los procesos y los sistemas
existentes, as, en caso de que haya un cambio en alguna de las dos capas, solo tendr que ser
modificada la intermediaria. Los servicios son manejados bajo ciertos parmetros para asegurar que
se cumplan ciertos contratos respecto a las funciones que deben proveer. Estos contratos son
llamados: acuerdos a nivel de servicios (SLA). Para ilustrar mejor que es un SLA, podramos ver el
caso de una revisin de tems como servicio, cuyo grupo de funciones lgicas podran ser: Listar
todos los tems, Eliminar tem por cdigo de tem o guardar los cambios sobre la lista.
Procesos de negocio: Un proceso de negocio consiste en una serie de operaciones que son
ejecutadas en una secuencia ordenada acorde a un conjunto de reglas de negocio. A menudo, los
procesos de negocio son descritos en un modelo de procesos de negocio, cmo los realizados con la
notacin estndar BPMN (Business Process Modeling Notation) y ejecutados por un sistema de
gestin de procesos de negocio: BPMS. La secuencia, seleccin y ejecucin de las operaciones es
llamada Orquestacin. Los procesos de negocio proveen conjuntos de accin o actividades de larga
duracin. Estn compuestos por servicios de negocio y tpicamente hacen uso de mltiples
invocaciones a servicios. Ejemplo de algunos procesos de negocio podran ser: La contratacin de
profesores de ctedra de una universidad, el proceso de pago a proveedores internacionales, la
matrcula de estudiantes a un colegio o la creacin de rdenes de compra. Ms adelante se hablar
en detalle sobre el concepto de BPM por ser de especial relevancia para esta gua.
La siguiente figura muestra una perspectiva empresarial de cmo se implementa SOA, y el uso que hace del
bus de servicios (Ver seccin 2.4 de este documento, Bus de Servicios Empresariales ESB) para comunicar
el modelo de negocio con los servicios y componentes definidos a nivel lgico.
Ilustracin 4. Perspectiva empresarial de SOA [18]
Como parte de la determinacin del uso que se le dar a la arquitectura se debe observar el ambiente de
desarrollo, los frameworks, la infraestructura y las herramientas. No es suficiente con la descripcin de
cules son los servicios; la arquitectura debe permitir una fcil y eficiente creacin de esos servicios.
Inclusive, se debe especificar como la arquitectura encaja con el proceso de desarrollo y lo apoya en la
medida para agregar valor. Es importante que la arquitectura entienda los aspectos de los servicios que
deben ser consistentes a lo largo del rango de ambientes de desarrollo, y crear estndares, documentos
guas, ejemplos, frameworks, plug-ins o similares que apoyen esos ambientes y procesos de desarrollo [18].
Por ltimo, y no por ello menos importante, se deben consideran las mtricas y las medidas de xito. Una
arquitectura orientada a servicios solo es efectiva si esta apoya la consecucin de las metas de negocio por
las que fue creada. El proceso debe tener mtricas y mtodos para la recoleccin de medidas que permitan
demostrar cuan efectiva fue la implementacin de la SOA [18].
2.4. Bus de servicios empresariales (ESB)

Un bus de servicios empresariales (Enterprise Service Bus ESB) es un software que provee servicios
fundamentales para arquitecturas complejas. En el caso de SOA, un ESB provee muchas de las
caractersticas para su implementacin. Se podra definir un ESB como aquel mecanismo que gestiona el
acceso a aplicaciones y servicios (incluidos los sistemas legacys) para proveer una interface nica, simple y
consistente a los usuarios finales [21].
Ilustracin 5. Arquitectura del bus de servicios empresariales
Entre los propsitos ms relevantes de un ESB se encuentran: ocultar la complejidad que implica la
comunicacin entre servicios heterogneos, simplificar el acceso a servicios y aplicaciones, hacer que la
complejidad y las comunicaciones sean transparentes para el usuario. La clave del xito de un ESB radica en
cuan hbil es para soportar un servicio incremental y la integracin de las aplicaciones, no pensado desde el
punto de vista de la tecnologa disponible, sino de los requerimientos del negocio [21]. De acuerdo con uno
de los proveedores de esta herramienta, IBM, un ESB no es un nuevo producto de software, es una nueva
forma de observar cmo se integran las aplicaciones, se coordinan recursos y se manipula la informacin
[21].
La arquitectura de un bus de servicios que soporta una arquitectura orientada a servicios, contiene [24]:
Aprovechamiento de las aplicaciones legacy. Son tcnicamente elementos muy antiguos de
almacenamiento o procesamiento de informacin que son de misin crtica para la organizacin,
pero que son muy susceptibles a la hora de ser modificados y demasiado importantes para ser
descartados y por lo tanto deben ser reutilizados. Estratgicamente, el objetivo es construir una
nueva arquitectura que dar todo el valor esperado, pero tcticamente, los activos de legado deben
ser aprovechados e integrados con las nuevas tecnologas y aplicaciones.
Capacidad de comunicacin de servicios. Esta es una de las capacidades crticas de un ESB, la cual
busca la interaccin entre servicios a travs de una variedad de protocolos y la transformacin a
partir de un protocolo a otro cuando sea necesario. Otro aspecto importante de una implementacin
de ESB es la capacidad de soportar los modelos de servicio de mensajera compatible con las
interfaces de la arquitectura orientada a servicios (SOA), as como la capacidad de brindar:
seguridad, transacciones o informacin de correlacin entre los mensajes.
Capacidad de integracin. Para apoyar una arquitectura orientada a servicios en un entorno

heterogneo, el ESB debe integrarse con una variedad de sistemas que no soportan directamente el
estilo de servicio de interacciones. Esto puede incluir sistemas de legacy, aplicaciones
empaquetadas, COTS, etc.
Capacidad de transformacin. Los distintos componentes conectados a un bus de servicios esperan

que sus entradas se presenten en ciertos formatos, y estos pueden ser diferentes a los presentados
en las salidas de otros servicios que le envan mensajes. Una de las caractersticas de mayor valor
en un ESB es que encapsula los detalles de implementacin de todos los componentes, logrando
que cualquier otro de ellos no conozca estos detalles sobre otro componente. Los servicios de
transformacin permiten asegurar que los mensajes y datos recibidos por cualquiera de los
componentes est en el formato que espera recibirlos, eliminando as la carga de que este se
encargar de realizar su propia transformacin. El ESB est en capacidad de transformar mensajes
en diferentes formatos: XML, de Objetos, entre otros.
Capacidades de seguridad. El manejo de la seguridad es uno de los factores claves a la hora de

implementar un ESB. Un ESB debe permitir tanto proveer un modelo de seguridad para los
consumidores de los servicios, como integrarse con los distintos modelos de seguridad de
proveedores de este servicio. En general, se busca que la seguridad tenga aspectos de:
autenticacin, validacin y encriptacin/des-encriptacin.
Capacidades de gestin y monitoreo. En un ambiente SOA, las aplicaciones y los servicios usados
pueden cambiar a lo largo del tiempo. Administrar esos cambios es un gran reto, en especial cuando
se deben garantizar ciertos requerimientos, por ejemplo, de disponibilidad del sistema. Por esta
razn, es importante que un ESB sea capaz de localizar servicios de forma dinmica y se comporte
de acuerdo a las necesidades estipuladas.
3. Instalacin de herramientas
3.1. Eclipse
Dirjase al siguiente enlace: http://www.eclipse.org/ganymede/ y descargue la versin llamada Eclipse IDE
for Java Developers. Luego, comience la instalacin en su mquina y si no desea realizar ninguna
configuracin especial, puede aceptar la que viene por defecto.
3.2. Plugins
Esta seccin se toma totalmente de la gua elaborada por la Ingeniera Mara Consuelo Franky, titulada
Instalacin y configuracin de las herramientas para Java EE 5. Curso: Desarrollo de aplicaciones en Java
EE 5 en base a framework. Presentacin: 1-guia-configuracion-javaee5.pdf, encontrada en:
http://orion.javeriana.edu.co/gf/project/javeviajes/docman/?subdir=7
El conjunto de plugins JBoss Tools All para Eclipse ofrece facilidades adicionales para el desarrollo de
aplicaciones Java EE 5, agregando las perspectivas de Web Development y Seam con vistas (windows)
especializadas en:
Explorador de proyectos JSF (vista Web Projects)
Paleta para disear pginas JSF (vista JBoss Tools Palette con elementos HTML, Facelets, jax4jsf,
RichFaces, Seam; se puede extender con otros elementos como ADF, ICEfaces, etc.)
Herramientas Hibernate que permiten ejecutar consultas JPQL (vistas Hibernate Configurations,
Query Parameters, Hibernate Query Result, Hibernate Dynamic SQL Preview)
Asociar proyectos a servidores registrados en Eclipse (vista JBoss Server View)
Diseo de procesos de negocio jBPM (vista Overview, editor jBPM Graphical Process Designer)
Lista de componentes Seam de un proyecto, indicando el contexto de cada componente (vista Seam
Components, solo funciona para proyectos generados con el asistente Seam Web Project)
Antes de instalar este conjunto de plugins debe cerrarse Eclipse y agregar al principio del archivo
eclipse.ini (bajo el directorio de instalacin de Eclipse) la opcin -clean Con esta opcin Eclipse
refrescar sus plugins instalados cada vez que se inicie.
Para la instalacin descomprimir el archivo: JBossTools-ALL-win32-3.0.2.v200909151014R-H192-GA.zip

en el directorio raz de la instalacin de Eclipse. El archivo lo puede encontrar en el siguiente link:
http://es.sourceforge.jp/projects/sfnet_jboss/downloads/JBossTools/JBossTools3.0.x/JBossTools-ALL-win32-
3.0.2.v200909151014R-H192-GA.zip/
Luego se puede invocar Eclipse y abrir las perspectivas agregadas (Web Development y Seam)
3.3. JBoss AS
Descargue el Application Server de la direccin: http://www.jboss.org/jbossas/downloads/ y ubquelo en una
carpeta fcil de recordar para usted. Luego, en Eclipse y abriendo la pestaa del plugin JBoss AS instalado,
registre el servidor.
Esta accin se realiza dando click derecho, seleccionando la opcin para agregar un nuevo servidor, y dentro
de este slo deber proveer un nombre y la direccin donde se encuentra la carpeta descargada. Luego,
podr correr el servidor normalmente.
3.4. JBoss ESB

Luego de tener instalado JBoss Application Server, deber descargar JBoss ESB 4.9 en la siguiente
direccin: http://www.jboss.org/jbossesb/downloads.
Cuando haya descargado la carpeta, regstrela en el IDE Eclipse. Ingrese a jbossesb-

4.9/install/deployment.properties.example y borre la extensin .example de tal forma que ste descriptor
tenga extensin .properties. Luego, bralo y edite las siguientes propiedades de tal forma que quede como
se indica a continuacin:
# application server root directory

org.jboss.esb.server.home=/jboss-4.2.3.GA
# the instance of jboss you are running(default)
org.jboss.esb.server.config=default
Tenga en cuenta que la seccin resaltada en rojo deber tener la direccin de la carpeta de su computador
donde se encuentra el JBoss AS.
Luego registre el buildfile y ejecute la tarea ant deploy. Esto instalara todo lo necesario dentro de JBoss AS
para que en todas las ocasiones que inicie este servidor, se disponga para usted las herramientas brindadas
por el Bus de servicios de JBoss.
4. Modelacin de procesos en BPMN
4.1. Introduccin
A medida que las empresas se desarrollan, sus procesos de negocio se van haciendo ms complejos y el
mercado comienza a exigir que sean ms organizadas en cuanto a la integracin de los procedimientos que
manejan y a la efectividad con la que apoyan la consecucin de metas planteadas. Cuanto ms exigencias
tenga una empresa y mayor maduracin tenga, sus procesos sern repetibles y escalables, organizados de
tal forma que se puedan re-configurar y brindar flexibilidad en la operacin de la compaa [19].
Uno de los pilares de la gestin y direccin de las empresas consiste en tener claros estos procesos que
permiten la supervivencia en el mercado. Si se comprende con detalle estos procesos, ser factible
evaluarlos y mejorarlos. En otras palabras, se podr organizar el trabajo de mejor manera y considerar las
siguientes preguntas para mejorar la productividad [19]:
Cules pasos son realmente necesarios?

Quin debera realizarlos?
Deben quedarse en la empresa o en el subcontratado?
Cmo deben ser realizados?
Qu funcionalidades se necesitan?
Qu resultados se esperan y como sern monitoreados?
Para facilitar el proceso de dar respuesta a estas preguntas, se toma la decisin de modelar los procesos,
preferiblemente bajo un estndar que facilite la comunicacin entre entidades o personas y el entendimiento
por cada una de ellas sobre las actividades que se deben seguir dentro del proceso. Generalmente, estos
modelos guiarn el trabajo y la forma en que se organizan los recursos para alcanzar los objetivos. Para ver
como se ilustra el flujo de trabajo se puede ver la imagen a continuacin [19].
Ilustracin 6. Ejemplo de proceso en BPMN [19]
En la ilustracin anterior, se pueden ver actividades que dan inicio al proceso (crculo verde) o que indican la
finalizacin del mismo (crculo rojo). Adems, se tienen actividades realizadas por humanos (las cuales estn
indicadas con el smbolo de una persona en la parte superior derecha) y actividades realizadas
automticamente (las cuales estn indicadas con el smbolo de un pio en la parte superior derecha).
Finalmente, el rombo indica las decisiones que deben ser tomadas por cierto actor o de forma automtica por
un servicio o sistema. Las convenciones completas sern explicadas en la seccin 5.3
En la industria, el estndar utilizado para la modelacin de procesos es BPMN, el cual provee una serie de
herramientas conceptuales para expresar los procesos de negocio en un lenguaje intuitivo, el cual puede ser
interpretado luego en un lenguaje de ejecucin, como BPEL, el cual es un estndar para componer servicios
asncronos y sncronos en un flujo colaborativo de proceso [25]. Adems es una notacin usada para disear
todos los procesos organizacionales uniformemente, para que de esta forma se pueda comunicar fcilmente
cada proceso con otras personas tanto dentro como fuera de la organizacin [16].
Otra de las razones por la cual BPMN es ampliamente utilizado como estndar, es que adems de facilitar la
comunicacin entre los analistas del dominio, les permite apoyarse para tomar decisiones basadas en
tcnicas como anlisis de costo, anlisis de escenario y simulacin. Sin embargo, los modelos BPMN
tambin son usados como la base para especificar los requerimientos de software y en tales casos, son
entregados a los desarrolladores de software encargados de la elaboracin del sistema [17].
4.2. Demo
A continuacin se mostrar la modelacin BPMN que se realiz de los dos procesos de la direccin de
gestin humana de la Pontificia Universidad Javeriana: seleccin y contratacin de profesores de ctedra. De
estos casos se tomar un subconjunto para implantarlo como demo con el fin de ilustrar el uso de
herramientas SOA.
Se explicaran los componentes de dichos diagramas, sin embargo, para ver ms detalles sobre la notacin
usada y cmo podra usted elaborar sus propios modelos de procesos, por favor dirjase a la seccin 5.3 de
este documento. Tenga en cuenta que la descripcin de la notacin y la realizacin de estos modelos fue
hecha a partir del uso del modelador de procesos de negocio de Bizagi: http://www.bizagi.com/.
Antes de realizar cualquier modelo, debe partir de la premisa bajo la cual debe identificar que entidades
intervienen en el proceso de negocio. Entienda por entidades aquella agrupacin de individuos o
instituciones homogneos pero que entre el grupo de entidades es heterognea respecto a los dems.
Tambin tenga en cuenta que bien puede usted dividir a todos los involucrados en el proceso como
entidades diferentes, dependiendo del grado de complejidad y tipo de tareas que deba realizar cada uno.
Luego de identificar las entidades, debe resaltar los individuos o departamentos que dentro de ellas actan
para llevar a cabo las actividades del proceso de negocio. Cada uno de estos individuos o departamentos
tendr una lnea dentro del pool llamada lane. De esta forma, usted tendr tantos pools como entidades
haya identificado, y dentro de cada uno de los pool tendr tantos lanes como individuos o departamentos
pertenecientes a cada entidad haya determinado.
Finalmente, debe conocer que actividades realiza cada individuo dentro del contexto de su entidad y de qu
tipo es esa actividad: si es manual o automtica, y dentro de estos dos tipos podr encontrar ciertas
variaciones como envi de correos, solicitud de servicios, tiempos de espera, etc.
La modelacin en Bizagi es sencilla de realizar, simplemente debe seleccionar el elemento que desea
insertar en el men de la derecha y arrstralo hasta la hoja en blanco. A partir de esta accin puede realizar
cualquier diagrama. Adems, provee de cierta flexibilidad que dando click derecho sobre cada componente
insertado, le permitir indicar ms exactamente el tipo de componente, es decir, a travs de esta accin
puede ilustrar si una actividad es el envo de un correo electrnico, la recepcin de un correo, una tarea
humana o una actividad automtica.
Nota: Dado que el alcance de esta gua no pretende ahondar mucho en la modelacin de procesos en
BPMN, le recomendamos que para ms detalles consulte la gua oficial provista por la OMG (Object
Management Group) o ingrese a la documentacin provista en la pgina de Bizagi: http://www.bizagi.com/.
4.2.1. Proceso de seleccin

El proceso de seleccin de profesores de ctedra en la Pontificia Universidad Javeriana se realiza siempre
que un director de departamento o un instituto soliciten la contratacin de una persona para uno de estos
cargos. En ste participan cuatro entidades representadas en cuatro diferentes pools: La facultad, la oficina
de relaciones laborales, la vicerrectora acadmica y los candidatos. En la imagen del proceso mostrada en
la ilustracin 6 (que puede detallar mejor, junto con las abreviaciones correspondientes, en la imagen
adjunta a este documento llamada: GRH BPMN modelo seleccin), cada pool se muestra con colores
diferentes. Encontrar en el pool de la facultad, en el lane del director de departamento o instituto el smbolo
de comienzo del proceso representado a travs de un crculo verde.
Finalizado todo el proceso de negocio, en el caso de que un candidato haya rechazado la propuesta, podr
ver que en el pool de la oficina de relaciones laborales, en el lane del asistente de nmina se dar
terminacin a la oferta laboral y se acabar la instancia del proceso, que se simboliza con un crculo rojo. Si
por el contrario, un candidato decidi aceptar la oferta realizada, se dar paso al proceso de contratacin y
posterior a este se darn por finalizados los procesos de seleccin y contratacin del profesor de ctedra.
Del modelo, tambin es importante destacar el envo y recepcin de correos electrnicos, los cuales se
identifican porque en la parte derecha superior de cada actividad hay una figura con forma de carta y tienen
una flecha con direccin izquierda derecha si es de envo, mientras que las actividades de recepcin de
correos tienen la misma identificacin de la figura pero la flecha esta con direccin derecha izquierda.
Para ver el detalle del proceso de seleccin de profesores de ctedra de la Pontificia Universidad Javeriana,
puede dirigirse a la primera seccin de este documento, donde se explica detalladamente el flujo y podr
comparar sus caractersticas respecto al siguiente diagrama en notacin BPMN.
Ilustracin 7. Proceso de seleccin de profesores de ctedra de la Pontificia Universidad Javeriana
Tambin encontrar actividades de decisin, representadas por un rombo amarrillo. En ellas las decisiones
se toman de acuerdo a ciertas reglas y dependiendo de su respuesta tomarn un rumbo u otro. En el
modelo, podr ver que cada camino ser tomado si la respuesta a esa pregunta coincide con el nombre que
se le dio a la relacin que lleva a la siguiente actividad.
4.2.2. Proceso de contratacin

El proceso de contratacin de un profesor de ctedra se realiza inmediatamente despus de que termina el
proceso de seleccin. En ste participan tres entidades representadas en tres diferentes pools: La oficina de
operaciones, la facultad que solicito el profesor y el o los candidatos elegidos. En la imagen del proceso
mostrado en la ilustracin 7 (que puede detallar mejor, junto con las abreviaciones correspondientes, en la
imagen adjunta a este documento llamada: GRH BPMN modelo contratacin), el pool de la oficina de
operaciones se representa en el degradado de azul oscuro. En ellos encontrara los puntos de inicio del
proceso y de finalizacin, representados con un crculo verde y rojo respectivamente.
Para ver el detalle del proceso de contratacin de profesores de ctedra de la Pontificia Universidad
Javeriana, puede dirigirse a la primera seccin de este documento, donde se explica detalladamente el flujo y
podr comparar sus caractersticas respecto al siguiente diagrama en notacin BPMN.
Ilustracin 8. Proceso de contratacin de profesores de ctedra de la Pontificia Universidad Javeriana
Adems, ver que dentro del proceso hay dos actividades que deben ser realizados por personas
representados con el smbolo de un humano. Y encontrar cinco actividades ms que deben ser realizadas
por el sistema bien sea automticamente o con el llamado a ciertos servicios de negocio pertenecientes a la
misma oficina de operaciones.
En el pool de la facultad y en su lane de secretario de la facultad, ver que esta persona solo enva un correo
electrnico. Luego en el pool de los candidatos, en el lane de candidato se hace la firma del contrato y
finalmente se archivan los documentos generados, actividad bajo la responsabilidad del auxiliar de archivo
cuyo lane est ubicado en el pool de la oficina de operaciones.
5. Modelacin de procesos en jBPM
5.1. Introduccin
En la actualidad, las compaas necesitan crecer de manera rpida para permanecer en el mercado que cada
vez es ms competitivo; la mayora de estas compaas comprenden el problema y optan por disear
procesos de negocio, sin embargo, no estn organizados ni mucho menos automatizados, la razn es que
implementar soluciones para automatizar los procesos resulta costoso. Actualmente las empresas invierten
entre $500.000 - $1000.000 de dlares para esta tarea [2], pero lo que muchas de ellas desconocen es que
existen herramientas libres para implementar tales soluciones, una gran alternativa para que las empresas
sean competitivas en el mercado a un precio favorable.
Jboss jBPM es una de estas herramientas libres la cual permite modelar procesos de negocio. Una de sus
mayores ventajas es que establece un puente entre los analistas de negocio y los desarrolladores [1]. Esta
gua presenta varias caractersticas sobre jBPM versin: 3.X, entre ellas: la forma de modelar los procesos de
negocio, el uso de anotaciones para conducir el proceso de negocio y un demo.
Existen en el mercado varios editores libres para BPM. Sin embargo, vale la pena destacar que gracias a que
se cuenta con la suite SOA de JBoss para implementar los procesos de negocio modelados, se puede hacer el
paso del diagrama jBPM a su desarrollo. Lo anterior, se hace sin costos de licencia lo que facilita su
adquisicin y ajuste a presupuesto de las Pymes en ste caso. Gracias a esa situacin y a la curva de
aprendizaje elevada para la utilizacin de esta herramienta, se decidi realizar esta gua.
5.2. Qu permite modelar el editor grfico de
jBPM?
5.2.1. Descripcin general
Una definicin de proceso jBPM representa la especificacin formal de un proceso de negocio y est basada
en un grafo dirigido. El grafo est compuesto de nodos y transiciones. Cada nodo del grafo tiene un tipo
especfico. El tipo del nodo define el comportamiento en tiempo de ejecucin. Una definicin de proceso tiene
exactamente un estado inicial. [3]
Ilustracin 9. Ejemplo inicial de un modelo desarrollado con jBPM
Un Token indica en que nodo del grafo se encuentra la ejecucin. A medida que la ejecucin avanza, el token
va de nodo en nodo segn sea la instruccin dada. [3]
Una instancia de proceso es una ejecucin de una definicin de proceso jBPM. Cuando una instancia de
proceso es creada, un Token es creado para el camino principal de la ejecucin. Este Token es llamado el
Token Raz de la instancia de proceso y es posicionado en el estado inicial de la definicin de proceso. [3]
Una seal hace que el Token contine en la ejecucin del grafo. Cuando el Token recibe una seal sin nombre,
ste dejar su nodo actual y saldr hacia la transicin por defecto. Sin embargo, si en la especificacin de la
seal viene un nombre de transicin definido, el Token dejar el nodo actual y saldr por la transicin definida.
[3]
Tan pronto un Token entra a un nodo, ste ser ejecutado. Los nodos en s mismos son responsables por la
continuidad de la ejecucin del grafo y de su comportamiento depender los caminos que siga el Token de ese
punto en adelante. Un nodo que espera una seal para continuar con la ejecucin ser llamado un nodo
estado. [3]
El grfico representa la secuencia del proceso de negocio y cmo se comporta desde una vista gerencial. Sin
embargo, oculta muchos detalles tcnicos que ms adelante sern modelados por las acciones en cdigo
Java. [3]
5.2.2. Nodos
Un nodo tiene un tipo especfico. El tipo determina qu pasar cuando la ejecucin llegue a este nodo en el
tiempo de ejecucin. En jBPM existen ciertos tipos de nodos pre-implementados que pueden ser usados, o
bien, se podran crean nuevos tipos de nodos escribiendo el cdigo correspondiente para implementar un
comportamiento especfico [3].
El propsito de este documento solo es presentar un resumen, si desea conocer ms informacin al respecto
consulte el Manual [6].
A. Responsabilidad de los Nodos

Cada nodo tiene dos responsabilidades principales:
Primero, pueden ejecutar cdigo Java plano, es decir la funcin que deben realizar dentro del proceso.
Por ejemplo, actualizar una base datos, enviar un email, etc.
Segundo, un nodo es responsable por la propagacin (continuidad) de la ejecucin del proceso. Un

nodo podr: No propagar la ejecucin; Propagar la ejecucin por una de las transiciones; Propagar la
ejecucin por varios caminos (fork), creando varios tokens; Finalizar la ejecucin del camino. [3]
Muchas de las herramientas de flujos de trabajo y sistemas BPM son propietarias. En este sentido, jBPM
representa una ventaja ya que a travs del lenguaje JPDL (jBPM Process Definition Language) [4], se le otorga
el don a los desarrolladores de crear modelos ms complejos y poderosos. A continuacin, se discutirn los
tipos de nodos ms importantes de JPDL.
Se podra decir que JPDL es a jBPM, lo que BPEL es a BPMN. JPDL permite darle vida al modelamiento
realizado en jBPM, dando paso a la ejecucin de los nodos propuestos. Es un esquema XML en el cual se
relaciona el modelo con las clases o direcciones de servicios que deber ejecutar cuando se encuentre en un
nodo determinado.
B. Tipo de Nodo: Tarea

Un nodo de tarea representa una o ms tareas que son realizadas por humanos. As
que cuando la ejecucin llega a un nodo de Tarea, se esperar hasta que el usuario
realice su tarea cuya finalizacin crear la seal que dar continuidad al token hacia
los nodos siguientes. El tiempo que tardan los usuarios desde que llega la ejecucin al nodo hasta que
completan sus tareas, se llama estado de espera. [3]
C. Tipo de Nodo: Estado
Es un nodo de espera en el cual no se ejecuta ninguna tarea. Su principal uso es

cuando se espera la seal de otro sistema para continuar con la ejecucin. [3]
D. Tipo de Nodo: Decisin

Existen dos formas de modelar una decisin. La diferencia radica en Quin est
tomando la decisin. La decisin deber ser tomada por el proceso, segn la
definicin de proceso?, o La decisin depender de una entidad externa?
a. Un nodo de decisin debe ser usado si es el propio proceso el responsable de tomar la decisin. Hay
dos formas para especificar el criterio de decisin. Una es aadiendo condiciones a las transiciones
mediante scripts, los cuales pueden estar en XML o beanshell script. Los nodos recorrern estas
transiciones, hasta que encuentren una que satisfaga las condiciones. La primera que retorne true,
marcar el camino a seguir.
b. Cuando la decisin no depende del proceso, sino de una entidad externa, la solucin ideal es ubicar
un nodo de estado con varias transiciones de salida. Cuando llegue la seal, sta deber indicar cul
es el camino a tomar. [3]
E. Tipo de Nodo: Fork

Un fork divide un camino de ejecucin en mltiples caminos de
ejecucin concurrente. El comportamiento por defecto del Fork,
crea un token hijo para cada transicin que se desprende de
este nodo. De esta forma se crea una relacin de padre - hijo. [3]
F. Tipo de Nodo: Join

Un Join por defecto asume que todos los tokens que llegan a l,
son hijos de un mismo padre. Esta situacin se presenta cuando
con anterioridad se us un nodo fork y se pretende que la
ejecucin concurrente de los tokens hijos creados llegue a un solo punto. Luego de que todos lleguen a este
punto, se seguir por una nica transicin.
Cuando uno o ms tokens hijos no han llegado, el nodo se comportar como un nodo de estado a la espera de
ellos. [3]
G. Tipo de Nodo: Nodo

Este nodo permite escribir el propio cdigo a travs de una accin. ste nodo, al
igual que los anteriores, ser representado en el grafo pero no s darn detalles
tcnicos ya que la implementacin lgica no es relevante para el analista de
negocio. [3]
Si se desea invocar un Web-Service, este nodo permitir realizar esta accin. El siguiente ejemplo puede
aclarar esta implementacin [7]:
Se puede observar como los

Nodo tipo <<Node>> son
invocaciones a Web-Services
que posiblemente residan en un
Bus de Servicios, mientras que
los nodo tipo <<Task Node>>
son acciones de revisin por
parte de los usuarios
interesados.
H. Tipo de Nodo: Start-State
Este nodo es el primero en un proceso. Al ser el primero debe cumplir que a l no
llega ninguna transicin y solo podr haber un Start-State por proceso. Otra
caracterstica importante es que ste nodo no se ejecuta. Solo sirve para indicar que
un proceso se ha creado y an no comienza su ejecucin. Un proceso sin nodo Start es vlido, pero no puede
ser ejecutado. [4][5]
I. Tipo de Nodo: End-State
Una definicin de proceso tiene solo un nodo de este tipo. La instancia de proceso
es finalizada cuando la ejecucin llega a este punto. [9]
J. Tipo de Nodo: Mail-Node

Este nodo se encarga precisamente de enviar un email, segn la configuracin dada.
Se tiene un gran nmero de configuraciones que van desde el mensaje en s mismo
hasta el servidor como un todo. En el caso del nodo y en cdigo JPDL, un email
podra ser enviado de la siguiente forma [8]:
<mail-node name="send email" to="#{universidad}" subject="investigacin" text="Se

ha cumplido el objetivo">
<transition to="the next node" />
</mail-node>
Se hablar sobre la forma de implementar este nodo en en el captulo dedicado al uso de la Consola de JBoss.
K. Tipo de Nodo: ESB-Service

Cuando se invoca un nodo de este tipo, se conoce como Orquestacin de Servicios.
De esta forma se pueden invocar servicios ESB registrados en el bus JBoss ESB y
embebidos en algunas acciones especiales dentro de la definicin del proceso. Hay
tres tipos de comunicacin en este sentido:
Llamado de una va, cuando se desea enviar informacin del proceso jBPM al bus ESB, generalmente
se hace dentro de las transiciones;
Comunicacin de dos vas, realizado en un nodo aparte, sirve para enviar peticiones y recibir
informacin;
Comunicacin de dos vas con tiempo de espera, se establece un tiempo lmite de espera de las
respuestas [10].
Los servicios ESB se explicarn ms adelante en el captulo dedicado al uso de la Consola de JBoss.
5.2.3. Transiciones
Las transiciones tienen un nodo fuente y un nodo destino. El nodo fuente es representado con la propiedad
FROM y el nodo destino es representado con la propiedad TO.
Una transicin puede tener un nombre, el cual ser especificado en sus propiedades. Es importante que esta
propiedad sea nica. Adicionalmente, cada nodo conocer la lista de transiciones con las que se relaciona, en
caso de que la programacin as lo requiera, la transicin por defecto ser la primera en la lista de un nodo
fuente. [3]
Nota: Si desea ver ms ejemplos o aclarar alguna particular puede dirigirse al documento: Caractersticas y
posibilidades con jBPM 3.X [11]
5.3. Adaptacin a partir de un modelo BPMN
En la seccin anterior se mostr como se trabajaba con jBPM a la hora de modelar ciertas actividades
necesarias dentro de un proceso. De la misma manera, BPMN tiene sus propias siglas descritas a
continuacin y como stas se pueden traducir a jBPM.
Elemento jBPM BPMN
Tarea
Desempeada por humanos, ser

asignada a una persona cuando el
proceso sea ejecutado, la instancia
del proceso esperara a que la tarea
Representan el trabajo realizado dentro de una
sea completada por la persona
organizacin. Consumen recursos. Pueden ser simples
encargada.
o compuestas. Se divide en los tipos que se muestran
en la imagen anterior. El tipo de tarea similar a la tarea
de jBPM es la denominada Usuario.
Las ms importantes en nuestro ejemplo, son las tareas

Es un tipo de nodo especial. de usuario, que son las realizadas por un humano. Las
Permite al desarrollador escribir un tareas de servicio, que son realizadas automticamente
nodo definido por l. Tpicamente bien sean por un servicio interno o externo. Y
es usado cuando el desarrollador finalmente, las tareas de envo o recepcin que tienen
necesita escribir cdigo para hacer que ver con el correo electrnico.
que el sistema desempee alguna
accin.
Decisin
Se utiliza cuando la decisin que se Compuerta Exclusiva basada en eventos.

toma es basada en datos y no por
el usuario, si no por el proceso en s Divergencia: Ocurre cuando en un punto del flujo
mismo. basado en los datos del proceso se escoge un solo
camino de varios disponibles.
Convergencia: Es utilizada para confluir caminos

excluyentes.
Las compuertas son utilizadas para controlar la

divergencia y convergencia del flujo.
Inicio Eventos de inicio: Indican cuando un proceso inicia,

no tienen flujos de secuencia entrantes.
Solo sirve para indicar que un

proceso se ha creado y an no Evento de inicio sin especificar: No se especifica
comienza su ejecucin. ningn comportamiento en particular para iniciar el
proceso.
Evento de inicio de Mensaje: Un proceso inicia

cuando un mensaje es recibido.
Evento de Inicio de Temporizacin: Indica que un

proceso inicia cada ciclo de tiempo o en una fecha
especfica.
Evento de Inicio de Condicin: Un proceso inicia

cuando una condicin de negocio se cumple.
Evento de Inicio de Seal: El proceso inicia cuando se

captura una seal lanzada desde otro proceso. Tenga
en cuenta que una seal no es un mensaje, un mensaje
tiene claramente definido un destinatario, la seal no.
Evento de Inicio Mltiple: Indica que existen muchas

formas de iniciar el proceso y que al cumplirse una de
ellas iniciar el proceso.
Fin
Evento de Fin sin especificar: Indica que un camino

Una definicin de proceso tiene
del flujo llego al fin.
solo un nodo de este tipo. La
instancia de proceso es finalizada
cuando la ejecucin llega a este
punto. Evento de Fin de Mensaje: Permite enviar un mensaje
al finalizar el flujo.
Evento de Fin de Seal: Permite enviar una seal al

finalizar el flujo.
Evento de Fin Mltiple: Indica que varios resultados

pueden darse al finalizar un flujo.
Evento de Fin de Cancelacin: Permite enviar una

excepcin de la cancelacin al finalizar el flujo. Solo se
utiliza en subprocesos transaccionales.
Evento de Fin de Error: Permite enviar una excepcin
de error al finalizar el flujo.
Evento de Fin de Compensacin: Este tipo de fin

indica que es necesaria una compensacin al finalizar
el flujo.
Fork/Join
Compuerta Paralela:
Divergencia: Se utiliza cuando varias actividades
pueden realizarse concurrentemente o en paralelo,
Representa actividades que se corresponde a Fork en jBPM.
pueden realizar en paralelo. Un Convergencia: Permite sincronizar varios caminos
Fork divide el camino de ejecucin, paralelos en uno solo. El flujo contina cuando todos
para luego ser unidos por un Join. los flujos de secuencia de entrada hayan llegado a la
figura, corresponde a Join en jBPM.
Transiciones
Secuencia: representan el control de flujo y secuencia
de los objetos del flujo (actividades, compuertas,
eventos).
Especifica la ruta entre nodos.

Pueden tener nombre en el grafo.
--------------------------------------------------------------------
Mensaje: representan la interaccin entre varios

procesos. No representan flujos de control, representan
seales o mensajes.
---------------------------------------------------------------------
Asociaciones: Se usan para asociar informacin

adicional del proceso.
Subprocesos
Es usado cuando se necesitan Subproceso: Actividad compuesta que incluye un

modelar subprocesos a un alto nivel conjunto interno lgico de actividades y que puede ser
que se requieren dentro del proceso. analizado en ms detalle.
Nos permite romper un modelo muy
complejo en varios ms manejables.
Subproceso embebido: Depende del proceso padre.
No contiene ni pools ni lanes.
Subproceso reusable: Es un proceso definido como
un diagrama de procesos independiente y que no
depende del proceso padre.
Canales / No se representan grficamente,

Swimlanes sin embargo, si se especifican en
XML. Se definen grupos o roles que Pool: Acta como contenedor de un proceso,
luego sern tiles para asignar las representa un Participante Entidad o Rol. Siempre
tareas a las personas. existe al menos uno, as no se diagrame.
Lane: Subdivisiones del Pool. Representan los

diferentes participantes al interior de una entidad.
Nota: La tabla anterior fue generada a partir de: [13] [14] [15].
5.4. Demo
Para la modelacin de procesos, se ha tomado como referente el proceso de seleccin y contratacin de
profesores de ctedra de la Pontificia Universidad Javeriana [12]. De esta forma, podr ver la transformacin
de cualquier diagrama hacia un esquema jBPM.
Para este ejemplo se han elaborado los diagramas correspondientes en notacin BPMN con el fin de que
tenga un referente de un estndar internacional, y luego se muestra como su notacin se transforma en un
diagrama jBPM.
Para crear un diagrama de jBPM, utilizando Eclipse con los plugins indicados en el captulo de instalacin,
debe iniciar un nuevo proyecto.
Ilustracin 10. Creacin de un nuevo proyecto
Asigne un nombre a su proyecto.
Ilustracin 11. Asignando nombre a un nuevo proyecto
D click derecho sobre el nombre del proyecto y cree un nuevo elemento Other.
Ilustracin 12. Creacin de un nuevo elemento
Ahora, busque el elemento Process Definition dentro de la carpeta JBoss jBPM.
Ilustracin 13. Creacin del elemento Process Definition
Finalmente, escriba el nombre que le dar a su proceso.
Ilustracin 14. Nombrando el proceso
Luego tendr acceso a todas las herramientas de modelacin que brinda jBPM. Ver que el proceso creado
corresponde a un archivo XML, y que como puede ver en la siguiente imagen, tiene 4 modos de edicin:
Diagram, Deployment, Design y Source.
En el modo de edicin Diagram, tiene acceso a todos los tipos de nodo, descritos en la seccin anterior, en el
men de la izquierda. Deber seleccionar uno y arrstralo para comenzar la modelacin de su proceso.
Igualmente, con la opcin llamada Transition podr agregar las relaciones entre los diferentes nodos que
haya puesto en el diagrama.
Ilustracin 15. Partes importantes para la realizacin de diagramas
Para observar mejor la modelacin de un proceso, lo ilustraremos con el caso de desarrollo escogido: El
proceso de seleccin y contratacin de profesores de ctedra de la Pontificia Universidad Javeriana.
Primero, si usted ya tiene sus diagramas en otra notacin, por ejemplo BPMN, ver que es sencillo modelar
el mismo proceso en jBPM. A continuacin se muestra una parte del proceso de seleccin de profesores de
ctedra (El proceso completo se encuentra en la imagen adjunta a este documento: GRH BPMN Modelo
Seleccin) modelado con la notacin BPMN. Ver que cada uno de los nodos tiene un tipo de nodo, bien sea
enviar un e-mail o realizar una tarea humana. Adems, a la izquierda puede ver que cada uno de esos nodos
tiene un responsable, en este caso el profesional de compensacin de la entidad: Oficina de relaciones
laborales.
En el siguiente ejemplo, ver cmo llega un mensaje o una seal al nodo llamado: revisin de la vacante
ORL_PC. En este punto el profesional de compensacin de la oficina de relaciones laborales (ORL_PC) har
una revisin de la vacante propuesta para profesor de ctedra de la Universidad. Luego, de realizar la
revisin, pasara a un nodo de decisin donde se preguntar si aprueba o no la propuesta de esa vacante. De
no hacerlo, enviara una notificacin va e-mail al Director de departamento o instituto (ORL_PC DDI). Si la
aprueba, y se requiere publicacin en medios publicitarios, ira a un servicio que realice esta actividad.
Finalmente, en este ejemplo, el flujo de actividades termina con la publicacin de la vacante en el sistema
interno de la Universidad.
Ilustracin 16. Demo en notacin BPMN
En las imgenes adjuntas no solo encontrara el proceso de seleccin, sino tambin el de contratacin (Ver
imagen adjunta a este documento: GRH BPMN Modelo Contratacin). Ahora, la imagen 15, que encuentra a
continuacin, corresponde a la misma seccin de proceso anterior pero con la imagen generada desde la
modelacin con jBPM.
Igual que BPMN y como se ilustro al inicio de la seccin de modelacin, jBPM provee un ambiente para crear
nodos de cualquier tipo, y en este caso equivalentes a los ya presentados con la notacin anterior. Los nodos
fueron creados arrastrndolos dentro del diagrama y las relaciones entre ellos, con la opcin Transition del
men lateral. Si desea ver y comparar los modelos generados con una y otra notacin, tambin se ha
adjuntado a este documento dos imgenes donde se us jBPM (Ver imgenes adjuntas a este documento:
GRH jBPM Modelo Contratacin y GRH jBPM Modelo Seleccin).
La explicacin correspondiente del diagrama, donde podr detallar cul es la funcin de cada nodo, la podr
encontrar en el archivo adjunto llamado: Documentacin modelo jBPM.
De esta forma, puede crear sus diagramas de proceso inicialmente desde jBPM, o puede crearlos a partir de
los diagramas con los que ya cuente dentro de su organizacin. Para facilitar la conversin, en este caso de
la notacin estndar internacional BPMN, hacia jBPM puede consultar la siguiente seccin. Luego, se
mostrar el archivo XML generado por el grfico y como se interpreta.
Ilustracin 17. Demo jBPM
5.4.1.Archivo XML generado
Ilustracin 18. Pestaas de navegacin en Eclipse
El archivo XML generado a partir del diagrama realizado en jBPM se puede visualizar haciendo click en la
pestaa llamada Source.
Las siguientes son las lneas escritas en lenguaje JPDL, encontradas en el archivo XML, a partir del modelo
realizado en jBPM con el caso de la seleccin de profesores de la Pontificia Universidad Javeriana (Ver
imagen adjunta a este documento: GRH jBPM Modelo Seleccin). Tenga en cuenta que ste archivo no tiene
tildes para evitar posibles problemas despus a la hora de ejecutar el diagrama.
En primera instancia, fjese en la seccin de cdigo resaltada en rojo. Es un nodo tipo start, lo puede
reconocer por el inicio y final de la etiqueta: start-state. Adems, encuentra que tiene una propiedad name.
Todos los nodos cuentan con esta propiedad que indica cual ser el nombre que identificara a este nodo (sin
embargo, para el caso de los fork y los join, el nombre no aparecer en el diagrama). Es importante, porque
adems de identificar el nodo en el diagrama, permite la creacin de las relaciones entre nodos.
Precisamente, el atributo transition to es el que indica hacia donde se dirigir la ejecucin luego de terminar
las tareas del nodo que contiene la propiedad. En el ejemplo, luego de que el nodo start-state llamado inicio
de la seal, la ejecucin pasar directamente al nodo llamado crear vacante DDI. (Recuerde que las siglas y
la explicacin de cada nodo la puede encontrar en el archivo adjunto a este documento, llamado:
Documentacin modelo jBPM).
Las transiciones y su direccionalidad se pueden ver representadas a travs de la propiedad to, la cual tiene
como valor el nombre del nodo al cual se deben dirigir.
Cuando se crea un modelo con el editor grfico podr editar los nombres de las transiciones. Si lo considera
importante para su entendimiento, puede poner nombre a todas las transiciones entre nodos. Sin embargo,
los casos ms relevantes para realizar esta accin es cuando se tiene nodos de decisin. Fjese en la
seccin que est en azul, en ella se aclara que dependiendo de la decisin, el nodo destino ser requiere
publicacin o notificacion encargado ORL_PC DDI. (Recuerde que las siglas y la explicacin de cada nodo
la puede encontrar en el archivo adjunto a este documento, llamado: Documentacin modelo jBPM).
A continuacin, se mostrar un segmento del cdigo JPDL que corresponde a la imagen del demo de jBPM.
Si desea ver el cdigo entero de ambos diagramas, podr ver los archivos adjuntos a esta gua titulados:
Seleccin XML y Contratacin XML.
Las etiquetas resaltadas en color verde muestran como cada tipo de nodo es traducido al lenguaje JPDL
con el cual se podrn hacer posteriores referencias a mtodos de clases o servicios del bus que permitan
desarrollar determinada funcionalidad. Por ejemplo, un nodo de tarea ser identificado con la etiqueta: task-
node; un nodo de decisin lo identificar con la etiqueta: decision; un nodo de correo electrnico lo
identificar con la etiqueta: mail-node.
El cdigo resaltado en color rojo muestra un ejemplo de cmo, al dibujar un nodo start en el diagrama,
automticamente se crea este cdigo para ilustrar el nodo de inicio y la primera transicin hacia donde se
dirige. En el cdigo resaltado en azul, se da el ejemplo de un nodo de decisin, el cual dentro de sus
transiciones incluye el atributo name, para que la persona que interpreta el diagrama pueda seguir la
secuencia de acciones cuando existe una decisin por tomar y dependiendo de su resultado la ejecucin
seguir por un camino u otro.
<?xmlversion="1.0"encoding="UTF8"?>
<processdefinitionxmlns=""name="Seleccioncatedra">
<startstatename="inicio">
<transitionto="crearvacanteDDI"></transition>
</startstate>
<tasknodename="crearvacanteDDI">
<transitionto="revisiondelavacanteORL_PC"></transition>
</tasknode>
<tasknodename="revisiondelavacanteORL_PC">
<transitionto="aprobaciondelavacante"></transition>
</tasknode>
<decisionname="aprobaciondelavacante">
<transitionto="requierepublicacion"name="si"></transition>
<transitionto="notificacionencargadoORL_PCDDI"name="no"></transition>
</decision>
<decisionname="requierepublicacion">
<transitionto="publicarvacanteexterno"name="si"></transition>
<transitionto="publicarvacantesistema"name="no"></transition>
</decision>
<mailnodename="notificacionencargadoORL_PCDDI">
<transitionto="eliminaciondevacante"></transition>
</mailnode>
<nodename="publicarvacanteexterno">
<transitionto="publicarvacantesistema"></transition>
</node>
<nodename="publicarvacantesistema">
<transitionto="elaboracionhojadevidaC"></transition>
</node>
<tasknodename="elaboracionhojadevidaC">
<transitionto="asociarcandidatoDDI"></transition>
</tasknode>
(...)
<endstatename="fin"></endstate>
</processdefinition>
Ilustracin 19. Estructura del cdigo jpdl generado por el grafo
Igualmente, en el caso del modelo para la contratacin de profesores de ctedra de la Pontificia Universidad
Javeriana (Ver imagen adjunta a este documento: GRH jBPM Modelo Contratacin), se gener un archivo
XML en lenguaje JPDL que encontrar en un documento adjunto a esta gua titulado: Contratacin XML.
Podr observar que en el caso del nodo de decisin tambin se modific el nombre de las transiciones.
Tenga en cuenta que los cambios realizados en ste archivo, se vern reflejados automticamente en la
pestaa Diagram. Ms adelante, veremos ms atributos que pueden ser agregados a la hora de programar
acciones determinadas que deben ser ejecutadas por cada nodo.
6. Implantacin del proceso de negocio
usando la consola de JBoss
6.1. Introduccin
La aplicacin web de la Consola de jBPM cumple con varios propsitos. En primer lugar, sirve como una
interfaz central de usuario para interactuar con las tareas en tiempo de ejecucin generadas por la ejecucin
de procesos. En segundo lugar, se trata de una consola de administracin y monitoreo que permite
inspeccionar y manipular instancias de ejecucin. La tercera funcin es BAM (Business Activity Monitoring)
Estas son las estadsticas sobre las ejecuciones del proceso. Esta informacin es til para los gerentes ya
que pueden encontrar cuellos de botella o generar otro tipo de optimizaciones [26].
Ilustracin 20. Vista general de los componentes de la consola [27]
El desarrollo para ejecucin en Consola brinda varios beneficios, entre los que se encuentra un desarrollo
ms rpido de la aplicacin debido a que no requiere de un trabajo intenso en el diseo grfico. La consola
ya provee un entorno en el cual solo se deben especificar los campos de los formularios necesarios para la
realizacin de las tareas humanas y, del modo que veremos, se vinculan los nodos del proceso a estos
formularios. Sin embargo, tenga en cuenta que esta consola es estndar, por lo cual si usted requiere de un
nivel de personalizacin mayor deber recurrir al desarrollo de una aplicacin.
Para acceder a la consola debe tener un servidor activo y luego, a travs de un navegador web, ingresar a la
direccin: http://localhost:8080/jbpm-console. En ella encontrar una pantalla de bienvenida, la cual tendr
una seccin para que se identifique con cualquiera de los usuarios y contraseas definidos, los cuales
debern tener diferentes permisos sobre el proceso en ejecucin. Para la asignacin de estos permisos y la
correspondiente creacin de usuarios y contraseas, remtase a la siguiente seccin donde se dar la
demostracin de cmo hacerlo.
6.2. Demo
6.2.1. Alcance
Dado que para mostrar la funcionalidad de la consola es innecesario desarrollar por completo los dos
procesos, se realizar el demo tomando como ejemplo solo una parte del proceso de seleccin de profesores
de ctedra. Se ilustraran los nodos ms importantes: nodo de inicio, nodo de finalizacin de proceso, correo
electrnico, tarea humana, nodo de decisin y llamado a un servicio del bus. Podr ver el alcance en la
siguiente imagen:
Ilustracin 21. Alcance del desarrollo del demo utilizando la Consola
6.2.2. Formularios
A. Complemento de cdigo en el nodo
Una de las funciones de la consola de jBPM permite enlazar formularios con nodos de tarea. A travs de
estos formularios usted podr mostrar o recopilar informacin necesaria para la continuidad de su proceso.
En el demo adjunto a este documento usted encontrara en la carpeta processDefinition los archivos de
extensin .xhtml (pginas web) que son enlazados a los nodos de tarea.
Se va a tomar como ejemplo el nodo de tarea llamado: crear vacante DDI. Fjese en el cdigo que se debe
agregar para realizar el enlace.
Con color azul ver las variables del formulario que debe llenar la persona. En este caso, la variable es
llamada tipo_vacante y el usuario que tenga acceso a esta tarea tendr los permisos de escritura (write) y
lectura (read). Adems se indica que antes de pasar a la siguiente etapa, el usuario deber ingresar este
valor obligatoriamente. Eso se indica con la palabra required.
Por otro lado, y muy importante para la seguridad, fjese en la seccin resaltada en color naranja. El valor
asignado a la variable llamada actor-id es la que corresponde al rol que podr tener permisos sobre esta
tarea. La forma de crear estos roles la ver ms adelante.
Tambin debe asegurarse de poner la etiqueta controller, resaltados en color rojo, dentro de los cuales
especificara las variables usadas en el formulario. Ahora, vista la forma de especificar en jpdl las variables
que se usarn, podr ver a continuacin la forma de realizar y enlazar el archivo xhtml que le dar soporte
grfico al cdigo realizado.
<task-node name="crear vacante DDI">

<task name="Crear vacante">
<assignment actor-id="DDI"></assignment>
<controller>
<variable name="tipo_vacante" access="read,write,required" />
<variable name="unidad_negocio" access="read,write,required" />
<variable name="familia_puesto" access="read,write,required" />
<variable name="posicion" access="write" />
<variable name="Cd_puesto" access="read,write,required" />
<variable name="titulo_oferta" access="read,write,required" />
<variable name="fecha_inicial" access="read,write,required" />
<variable name="fecha_final" access="read,write,required" />
<variable name="detalles" access="read,write,required" />
<variable name="publicacion" access="read,write,required" />
</controller>
</task>
<transition to="revision de la vacante ORL_PC"></transition>
</task-node>
Ilustracin 22. Cdigo en jPDL asociado al formulario de una tarea humana
B. Creacin de la forma
Para ver el cdigo completo de los formularios con extensin .xhtml ingrese a la carpeta del demo llamada
processDefinition. A continuacin slo vera secciones orientadas a guiar el entendimiento sobre la forma de
creacin de formularios. En este caso, se muestra el archivo llamado Vacante.xhtml el cual contiene la
orientacin grfica, por darle una definicin, sobre el formulario que aparecer en la consola.
Las etiquetas en color rojo delimitan la seccin del formulario, sin ellas, no ser entendible cules campos se
deber incluir en la consola. La etiqueta en color verde sirve para que en el titulo del formulario se muestre el
nombre de la tarea que se esta realizando en el momento.
La seccin de cdigo en color naranja es la forma en que se agrega una celda. Cada celda es un campo en
el formulario que contiene un nombre, el cual servir de gua a la persona que esta llenando los datos, y un
valor que corresponde a la asignacin que tiene esta variable. Si esta variable ya existe, aparecer el valor
establecido anteriormente, mientras que si no tiene valor alguno, se guardar esta informacin en el contexto
de ejecucin de la aplicacin. Tenga en cuenta que se esta guardando un vector de variables y por esta
razn se denomina var[nombre_de_la_variable]. El nombre que le de a la variable en un campo debe
corresponder al nombre que le dio en el cdigo del proceso escrito en jpdl.
La seccin en cdigo azul es otro ejemplo de celda de datos donde al contrario de usar un elemento tipo
inputText como en la seccin naranja, se uso un selectBooleanCheckBox para la necesidad que se requiera.
Podr encontrar una variedad de elementos como estos dentro de la plataforma UI. En este caso concreto, al
tener un elemento de tipo CheckBox, dentro de la variable quedaran almacenados dos valores: true o false.
True ser en caso de que se sea seleccionada la caja y false si sta se deja vaca. Es importante que tenga
en cuenta que tipo de retorno tienen los elementos escogidos.
Finalmente, la seccin morada indica los botones de accin que se tendrn disponible en el formulario. En
este caso, se puede usar los provistos por los componentes tf que principalmente ofrecen:
saveButton: Permitir guardar los datos de la tarea y regresar ms tarde a completarla, tomando en
cuenta la misma instancia de proceso.
cancelButton: Cancelar y eliminara todos los datos que hayan sido llenados. Finaliza el nodo de
tarea.
transitionButton: Da paso a la transicin, con una funcin de guardar ejecutada antes de pasar al
siguiente nodo, de tal forma que se siga con la secuencia natural modelada para el proceso.
<ui:component>
<jbpm:dataform>
<f:facet name="header">
<h:outputText value="#{taskName}"/>
</f:facet>
<jbpm:datacell>
<h:outputText value="Tipo de vacante:"/>
</f:facet>
<h:inputText value="#{var['tipo_vacante']}" />
</jbpm:datacell>
()
<jbpm:datacell>
<h:outputText value="Requiere publicacion:"/>
</f:facet>
<h:selectBooleanCheckbox name="pub" value="#{var['publicacion']}"/>
</jbpm:datacell>
<jbpm:datacell>
<h:outputText value="Acciones"/>
</f:facet>
<tf:saveButton value="Guardar"/>
<tf:cancelButton value="Cancelar"/>
<tf:transitionButton value="Crear vacante"/>
</jbpm:datacell>
</jbpm:dataform>
</ui:component>
Ilustracin 23. Cdigo xhtml del formulario de la tarea humana
C. Integracin del nodo con la forma
Luego de haber realizado las dos secciones anteriores, deber vincular los archivos para que efectivamente,
cuando se ejecute el proceso y se llegue al nodo de tarea estipulado, se llame el formulario indicado para
que el usuario pueda ingresar o consultar la informacin pertinente y se logr la operacin deseada. Para
vincular el formulario con el nodo debe ingresar al archivo llamado forms.xml dentro de la carpeta de
processDefinition, all encontrar la estructura resaltada en el cuadro rojo.
Ilustracin 24. Estructura de cdigo en forms.xml
Las etiquetas <forms> delimitan el nmero de formas que se especificarn para la aplicacin en consola.
Dentro de ellos existen formas individuales con dos atributos: task y form. Para un mejor entendimiento,
observe la seccin anterior en color verde. El atributo task tiene como valor el nombre que tiene la tarea
dentro del nodo y el atributo form tiene el nombre del archivo donde se creo la estructura de la forma. De
esta manera, podr vincular todas sus tareas humanas a una forma creada por usted mismo.
6.2.3. Creacin de usuarios

Para crear los usuarios que tendrn permisos sobre cada uno de los nodos, por ejemplo, en el caso de un
nodo de tarea aquellos usuarios que podrn ingresar o leer informacin, debe dirigirse a la carpeta dentro del
servidor ~/server/default/deploy/jbpm.esb/jbpm-sql/ y all editar el archivo llamado import.sql. Dentro de ste
encontrar instrucciones de insert dirigidos a tres tablas diferentes que contienen: los usuarios, los grupos de
usuarios y finalmente como se asocian esos grupos con los usuarios existentes.
En este caso vamos a realizar la siguiente insercin de usuarios en la tabla. Como puede ver en el ejemplo,
ver que se aadieron los usuarios: DDI (Director de departamento o instituto), ORL_PC (Oficina de
relaciones laborales Profesional de compensacin) y C (Candidato). En cuanto al ID, usted podr ingresar
cualquier nmero siempre y cuando sea nico en la tabla; CLASS_ hace referencia a si es usuario por lo
tanto deber ir el valor U siempre; NAME_ es el rol del usuario; EMAIL_ el correo electrnico y
PASSWORD_ la contrasea que le asignara a ese rol de usuario.
insert into JBPM_ID_USER (ID_,CLASS_,NAME_,EMAIL_,PASSWORD_) values
(5,'U','DDI','ddi@sample.domain','DDI');
(6,'U','ORL_PC','orl_pc@sample.domain','ORL_PC');
(7,'U','C','c@sample.domain','C');
Ilustracin 25. Cdigo SQL para insercin de usuarios
Es importante que recuerde que los nombres de usuario que cree, sern los usados en el cdigo JPDL
asociado al diagrama de proceso dentro de la etiqueta assignment.
Ilustracin 26. Relacin de la creacin de usuario con el proceso
Luego de esto, se crean los grupos de usuario. En este caso crearemos un grupo de usuarios en la tabla
JBPM_ID_GROUP. Se tiene un ID_ el cual debe ser nico en la tabla, CLASS_ la cual debe ser G ya que se
esta creando un grupo, un NAME_ el cual ser el nombre del grupo, TYPE_ en este caso se crea para que
sea un rol de seguridad y finalmente PARENT_ en el caso de que existan jerarquas dentro de la
organizacin, sin embargo, en este caso como no aplica se deja el valor en NULL.
insert into JBPM_ID_GROUP (ID_,CLASS_,NAME_,TYPE_,PARENT_) values

(3,'G','user','security-role',NULL);
Ilustracin 27. Cdigo SQL para insercin de grupos
Finalmente, debemos asociar los usuarios creados con el grupo indicado. Para esto, usaremos los ID_ de
usuario y de grupo, con la particularidad de que debemos dejar en valor null el NAME_ y el ROLE_ de la
membresa, ya que lo hemos definido con anterioridad y en nuestro caso no tendr ninguna aplicacin.
Tenga en cuenta que el CLASS_ en este caso se seala con una M de membership.
insert into JBPM_ID_MEMBERSHIP (ID_,CLASS_,NAME_,ROLE_,USER_,GROUP_) values

(13,'M',NULL,NULL,5,3);
(14,'M',NULL,NULL,6,3);
(15,'M',NULL,NULL,7,3);
Ilustracin 28. Cdigo SQL para relacin de usuarios con grupos
Luego de realizar esta creacin de usuarios, grupos y membresas en la base de datos, el usuario podr
ingresar a la consola de jBPM y tomar parte de los nodos bajo los cuales se les ha dado permiso de manejo.
6.2.4. Nodo de correo electrnico

La versin de jBPM 3.X no soporta SSL ni STARTTLS, por lo tanto, esta dificultad hace que no se pueda
implementar un nodo de correo electrnico usando un servidor como Gmail. Sin embargo, existe una
solucin a este inconveniente la cual consiste en cambiar el tipo de nodo de mail-node a un node. Luego, con
este nodo, se llamar una accin ejecutada desde una clase que permite enviar correos electrnicos. A
continuacin, ver el desarrollo de esta solucin.
Primero, en el cdigo escrito en JPDL del nodo tipo node, deber agregar la siguiente accin:
<node name="notificacion encargado ORL_PC - DDI">

<action name="mail" class="org.jboss.soa.esb.mail.Enviarmail">
</action>
<transition to="crear vacante DDI"></transition>
</node>
Ilustracin 29. Estructura del nodo para enviar un correo electrnico
La parte resaltada en rojo indica la ubicacin de la clase que tiene el mtodo a ejecutar para enviar un correo
electrnico. Dentro de esta clase usted encontrar lo siguiente. Tenga en cuenta que la clase, resaltada en
color rojo, deber llamarse de la misma forma descrita en la seccin de cdigo anterior.
public class Enviarmail implements ActionHandler {
@Override
public void execute(ExecutionContext arg0) throws Exception {
Properties props = new Properties();
props.put("mail.smtp.host", "smtp.gmail.com");
props.put("mail.smtp.socketFactory.port", "465");
props.put("mail.smtp.socketFactory.class",
"javax.net.ssl.SSLSocketFactory");
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.port", "465");
props.put("mail.smtp.starttls.enable", "true");
Session session = Session.getDefaultInstance(props,

new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication("usuarioejemplo", "contraseaejemplo");
}
});
try {
Message message = new MimeMessage(session);
message.setFrom(new InternetAddress("emisor@ejemplo.com"));
message.setRecipients(Message.RecipientType.TO,
InternetAddress.parse("recipiente@ejemplo.com"));
message.setSubject("[Asunto de prueba] Notificacin proceso de
seleccin");
message.setText("Estimado seor(a),"
+ "\n\n Su solicitud ha sido rechazada.
Modifquela y envela de nuevo.");
Transport.send(message);
System.out.println("Email enviado");
} catch (MessagingException e) {
throw new RuntimeException(e);
}
}
}
Ilustracin 30. Mtodo para el envo de un correo electrnico
El mtodo resaltado en color azul es el que indica que su contenido se debe ejecutar tan pronto como el
nodo llame esta accin. Dentro de este mtodo se encuentran varias secciones resaltadas en color naranja.
A continuacin se har una descripcin de cada una de ellas y cmo, para el caso de gmail, usted deber
configurarlas:
Mail.smtp.host: este atributo deber tener la caracterstica STMP que usar para enviar los correos.
En el ejemplo usted ve que se usara gmail. Para los dems atributos de configuracin del servidor de
correos puede consultar la documentacin del servicio que desee usar y fijar estos valores.
Usuarioejemplo y contraseaejemplo: Se deber tener una cuenta de correo electrnico con
contrasea, y esos valores se debern escribir en este campo.
emisor@ejemplo.com: Este es el correo del cul ser emitido el mensaje.
recipiente@ejemplo.com: Este es el correo al cul ser remitido el mensaje.
[Asunto de prueba]: Ac podr especificar el asunto con el cual enviar el mensaje.
Texto del mail: El texto que enviar en el mensaje.
6.2.5. Nodo de decisin

Estos nodos basan su decisin dependiendo del valor que tenga uno de los objetos contenido en cualquiera
de los formularios. Por ejemplo, un nodo de decisin determinara hacia donde enviar el token de ejecucin
dependiendo de si un checkbox esta o no seleccionado o tambin si se escribi determinada palabra en un
rea de texto.
En el caso de ste demo, el primer nodo de decisin se relaciona con la aprobacin o negacin de la vacante
creada para la contratacin de un profesor. Por lo tanto, a continuacin veremos el cdigo escrito en JPDL
derivado de la diagramacin del modelo y cmo, en la seccin resaltada en rojo, se fija el atributo expression
para consultar el valor de la variable, en este caso, un checkbox.
El atributo expression mira el valor con el que haya sido enviando el checkbox dentro del formulario en el
momento en que llega al nodo de decisin. Si su valor fue true, fijar la respuesta como un verdadero y
seguir su ejecucin mediante la transicin que tenga en su atributo name el mismo valor. En el caso
contrario, la ejecucin se dirigir a travs de la transicin con name falso.
<decision name="aprobacion de la vacante" expression="#{(aprob.value ==

true)?'verdadero':'falso'}">
<transition to="requiere publicacion" name="verdadero"></transition>
<transition to="notificacion encargado ORL_PC - DDI"
name="falso"></transition>
</decision>
Ilustracin 31. Estructura del nodo de decisin
Por otro lado, tenga en cuenta que la celda en el archivo revision_vacante.xhtml se debe relacionar, como se
menciono en la seccin 6.2.2, con la variable del checkbox. Adems, en este momento es importante el
name que se le haya dado tambin en la celda. Compare el atributo expression resaltado con rojo en la
seccin anterior y ver que su contenido hace un llamado a aprob.value, ahora mire la siguiente seccin de
cdigo resaltada en rojo y ver que se tiene el mismo nombre aprob. El llamado a su value, se hace para
saber si fue o no checkeado.
<jbpm:datacell>
<h:outputText value="Es aprobada:"/>
</f:facet>
<h:selectBooleanCheckbox name="aprob" value="#{var['aprobacion']}"/>
</jbpm:datacell>
Ilustracin 32. Estructura de la celda para el checkbox de aprobacin
6.2.6.Nodos para llamar servicios web

Como se habl en la seccin 5.2.2, los nodos tipos node dan la libertad para realizar acciones ms
complejas que la toma de una decisin o de la realizacin de una tarea humana. Una de las situaciones
frecuentes es invocar servicios de sistemas existentes dado que en general los procesos de negocio
modelan integracin de mltiples sistemas de la empresa. Esta integracin se puede realizar a travs de la
invocacin de servicios web, los cuales pueden ser creados internamente en la organizacin, adquirirlos
gratis o bajo algn tipo de licenciamiento. El alcance de esta gua no abarca el tema de conceptos y gestin
de servicios web, sin embargo, si se mostrar el camino para usarlos en un modelo de proceso, desarrollado
con las herramientas de JBoss.
Para comenzar, y dado nuestro ejemplo del proceso de seleccin de profesores de ctedra, crearemos un
servicio web para el nodo que implica publicacin de una vacante en un sistema externo.
Primero, se debe crear un nuevo proyecto siguiendo la siguiente ruta: File New Project Java / Java
Project. Se da el nombre que se desee y se acepta la creacin del mismo. Dentro del proyecto se debe crear
una clase que contendr el servicio web.
Ilustracin 33. Ruta de creacin del servicio web
Como puede ver en la ilustracin anterior, se creo la clase siguiendo una ruta determinada. Esta prctica es
recomendada como una forma de tener un orden y estndar para la creacin de servicios web. La ruta de
carpetas o paquetes ndica que se alojar y podr ser consultado en la direccin
http://javeriana.edu.co/publicarext. En la ltima carpeta es donde se debe poner la clase creada.
Esta clase tendr en su implementacin los mtodos web que podrn ser invocados cuando se tenga acceso
al servicio web. A continuacin puede ver un ejemplo sencillo de la implementacin de un servicio web, ste
puede tener la complejidad que desee otorgarle.
Tenga en cuenta las anotaciones que debe agregar como @Stateless, @WebService y @WebMethod.
Dentro de la clase puede crear tantos mtodos web como sean necesarios para sus operaciones, o bien,
esto es lo que hacen los proveedores cuando le ofrecen a usted una licencia por el uso de algn servicio web
ya creado, como servicios de pago desde tarjetas de crdito, entre otros.
Adems de las anotaciones anteriores, tambin existe @WebParam, sta se usa dentro de los mtodos
cuando necesite que lleguen a ellos valores por parmetro. Por ejemplo, si necesitara un parmetro llamado
identificacin en el mtodo publicar(), debera mostrarlo de la siguiente manera:
publicar(@WebParam(name = identificacion) String identificacion)
import javax.ejb.Stateless;
import javax.jws.WebMethod;
import javax.jws.WebService;
@Stateless
@WebService(name = "publicar_ext_vac_ws", targetNamespace =
"http://javeriana.edu.co/publicarext")
public class publicar_ext_vac_ws {
@WebMethod
public void publicar() {
System.out.println("Publicando en un sistema externo");
}
}
Ilustracin 34. Estructura de la clase que contiene el servicio web
Una vez creada la clase, debe generar el .jar de la aplicacin creada. En Eclipse, se hace dando click
derecho sobre el archivo .java (resaltado en la ilustracin 33), luego se da click en Export y finalmente se
selecciona dentro de la carpeta Java la opcin JAR file. All deber dar una ubicacin para guardar el archivo.
Ilustracin 35. Muestra de la bsqueda del .wsdl
Ahora, debe copiar el archivo dentro del servidor que este usando en la siguiente ruta:
~/server/default/deploy. Una vez puesto dentro de esta carpeta, inicie el servidor y cuando termine de
hacerlo, dirjase a la siguiente direccin: http://localhost:8080/jbossws/services. All encontrar el
archivo .wsdl del servicio publicado, el cual es el descriptor del servicio web creado y publicado. ste archivo
ser usado dentro de nuestro proyecto principal para invocar los mtodos del servicio web. Para obtenerlo,
debe dar click derecho y descargarlo en una carpeta de su computador.
A partir de ste archivo y haciendo uso de uno de los plugins instalados (JAX WS), los cuales generan
clases proxy que permiten la conexin, realice sobre el proyecto principal las siguientes acciones: New
Web Service Client. All indique la ruta donde se encuentra el wdsl y luego el directorio de salida. Con este
plugin se van a generar clases e interfaces esenciales para la invocacin del servicio web creado. Las
interfaces son las siguientes: publicar_ext_vac_ws y publicar_ext_vac_wsService y las clases
son: publicar_ext_vac_wsServiceLocator, publicar_ext_vac_wsBindingStub y
publicar_ext_vac_wsProxy [28].
Ahora, de la misma forma que se hace con el nodo de enviar el correo electrnico, debemos crear una clase
para invocar el servicio web, atando el mtodo a una accin llamada desde el nodo. Para realizar esto, cree
una clase dentro de la carpeta: org.ejemplo.jboss.soa.esb.invocacionws, de la siguiente manera:
public class invocarwsext implements ActionHandler {
@Override
public void execute(ExecutionContext arg0) throws Exception {
try {
Publicar_ext_vac_wsProxy pwse = new
Publicar_ext_vac_wsProxy();
pwse.publicar();
} catch (RemoteException e) {
e.printStackTrace();
}
return null;
}
}
Ilustracin 36. Estructura de la celda para el checkbox de aprobacin
En la ilustracin 36 puede ver cmo, en color verde, se crea una instancia del proxy generado previamente
automticamente, y luego usando ese proxy, llama al mtodo que desea ejecutar. De esta forma, cuando
ejecute el proceso y pase por este nodo, se llamar al mtodo del web service deseado, dando un rango ms
amplio de posibilidades de desarrollo para sus propsitos.
6.2.7. Uso del bus de servicios

Ahora veremos cmo se pueden implementar los nodos de correo electrnico y los llamados a servicios web
aprovechando el bus de servicios, el cul finalmente, es el motor que permitir a la empresa tener ms
flexibilidad, escalabilidad e integridad.
Ilustracin 37. Cambio de tipo de nodos
Se deben modificar cuatro archivos que ataen a la configuracin del bus de servicios, con el propsito de
crear las colas, los listeners y los servicios como tal que podrn ser invocados desde un modelo de jBPM. El
primero de ellos es: hornetq-jms.xml. En este archivo se declara la creacin de la cola que nos servir para
invocar el servicio que necesitemos. En las ilustraciones 38 y 39 ver el ejemplo tanto de la cola para el
correo electrnico como para la invocacin de servicios web.
<queue name="quickstart_bpm_orchestration4_enviarMail_service_esb">
<entry name="queue/quickstart_bpm_orchestration4_enviarMail_service_esb"/>
</queue>
Ilustracin 38. Creacin de la cola para el servicio de correo electrnico en el descriptor hornetq-
jms.xml
<queue name="quickstart_bpm_orchestration4_publicarwsext_service_esb">
<entry name="queue/quickstart_bpm_orchestration4_publicarwsext_service_esb"/>
</queue>
Ilustracin 39. Creacin de la cola para el servicio de invocacin de un servicio web en el descriptor
hornetq-jms.xml
Usted podr dar cualquier nombre a estas colas siempre y cuando sea antecedida por la sentencia: queue/
(nombre de la cola). El segundo y tercer archivo se encargan de la creacin de los Managed Beans
(mbeans) dentro del servidor de mensajes (JMS) y el servidor para monitorear los servicios publicados
(JMX). En ambos deben existir sentencias que aseguren el funcionamiento de los servicios que
posteriormente sern llamados desde el bus de servicios.
El cdigo correspondiente al segundo archivo llamado: jbm-queue-service.xml lo ver en las ilustraciones 40
y 41. El cdigo correspondiente al tercer archivo llamado: jbmq-queue-service.xml lo ver en las ilustraciones
42 y 43. Fjese que las sentencias resaltadas en rojo, las cuales se encargan de citar la cola, deben coincidir
con las vistas en las ilustraciones 38 y 39.
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.esb.quickstart.destination:service=Queue,name=
quickstart_bpm_orchestration4_enviarMail_service_esb"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">
jboss.messaging:service=ServerPeer</depends>
</mbean>
Ilustracin 40. Creacin del mbean para el servicio de correo electrnico en el servidor JMS en el
descriptor jbm-queue-service.xml
<mbean code="org.jboss.jms.server.destination.QueueService"
quickstart_bpm_orchestration4_publicarwsext_service_esb"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">
jboss.messaging:service=ServerPeer</depends>
</mbean>
Ilustracin 41. Creacin del mbean para el servicio de invocacin de un servicio web en el servidor
JMS en el descriptor jbm-queue-service.xml
<mbean code="org.jboss.mq.server.jmx.Queue"
quickstart_bpm_orchestration4_enviarMail_service_esb">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
Ilustracin 42. Creacin del mbean para el servicio de correo electrnico en el servidor JMX en el
descriptor jbmq-queue-service.xml
<mbean code="org.jboss.mq.server.jmx.Queue"
quickstart_bpm_orchestration4_publicarwsext_service_esb">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
Ilustracin 43. Creacin del mbean para el servicio de invocacin de un servicio web en el servidor
JMX en el descriptor jbmq-queue-service.xml
Finalmente, tendremos que crear los servicios dentro del descriptor: jboss-esb.xml. Una vez desplegado,
este archivo se encarga de facilitar los servicios para que sean llamados desde el modelo jBPM. Primero,
dentro de los tag <providers> y <jms-provider> deberemos llamar a travs de un tag <jms-bus> las colas
creadas con el propsito de darle soporte a cada uno de los servicios, en nuestro caso, el nodo de correo
electrnico y el de invocacin a un servicio web.
En la ilustracin 44, se detallan en color azul los tags dentro de los cuales deben ser creados los canales,
encargados de hacer uso de las colas creadas para el intercambio de mensajes. El nombre de estos canales
se resalta en color verde y deben ser tenidos en cuenta debido a que ms adelante sern referenciados en
los servicios del bus. Recuerde, que las sentencias en color rojo deben coincidir con las enunciadas en la
ilustracin 37 y 38.
<providers>
<jms-provider connection-factory="ConnectionFactory"
name="JBossMQ">
(...)
<jms-bus busid="enviarMailChannel">
<jms-message-filter dest-name=
"queue/quickstart_bpm_orchestration4_enviarMail_service_esb"
dest-type="QUEUE" />
</jms-bus>
<jms-bus busid="publicarwsextChannel">
<jms-message-filter dest-name=
"queue/quickstart_bpm_orchestration4_publicarwsext_service_esb"
dest-type="QUEUE" />
</jms-bus>
</jms-provider>
</providers>
Ilustracin 44. Creacin de los canales de correo electrnico e invocacin de servicio web en el
descriptor jboss-esb.xml
Luego, se arma la estructura de los servicios que harn uso de los canales anteriores para la transferencia
de mensajes. Estos servicios deben tener una categora, la cual usted puede crear de acuerdo a sus
parmetros, por ejemplo, en este caso el atributo category ser proceso_Javeriana. Adems debe tener un
nombre, til a la hora de invocar el servicio, y una descripcin que har ms entendible la razn de ser del
servicio registrado en el bus.
A continuacin, en la ilustracin 45 puede ver en color naranja, las categoras de los servicios; en color azul,
sus descripciones; y en color rojo sus nombres. Tenga en cuenta que ninguno de estos parmetros puede
llevar tildes ni ningn otro carcter especial ya que por cuestiones de la herramienta, no permite compilar.
Adicionalmente, en color verde se enuncian los canales previamente definidos y que deben coincidir con las
propiedades de la ilustracin 44.
Las acciones, igual que se haca en la invocacin sin usar el bus de servicios, debern ser indicadas en la
propiedad class, referenciando a la clase donde se encuentra la implementacin. stas se resaltan con color
morado.
<services>
<service category="proceso_Javeriana" description=
"Envio de correos electronicos" name="enviarMail">
<listeners>
<jms-listener busidref="enviarMailChannel"
name="enviarMailChannel" />
</listeners>
<actions>
<action class="org.jboss.soa.esb.mail.Enviarmail"
name="mail" />
</actions>
</service>
<service category="proceso_Javeriana" description="Publicacion de una

vacante en un sitio externo" name="publicarwsext">
<listeners>
<jms-listener busidref="publicarwsextChannel"
name="publicarwsextChannel" />
</listeners>
<actions>
<action class="org.jboss.soa.esb.invocacionws.invocarwsext"
name="invext" />
</actions>
</service>
</services>
Ilustracin 45. Estructura de los servicios registrados en el bus en el descriptor jboss-esb.xml
En este punto, ya se tiene listo el desarrollo que permitir la invocacin de un servicio registrado en el bus.
Sin embargo, es importante que en el descriptor encargado de desplegar las colas, incluya las creadas para
el correo y la invocacin del servicio web. Esto se realiza en el archivo llamado: deployment.xml, de la forma
como se ilustra en la ilustracin 46.
<jbossesb-deployment>
(...)
<jmsQueue>quickstart_bpm_orchestration4_enviarMail_service_esb</jmsQueue>
<jmsQueue>quickstart_bpm_orchestration4_publicarwsext_service_esb</jmsQueue>
</jbossesb-deployment>
Ilustracin 46. Lneas a insertar en el descriptor de despliegue de colas del bus en el descriptor
deployment.xml
Luego de haber realizado los pasos anteriores, ya est lista la configuracin para hacer uso del bus de
servicios. Sin embargo, hay que hacer unas pequeas modificaciones a las clases que ya se tenan de
correo electrnico e invocacin de servicio web, como se muestra en la ilustracin 47. En color rojo podr ver
como se deber extender ahora de una clase llamada AbstractActionPipelineProcessor. Adems, el
mtodo ahora ser process y devuelve un Message al bus. Adicionalmente es importante que incluya un
constructor, ya que sin ste, no har deploy el servicio creado. En nombredelaclase usted deber poner el
nombre con el cual desea identificar la clase, para el ejemplo del demo, este nombre de la clase toma los de:
EnviarMail e invocarwsext.
public class nombredelaclase extends AbstractActionPipelineProcessor {
@Override
public Message process(Message arg0) throws ActionProcessingException {
//Contenido del mtodo
return null;
}
public invocarwsext(ConfigTree configTree) {
}
}
Ilustracin 47. Cambio en las clases.
Finalmente, sobre el buildfile registrado del proyecto, oprima la funcin de deploy para desplegar las colas y
archivos en el servidor. Luego entre a la pgina de la consola y siga el proceso que ha creado, o bien, si est
ejecutando ste demo, podr realizar las mismas acciones cmo se ndico a travs de toda la seccin 6.
7. Integracin de una aplicacin JEE5
con el bus de servicios de JBoss
7.1. Introduccin
En algunos casos, las funcionalidades brindadas por la consola de jBPM no es suficiente para suplir las
necesidades de una organizacin. Por esta razn, se presentan a continuacin una serie de anotaciones
importantes a la hora de acoplar una aplicacin Java EE 5 con jBPM, resaltando el uso del framework Seam
y del bus de Servicios dentro de jBPM.
7.1.1. Anotacin @CreateProcess

@CreateProcess(definition="process definition name")
Crea una nueva instancia del proceso jBPM cuando el mtodo retorna una salida no nula. El objeto
ProcessInstance estar disponible en la variable de contexto denominada processInstance [29].
Propiedades:
definition: El nombre de la definicin del proceso jBPM va
org.jboss.seam.core.jbpm.processDefinitions [29].
7.1.2. Anotacin @ResumeProcess

@ResumeProcess(processIdParameter="processId")
Vuelve a entrar al alcance de la instancia del proceso existente jBPM cuando el mtodo retorna una salida no
nula. El objeto ProcessInstances estar disponible en la variable de contexto denominada processInstance
[29].
Propiedades:
processIdParameter: Corresponde al nombre del parmetro de solicitud guardando el identificador del
proceso [29].
7.1.3. Anotacin @StartTask

Inicia una tarea en jBPM. Especifica que una conversacin de larga duracin al igual que la anotacin @Begin
comienza cuando el mtodo retorna una salida no nula. Esta conversacin est asociada con la tarea de
jBPM especificada en el parmetro de solicitud nombrada, tambin se define un contexto del proceso de
negocio, para la instancia del proceso de negocio [29].
La instancia de tareas de jBPM estar disponible en la variable de contexto request denominada

taskinstance. La instancia del proceso tambin estar disponible en la variable de contexto request
denominada processInstance. Estos objetos estn disponibles por inyeccin @in [29].
Propiedades:
taskIdParameter: Es el nombre del parmetro de solicitud el cual contiene el identificador de la tarea
[29].
FlushMode: modifica este modo a cualquiera de los manejados por las sesiones Hibernate o el
contexto de persistencia JPA [29].
7.1.4. Anotacin @BeginTask

Especifica que una conversacin de larga duracin comienza cuando el mtodo retorna una salida no nula. Se
asocia con la tarea jBPM especificada en el parmetro de solicitud mencionada [29]. La diferencia entre
@StartTask y @BeginTask es que la primera marca la tarea como iniciada una vez el mtodo retorna de
manera exitosa, la segunda no afecta la tarea, es decir, no modifica ningn valor de la tarea [30].
7.1.5. Anotacin @EndTask

Finaliza una tarea jBPM de tipo Task Node. Especifica que una conversacin de larga duracin termina
cuando el mtodo retorna un valor no nulo, y que la tarea actual ha sido completada. Desencadena una
transicin jBPM. La transicin real disparar la transicin por defecto a menos que la aplicacin haya llamado
el siguiente mtodo: Transition.setName() [29].
Disparadores de la transicin jBPM

@EndTask(transition="transitionName")
Especifica que la tarea termina cuando el mtodo retorna una de las salidas mencionadas.
@EndTask(ifOutcome={"success", "continue"})
Propiedades:
transition: Corresponde al nombre de la transicin jBPM que se disparar cuando termine la tarea. Se
utiliza Defaults a la transicin por defecto [29].
ifOutcome: Especifica la salida o salidas JSF (Java Server Faces) que resultan al final de la tarea [29].
beforeRedirect: Por defecto, la conversacin no ser destruida hasta despus de que haya alguna
redireccin. Cambiando beforeRedirect a verdadero se especifica que la conversacin debera ser
destruida al final de la solicitud actual, y que la redireccin ser procesada en un nuevo contexto de
conversacin [29].
7.1.6. Relacin Entre Anotaciones
Con el fin de dar ms claridad a las anotaciones presentadas anteriormente se ilustrarn como estas se
relacionan con algunos nodos del ejemplo de una solicitud de materia prima a proveedor.
El nodo Start State se soporta sobre un mtodo

en una clase POJO que se ve de la siguiente
manera [31]:
@CreateProcess(definition="simple")
public void startProcess() {
// Nueva Instancia de la peticin
}
Los Task Node tambin se soportan sobre clases

POJO que contienen mtodos con las
anotaciones para conducir a diferentes
transiciones dependiendo del nodo [31].
@StartTask
@EndTask(transition="next")
public void valorMateriaPrima() {
//Operaciones que requiera
}
Ilustracin 48. Solicitud de materia prima
8. Referencias
[1] Pgina oficial del Proyecto JBoss jBPM. Consultada el da 22 de Octubre de 2011:
http://www.jboss.org/jbpm
[2] Informacin sobre tendencias en la gestin de procesos de negocio 2010. Consultado el da 22 de Octubre
de 2011: http://www.bptrends.com/surveys_landing.cfm
[3] Captulo 9, Process Modelling. Gua para usuarios de jBPM. Consultado el da 22 de Octubre de 2011:
http://docs.jboss.org/jbpm/v3/userguide/processmodelling.html
[4] Captulo 18, jBPM Process Definition Language. Gua para usuarios de jBPM. Consultado el 22 de Octubre
de 2011:http://docs.jboss.org/jbpm/v3/userguide/jpdl.html
[5] Jugando con jBPM #4. Start-State Node. Blog Salaboy. Consultado el da 22 de Octubre de 2011:
http://salaboy.wordpress.com/2008/08/21/jugando-con-jbpm-4-start-state-node/
[6] Gua para usuarios de jBPM. Consultado el da 01 de Abril de 2011:

http://docs.jboss.org/jbpm/v3/userguide/
[7] Captulo 6, Service Orchestration. JBoss Documentation. Consultado el da 22 de Octubre de 2011:

http://docs.redhat.com/docs/en-US/JBoss_Enterprise_SOA_Platform/5/html/ESB_Services_Guide/ch06.html
[8] Captulo 16, Email Support. Gua para usuarios de jBPM. Consultado el da 22 de Octubre de 2011:
http://docs.jboss.org/jbpm/v3/userguide/mail.html
[9] JBoss jBPM 2.0 jPDL Reference Manual. Consultado el da 22 de Octubre de 2011:
http://www.jboss.com/products/jbpm/docs/jpdl/
[10] ESB Service Orchestration with jBPM. Consultado el da 22 de Octubre de 2011:

http://www.mastertheboss.com/soa-a-esb/120-esb-service-orchestration-with-jbpm.html
[11] Romero, Cristian; Arias, Laura. Caractersticas y posibilidades con jBPM 3.X. Proyecto especial SOA-BPM.
Pontificia Universidad Javeriana. 2011.
[12] Macroproceso gestin del talento Humano, Proceso seleccin. Oficina de organizacin y mtodos.
Consultado el da: 24 de Agosto de 2011. Disponible en:
http://www.javeriana.edu.co/puj/viceadm/oym/ppd/documentos4-DGRH-TH-11.html
[13] Matt Cumberlige, Business Process Management with JBoss jBPM, A practical guide for business
analysts, Packt Publishing, 2007.
[14] BPMN Gua de Referencia, Bizagi.
[15] JBoss jBPM 2.0 jPDL Reference Manual. Consultado el da 22 de Octubre de 2011:
http://www.jboss.com/products/jbpm/docs/jpdl/
[16] Z. E. Akkaoui and E. Zimnyi. Defining ETL worfklows using BPMN and BPEL. In DOLAP, pp. 41-48,
2009.
[17] C. Ouyang, M. Dumas, W. M. P. van der Aalst, A. H. M. ter Hofstede, and J. Mendling. From Business
Process Models to Process-Oriented Software systems. ACM Trans. Softw. Eng. Methodol., 19(1), 2009.
[18] Rosen, Michael; Lublinsky, Boris; Smith, Kevin; Balcer, Marc. Applied SOA Service Oriented
Architecture and design strategies. Wiley Publishing. 2008.
[19] White, Stephen; Miers, Derek; Fisher, Layna; Moreno, Juan. BPMN Gua de Referencia y Modelado:
Comprendiendo y Utilizando BPMN. 2010.
[20] R.K. Ko, A Computer Scientists Introductory Guide to Business Process Management (BPM),
Crossroads, Vol. 15, No. 4, 1118 (2009).
[21] Valani, D. and Chawan, R. K. and Ghazali, S. SOA enabled BPM rule engine. Proceedings of the
International Conference; Workshop on Emerging Trends in Technology. 2011
[22] Yang Liu; Enzhao Hu; Xudong Chen;, "Architecture of Information System Combining SOA and BPM,"
Information Management, Innovation Management and Industrial Engineering, 2008. ICIII '08. International
Conference on , vol.1, no., pp.42-45, 19-21 Dec. 2008
[23] Kiran K. Garimella; Bruce D. Williams; Michael J. Lees. BPM Basic for Dummies.
[24] Mike P. Papazoglou, Willem-Jan van den Heuvel; Service oriented architectures: approaches,
technologies and research issues, The VLDB Journal. Springer verlag. 2007.
[25] Kennedy , Mark. Oracle BPEL Process Manager Quick Start Guide, 10g. BPEL Process Manager.
Oracle. Septiembre 2006.
[26] The jBPM console web application. Jboss. RedHat documentation.
[27] Chapter 1. Introduction. JBoss jBPM jPDL 3.2. jBPM jPDL user guide.
[28] Franky, Maria Consuelo. Aspectos avanzados en las aplicaciones Java EE 5. Parte G. Desarrollo de
aplicaciones Java EE 5 en base a Frameworks. Pontificia Universidad Javeriana.
[29] Informacin sobre anotaciones JEE que soportan jBPM. Consultado el da 27 de Enero de 2012:
http://docs.jboss.org/seam/1.2.1.GA/reference/en/html/annotations.html
[30] Dan Allen, Seam In Action, Mannin Publications 2009, Chapter 14.
[31] Informacin sobre anotaciones Jbpm. Consultado el da 27 de Enero de 2012:

http://mastertheboss.com/seam/90-seam-jbpm.html

Guía

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Guía

Enviado por

Direitos autorais:

Formatos disponíveis

Modelado e implementacin de un

proceso de negocio BPM mediante

2|Gua Prctica. BPM - SOA

3|Gua Prctica. BPM - SOA

4|Gua Prctica. BPM - SOA

5|Gua Prctica. BPM - SOA

6|Gua Prctica. BPM - SOA

1.2. Acerca del demo

1.2.1. Descripcin del Proceso de seleccin

2. El profesional de compensacin de la oficina de relaciones laborales de la Universidad revisa la

4. Si la vacante fue rechazada, el profesional de compensacin notifica va correo electrnico al director

a. Luego de la notificacin del rechazo, se procede a eliminar la vacante creada en el sistema,

7|Gua Prctica. BPM - SOA

6. Independientemente de si se solicit publicacin externa, se publica la vacante en el sistema interno

13. Luego de revisarla, el decano deber aprobar o rechazar la solicitud.

17. El asistente para asuntos profesorales debe aprobar o rechazar la solicitud.

18. Si la solicitud fue aprobada, se le notifica va correo electrnico al vicerrector acadmico.

a. El decano acadmico realizar los ajustes a la oferta econmica realizada, si as se lo indica

21. El vicerrector debe aprobar, devolver o rechazar la solicitud.

8|Gua Prctica. BPM - SOA

b. Si no la devuelve, se realiza la gestin indicada con el decano acadmico para pasar a

c. Si es devuelta al decano acadmico y despus de que sea realizada la gestin de

27. Se realiza la vinculacin laboral en el ERP, la asociacin de la clase y genera el contrato en el

28. El candidato revisa los trminos de su contrato y la oferta econmica realizada.

29. El candidato deber evaluar si acepta o no el contrato con la Universidad.

31. Si el candidato acepta, se procede a realizar el proceso de contratacin.

1.2.2. Descripcin del Proceso de contratacin

1. Dados los recursos de informacin se define si el profesor es nuevo.

2. En caso de que un profesor sea nuevo:

a. Verifica el nombramiento y realiza la solicitud de una apertura bancaria para el pago de la

b. Se realiza el proceso del examen mdico.

c. Se realiza el proceso de la carnetizacin institucional.

9|Gua Prctica. BPM - SOA

e. Se le asigna una cuenta de correo electrnico al profesor.

3. Se firma el contrato y es remitido a la direccin de recursos humanos de la Universidad. Posterior a

1.2.3. Descripcin del Demo

Ilustracin 1. Relacin entre servicios de negocio y procesos en SOA [18]

2.2. Gestin de Procesos de negocio (BPM)

La gestin de procesos de negocio (BPM) es un conjunto de mtodos, herramientas y tecnologas usadas

Ilustracin 2. Ejemplo de un modelo en notacin BPMN [19]

La integracin se relaciona con aspectos de sistemas de control, sistemas de informacin, fuentes de

2.2.2. Qu hace BPM?

Composicin de soluciones: BPM facilita el diseo rpido, montaje y despliegue de procesos de

2.3. Arquitectura orientada a servicios (SOA)

En otras palabras, la arquitectura SOA permite que diferentes organizaciones desarrollen

Sean similares en cuanto a: tamao, forma, funcin y otras caractersticas.

Se adecuen a los estndares de la empresa.

Se comuniquen a un nivel tcnico.

Se comuniquen a un nivel semntico.

No tengan huecos ni solapamientos en sus responsabilidades [18].

Ilustracin 3. Elementos arquitecturales de SOA [18]

De abajo hacia arriba las capas son [18]:

Recursos de la empresa y datos operacionales: Esta capa se compone de aplicaciones existentes,

Ilustracin 4. Perspectiva empresarial de SOA [18]

2.4. Bus de servicios empresariales (ESB)

Ilustracin 5. Arquitectura del bus de servicios empresariales

Capacidad de integracin. Para apoyar una arquitectura orientada a servicios en un entorno

Capacidad de transformacin. Los distintos componentes conectados a un bus de servicios esperan

Capacidades de seguridad. El manejo de la seguridad es uno de los factores claves a la hora de

Explorador de proyectos JSF (vista Web Projects)

Asociar proyectos a servidores registrados en Eclipse (vista JBoss Server View)

Para la instalacin descomprimir el archivo: JBossTools-ALL-win32-3.0.2.v200909151014R-H192-GA.zip

3.4. JBoss ESB

Cuando haya descargado la carpeta, regstrela en el IDE Eclipse. Ingrese a jbossesb-