Posts Tagged ‘SOA’

h1

Suites de Gestion de Procesos de Negocio de Codigo Abierto: el caso Mexicano

03/28/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

[Se ha estimado] que el proceso de negocio como servicio (BPaaS) y el mercado de BPM en la nube crecerán en valor desde USD 1 mil millones en 2013 hasta 7,120 millones de dólares en 2018.

The next evolution of BPM. Lance Harris. (Business Technology News and Information, 2013).

Hace algunas semanas nuestro country head me encargó encontrar los BPMS (Business Process Management SuitesSuites de Gestión de Procesos de Negocio) de mayor uso en México, y si entre éstos existe una opción basada en código abierto lo suficientemente competitiva como para incluirla dentro de nuestra oferta de servicios. Los resultados se obtuvieron en su mayoría a partir de información encontrada libremente en la web, por lo que me es posible compartir una buena parte de éstos:

Esta investigación presenta las opciones más utilizadas para el software de código abierto con respecto a Business Process Management Suites (BPMS) en México. Los resultados se presentan tomando en cuenta que el software BPMS es poco utilizado en México y el resto de América Latina. El conjunto de opciones mostradas a continuación está pensado principalmente con la finalidad de fomentar la evaluación de opciones de código abierto durante la generación de nuestras propuestas de solución y servicios. Se entiende que el mercado de software, especialmente la rama de código abierto, es un entorno de desarrollo muy dinámico y las opciones que figuran en este documento pueden quedar obsoletas rápidamente. Aun así, esta lista tiene como objetivo ser de utilidad para los clientes potenciales que consideren el código abierto como una opción, y para ayudar a darle mayor credibilidad y seguridad a nuestras propuestas.

Contexto

Típicamente, los beneficios del software de código abierto incluyen precios más bajos de adquisición, bajos o nulos costes de licencia, interoperabilidad, así como integración y personalización fácil de implementar; menos barreras para la reutilización, conformidad con los estándares abiertos de tecnología y datos que dan autonomía sobre su propia información. Finalmente, proporciona la posibilidad de no tener que “casarse” con un proveedor determinado.

El código abierto es poco o en absoluto utilizado en las organizaciones mexicanas de gran tamaño. Los integradores de sistemas y fabricantes no consideran al software de código abierto para sus soluciones de TI. Esto se puede demostrar en el Cuadrante Mágico de Gartner para BPMS (2010):

pic: Magic Quadrant for Business Management Suites (Oct 2010)

Cuadrante Mágico de Gartner para suites de gestión de procesos de negocio (Octubre 2010). (Fuente: avoka.com)

De entre 27 opciones diferentes, sólo una (Intalio) es de código abierto. Éste cae dentro del grupo de visionarios.

Hay importantes obstáculos al código abierto en México. Algunos de ellos incluyen una falta de una orientación clara para su adquisición, resistencia por parte de los proveedores, preocupaciones sobre las obligaciones de licenciamiento y – desde que el TLCAN comenzó su existencia hace más de 20 años – el tema de las patentes, malos entendidos acerca del proceso de acreditación de seguridad y mitos alrededor de la calidad y el soporte técnico del código abierto.

Cómo interpretar este documento

Este documento presenta el software de código abierto para ser considerado en nuevas soluciones BPM que cumplan con los requerimientos del negocio, o como sustitutos de software propietario ya existente. Se ofrecen varias opciones sobre la base de las implementaciones ya liberadas en el mercado mexicano hasta marzo de 2014. Este conjunto de opciones se puede utilizar para:

• Informar durante el diseño de nuevas soluciones de TI.

• Sugerir oportunidades de TI de servicios o soluciones nuevas.

• Retar propuestas de solución que no utilicen las tecnologías de código abierto.

El criterio general para que un software de código abierto sea listado entre las opciones sugeridas es que debe existir una oportunidad real para su uso. Un uso significativo y probado es un factor clave, en el que “probado” puede significar:

• Uso a gran escala, volumen o en escenarios de alto rendimiento.

• Uso en funciones críticas, tales como salud o seguridad.

• Historial de uso, de preferencia durante muchos años.

Uso de los BPMS

La mayoría de los proveedores de BPMS proporcionan análisis de procesos, diseño y herramientas de modelado de flujos de trabajo dentro de sus suites.
Por otro lado, la mayoría de las organizaciones optan por invertir en BPMS porque necesitan apoyo para un programa de mejora continua de procesos, el apoyo a un proyecto de transformación de negocios, y/o el middleware necesario para implementar una arquitectura orientada a servicios (SOA). Las organizaciones también pueden buscar adoptar un BPMS para guiar el proceso de implementación de una solución de procesos específica.

