I
Universidad de las Ciencias Informáticas
Facultad 3
Caracterización de los módulos para la
integración de procesos en los sistemas BPM de Oracle y Microsoft.
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autores: Yadira Tamayo Liens.
Fernando Rodríguez Medina.
Tutores: Lic. Arturo Alfonso Villarnovo.
Lic. Ana R .Rojas Blaquier.
Co-tutor: Ing. Alián Rigñack Quevedo.
Ciudad de La Habana, Junio 2009
“Año del 50 aniversario del Triunfo de la Revolución”
II Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de Junio del año 2009.
Yadira Tamayo Liens Fernando Rodríguez Medina
______________ ______________
Firma del Autor Firma del Autor
Arturo Alfonso Villarnovo Ana R. Rojas Blaquier
______________ ______________
Firma del Tutor Firma del Tutor
III Teniente Coronel Lic. Arturo Alfonso Villarnovo.
Departamento de Desarrollo de Software, Dirección de Informática Y Comunicaciones. Ministerio del Interior.
Licenciado en Cibernética Matemática, Universidad de La Habana 1982.
Se ha desempeñado en el campo del desarrollo de Software y las Bases de Datos.
Investigador Auxiliar.
Teniente Coronel Lic. Ana R Rojas Blaquier.
Departamento de Desarrollo de Software, Dirección de Informática Y Comunicaciones. Ministerio del Interior.
Licenciada en Cibernética Matemática, Universidad de La Habana 1986.
Se ha desempeñado en el campo del desarrollo de Software y las Bases de Datos.
Investigadora Auxiliar.
IV
Agradecimientos
En primer lugar quiero agradecer al Comandante, por darme la oportunidad de graduarme en su idea de futuro.
A mis padres por todo el apoyo que siempre me han dado, a mis hermanos, mi ejemplo en todo momento.
A mi novia por acompañarme durante todo este tiempo en adelante.
A Alián, Ana y Arturo, sin ellos no hubiera sido posible, gracias por todas las experiencias.
A todos mis amigos, que aunque no lo crean han ayudado a todo lo que soy.
A Fidel, Raúl y a la Revolución por la oportunidad de estudiar y de que fuera en una universidad como la de ciencias informáticas.
A Alián, Arturo y Ana por el tiempo dedicado, por sus experiencias, por sus conocimientos, por sus consejos y por todo lo que aprendí en estos meses.
A mis madres, a mis padres y a mis hermanos por su apoyo incondicional.
V nuestra formación.
VI dinamismo y agilidad en la producción e integración de los Sistemas existentes, desarrollados en plataformas heterogéneas, con dispares grados de modernidad, necesarios e insustituibles a corto plazo, que se deben integrar a las nuevas soluciones. BPM con sus patrones de integración resuelve una parte de estos problemas y se ha decidido su introducción.
La novedad tecnológica entraña retos: ¿Cómo seleccionar las plataformas de Software más adecuadas en un mercado inmaduro, pleno de proveedores continuamente liberando versiones y facilidades, principalmente dirigidas a la integración de Sistemas Legados? ¿Qué aspectos de las plataformas resultan más relevantes para una organización? ¿La fuerte presencia de productos de un proveedor en una organización representa un factor decisivo a considerar en la elección?
Interrogantes sin respuestas triviales, de ahí la necesidad de iniciar un estudio de caracterización de las principales soluciones.
Se realiza una investigación del estado del arte: integración de procesos, estándares, adopción, beneficios y modelos de componentes disponibles. Se describen sus características principales, arquitectura, e integración con soluciones de terceros. Incluye un análisis y caracterización del entorno de informatización del Minint.
Para la investigación se diseñó un caso de estudio experimental, consistente en la integración en un proceso tecnológico de un conjunto de sistemas legados y la adaptación de un instrumento de comparación para analizar los resultados. Esto permitió obtener los conocimientos adecuados para caracterizar las plataformas, dictaminar sobre la factibilidad de su introducción en la práctica de la institución y orientar los pasos futuros.
Palabras claves
BPM, Integración de Procesos, SOA, ESB, BizTalk Server, Oracle SOA Suite, Sistemas legados.
VII
CAPÍTULO 1... 16
1.1 INTRODUCCIÓN ... 16
1.2 CONCEPTOS BÁSICOS ... 16
1.3 GESTIÓN DE PROCESO ... 17
1.4 ADMINISTRACIÓN DE PROCESOS DE NEGOCIOS ... 18
1.4.1 ORIGEN ... 18
1.4.2 ADOPCIÓN ... 19
1.4.3 BENEFICIOS ... 20
1.5 SISTEMAS DE ADMINISTRACIÓN DE PROCESOS DE NEGOCIO ... 20
1.5.1 BENEFICIOS ... 22
1.5.2 COMPONENTES FUNCIONALES... 22
1.5.3 ESTADO DEL MERCADO ... 23
1.5.4 ESTÁNDARES UTILIZADOS POR LOS BPMS ... 27
1.5.5 PROPUESTAS DE CÓDIGO ABIERTO ... 28
1.6 ARQUITECTURA ORIENTADA A SERVICIOS ... 28
1.6.1 EVOLUCIÓN ... 29
1.6.2 BENEFICIOS ... 30
1.7 SERVICIO ... 30
1.7.1 SERVICIOS WEB ... 30
1.7.2 ESTÁNDARES UTILIZADOS POR LOS SERVICIOS WEB ... 32
1.7.3 SERVICIOS REST ... 33
1.8 SOFTWARE COMO SERVICIO ... 34
1.9 COMPUTACIÓN EN LA NUBE ... 35
1.10 MASHUP ... 37
1.11 ORQUESTACIÓN DE SERVICIOS WEB... 38
1.12 LENGUAJE PARA LA EJECUCIÓN DE PROCESOS DE NEGOCIO ... 39
1.12.1 DEFICIENCIAS ... 40
1.13 INTEGRACIÓN DE APLICACIONES EMPRESARIALES ... 40
1.13.1 NIVELES DE INTEGRACIÓN ... 41
1.14 ARQUITECTURA DE INTEGRACIÓN DE APLICACIONES ... 43
1.14.1 ADAPTADORES ... 44
VIII
1.15 BUS DE SERVICIOS EMPRESARIALES ... 47
1.15.1 CAPACIDADES DE UN ESB ... 48
1.15.2 TENDENCIA ... 49
1.15.3 ESTADO DEL MERCADO ... 51
1.16 SISTEMAS LEGADOS ... 52
1.17 RELACIÓN ENTRE TECNOLOGÍAS BPM-SOA-ESB ... 53
1.18 CONCLUSIONES ... 54
CAPÍTULO 2 ... 55
2.1 INTRODUCCIÓN ... 55
2.2 CARACTERIZACIÓN DEL ENTORNO MININT ... 55
2.3 CARACTERIZACIÓN DE LAS HERRAMIENTAS ... 58
2.4 ORACLE SOA SUITE ... 58
2.4.1 ARQUITECTURA ORACLE SOASUITE ... 59
2.4.1.1 Integrated Service Environment ... 60
2.4.1.2 Oracle BPEL Process Manager ... 61
2.4.1.3 BPEL Designer ... 61
2.4.1.4 BPEL Server ... 61
2.4.1.5 BPEL Console... 64
2.5 ORACLE ESB ... 65
2.5.1 ARQUITECTURA ORACLE ESB ... 66
2.5.2 CAPACIDADES QUE INCLUYE ORACLE ESB... 67
2.6 ORACLE WEB SERVICES MANAGER (OWSM) ... 69
2.7 ESTÁNDARES SOPORTADOS POR LA ORACLE SOA SUITE ... 70
2.8 BIZTALK SERVER 2006 ... 71
2.9 ARQUITECTURA DE BIZTALK SERVER 2006 ... 72
2.10 ARQUITECTURA DEL MOTOR DE BIZTALK SERVER 2006 ... 73
2.10.1.1 Adaptadores ... 74
2.10.1.2 Pipelines ... 75
2.10.1.3 MessageBox ... 78
2.10.1.4 Orquestaciones ... 78
2.10.1.5 Funcionamiento del motor de BizTalk ... 78
2.11 XLANG ... 79
2.12 ESQUEMAS Y ASIGNACIONES ... 80
IX
2.15 INTEROPERABILIDAD ENTRE LAS PLATAFORMAS DE MICROSOFT Y ORACLE ... 86
2.16 CONCLUSIONES ... 88
CAPÍTULO 3 ... 89
3.1. INTRODUCCIÓN ... 89
3.2. CASO DE ESTUDIO ... 89
3.2.1. DESCRIPCIÓN DEL PROCESO: ... 90
3.2.2. PRIMERA PARTE (DESCRIPCIÓN DEL PROCESO ACTUAL) ... 90
3.2.3. SEGUNDA PARTE (DESCRIPCIÓN DEL PROCESO MEJORADO) ... 92
3.3. INSTRUMENTO DE CARACTERIZACIÓN ... 93
3.4. INDICADORES CLAVE ASOCIADOS A LAS TECNOLOGÍAS DE INTEGRACIÓN ... 93
3.5. INDICADORES CLAVE DE INTERÉS PARA EL DEPARTAMENTO DE DESARROLLO DE SOFTWARE (DDS) 103 3.6. VALORACIONES SOBRE EL USO DE ESTAS TECNOLOGÍAS EN EL MININT ... 106
3.7. CONCLUSIONES ... 108
CONCLUSIONES Y RECOMENDACIONES ... 109
REFERENCIAS BIBLIOGRÁFICAS ... 110
BIBLIOGRAFÍA ... 113
ANEXO I. MODELACIÓN DEL PROCESO CONDUCIDO CON LA HERRAMIENTA ORACLE SOA SUITE. ... 115
ANEXO II. INSTRUMENTO DE CARACTERIZACIÓN ... 116
ANEXO 3. APLICACIÓN DEL INSTRUMENTO DE CARACTERIZACIÓN A LA HERRAMIENTA ORACLE SOA SUITE ... 120
ANEXO 4. APLICACIÓN DEL INSTRUMENTO DE CARACTERIZACIÓN A LA HERRAMIENTA BIZTALK SERVER 2006 123 GLOSARIO ... 126
X
Índice imágenes
FIGURA 1ADOPCIÓN DE SOFTWARE BPM.RENATO DE LAURENTIIS,INFORMÁTICA 2009 ... 19
FIGURA 2.SURGIMIENTO DE LOS BPMS ... 21
FIGURA 3.GARTNER:ANÁLISIS DE MERCADO DE LAS SUITES BPM,Q12009 ... 25
FIGURA 4.BPMS RATINGS, INTEGRATION-CENTRIC VS. HUMAN-CENTRIC BPM,Q22008 ... 25
FIGURA 5.FORRESTER WAVE™:INTEGRATION-CENTRIC BUSINESS PROCESS MANAGEMENT SUITES,Q4’08 ... 26
FIGURA 6 EVOLUCIÓN DE LAS ARQUITECTURAS DE INTEGRACIÓN. ... 29
FIGURA 7.ARQUITECTURA DE SERVICIOS WEB MOSTRANDO LA VINCULACIÓN DE LAS TECNOLOGÍAS QUE LA COMPONEN... 31
FIGURA 8CLOUD COMPUTING ... 36
FIGURA 9MASHUP ... 37
FIGURA 10.ORQUESTACIÓN DE SERVICIOS WEB ... 38
FIGURA 11.INTEGRACIÓN ORIENTADA A LOS DATOS. ... 41
FIGURA 12INTEGRACIÓN ORIENTADA A PROCESOS ... ERROR!BOOKMARK NOT DEFINED. FIGURA 13INTEGRACIÓN ORIENTADA A SERVICIOS ... 43
FIGURA 14INTEGRACIÓN ORIENTADA A PORTALES ... 43
FIGURA 15.ARQUITECTURA HUB/SPOKE ... 46
FIGURA 16ARQUITECTURA BUS ... 47
FIGURA 17BUS DE SERVICIOS EMPRESARIALES ... 49
FIGURA 18FORRESTER WAVE™:ENTERPRISE SERVICE BUS,Q1‘09 ... 51
FIGURA 19ARQUITECTURA ORACLE SOASUITE ... 60
FIGURA 20.ARQUITECTURA ORACLE BPELPROCESS MANAGER. ... 64
FIGURA 21COMPONENTES DEL ORACLE ESB ... 66
FIGURA 22ARQUITECTURA DEL ORACLE ESB ... 67
FIGURA 23ARQUITECTURA DE BIZTALK SERVER 2006... 73
FIGURA 24COMPONENTES DEL MOTOR DE BIZTALK SERVER 2006 ... 73
FIGURA 25ETAPAS Y COMPONENTES DE UN PIPELINE DE ENTRADA ... 75
FIGURA 26ETAPAS Y COMPONENTES DE UN SEND PIPELINE ... 77
FIGURA 27FUTURO BIZTALK SERVER “OSLO &DUBLÍN” ... 85
FIGURA 28INTEROPERABILIDAD ENTRE PLATAFORMAS ... 86
XI El Ministerio del Interior se encuentra inmerso en un amplio proceso de informatización dirigido a fortalecer las áreas del trabajo operativo y de dirección del enfrentamiento. La complejidad de los escenarios en los que desempeña sus misiones reclama un proceso de modernización tecnológica que garantice satisfacer los requerimientos del trabajo. Se ha configurado un entorno en el que las necesidades de producción de software y su continua adaptación a la dinámica de los acontecimientos resultan crecientes.
Cuenta con una organización para el desarrollo de software que no ha estado exenta de las principales dificultades por las que ha transitado la industria del sector en todos estos años, pero que ha logrado producir y poner en explotación un significativo volumen de sistemas informáticos que, a pesar de sus limitaciones e insuficiencias, resultan imprescindibles para el trabajo diario de las diferentes líneas ministeriales.
A estos elementos se une el déficit de recursos humanos con la capacitación idónea y la propia dinámica de los cambios tecnológicos en el sector que complican aún más el escenario, haciendo más compleja la respuesta a las necesidades de informatización.
La jefatura, a partir de una nueva visión estratégica del proceso de informatización, ha tomado un conjunto de medidas con el fin de ir disminuyendo paulatinamente estos elementos negativos, modernizar la organización progresivamente y crear las condiciones adecuadas para dar respuesta a las necesidades de diversas áreas. Entre las principales, ha decidido la introducción de los conceptos y tecnologías asociadas a la Administración de Procesos de Negocio, BPM por sus siglas en inglés.
BPM constituye la propuesta de solución actual a muchas de las dificultades relacionados con la producción de software y la competitividad que reclaman las organizaciones. Plantea la orientación a procesos y la adopción de una Arquitectura Orientada a Servicios, SOA por sus siglas en inglés, desde una perspectiva tecnológica.
XII relativamente discreto, lo que pudiera ser un reflejo del momento.
Resulta extremadamente riesgoso para el Ministerio del Interior adoptar una solución BPM sin una adecuada caracterización de las tecnologías subyacentes y sus posibilidades reales de integración con su entorno informático. Del inventario de Sistemas que tiene en producción, un monto importante ha sido implementado sobre el Sistema Gestor de Base de Datos Relacional Oracle con tecnología Microsoft .NET en la capa de aplicación; en ambas plataformas ha invertido un esfuerzo considerable de capacitación, adquiriendo una relativa fortaleza.
Por tanto el problema científico a resolver con esta investigación consiste en: ¿Cómo seleccionar tecnologías BPM que faciliten integrar los sistemas legados de una organización con sus nuevos procesos?
El problema planteado tiene como objeto de estudio: los módulos de integración de los sistemas BPM.
Se plantea como objetivo caracterizar los módulos de Integración de Procesos de los sistemas BPM BizTalk Server y Oracle SOA Suite con vista a su posible introducción en la práctica.
Siendo el campo de acción los módulos de integración de los sistemas BPM BizTalk Server y Oracle SOA Suite.
Para conducir la investigación se planteó la siguiente pregunta científica: ¿Cómo cumplen BizTalk Server y Oracle SOA Suite los criterios establecidos para facilitar la integración de los Procesos con los Sistemas legados de la organización?
Para la ejecución de la investigación y dar cumplimiento a sus objetivos se concibieron las siguientes tareas de investigativas:
Estudio del estado del arte de los módulos de integración de los sistemas BPM.
Estudio del estado de los lenguajes y estándares para la Orquestación de Procesos.
XIII Métodos Teóricos: Analítico – Sintético, Histórico-Lógico e Inductivo- Deductivo.
Asimilación de los módulos de Integración BizTalk Server y Oracle SOA Suite.
Asimilación de los lenguajes de orquestación disponibles en BizTalk Server y Oracle SOA Suite.
Integración de un proceso con sistemas legados típicos.
Validación de Indicadores Claves mediante su puesta en práctica.
Métodos Empíricos: Observación y Experimentación.
Posibles resultados a obtener:
Caracterización de los Sistemas Legados en el Ministerio del Interior.
Determinación de Indicadores Claves de mayor impacto a considerar para la integración con soluciones BPM.
Caracterización de los módulos de Integración de Procesos de los sistemas BPM BizTalk Server y Oracle SOA Suite.
Ha quedado establecido que el Ministerio del Interior necesita un impulso tecnológico de envergadura para mejorar la labor de enfrentamiento. Este trabajo, de culminar con éxito, que podrá servir de referencia para la adopción de una solución BPM adecuada, ajustada al contexto, lo que contribuirá positivamente a la implementación de la estrategia de Informatización trazada.
Por lo novedoso del tema en nuestro país, este resultado igualmente contribuirá a aportar conocimientos que ayuden a otras empresas que intentan adoptar estas tecnologías, pues la selección de una plataforma constituye un problema fundamental en la adopción de una solución BPM, debido a la gran variedad de productos y proveedores existentes y a las características particulares de nuestro país, donde un simple estudio de mercado no garantiza el éxito de una tecnología. Dejando por sentado la importancia y actualidad de esta investigación.
XIV
XV Capítulo 1: Fundamentación teórica. Se describen los resultados de la investigación sobre el estado actual en que se encuentran las tecnologías BPM, el énfasis se hace en aquellas relacionadas con la integración de procesos de negocios. Se puntualizan las definiciones de los principales componentes y sus interrelaciones.
Capítulo 2: Estudio de las herramientas. En este capítulo se describen las características resultantes del estudio de las capacidades de BizTalk Server 2006 y Oracle SOA Suite, se analizan sus arquitecturas y proyección hacia el área de la integración. Se hace un resumen del entorno Minint.
Capítulo 3: Resultados del estudio. Se analizan los resultados obtenidos a partir de la puesta en práctica de un caso de estudio típico del entorno Minint, que permitirá la asimilación de las tecnologías seleccionadas. Se describen los criterios identificados durante el estudio que facilitarán la evaluación de propuestas de otros proveedores. Se presentan valoraciones sobre la explotación de estas tecnologías en el Minint.
A continuación se exponen las conclusiones generales de la investigación y las recomendaciones; por último se encuentran los anexos y el glosario de términos empleados a lo largo del informe.
Para una mejor comprensión del documento se deben considerar las siguientes convenciones tipográficas adoptadas en su elaboración:
Se enfatizan las palabras que representan conceptos importantes la primera vez que se introducen.
Los términos en inglés se escriben en itálicas.
Se encierran en un recuadro sombreado las conclusiones parciales.
Las frases o definiciones citadas se encuentran encerradas “entre comillas”.
16
Capítulo 1
1.1 Introducción
En este capítulo se tratan los fundamentos teóricos que sustentan la investigación, se introducen los conceptos relacionados a las tecnologías BPM, la interrelación con SOA y los Bus de Servicios Empresariales, ESB por sus siglas en inglés, como herramienta que permite integrar sistemas a nivel de servicios, resaltando la alineación del negocio con la tecnología. Se presentan análisis de tendencias, estudios de las empresas líderes y el estado actual del mercado.
1.2 Conceptos básicos
Proceso de negocio
Un proceso de negocio se define como el conjunto de tareas relacionadas lógicamente, ejecutadas para lograr un resultado de negocio específico donde se involucran múltiples aplicaciones preexistentes y/o personas. Normalmente, estos procesos pueden modelarse como flujos (workflows) que especifican cómo deben colaborar entre sí las distintas entidades para llevar a cabo el proceso.
Fundamentación teórica
17
1.3 Gestión de proceso
Desde hace varios años, las áreas de sistemas en las empresas han estado sufriendo un cambio muy importante, están dejando de ser áreas técnicas, para convertirse en áreas de soporte y habilitación del negocio. Bajo el argumento de que “lo único constante es el cambio”, las empresas están siendo obligadas a ser ágiles y adaptarse rápidamente a los cambios en su entorno.
Para enfrentar un mercado tan competitivo como el actual y obtener ventajas en él, se requiere de un rediseño organizacional. Esto es posible, con la aplicación de las mejores prácticas en el desarrollo de una reorganización por procesos, que implica ganancia en agilidad a la atención de oportunidades, flexibilidad para adaptarse al cambio e integración de los procesos y las tecnologías de información. El enfoque de procesos redunda a su vez en mayor eficiencia en la toma de decisiones estratégicas para ubicar a la organización en el escenario actual y prepararse para el futuro.
Los procesos están implícitos dentro de una organización, ocultos dentro de una red de personas y sistemas que evolucionan a través de los años (Lira, 2005). Por esta razón los procesos son, frecuentemente, difíciles de definir formalmente, y como consecuencia se hace complejo para muchas organizaciones entender cómo funcionan exactamente, y más aún, trabajar para mejorarlos.
Uno de los aspectos para responder a estos problemas, ha sido un cambio en la forma en que las compañías están usando la gestión de los procesos. Estas buscan una manera diferente de mejorar los procesos de negocio, influenciando el uso de aplicaciones dedicadas a la captura, diseño e implementación de procesos a través de la organización.
18
1.4 Administración de procesos de negocios
La administración de procesos de negocios, es toda una filosofía de trabajo que coloca al proceso de negocio al centro de su universo, consiste en administrar el ciclo de vida de los procesos. Apoyándose en herramientas de automatización de flujo de trabajo, conocidos por Sistemas de Gestión de Proceso de Negocio o BPMS.
Por otro lado el Business Process Management Group (BPMG) ha establecido que BPM es “el enfoque deliberado y colaborativo para manejar sistemáticamente todos los procesos de negocio de una organización” donde sus dos facilitadores fundamentales son el pensamiento sistémico y las tecnologías de la información centradas en procesos.
1.4.1 Origen
A lo largo de los años se han propuesto varias iniciativas para que las empresas puedan lograr condiciones que permitan competir con mayores oportunidades. Desde la Gestión de Calidad Total (TQM) hasta Six Sigma, pasando por Reingeniería de Procesos de Negocio (BPR), Just in Time (JIT), Costeo Basado en Actividades (ABC), Kaizen, Supply Chain Management (SCM) y Balanced Scorecard (BSC). La tecnología de información(IT) ha estado presente con propuestas propias, que se remontan a la promesa de los Sistemas de Información Gerenciales (MIS) y la tecnología Cliente/Servidor hasta llegar a los ERP y los CRM, sin olvidar las soluciones Business to Business (B2B). Estas iniciativas no siempre dieron los resultados esperados. En este contexto, surge con mucha fuerza BPM que puede ayudar a consolidar todos los esfuerzos anteriores.
Siendo un concepto novedoso en origen, engloba un conjunto de productos y soluciones tecnológicas que han ido evolucionando en los últimos años. Ha emergido como el componente crítico que proporciona a las organizaciones la agilidad y flexibilidad necesarias para responder de forma rápida y productiva a las nuevas oportunidades y a los cambios de mercado.
19 1.4.2 Adopción
De acuerdo con el estudio de BPTrends de febrero de 2008, “The State of Business Process Management” (BPTrends, 2008), en el que participaron 274 ejecutivos de compañías de más de quince sectores de actividad en todo el mundo, el mercado de BPM continuó expandiéndose en el 2007 a medida que la mayoría de las organizaciones fue reconociendo el potencial estratégico de la gestión de procesos de negocio. También fue destacable un mayor interés en las suites de gestión de procesos de negocio como una alternativa más completa a la simple creación de modelos de procesos, de ahí la importancia que le concede Renato de Laurentiis Gianni, Director del Club BPM (Gianni, 2009), “la selección de la solución BPM no es fácil, es un procesos largo y complicado” y es considerado uno de los pilares en la adopción e implantación de BPM en las empresas como se muestra en la Figura 1.
Figura 1 Adopción de software BPM. Renato de Laurentiis, Informática 2009
Teniendo en cuenta la variedad de propuestas existente y su diferente grado de madurez, la diversidad de estándares propuestos y su adopción, hace que la selección de una herramienta BPM se convierta en una decisión estratégica para la organización.
20 1.4.3 Beneficios
La aplicación de BPM trae consigo una serie de beneficios para las empresas. Los casos en los cuales se ha utilizado el concepto, han reportado beneficios que van desde la mejora en las capacidades de dirección, pasando por la reducción de obstáculos al momento de reaccionar ante cambios del mercado, hasta adquirir mayor capacidad de análisis sobre el desempeño de la empresa. Los siguientes son otros beneficios identificados:
Visibilidad de los procesos de las empresas.
Mayor flexibilidad y agilidad para adaptación al cambio.
Posibilidad de integrar la información del negocio dispersa en diferentes sistemas.
Dirigir los esfuerzos de la empresa de una manera planeada y alineada con los objetivos estratégicos.
Es posible obtener rápidamente un retorno de la inversión.
Lograr estos beneficios es el resultado de la aplicación metódica de prácticas de gestión, de la implantación y adopción de formas de operar automatizadas y estratégicamente seleccionadas.
En definitiva las soluciones BPM facilitan que una compañía sea capaz de redefinir y automatizar sus procesos de negocio simplificándolos, acortando su duración y reduciendo el número de errores.
1.5 Sistemas de Administración de Procesos de Negocio
A finales de la década pasada aparecieron los primeros Sistemas de Administración de Procesos de Negocio o BPMS por sus siglas en ingles, que permiten a las organizaciones mapear, integrar, monitorizar, controlar, analizar y optimizar procesos de negocio de misión crítica que requieren ser integrados en una verdadera cadena de generación de valor para un cliente final y ligada directamente al logro de objetivos estratégicos.
21 Los BPMS surgieron de dos grupos de tecnologías fundamentalmente, las centradas en los procesos humanos que provenían del tradicional flujo de trabajo de actividades humanas y las centradas en la integración que involucraba las Aplicaciones de Integración Empresarial o EAI por sus siglas en inglés. Estas líneas continúan convergiendo en sus puntos fuertes y cada vez más fortalecen los BPMS actuales.
Figura 2. Surgimiento de los BPMS
Desde el punto de vista BPM, un BPMS es el principal facilitador para implantar un programa permanente de mejora continua en la práctica, ya que es difícil administrar sistemas tan complejos como son los procesos de negocio empresariales.
Desde el punto de vista técnico, un BPMS es una plataforma que permite integrar la infraes- tructura tecnológica existente en un ambiente que, a su vez, permite preservar los beneficios específicos de aplicaciones legadas. Al mismo tiempo, es un bloque de construcción esencial para un nuevo tipo de arquitectura, basada en estándares y orientada a servicios. (Silva, 2005).
22 1.5.1 Beneficios
Según Gartner (Gartner, 2009), “los BPMS entregan ventajas a corto plazo (tales como ahorros en coste y tiempo y de conformidad) y ventajas a largo plazo, incluyendo visibilidad en los procesos, agilidad para adaptarse a las necesidades cambiantes del mercado y del usuario, e incluso incrementar los beneficios”. Entre otros que listamos a continuación:
Automatización de tareas repetitivas.
Monitorización y gestión de los procesos.
Introducción rápida de nuevas aplicaciones.
Mayor alineación entre Negocio y Sistemas.
1.5.2 Componentes funcionales
Para clarificar el concepto, entendemos que los posibles elementos necesarios para disponer de un completo BPMS son los siguientes:
Herramientas de Análisis de Procesos de Negocios
Este componente permite el diseño gráfico de los procesos de negocio, de forma que pueda ser utilizada por los usuarios de negocio sin necesidad de conocimientos técnicos de programación y a su vez nos permite analizar el resultado de la introducción de datos, mediante la simulación de los procesos.
Motor de ejecución o de Workflow
También denominado genéricamente como motor BPM, este componente toma instrucciones de ejecución a partir de un repositorio que contenga el modelado del proceso. Debe ser capaz de controlar a lo largo del tiempo (días, semanas o incluso meses) el estado de cada una de las tareas de las diferentes instancias de cada proceso, es decir, debe ser capaz de gestionar el estado del proceso. En caso de interrupción de la ejecución de un proceso, debe ofrecer mecanismos de recuperación y reanudación.
23
Motor de Reglas
Este componente está muy relacionado con el motor de ejecución (muchas veces está embebido dentro del mismo) permite definir reglas de negocio o condiciones basadas en parámetros asociados al proceso. En función del resultado de ejecución de la condición el proceso evolucionará de manera diferente.
Servidor de Integración
Este componente implementa las interfaces con las diferentes aplicaciones o sistemas con los que se interactúa a lo largo del proceso. El motor de ejecución utiliza los servicios de este componente, bien para obtener información o bien para incluirla/actualizarla en los sistemas afectados. Este componente debe ofrecer las funcionalidades de mensajería, reglas de transformación y enrutamiento, conexión con sistemas externos.
Monitorización
Los productos de esta categoría ofrecen la posibilidad de analizar datos de la ejecución de los procesos de negocio en tiempo real, permitiendo identificar problemas como cuellos de botella, fallos de un sistema, entre otros, y tomar las acciones correctoras que sean necesarias.
Ofrecen indicadores predefinidos pero también permite desarrollar nuevos indicadores definiendo cómo se calculan, algunos mecanismos de extracción de la información de origen, período de actualización, etc.
1.5.3 Estado del Mercado
Desde su aparición, el mercado de los BPMS ha experimentado un continuo crecimiento, como señala un informe de Gartner (Gartner, 2007), que estima una tasa de crecimiento compuesta anual del 24% entre 2006 y 2011.
De acuerdo con encuestas realizadas en Estados Unidos, BPM ha tomado el primer lugar en la lista de prioridades de los directores de sistemas, por encima de iniciativas como outsourcing y seguridad en Tecnologías de la Información (TI) (Gartner, 2009).
24 El sector donde mayor adopción está teniendo los sistemas BPM hasta el momento, es el financiero. De acuerdo con cifras en Estados Unidos, 46% de los proyectos de BPM son en este sector, seguido por telecomunicaciones (12%), salud (10%), y gobierno (8%) (Gartner, 2007).
Los expertos del tema concuerdan en que los primeros productos que realmente pueden ser considerados como BPMS hicieron su aparición entre 1999 y el 2000, con la aparición de los llamados BPM pureplays, entre los cuales se encontraban proveedores como Savvion, Lombardi y Appian. Otros rápidamente se involucraron en la competencia estableciéndose como vendedores de sistemas de Workflow y de EAI, entre estos se encontraban TIBCO, Global 360, Pegasystems y BEA, sin embargo en estos momentos existen grandes proveedores de infraestructura, middleware y aplicaciones empresariales tales como IBM, SAP y Oracle que son considerados plataformas de procesos.
Realizando un estudio del mercado actual, buscando una tendencia mundial sobre las herramientas BPM, consultamos prestigiosas firmas de investigación como Gartner y Bruce Silver Associates, Los estudios que se tomaron como referencia fueron el realizado por Gartner Group (Gartner, 2009): que abarcó más de 22 proveedores de BPMS y el estudio realizado por Bruce Silver Associates (Silver, 2008) : que enroló a 11 de los principales líderes. Las figuras 3 y 4 muestran una parte del resultado del estudio:
25
Figura 3. Gartner: Análisis de Mercado de las Suites BPM, Q1 2009
Figura 4. BPMS ratings, integration-centric vs. human-centric BPM, Q2 2008
Es importante notar la coincidencia de los proveedores en ambos análisis. Los líderes más fuertes incluyen en su solución elementos importantes de integración.
26 Actualmente existen 30 o más fuertes proveedores de soluciones BPMS, pero según Bruce Silver Associates (Silver, 2008), existen dos categorías fundamentales donde se debaten los líderes de BPMS: los sistemas centrados en humanos human-centric, donde el proceso enfatiza en la tareas humanas y los centrados en la integración integration-centric (IC-BPMS), cuyo objetivo es mejorar la integración en el negocio, coordinando las acciones y los datos con otro grupo de sistemas que coexisten en el núcleo central de la empresa.
El mercado de los IC-BPMS según estudio de Forrester (Vollmer, 2008), en cuanto a funcionalidades y presencia en el mercado ubica los proveedores en dos categorías fundamentales:
Líderes: Estos proveedores brindan soluciones integrales donde incluyen las funcionalidades que involucran a los IC-BPMS.
Fuertes Ejecutores: Mientras otros proveedores ofrecen fuertes capacidades generales en sus suites, estos presentan algunas limitaciones en el área de BPM.
Figura 5. Forrester Wave™: Integration-Centric Business Process Management Suites, Q4 ‟08
27 1.5.4 Estándares utilizados por los BPMS
Los estándares son definiciones obtenidas por consenso que aprueban, reconocen y promueven organizaciones internacionales para el intercambio de información o del conocimiento. Generalmente estos organismos están formados por el conjunto de empresas más representativas de un sector o de un campo de la producción. Los estándares permiten que las industrias desarrollen componentes con las garantías suficientes de: interoperabilidad, funcionalidad y calidad. Ayudan a desarrollar los bloques básicos sobre los cuales pueden ser construidos desarrollos tecnológicos. Los estándares son extremadamente importantes en la computación, ya que permiten que se combinen productos de diferentes fabricantes para el desarrollo de sistemas, tanto de software como de hardware.
Sin estándares, solo los productos de una misma compañía podrían ser utilizados de forma conjunta. Actualmente existen estándares para diversos protocolos de comunicación con, formatos de datos, lenguajes de programación, etc. Los organismos más importantes de estandarización son: ANSI, IEEE, ISO y W3C.
En torno a BPM algunas organizaciones de estandarización de procesos definen numerosos estándares como son: OMG (BPMN, BPDM), WfMC (XPDL), OASIS (BPEL, ebXML). Son pocos los que se han impuesto (entre ellos los antes mencionados), mientras que la gran mayoría (como BPML o WSFL) han quedado en desuso.
Analizando BPMS Report Series (Silver, 2008), algunos de los reportes de empresas líderes del mercado, se puede constatar cuan apegados se encuentran a los estándares. La siguiente tabla muestra un análisis de estos reportes con el objetivo de determinar el impacto que estos tienen sobre el mercado de adopción de los BPMS.
28
Tabla 1. Adopción estándares BPMS.
1.5.5 Propuestas de código abierto
Según el artículo de Neil McAllister (McAllister, 2006) hay muchos proyectos de código abierto o open source actualmente en curso, como JBOSS, Enhidra, etc. Sin embargo, al decir de Renato de Laurentiis Gianni, Intalio parece ser el más destacado y avanzado (Gianni, 2009). Es un producto open source en el que ofrecen su código, y posee una versión Community bajo la licencia Community Edition license, la cual se puede descargar del sitio oficial de forma gratuita pero no comprende la suite completa.
1.6 Arquitectura Orientada a Servicios
Con el surgimiento de XML se han desarrollado estándares encaminados a resolver la interoperabilidad de los sistemas, como los servicios web con SOAP (Simple Object Access Protocol). Esto permite que las aplicaciones expongan su funcionalidad como un conjunto de servicios reutilizables y preparados para colaborar entre ellos. También surge la necesidad de independencia del proveedor, abordar la diversidad tecnológica y protección a la inversión existente en las aplicaciones empresariales. Este es el concepto clave de SOA: exponer la funcionalidad de las aplicaciones con servicios estándares con XML que se puedan utilizar de forma ágil para lograr la flexibilidad tecnológica demandada por la dinámica de los procesos de negocio. Por lo tanto:
Resaltan en el análisis la utilización por parte de los líderes del binomio BPMN-BPEL tal y como recomienda el BPMI (Business Process Management Initiative).
29 SOA es un estilo arquitectónico que soporta servicios débilmente acoplados para permitir flexibilidad al negocio de una forma interoperable y tecnológicamente agnóstica. SOA consiste en un conjunto de servicios alineados con el negocio que soportan la realización de los procesos de negocios de principio a fin de forma flexible y dinámicamente reconfigurable usando descripciones de servicios basado en interfaces.
1.6.1 Evolución
En los primeros tiempos, cada compañía tenía su ordenador central (mainframe) donde se ejecutaban todas las aplicaciones de la compañía. La interoperabilidad de aplicaciones se realizaba mediante transferencia de datos en modo batch. Primero mediante envíos de ficheros y posteriormente, en algunos casos, mediante la interconexión de bases de datos.
Más recientemente, empezaron a surgir formas más sofisticadas de integración. Empezando por RPC (Remote Procedure Call), a lo largo del tiempo han surgido mecanismos como DCOM, CORBA, COM+, .NET Remoting, RMI. SOA es el último estadio en ese camino. Sobre todos los anteriores surge el concepto de SOA que se centra, de forma diferencial, en conceptos de negocio en vez de conceptos tecnológicos.
Figura 6 Evolución de las arquitecturas de integración.
30 1.6.2 Beneficios
Basado en estándares ampliamente adoptados: a diferencia de los anteriores mecanismos de integración, SOA se basa en estándares soportados por prácticamente la totalidad de la industria.
Abstracción de la tecnología: los servicios son independientes de la tecnología que los implementa.
Reducción de la complejidad de integración: al estar basado en estándares y abstraer la integración de la tecnología, la complejidad de la integración se reduce.
Rehúso: las arquitecturas SOA se basan en un nivel de reutilización sin precedentes. Debido a un factor clave: la existencia de un catálogo o repositorio.
1.7 Servicio
Un servicio representa una función claramente definida que puede ser invocada remotamente mediante protocolos de comunicación estándar. Se definen mediante interfaces explícitas que son totalmente independientes de la implementación del servicio y deben poder ser invocados utilizando protocolos de comunicación estándar que enfatizan la interoperabilidad e independencia de ubicación. Si los servicios exponen funcionalidad de negocio clave para la organización entonces podemos decir que se trata de servicios de negocios.
1.7.1 Servicios web
Tradicionalmente se han utilizado diversas alternativas para intercomunicar sistemas: sockets, acceso directo a las bases de datos, o mecanismos como RMI, CORBA o DCOM, con los cuales es posible lograr la interoperabilidad deseada, pero a costa de un alto acoplamiento.
Esta situación llevó a las principales empresas de la industria a trabajar en conjunto para definir un grupo de estándares que permitiera homogeneizar la forma en que los sistemas
31 interactúan a través de servicios. Este conjunto de especificaciones definen lo que conocemos como servicios web, y son administradas por organismos de estándares como el World Wide Web Consortium (WC3), OASIS y WS-I.
Precisamente la W3C lo define como “un componente de software funcional o aplicación web identificada a través de un URI, cuya interfaz y uso es capaz de ser definida, descrita y descubierta mediante artefactos XML, la cual además soporta interacciones directas con otras aplicaciones de software usando mensajes XML y protocolos basados en Internet” (W3C, 2004).
La arquitectura sobre la cual descansa todo servicio web es mostrada en la figura 7. Veamos entonces cuáles son los elementos que participan en esta y cuáles son sus relaciones.
Figura 7. Arquitectura de servicios web mostrando la vinculación de las tecnologías que la componen.
Concretamente las características principales de los servicios web pueden ser resumidas en los siguientes puntos.
1. Son accesibles a través de la web. Gracias a la utilización de protocolos de transporte estándares como HTTP y la codificación de sus mensajes en SOAP, lenguaje estándar basado en XML.
32 2. Son interoperables. Debido a que los servicios pueden interactuar independientemente
de la plataforma o lenguaje de programación en el cual hayan sido desarrollados.
3. Se describen a sí mismos. De esta forma una aplicación conocería cual es la interfaz del servicio y podría integrarlo y utilizarlo de manera automática. Dicha interfaz debe ser escrita en WSDL, el cual (al igual que SOAP) es un lenguaje basado en XML.
4. Son localizables. Mediante el uso de un repositorio de servicios web, mismo que permitiría que los servicios sean almacenados, publicados y descubiertos por distintas aplicaciones. Actualmente los nodos UDDI representan la tecnología más utilizada.
1.7.2 Estándares utilizados por los servicios web
Los servicios web se construyen sobre estándares y a su vez pretenden ser un estándar mediante el cual sea posible construir sistemas a partir de piezas heterogéneas, desarrollas por diversos fabricantes, funcionando en distintos sistemas y construidas con distintas tecnologías. Los principales estándares para el desarrollo de servicios web son XML, WSDL, SOAP y UDDI
HTTP/HTTPS: es el protocolo estándar, genérico y sin estado, que utilizan los WS como mecanismo de comunicación. Aunque pueden utilizarse otros protocolos, la gran mayoría de las implementaciones se basan en este.
XML: es la base de los WS. XML ha revolucionando la comunicación entre aplicaciones. Ofrece un formato de datos que permite adaptar o transformar fácilmente la información. Los mensajes en los que se basa la arquitectura SOA se envían en este formato, estándar y neutral, a la plataforma, distribuido a través de las interfaces.
WSDL (Web Service Definition Language): Define las reglas que deben de seguir los documentos que describen un servicio web. Estos documentos contienen información como tipos de datos, mensajes y protocolos soportados por el servicio.
33 UDDI (Universal Description, Discovery and Integration): Es un mecanismo para encontrar servicios web. Si tomamos en cuenta que cualquier persona puede escribir un servicio y publicarlo, entonces nos enfrentamos a la necesidad de contar con un directorio que nos permita tanto publicar como buscar los servicios que nos interesan.
SOAP (Simple Object Access Protocol): Ofrece los mecanismos de comunicación básicos para el envío de mensajes en formato XML, permitiendo la invocación remota de servicios.
1.7.3 Servicios REST
La Transferencia de Estado Representacional o REST por sus siglas en ingles, fue ganando amplia adopción en toda la web como una alternativa más simple a SOAP y a los servicios web basados en el WSDL. Ya varios grandes proveedores de Web 2.0 están migrando a esta tecnología, incluyendo a Yahoo, Google y Facebook.
REST define un conjunto de principios arquitectónicos por los cuales se diseñan servicios web haciendo foco en los recursos del sistema, incluyendo cómo se accede al estado de dichos recursos y cómo se transfieren por HTTP hacia clientes escritos en diversos lenguajes.
Una implementación concreta de un servicio web REST sigue cuatro principios de diseño fundamentales:
Utiliza los métodos HTTP de manera explícita.
No mantiene estado.
Expone URIs con forma de directorios.
Transfiere XML, JavaScript Object Notation (JSON), o ambos.
No siempre REST es la mejor opción. Está surgiendo como una alternativa para diseñar servicios web con menos dependencia en middleware propietario, que su contraparte SOAP y los servicios basados en WSDL. De algún modo, REST es la vuelta a la Web antes de la aparición de los grandes servidores de aplicaciones, ya que hace énfasis en los primeros estándares de Internet, URI y HTTP.
34 REST ayuda a cumplir con los requerimientos de integración que son críticos para construir sistemas en donde los datos tienen que poder combinarse fácilmente (mashups) y extenderse y dar paso a algo mucho más global.
1.8 Software como Servicio
El Software como un Servicio o SaaS por sus siglas en ingles, es un modelo de distribución del software que proporciona a los clientes el acceso al mismo a través de la red (generalmente Internet), de manera que les libra del mantenimiento de las aplicaciones, de operaciones técnicas y de soporte. Las aplicaciones distribuidas en la modalidad SaaS pueden llegar a cualquier tipo de empresa sin importar su tamaño o su ubicación geográfica. Se trata de un modelo que une el producto (software) al servicio, para dotar a las empresas de una solución completa que permita optimizar sus costes y sus recursos.
Nos referimos a elementos como:
El foco es el servicio frente a hablar de tecnología, aplicaciones, etc.
Los clientes pasan a ser virtuales.
Hablamos de plataformas de N clientes.
El cliente sale claramente beneficiado del modelo:
o Menor coste e inversión inicial.
o Menor riesgo.
o Alta escalabilidad asegurada.
o El cliente se centra en el negocio.
o Aumenta la seguridad.
o La respuesta ante los cambios es muy rápida.
En palabras simples: El cliente tiene el sistema hospedado en la compañía de TI.
35 Algunos inconvenientes de SaaS:
Los clientes no tienen acceso directo a sus contenidos, ya que están guardados en un lugar remoto, y en caso de no contar con mecanismos de cifrado y control disminuye el índice de privacidad, control y seguridad que ello supone, ya que la compañía de TI podría consultarlos.
El usuario no tiene acceso al programa, por lo cual no puede hacer modificaciones (dependiendo de la modalidad del contrato de servicios que tenga con la compañía TI).
Al estar el servicio y el programa dependientes de la misma empresa no permite a la usuaria migrar a otro servicio utilizando el mismo programa (dependiendo de la modalidad del contrato de servicios con la compañía de TI).
1.9 Computación en la nube
Actualmente se habla mucho sobre que los datos no se encuentren en nuestros equipos ni dependan de un sistema operativo local, sino que se encuentren en la red (en las nubes, the cloud). Definido de otro modo, el la computación en la nube o Cloud computing va en la dirección esencial de ofrecer el soporte y la infraestructura de despliegue también como un servicio, basando las aplicaciones en servicios alojados de forma externa, en la propia web. Una de las principales cualidades del Cloud Computing es que no hay necesidad de conocer la infraestructura detrás de esta, pasa a ser “una nube” donde las aplicaciones y servicios pueden fácilmente escalar y funcionar sin conocer los detalles del funcionamiento de la misma.
36
Figura 8 Cloud computing
Entre las ventajas de la Cloud Computing se pueden mencionar:
Acceso a la información y los servicios desde cualquier lugar.
Servicios gratuitos y de pago según las necesidades del usuario.
Empresas con facilidad de escalabilidad
Capacidad de procesamiento y almacenamiento sin instalar máquinas localmente.
Entre las desventajas podemos mencionar:
Acceso de toda la información a terceras empresas.
Dependencia de los servicios en línea.
La desventaja fundamental del Cloud Computing es precisamente la Cloud. Las aplicaciones son independientes de del sistema operativo o de las especificidades del ambiente de una organización, pero dependen de la conectividad. La inaccesibilidad a la red es una realidad para muchas personas, para ellas no hay Cloud Computing.
37
1.10 Mashup
La Web 2.0 ha liberado una era de participación online, personalización e interoperabilidad puestas a cambiar la forma en que nos interconectados, hacemos negocios e interactuamos con los medios que nos absorben. Uno de los desarrollos más recientes en el entorno de la web 2.0 es el de los llamados mashup. El término mashup puede parecer un poco confuso, ya que tiene más de un significado.
Figura 9 Mashup
Una aplicación web híbrida (mashup o remezcla) es una aplicación web que usa el contenido de otras aplicaciones web para crear un nuevo contenido completo, consumiendo servicios directamente, siempre a través del protocolo http.
38 Al ser componentes, los servicios web pueden verse como cajas negras con la capacidad de ser utilizadas y reutilizadas sin necesidad de conocer como fue implementada su funcionalidad.
Dicha propiedad facilita la composición de servicios.
1.11 Orquestación de servicios web
La orquestación de servicios web es un área de gran interés debido a que ésta permite que aplicaciones de negocios heterogéneas puedan comunicarse y acoplarse en una nueva solución para obtener un mayor potencial en su funcionalidad.
El proceso de orquestación consiste en “relacionar, organizar y administrar las interacciones entre los servicios web referentes a la lógica del proceso de negocios” (Peltz, 2003).
En la Figura 10, podemos observar gráficamente como se lleva a cabo la orquestación de servicios web, donde el rectángulo mayor representa el proceso que orquestará los servicios web y los rectángulos sombreados pequeños las actividades involucradas en el mismo, las flechas horizontales el flujo de datos intercambiado y las flechas verticales el flujo de control del proceso.
Figura 10. Orquestación de Servicios web
Al orquestar servicios, necesitaremos elegir un lenguaje de coordinación que cumpla con un conjunto de características deseables para coordinar correctamente los componentes
39 involucrados. Dicho lenguaje debería ser simple, abstracto, dar soporte a enlace dinámico de recursos y a actividades primitivas y estructuradas y además debería garantizar persistencia y correlación a lo largo de las transacciones del flujo (Peltz, 2004).
1.12 Lenguaje para la Ejecución de Procesos de Negocio
El Lenguaje para la Ejecución de Procesos de Negocio o BPEL4WS por sus siglas en ingles, es un lenguaje basado en XML que define cómo los procesos de negocio interactúan entre las organizaciones. La especificación inicial de BPEL 1.0 fue propuesta conjuntamente por IBM, Microsoft y BEA en Agosto de 2002, para luego ser actualizada a la versión 1.1 en Mayo del 2003.
En marzo de 2007 se aprobó la especificación de Web Services Business Execution Language versión 2.0. (WS-BPEL 2.0. o simplemente BPEL), el cual es usado para especificar procesos automáticos de negocio que orquestan actividades de múltiples servicios web, sin embargo BPEL fue diseñado apuntando a las interacciones “sistema-a-sistema”, y en esencia no define mecanismos para interactuar con personas.
En ese sentido, IBM y SAP propusieron una extensión a BPEL denominada BEL4People, cuyo objetivo es cubrir una variedad de escenarios que involucran interacciones con personas en workflows de procesos de negocio.
BPEL4People se define como una extensión a lo que es el lenguaje BPEL. Permite ampliar el estándar incorporando nuevas características en caso de ser necesario, para incorporar la participación humana.
40 1.12.1 Deficiencias
1. No soporta transparencia de localidad de recursos. Esto quiere decir que la ubicación de los servicios debe ser explícitamente especificada en el proceso, debido a que BPEL fue concebido como un sistema para ambientes distribuidos. Dicha limitante resta claridad a la descripción del flujo a ser orquestado y dinamismo en el cambio de componentes.
2. Solo permite la invocación de métodos que sean provistos por un servicio web. Es decir, alguna funcionalidad local o propia al servicio que orquesta no puede ser descrita a menos que esta sea implementada como un método de un servicio web.
3. No es suficientemente modular. Debido a que la incorporación de requerimientos no funcionales como el manejo de excepciones, el logging o el control de acceso, afectaría diversos puntos de la especificación de un proceso.
1.13 Integración de Aplicaciones Empresariales
La integración de aplicaciones, es la necesidad en la empresa de unificar diversos sistemas, así como comunicarse con otras empresas para lograr un negocio objetivo de forma fiable, independientemente de la plataforma y la localización geográfica.
Se entiende por Integración de Aplicaciones en la Empresa al uso de metodologías, principios y tecnologías para hacer trabajar de forma conjunta, o integrada, las aplicaciones generalmente del entorno de los sistemas en la empresa.
41 1.13.1 Niveles de Integración
No existe una forma única de integración adecuada a todas las situaciones, por el contrario, a lo largo de los años se han desarrollado diferentes formas de integración, adecuadas a diferentes necesidades. Si bien no hay una taxonomía estándar, los siguientes son tipos de integración generalmente aceptados:
1. Integración Orientada a los datos:
Consiste en el pasaje de datos de un sistema a otro. Típicamente, la integración orientada a los datos no requiere modificaciones en las aplicaciones integradas, sino solamente la implementación del mecanismo de pasaje de datos entre los repositorios de las aplicaciones respectivas; esto hace que sea la forma de integración más simple y de menor impacto. No necesariamente esto implica que tal integración se realice pura y exclusivamente usando tecnología de base de datos. También podría realizarse mediante archivos planos, API de las aplicaciones, o incluso servicios de mensajería.
Figura 11. Integración Orientada a los datos.
2. Integración Orientada a Procesos:
Una de las características más importantes de los sistemas cuando se está desarrollando una solución de integración es que una transacción del negocio tiene lugar en diferentes sistemas.
42 En la mayoría de los casos, cuando requerimos integrar, la mayor parte de la funcionalidad ya se encuentra incorporada a sistemas existentes. Lo que queda faltando es la coordinación de todas las aplicaciones para llevar a cabo la transacción. Para esto, es posible agregar un componente encargado del manejo del proceso de negocio, que coordine la ejecución de una transacción a lo largo de los sistemas existentes.
Figura 122 Integración Orientada a Procesos
3. Integración Orientada a Servicios:
En este modelo, una aplicación expone una serie de servicios de negocio que pueden ser usados por otras aplicaciones. Se busca hacer que cierta lógica de negocio sea implementada una única vez en la empresa, y reutilizada el resto de las veces.
Dependiendo de la heterogeneidad tecnológica puede ser recomendable la utilización de un bus de servicios. Mediante el cual se coordina la ejecución de los distintos servicios existentes dentro o fuera de la empresa, en tecnología SOAP fundamentalmente, pero también con capacidad de invocar servicios en otras tecnologías. La arquitectura de bus será explicado más ampliamente en la sección 1.14.4
43
Figura 13 Integración Orientada a Servicios
4. Integración Orientada a los Portales:
Los portales visualizan información de diferentes sistemas en una sola vista, que se necesitan en un momento dado para realizar una función del negocio. Es presentada en múltiples zonas, cada una de ellas conteniendo información de un sistema diferente. Aún más, muchos de estos portales proveen cierta interacción, en el sentido de que la selección de un elemento en una zona, actualiza otra con información relacionada al elemento elegido.
Figura 14 Integración Orientada a Portales
1.14 Arquitectura de integración de aplicaciones
EAI comprende entre otros elementos mensajes de aceptación, transformaciones, traducción, enrutamiento, mensajes de entrega y gestión de procesos empresariales. Por lo general, los mensajes se transportan de forma asíncrona, aunque en dependencia de la solución puede realizarse sincrónicamente. Existen dos arquitecturas fundamentales para lograr este intercambio de mensajes, la arquitectura de Hub/Spoke y de Bus, que básicamente se basan en el uso de los adaptadores y el uso de sistemas de mensajería.
44 1.14.1 Adaptadores
La conexión con los servicios proporcionados por las aplicaciones se lleva a cabo a través de los conectores o adaptadores de cada aplicación. El adaptador es una pieza que puede ser suministrada por el fabricante, desarrollada por una tercera empresa o desarrollada a medida tomando como base el kit de desarrollo ofrecido por el fabricante. La mayoría de sistemas EAI incluyen adaptadores pre-construidos fácilmente configurables para algunos casos:
Servicios web, CORBA.
Aplicaciones de fabricantes populares: ERPs, CRMs, CMSs.
Para el resto de aplicaciones (normalmente un elevado porcentaje), es necesario programar de forma manual todo o parte del adaptador implementando alguna interfaz.
El adaptador se particulariza para cada aplicación al incorporar el mecanismo por el cual establece contacto y accede a los servicios que la aplicación quiere exponer.
1.14.2 Servicio de mensajería
La mensajería es una tecnología que permite comunicaciones de alta velocidad, asíncronas, entre programas y con una entrega confiable. Las aplicaciones se comunican entre ellas enviándose paquetes llamados mensajes. Los canales, o colas, son caminos lógicos que conectan a las aplicaciones y transportan los mensajes. El remitente o productor es una aplicación que envía un mensaje escribiéndolo en el canal. El destinatario o consumidor es una aplicación que recibe un mensaje leyéndolo y borrándolo del canal.
Un sistema EAI requiere de funcionalidades de creación, envío y recepción de mensajes y un grupo de funcionalidades como:
Garantía de entrega, de orden de mensajes.
Garantía de integridad y privacidad de mensajes.
Notificaciones de error.