Las soluciones BPM han sido adoptadas principalmente por los organismos financieros, donde la visibilidad y la adherencia a las regulaciones de cumplimiento son una parte integral de este sector (por ejemplo, la ley Sarbanes-Oxley). BPM también se ha aplicado en las organizaciones de servicios donde la productividad y la eficacia del personal desempeñan un papel clave en el rendimiento del proceso. La mayoría de las organizaciones deciden adoptar BPM porque prevén que los cambios en sus procesos se producen con frecuencia. Sin embargo, muchas organizaciones también están comenzando a ver más allá de BPM como un simple documentación y rastreo de procesos, considerándolo como una oportunidad para transformar su negocio, mejorar los procesos y reducir costos.

Adopción de los BPMS

La mayoría de las herramientas y software de BPM utilizados hoy en día son productos comerciales caros. El mercado está siendo liderado por IBM (Lombardi) y Oracle (Oracle BPM 11g), acaparando más de la mitad de la cuota de mercado. Sólo un pequeño porcentaje (aproximadamente 15%) de las empresas en México han adoptado una solución de código abierto para BPMS. Estos están dirigidos por Intalio y jBPM de JBoss. Otros jugadores incluyen BonitaSoft, ProcessMaker y Activiti, que representan una pequeña fracción de la cuota de mercado. Estos tres son adoptados en su mayoría por organizaciones pequeñas y medianas (PYMEs).

BPMS Clientes
IBM Afore Banamex, CaixaBank, Financiera Independencia, GNP Seguros, AXA Seguros, Coca-Cola, Redpack, Telcel
Oracle AXA Financials, Banamex Gpo. Financiero, Bimbo, Comex, Nextel, Movistar, Cablemas, Televisa, Casas GEO
Intalio Sky, Santander, Samsung de México, Costco, Sears de México, DHL
JBoss jBPM BBVA, Toyota, Grupo Posadas
BonitaSoft DirecTV, Xerox (gestión de documentos)
ProcessMaker Banregio, Mexbrit, Lenovo LatAm
Activiti CONACyT (Gobierno Mexicano)

Principales clientes de las suites BPM más utilizadas en México. Los clientes fueron obtenidos de las páginas web de cada proveedor.

Por qué código abierto y cuáles son los retos para su adopción

Antes de cualquier otra consideración, el principal motivo de adopción de una solución de código abierto u open source consiste en los costos de licenciamiento y servicios profesionales necesarios para su implementación. Los productos comerciales se encuentran en el orden de USD 250,000 por implementación, generalmente a través de pagos por adelantado. Por el contrario, las herramientas BPM de código abierto están atrayendo más atención en el mercado debido a los posibles ahorros en costos y términos de licenciamiento más flexibles. Los usuarios también pueden ampliar las prestaciones de los productos y su escalabilidad sin costes adicionales. En caso de que la solución requiera una personalización específica o corrección de bugs, es posible buscar la ayuda de un tercero o de la comunidad open source, en lugar de esperar los lentos tiempos de respuesta de los proveedores comerciales.

Los principales retos a los que se enfrenta cualquier adopción BPMS se enumeran a continuación:

• Fuerte dependencia de operadores que realizan sus tareas de forma manual, sin automatización ni flexibilidad para satisfacer las cambiantes necesidades del negocio.

• Falta de procesos y prácticas bien documentadas.

• Escasa colaboración en equipo; todo se hace a través de correo electrónico y llamadas telefónicas. Los documentos son almacenados en formato físico (hard-copy).

• Los proveedores actuales se centran en el departamento IT para proveer las necesidades de BPM de la organización; en realidad, BPM debería ser responsabilidad del área de negocios.

• Muchas organizaciones están centradas en datos (data-centric) en lugar de estar centradas en el proceso (process-centric).

• A menos que el cumplimiento normativo o de continuidad del negocio sean un factor, muchas organizaciones siguen un crecimiento orgánico, dejando la gestión de procesos en un segundo plano.

• Falta de confianza en BPM. Muchas organizaciones esperan resultados verificables en menos de 6 meses desde la adopción de BPM.

Principales Suites BPM Open Source

Intalio

Intalio es una plataforma de procesos de negocio de código abierto construido alrededor del modelador BPMN STP de Eclipse y el motor Apache ODE BPEL 2.0, ambos originalmente aportados por Intalio. La versión Enterprise proporciona los componentes necesarios para el diseño, la implementación y la gestión de varios procesos de negocio, tales como:

• BRE (Business Rules Engine – Motor de reglas de negocio).

• BAM (Business Activity Monitoring – Monitoreo de Actividades de Negocio).

• Portal.

• ESB (Enterprise Service Bus – Bus de Servicios Empresarial).

• ECM (Enterprise Content Management – Gestión de Contenidos Empresarial).

Intalio está disponible en varias ediciones, pero la versión relevante para este documento es la edición de comunidad libre (free community edition) de Intalio. Ésta se compone de dos módulos: Intalio Designer e Intalio Server. Intalio Designer permite el modelado de los procesos para ser eventualmente desplegados en el Intalio Server. Intalio Designer permite que modelos BPMN se conviertan en procesos BPEL ejecutables. De acuerdo a la filosofía de Intalio, el área de negocio podría generar, editar y ejecutar los procesos, sin requerir de un desarrollador técnico para traducir la visión de negocio en código.

JBoss jBPM

jBPM es una plataforma de código abierto para diferentes lenguajes de procesos ejecutables que van desde la gestión de procesos empresariales (BPM) hasta el flujo de trabajo para la orquestación de servicios. jBPM admite tres lenguajes de proceso diferentes. Cada uno de ellos está dirigido a una función y entorno específico:

• jPDL (lenguaje de definición de proceso propio de JBoss).

• BPMN 2.0

• Pageflow

jBPM genera todos estos lenguajes de proceso de forma nativa en la parte superior de la Máquina Virtual de Procesos (Process Virtual Machine – PVM). Así mismo, jBPM es independiente de las bases de datos, servidores y es integrable en otras aplicaciones (embeddable). Finalmente, esta suite es altamente personalizable – desde el punto de vista de los desarrolladores.

jBPM es modular. Funciona con el middleware empresarial de JBoss o cualquier otra plataforma de middleware que cumpla con la especificación Java EE. Está disponible a través de suscripciones que incluyen software certificado, soporte por industria, actualizaciones y parches, documentación y política de mantenimiento de varios años. El modelador es una aplicación Java estándar y no necesita un servidor de aplicaciones; las empresas que estén interesadas en jBPM pueden utilizarlo sin añadir más complejidad. Los formularios que pertenecen a los procesos modelados pueden implementarse como aplicaciones web o aplicaciones de escritorio (standalone) en Java.

Bonita Open Solution

Bonita BPM es un gestor de procesos de negocio de código abierto y suite de modelado de flujos de trabajo, creado en el 2001. El proyecto se inició en el Instituto Nacional de Investigación en Informática y Automática (Francia), para luego incubarse por varios años en el interior de la empresa informática francesa Groupe Bull. Desde 2009, el desarrollo y soporte de Bonita es realizado por Bonitasoft, una empresa creada específicamente para esta actividad.

Bonita consta de tres módulos principales:

• Bonita Studio: permite al usuario modificar gráficamente los procesos de negocio siguiendo el estándar BPMN. El usuario también puede conectar los procesos a otras piezas del sistema de información (tales como mensajería, planificación de recursos empresariales, administración de contenido empresarial y bases de datos) con el fin de generar una aplicación de negocio autónoma, accesible como un formulario web. Bonita Studio también permite al usuario diseñar gráficamente las formas que se mostrarán al usuario final con el fin de interactuar con el proceso. Por otra parte, el modelador permite al usuario empezar a trabajar con procesos diseñados con otros estándares y tecnologías como XPDL o jBPM. Se basa en Eclipse.

• Bonita BPM Engine: El motor de BPM es una API Java que permite al programador interactuar mediante programación de los procesos. Se basa en Hibernate.

• Bonita Portal: es un portal que permite a cada usuario final administrar en una interfaz parecida a webmail todas las tareas en las que él o ella está involucrada. El portal también permite que el propietario de un proceso pueda administrar y obtener informes sobre los procesos. Se basa en GWT.

ProcessMaker

ProcessMaker está diseñado estrictamente para las pequeñas y medianas empresas (PYMEs). Al igual que Intalio, ProcessMaker tiene la filosofía de que los usuarios de negocios y expertos en procesos que no tienen experiencia en programación puedan diseñar y ejecutar flujos de trabajo, así como automatizar los procesos de todos los sistemas. ProcessMaker tiene varios módulos con los que el usuario puede crear mapas de flujo de trabajo, formas de diseño personalizadas, extracción de datos de desde fuentes externas y otras características para generar y optimizar las operaciones de gestión del flujo de trabajo y de negocios:

• Diseñador de Mapa de Procesos

• Dynaform Builder (formularios personalizados para los procesos de la organización)

• Output Document Builder (diseñador de documentos de salida de proceso) / Gestión Documental

• Motor de reglas de negocio

• IDE para construcción de web services

• Gestión de usuarios

• Bandeja de entrada de casos

ProcessMaker posee una biblioteca en línea que proporciona plantillas de proceso que el usuario puede descargar y editar. La curva de aprendizaje también se puede reducir ya que el desarrollo puede basarse desde una plantilla ya construida y probada. Algunas plantillas de muestra incluyen:

• Solicitud de tarjeta de crédito

• Proceso de informe de gastos

• Solicitud de zonificación de distrito

Activiti

Activiti es una plataforma BPM de código abierto para un entorno basado en Java. Originalmente desarrollada por Alfresco, su código fuente se distribuye bajo la licencia Apache. Dentro de la plataforma Activiti BPM se encuentran los siguientes componentes:

• Modelado: Activiti Modeler, Designer y Kickstart

• Ejecución: Activiti Engine

• Gestión: Activiti Explorer, REST.

Activiti es soportada y desarrollada por varias empresas como SpringSource, Atos Origin, Signavio, Camunda y otros. Así mismo, la plataforma se puede integrar a mule, un popular ESB de código abierto, para la entrega de soluciones basadas en SOA. Su modelador soporta BPMN y jPDL; posee extensiones que permiten la integración con el middleware de JBoss.

Benchmark entre los diferentes BPMS

Finalmente, se presenta un comparativo de los diferentes BPMS, incluyendo los productos de IBM y Oracle:

BPMS Tipo Interfaz de Usuario Notación Workflows Binding
IBM Lombardi Workflow, Process Designer, ESB, ECM, Portal Todos BPMN BPEL J2EE, WSDL/WS
Oracle BPM 11g Workflow, Process Designer, ESB, ECM, Portal Todos BPMN BPEL J2EE, WSDL/WS
Intalio Workflow, Process Designer, ESB, ECM, Portal, BRE Web 2.0 BPMN WS-BPEL J2EE
JBoss jBPM Workflow, Process Designer Todos jPDL, BPMN, Pageflow BPEL WSDL/WS
BonitaSoft Workflow, Process Designer, Portal Java BPMN XPDL, BPEL J2EE
ProcessMaker Workflow, Process Designer, ECM Todos BPMN BPEL J2EE
Activiti Workflow, Process Designer Todos BPMN BPEL REST

Comparativo con las características de los BPMS más usados en México.

Análisis y recomendaciones

Para clientes pequeños con un gasto menor a USD 100,000 anuales dedicados a BPM, es recomendable adquirir un producto de código abierto. Dependiendo del requerimiento del cliente, puede utilizarse alguna de las opciones mostradas en el documento; sin embargo si el cliente tiene esperado un fuerte crecimiento en la demanda de su solución BPM, las mejores opciones son jBPM o Intalio, ya que ambos productos permiten conexión con plataformas de alta escalabilidad, incluyendo middleware y bases de datos comerciales. En el caso de jBPM, este producto permite utilizar la vasta gama de productos ofrecidos por Red Hat, mientras Intalio permite al cliente utilizar la Community Edition hasta que haya alcanzado la masa crítica necesaria para adquirir sus licencias. Basándose en una comparación a juicio de experto entre ambos productos, NO existe una clara ventaja competitiva de alguno sobre otro, por lo que dependiendo de las características del cliente variará el criterio de selección del BPMS a implementar.

h1

SOA (Parte 2)

09/11/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks.

En el anterior post describimos de manera general qué es un SOA, cuáles son sus orígenes y sus elementos más característicos. En esta ocasión nos enfocaremos en la parte funcional del SOA: qué elementos arquitectónicos lo componen y cómo interactúan entre sí. Adicionalmente veremos los frameworks SOA comerciales más fuertes en el mercado y revisaremos sus principales ventajas y desventajas.

Los elementos arquitectónicos de un SOA

Como comentamos anteriormente, un SOA es un modelo de diseño de arquitecturas empresariales; sin embargo, la implementación del mismo no sólo consiste en publicar web services y ya: aunque en un principio esto puede funcionar para facilitar la adopción de SOA, poco a poco conforme vayamos publicando más y más servicios, volveremos a un esquema desordenado. Así entonces, tarde o temprano el volumen de servicios será tal que:

• Será difícil encontrar los servicios que se necesitan. Esto es progresivamente más frecuente conforme publiquemos un más servicios.

• No será posible realizar una efectiva administración de los servicios y forzar su adhesión a un estándar organizacional, incluyendo características tales como seguridad o políticas de publicación y consumo.

Comúnmente este tipo de problemas son resueltos sobre la marcha, sin embargo es importante considerarlos y atacarlos desde la fase de diseño del SOA para evitar futuros cuellos de botella, facilitando la adopción del nuevo paradigma y lograr ver desde un principio los beneficios asociados a este tipo de arquitecturas:

Un esquema que muestra los componentes del SOA y las relaciones (publicación, descubrimiento, consumo) entre éstos.

[Click en imagen para ver a mayor escala]

A continuación se describen los componentes del SOA en mayor detalle:

• Capa aplicativa. Este elemento contiene las interfaces de usuario final; principalmente las aplicaciones web o cliente-servidor que consumen los procesos construidos a través del Gestor de Procesos y aquellos servicios que han sido publicados por terceros. La capa aplicativa es más dependiente de lenguajes o frameworks de desarrollo (por ejemplo, interfaces web desarrolladas en Java o aplicaciones que interactúan con sistemas legados desarrolladas en C/C++).

• Capa de servicios de terceros. Son los servicios publicados por organizaciones ajenas a la nuestra (por ejemplo, el servicio SOAP publicado por Google para explotar su motor de búsquedas). Dichos servicios son consumidos por la Capa Aplicativa y el Gestor de Servicios, siendo publicados en el Directorio de Servicios[1].

• Orquestador de Datos/Gestor de Servicios. El gestor de servicios u orquestador de datos[2] es el componente cuya función principal es la construcción de los procesos de negocio que utilizará la organización en su capa aplicativa mediante el uso de los servicios que han sido publicados en el Service Registry, incluyendo los servicios publicados por terceros[1]. Adicionalmente, este elemento interactúa con el Directorio de Servicios para extraer los metadatos de los servicios que se integrarán, aunque también hace uso de otro tipo de características como monitoreo o gestión del ciclo de vida de los procesos generados. Por otro lado, es frecuente que este componente incluya una interfaz de usuario que permita construir los procesos mediante la representación diagramática de BPEL (Business Process Execution Language – Lenguaje de Ejecución de Procesos de Negocio)[3].

• Directorio de Servicios. Este elemento es en su forma más simple un repositorio de los servicios publicados así como una "sección amarilla" que utilizará el Gestor de Servicios para construir los procesos de negocio. En versiones más sofisticadas incluye un componente de gestión y gobierno de los servicios incluyendo características tales como gestión del ciclo de vida de los servicios, versionamiento y gobernabilidad (es decir, adhesión a las políticas de negocio y seguridad que permean toda la arquitectura).

• Adaptadores ESB/ETL/EAI y Conexión XDMS[4]. No todas las fuentes de datos o lógica de negocio son fácilmente convertibles a servicios. En algunos casos, es necesario primero utilizar conectores o drivers nativos que son accedidos mediante "servicios empaquetadores" (wrapper services) para su uso por el resto de la arquitectura. Un ejemplo clásico es extraer la información de una AS400 utilizando un adaptador basado en la especificación JCA (Java EE Connector Architecture).

• Repositorio de Datos. Son las fuentes de información como Bases de Datos o archivos planos así como de lógica de negocio, incluyendo sistemas de Planeación de Recursos Empresariales (Enterprise Resource PlanningERP) como SAP R/3. Como se vio en el punto anterior, algunas de estas fuentes de datos no cuentan con interfaces de extracción de datos homogéneas que puedan usarse en un SOA, por lo que la extracción de la información de éstas requiere de adaptadores[4] para su explotación.

El Enterprise Service Bus

Un tema que no hemos visto hasta ahora ha sido, de entre todos estos componentes, ¿quien funciona como el "pegamento" que los une y permite su interacción? ¿Quién realiza la validación de mensajes entre servicios, reforzando las políticas de negocio y seguridad definidas? ¿Quién se dedica a realizar las transformaciones de los mensajes del formato seleccionado para nuestro SOA a los formatos utilizados por la capa aplicativa?

Presentamos el Enterprise Service Bus (o Bus de Servicios Empresariales – ESB) cuya función principal, de manera análoga al bus de las placas base o motherboards, es conectar los diferentes componentes del SOA, permitiendo el intercambio de información entre todos los elementos de la arquitectura:

Vista esquemática del Enterprise Service Bus. Éste es el middleware que gestiona el transporte, ruteo y seguridad de los mensajes entre los consumidores y publicadores de los servicios.

[Click en imagen para ver a mayor escala]

Como puede verse en el diagrama, el ESB es un bus de datos que facilita el transporte de los mensajes entre los consumidores y los publicadores de servicios realizando la tarea de mediación entre éstos:

• Transformaciones: conversiones XML a XML, búsquedas en base de datos y agregaciones (jerarquías de documentos).

• Validación de Mensajes: verificación de campos de datos o combinación de éstos contra reglas específicas de negocio.

• Selecciones de servicio de contenido o calidad: Selección de servicios basada en el contenido o calidad del servicio requeridos. En pocas palabras, balanceo de carga y failover.

• Ruteo basado en contenido: Como ejemplo, si los parámetros del servicio contienen información del país de origen, la petición puede ser redirigida al proveedor designado para ese país.

• Logueo personalizado: Este es un requerimiento legal que puede ser necesario para algunas interacciones entre servicios.

• Monitoreo y métricas de funcionamiento: Un bus debe poseer los puntos de control necesarios para controlar su comportamiento y de los servicios integrados:

Consola de monitoreo del AquaLogic Enterprise Service Bus de BEA/Oracle. (Original obtenido de BEA AquaLogic Service Bus 2.1 Documentation > User Guide > Monitoring )

[Click en imagen para ver a mayor escala]

• Comportamiento automático: Debe existir alguna funcionalidad que permita la auto-configuración, alta disponibilidad y optimización de recursos.

• Administración de políticas: Descripción de las reglas de comportamiento requeridas por todos los puntos anteriores y fácilmente configurables a través de archivos de metadatos basados en XML o algún otro lenguaje descriptivo.

Visto desde el punto de vista de implementación, el ESB es el framework de desarrollo o producto comercial con el cual construiremos nuestro SOA, siendo tan sencillo o tan complejo como deseemos; la mejor opción es utilizar frameworks que contengan todos los elementos de un SOA ya integrados para facilitar la adopción de la nueva arquitectura, como veremos en la siguiente sección.

Implementaciones SOA/ESB

Actualmente existen de manera dominante tres suites, frameworks o implementaciones comerciales del middleware SOA/ESB que permiten la adopción de una arquitectura orientada a servicios:

• AquaLogic de BEA/Oracle.

• Java Composite Application Platform Suite (Java CAPS) de Sun Microsystems.

• Connected Services Framework (CSF) de Microsoft.

Adicionalmente existen otras implementaciones (Como OpenESB) pero su principal limitante es el escaso soporte que ofrecen, un punto muy importante en un proyecto tan complejo como puede ser SOA y que podría requerir una alta curva de aprendizaje; por otro lado a menos que el presupuesto de migración a SOA sea muy reducido[5], es mejor contar con las soluciones que estos proveedores ofrecen.

Ahora bien, haciendo la comparación entre las tres plataformas:

•  AquaLogic es el mejor producto de su clase pero el precio que manejan, aún con el modelo de ventas utilizado por Oracle[6], es astronómico.

• El producto de Sun es muy bueno, pero le falta un poco de pulido a sus interfaces de usuario (esencialmente porque en ocasiones la construcción de procesos puede volverse una pesadilla de micromanagement y "necesitamos" un monitor de 24 pulgadas):

Interfaz de usuario del Process Manager (vista de alto nivel de un proceso, sin detallar los servicios individuales) en el Java CAPS. (Original obtenido de From Java CAPS 5.1.x to Java CAPS 6 and Open ESB – Reuse or Rewrite)

[Click en imagen para ver a mayor escala]

• Finalmente CSF tiene que ver con la penetración de la tecnología Microsoft: si nuestra infraestructura está montada en una arquitectura Wintel, adelante; de lo contrario estamos saltando de la sartén al fuego.

Conclusiones

Hemos visto que la implementación de un SOA no sólo es publicar y consumir web services: se trata de hacer disponibles los servicios de datos y lógica de negocio de una manera estandarizada para que puedan ser utilizados por las diferentes áreas de una organización; todo ello mediante un marco tecnológico – el Enterprise Service Bus – que nos permita realizar de manera efectiva las tareas de gestión, transporte y mediación de los servicios y procesos que componen nuestro SOA. Por otro lado, hemos visto que Sun, BEA/Oracle y Microsoft son los proveedores de soluciones tecnológicas de implementación SOA más importantes del mercado, siendo AquaLogic la mejor pero más cara, JCAPS la de mayor curva de aprendizaje y Microsoft una solución efectiva si disponemos de una infraestructura Wintel.

Notas y pies de página

1. ¿Por qué publicar servicios de terceros en nuestro Directorio de Servicios? Porque adicionalmente a la "sección amarilla" que ofrece, incluye otras funcionalidades como el cache y versionamiento de servicios; características que pueden ser útiles cuando hay que integrar a terceros en nuestros procesos de negocio.

2. Se denomina orquestador de datos porque en su forma más pura, éste componente sólo utiliza servicios de extracción de datos para conformar – orquestar – los procesos de negocio que requiere la capa aplicativa.

3. BPEL es un lenguaje basado en XML que posee una representación diagramática (ver aquí un ejemplo de un algoritmo de transformación) que permite la construcción de procesos de negocio y que fue originalmente desarrollado por la Organización para el Avance de Estándares Estructurados de Información (Organization for the Advancement of Structured Information StandardsOASIS). Actualmente, en la versión 2.0, dicho leguaje ha sido tomado por proveedores para desarrollar sus implementaciones de ESB y frameworks SOA.

4. Los adaptadores ESB (Enterprise Service Bus) son aquellos que de manera nativa pueden ser utilizados para un SOA (por ejemplo, si nuestro protocolo es HTTP y nuestro formato es SOAP, implicaría que nuestra fuente de datos puede regresar queries en forma de documentos XML). Los adaptadores ETL (Extract, Transform and Load – Extraer, Transformar y Cargar) son aplicaciones que obtienen consultas de las fuentes de información y las transforman de manera no nativa al formato que estamos buscando. Los adaptadores EAI (Enterprise Application Integration – Integración de Aplicaciones Empresariales) son, en resumidas cuentas, aquellos que se conforman a un estándar de integración como JCA. Finalmente, XDMS (XML Document Management Server – Servidor de Gestión de Documentos XML) es el equivalente a una base de datos que en vez de almacenar esquemas entidad-relación, almacena jerarquías de documentos XML.

5. Sin embargo, queda la interrogante: si el cliente escatima en un proyecto de tal envergadura – que por poner un ejemplo, puede consistir de unas 20,000 horas/hombre – ¿no es probable que no esté entendiendo el alcance de SOA o los beneficios que ofrece?

6. El modelo de ventas de Oracle es en resumidas cuentas: el costo de licencia por cada producto se multiplica por el número de CPUs en los que está corriendo, considerando los siguientes tabuladores: si el CPU es específicamente un Sun UltraSPARC T1 con 4, 6 u 8 cores, las licencias se multiplican 0.25 por cada core; en el caso de AMD es 0.5 por cada core y en el caso de cualquier otro fabricante multicore – es decir, Intel o alguno de sus partners – se multiplica 0.75 por cada core. Para procesadores de un solo core se contabiliza una licencia por CPU.

h1

SOA (Parte 1)

09/06/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks.

Había una vez un paradigma de diseño de arquitecturas IT – si es que así lo podemos llamar – donde todos los sistemas y recursos de una organización se localizaban y eran ejecutados desde una computadora central o mainframe. Dicho paradigma, denominado monolítico, tenía como misión generar reportes mediante procesos por lotes para facilitar la toma de decisiones de la alta dirección.

Sin embargo, a partir de la década de 1960 y con la creación del microprocesador, este paradigma comenzó a menguar en favor de las arquitecturas cliente-servidor, donde una computadora (el cliente) generaba una petición a otra (el servidor), que tomaba dicha petición, realizaba un procesamiento y devolvía un resultado; todo ello a través de un medio electrónico.

Desde ese momento la información de una organización y los procesos que la "masajeaban" ya no residían en una misma máquina, lo que desembocó en una explosión de requerimientos de las unidades de negocio hacia sus respectivas áreas IT para diseñar, construir y liberar cada vez más soluciones de acuerdo a sus necesidades específicas. Con la venida del Internet se reforzó la tendencia, pues aunadas a los sistemas de apoyo a la toma de decisiones, ahora se demandaban soluciones IT para prácticamente cualquier ámbito dentro de la organización: desde catálogos, órdenes de compra o administración de los recursos humanos hasta soluciones de mensajería y chat.

Sin embargo, esta explosión de sistemas de información trajo consigo un problema de gestión de arquitecturas: conforme aumentaba el número de aplicaciones, mayor necesidad había de integrar la información y los procesos que operaban sobre ésta, degenerando en un esquema como se muestra a continuación:


Una arquitectura empresarial convencional.
[Click en imagen para ver a mayor escala]

Este desorden genera estructuras rígidas y difíciles de adaptar a los requerimientos de una organización o sus necesidades de negocio. Así entonces, se encontró que la mejor forma de atacar el problema era diseñando una arquitectura que hiciera provecho de las tecnologías que facilitaban la interconexión entre plataformas de un ambiente heterogéneo generando un nuevo modelo de implementación arquitectónica. CORBA y SOAP son las tecnologías de mayor relevancia, aunque EDI fue el precursor de dichas plataformas de integración.

¿El resultado? La Arquitectura Orientada a Servicios (Service Oriented Architecture – SOA):

SOA es un paradigma de diseño de arquitecturas empresariales que facilita la conexión de las diferentes aplicaciones y fuentes de información mediante componentes seguros y estandarizados (los servicios) de tal manera que puedan ser reutilizados y combinados de manera flexible para atacar las cambiantes prioridades del negocio:

Una Arquitectura Orientada a Servicios. Nótese que el Gestor de Procesos es el encargado de combinar los servicios para generar procesos coherentes que sirvan a las necesidades de la organización, mientras que el Directorio de Servicios funciona como una "Sección amarilla" que permite listar y encontrar todos los servicios que contiene la organización.


[Click en imagen para ver a mayor escala]

Los servicios que componen un SOA

Una arquitectura orientada a servicios está compuesta por unidades lógicas individuales que existen de manera autónoma sin estar aisladas totalmente unas de otras. Estas unidades deben ajustarse a una serie de reglas y principios que les permiten evolucionar de manera independiente, manteniendo al mismo tiempo cohesión entre ellas y hacia un estándar. Dichas unidades son conocidas como los servicios:

Cuando se realiza la transformación de una arquitectura convencional a un SOA, comúnmente la generación de servicios se implementa sobre soluciones con procesos claramente definidos:

Los servicios pueden encapsular fragmentos de lógica de negocio de diferente "tamaño", "peso" o complejidad.

Como puede apreciarse en el diagrama, podemos fragmentar los procesos en unidades lógicas más sencillas que encapsulen operaciones con mayor o menor complejidad; si generamos nuestro SOA a partir de aplicaciones implementadas bajo el modelo de Programación Orientada a Objetos (Object-Oriented Programming – OOP), esta tarea puede ser llevada a cabo con mayor facilidad pues las operaciones de los objetos pueden ser publicadas como servicios:

Un Objeto de Acceso a Datos (Data Access Object – DAO) y un componente de negocio (en este caso un Enterprise Java Bean – EJB) tienen publicados sus métodos como servicios.


[Click en imagen para ver a mayor escala]

Frecuentemente se asocia un SOA y los servicios que lo componen a los llamados web services o servicios web, sin embargo la implementación de web services no es un SOA por sí mismo ni un SOA tiene que estar compuesto necesariamente por web services: los web services son una plataforma de interoperabilidad que facilita la generación y envío de mensajes entre sistemas heterogéneos. Es decir, mientras existan (1) un protocolo de transporte y (2) un formato de codificación y decodificación de los mensajes, cualquier medio puede ser utilizado para construir un SOA:

• SOAP – Simple Object Access Protocol.
• CORBA – Common Object Request Broker Architecture.
• SNMP – Simple Network Management Protocol.
• FTP – File Transfer Protocol.
• SMTP – Simple Mail Transfer Protocol.

Por ejemplo, es posible construir un SOA basado en SOAP para definir el formato de los mensajes y SMTP como medio de envío. Dicho de otra manera: llamadas a través de mensajes XML sobre correos electrónicos para ejecutar los servicios (aquí se muestra un ejemplo de esta implementación en el lenguaje de programación Python).

Conclusiones

SOA es un paradigma de construcción de arquitecturas empresariales como en un momento lo llegaron a ser los sistemas monolíticos, el cliente-servidor o las arquitecturas de N-Capas. SOA es un compendio de todas las buenas prácticas de desarrollo e implementación de soluciones de hardware, software y gestión de sistemas basándose en la modularidad de componentes y procesos, agilizando el desarrollo de nuevas aplicaciones que sirvan a las necesidades de negocio de una organización. Por otro lado, un SOA no sólo se trata de UDDI, WSDL y HTTP: los web services sólo son una plataforma de interconexión mientras que SOA es un modelo arquitectónico.

Por el momento, sólo hemos visto la punta del iceberg. En el próximo post veremos que una Arquitectura Orientada a Servicios no sólo se trata de publicar servicios sin ton ni son, sino que la implementación – véase las "tripas" – de un SOA está compuesta por una multitud de elementos arquitectónicos como BPEL (Business Process Execution Language), XDMS (XML Document Management Server) o el tan cacareado ESB (Enterprise Service Bus).