Mijao Blog

3/14/2015

Presidencia del Ecuador - Plataforma de Mediación, Integración e Interoperabilidad con Mule ESB, Bonita BPM y WSO2

La Dirección de Tecnología de la Presidencia del Ecuador necesitaba rediseñar y mejorar sus prácticas de Ingeniera de Software para responder de forma más ágil y efectiva a las necesidades de las diversas unidades de negocio que esta apoya mediante sus servicios informáticos. La Dirección necesitaba rediseñar sus prácticas de TI, contar con un entendimiento profundo de las disciplinas y estilos de arquitectura SOA, ESB, BPM; y poner en práctica nuevos métodos y herramientas para el desarrollo de soluciones, procesos, apis, servicios, rules, entre otros. Necesitaba explorar, aprender y aplicar.

Lo primero que hicimos fue conformar un equipo multidisciplinario; estos fueron nuestros avatares, una idea para romper el molde!!!!

El segundo paso fue recomendar la conformación de un proyecto piloto. Como iniciativa fue identificado un proceso transversal para controlar las actividades de ingreso y egreso de personal; este proceso fue seleccionado mediante la evaluación de diversas variables como el grado de transversalidad del proceso, su valor; entre otros. Con este proceso automatizado se podrá evitar la demora en los procesos de ingreso y egreso de personal, disminuir el papel, respetar los canales regulares de aprobación, proporcionar mayor trazabilidad y conocer el estado del proceso en cualquier etapa que este se encuentre; mejorando la coordinación y cooperación entre los departamentos; el establecimiento de acuerdos de servicios; en resumen, proporcionando mayor control y gobernabilidad en los recursos utilizados para su optimización y racionalización continua.

Como tercer paso, establecimos un marco metodológico y una caja de herramientas Open Source para rediseñar y actualizar las prácticas de TI de la unidad. Estos métodos y herramientas fueron insertados en la organización con el objeto de crear nuevas capacidades; para luego ponerlas en práctica en un proyecto piloto. La metodología abordo gaps, arquitectura, políticas, inmersión en SOA, ESB, BPM, entre otros; cada uno con herramientas metodológicas que fomentaran la colaboración, la participación, la empatía, la definición, la ideación, el prototipado y la evaluación continua de las soluciones propuestas.

Luego realizamos una inmersión en la aplicación real de las disciplinas SOA, ESB, BRE, MOM, CEP, BPM y BAM sobre una pila de productos Open Source.

Mas allá de contarles sobre los beneficios obtenidos, lo interesante fue lo aprendido, los enfoques y recomendaciones estratégicas que pueden soportar. Aquí algunas recomendaciones para disminuir los riesgos de proyectos BPM.

Seleccione un proyecto piloto de valor estratégico para la organización.
Establezca políticas iniciales.
Establezca un marco metodológico y herramientas de amplio espectro para abordar las verticales de servicios, apis, rules, procesos, entre otros.
Conforme una arquitectura mínima viable.
Conforme un modelo organizacional de nueva generación.
Conforme una Plataforma de Mediación, integración e interoperabilidad.
Utilice la notación gráfica BPMN 2.0 para modelar procesos.
Desarrolle un programa de formacion especializado, profundo y con patrones.

Para finalizar quiero agradecer a todo el equipo de mijao y de la presidencia por su hospitalidad y energía. Exploramos, prototipamos y aprendimos juntos!!!

Aquí algunos detalles que puedo compartir.

saludos;

La diferencia entre una política y una regla

Durante mi vida profesional he estado incentivando la adopción de nuevos enfoques de gestión organizacional con el objeto de transformar y rediseñar los métodos y técnicas que actualmente utiliza las organizaciones; donde siguen prevaleciendo el enfoque funcional vs el orientado en procesos.

Es evidente que en el segundo enfoque la organización tiene mayor gobernabilidad y control; en el primero la gestión es desordenada, desarticulada, desvinculada y deficiente. Es urgente de las organizaciones cambien, evolucionen y adopten nuevos métodos como la gestión por procesos.

Dentro las asesorías que he podido desarrollar una vez me preguntaron la diferencia entre una política y una regla. Tal vez la respuesta para algunos resulte evidente sin embargo, estoy convencido que la creación de políticas claras y concisas son unos de los factores que facilitan la transformación organizacional en cualquier ámbito, sin embargo voy a enfocarme en el tema tecnológico.

Un política es una directriz, una norma que debe ser acatada por todos los estratos de la organización, quien la dictamina está convencido de su impacto y sus beneficios, mientras que una regla de negocio es una condición que puede ser alterada por algún cambio de regulación en la organización.

Si un gerente de TI estableciera la siguiente política “Todo los sistemas de información deberán estar desarrollados sobre servicios, siguiendo los principios de la arquitectura SOA”, en su organizacion los beneficios e impactos sera evidentes; sin embargo es difícil poder encontrarla en organizaciones tanto privadas como publicas. Para acatar esta política la organización debe entender que es un servicio, como debe administrar su ciclo de vida, que procesos y políticas deben establecerse.

El camino a la mejora debe estar soportando por políticas de TI en una organización. En las asesorías siempre recomiendo el establecimiento de políticas para impulsar cambios organizacionales como primer paso.

1/07/2014

Bonita BPM y BPMN 2.0 - Formación Organizacional

Durante una actividad de transferencia de conocimiento y experiencia que impartí en técnicas y métodos para el modelado de procesos mediante la notación gráfica BPMN 2.0 y el motor de procesos Bonita BPM me preguntaron cual seria el enfoque mas apropiado (el paso a paso) para mejorar las posibilidades de éxito de un proyecto BPM utilizando cualquier motor de procesos. Esta pregunta genero una tormenta de ideas, opiniones que quise compartir con la comunidad.

Antes de iniciar, quiero agradecer la equipo por sus contribuciones, su pasión, y sobre todo sus preguntas, preguntas que permitieron establecer un tejido de acción que considero vital para disminuir los riesgos de un proyecto BPM.

Al comenzar un proyecto BPM debemos realizar lo que yo llamo un aprovisionamiento, es decir prepararnos para el ataque mediante la conformación de un conjunto de políticas metodológicas y técnicas que deben ser conformadas para disminuir los riesgo del desarrollo; por su puesto podemos describir muchas políticas desde gestión de proyectos, cambio, arquitectura, diseño, desarrollo, entre otras, sin embargo algunas son esenciales; si no se toman en cuenta pueden derivar en un retrabajo y en el peor de los casos en el fracaso de la iniciativa.

Recomendaciones antes de abordar un proyecto piloto BPM (Prototipo Funcional)

Conozca a profundidad los métodos y técnicas para modelar procesos mediante la notación gráfica BPMN 2.0. Esto evitara malas practicas desde un principio, son comunes practicas inadecuadas de la notación.
Establezca directrices de modelado para evitar procesos con mala compresión, y uso inadecuado de la sintaxis BPMN.
Establezca métodos no tradicionales para realizar el análisis de los procesos.
Establecer políticas para la especificación y descripción de los procesos.
Establezca una arquitectura simple y de tecnología neutral.
Comience con un proyecto piloto, pequeño pero de interés estratégico para la organización.

Anexo algunas imágenes de proyectos BPM que incluimos en la formación, para la gestión de acuerdos de servicios, invocación de web services, y el uso de subprocesos en bucle, entre otros aspectos.

Ejemplo de gestión de Acuerdos de Servicio

Utilización de Eventos Intermedios

Utilización de subprocesos e invocación en looping

Gracias a todos por su colaboración.

Es importante recordar que: La innovación proviene generalmente de los estratos técnicos!!!!. Agradezco al equipo por tomar el camino menos recorrido!!!

10/28/2013

Plataforma de Datos Públicos Enlazados - Interoperabilidad y Gobierno Electronico

Hace algunos días, tuve la oportunidad de presentar en el Segundo Seminario de Interoperabilidad "Venezuela SIO 2013" realizado en la Universidad de Carabobo las premisas, conceptos y estrategias que pueden ser utilizadas para conformar una Plataforma de Datos Públicos Enlazados que permita que el Estado y cualquier país pueda establecer las bases para compartir datos autoritativos de forma estándar. La esencia de dicha propuesta está en la aplicación de los estilos y disciplinas de arquitectura SOA, ESB y los principios de web semántica y linked data.

En esta presentación, describo de forma pragmática la necesidad y urgencia que tiene el Estado de conformar una plataforma de datos públicos enlazados; que esté integrada por la porción del conocimiento autoritativo de las instituciones que la integran. Al instanciar esta plataforma, el ciudadano no tendría que entregar ningún documento que haya sido generado o emitido por el propio Estado, dado que este documento o dato puede ser consultado por cualquier institución que lo requiera, gracias a la publicación de datos realizada por la autoridad o institución dueña del dato o documento.

Agradezco al Centro Nacional de Tecnologías de Información por la invitación y la oportunidad de impulsar estos conceptos tan necesarios en nuestros países.

Algunas Reflexiones

La interoperabilidad es la base que sostiene el concepto de gobierno electrónico.
La integración no significa que el estado pueda medir su efectividad y eficiencia.
No es un sueño, es una realidad técnicamente posible.

Saludos;

8/15/2013

Porque los proyectos BPM (Business process management) fallan?

Describir las causas que originan la falla de proyecto BPM (Business process management) seria una actividad muy extensa, sin embargo he recopilado un conjunto de errores, malas practicas, consideraciones que inciden directamente en el éxito de un proyecto BPM. Desde hace algunos años he participando en proyectos BPM de diversos tamaños, estados, fases y condiciones, he podido constatar y registrar un conjunto de inhibidores que están afectando el éxito BPM en diversas organizaciones a nivel nacional e internacional.

BPM en esencia es una disciplina que permite que una organización pueda racionalizar y mejorar de forma continua el uso de sus recursos (gente, procesos, tecnología) mediante la medición en tiempo real de indicadores y métricas relacionadas con el cumplimientos de sus objetivos estratégicos tácticos y operacionales. BPM transforma y rediseña organización funcionales a orientadas en procesos, organizaciones inteligentes!!!

Describo a continuación algunos factores que inciden que proyectos BPM fallen. Espero que sea de utilidad para gerentes, arquitectos y directores que tengan entre sus planes la adopción BPM.

Factores Generales:

Mucho énfasis en tecnológica y poca en metodología.
Ausencia de políticas que garanticen la disminución de riesgos de ejecución al inicio.
Ausencia de una arquitectura de software clara y sencilla.
Arquitectura y diseño inconsistente.
Falta de comprensión de la disciplina BPM, su enfoque, su esencia.
Ausencia de las dimensiones mínimas de análisis que deben estar presentes para asegurar una descripción y modelado adecuado de los procesos.
Ausencia de un marco metodológico para el análisis y descripción de procesos.
Soluciones BPM que son utilizadas como si fueran un IDE de desarrollo.
Falta de comprensión entre BPM y las disciplinas SOA, ESB, BRE, entre otras.
Falta en la concepción de orquestación de servicios vs orquestación de procesos.
Ausencia de una arquitectura orientada en servicio en proyectos BPM.
Ausencia de un enfoque multidisciplinario de análisis y descripción de procesos.
Falta del criterio "zapatero a su zapato".
Poca experiencia en la definición y uso de patrones BPMN.
Uso inadecuado de la sintaxis y semántica de la notación gráfica BPMN 2.0. (Técnicas de modelado de procesos pobres).
Falta del criterio "Primero modelar luego construir".
Procesos muy grandes e ingobernables (divide y vencerás).
Procesos que no se modelan sobre una perspectiva de automatización.
Mal dimensionamiento de los componentes de una solución BPM.
Una aplicación no es el proceso.
Inexperiencia de proveedores.

Saludos;

2/05/2013

Preguntas que debemos hacernos en un proyecto de Integracion SOA, ESB, BPM

He leído muchas veces la importancia de hacer buenas preguntas; en ese sentido, cuando abordamos proyectos de integración se presentan muchos problemas por no tomar en cuenta variables que son importantes para una buena implementación. Aquí algunas preguntas que como arquitectos debemos hacernos cuando necesitemos enfrentarnos a servicios de integración.

Que protocolo de transporte disponibiliza el servicio? (Por ejemplo: HTTP, HTTPS, JMS, SMTP, TCP/IP)
Que protocolo de comunicación utiliza el servicio?. (Por ejemplo: HTML, XHTML, SOAP, XML, JSON)
Qué tipo de patrón de mensajería utiliza el servicio? (Por ejemplo: Síncrono o Asíncrono)
El acceso al servicio requiere autentificación y autorización?
Qué tipo de seguridad utiliza el servicio? (Por ejemplo: ws-security, token, request).
El servicio tiene asociada alguna política? (Por ejemplo: Solo puede ser invocado desde una direccion ip especifica, algunos datos deben estar encriptados, el response time del servicio no puede exceder de 200 ms, solo puede ser invocado una sola vez al día).
Como se gestionaran los errores que pueden presentarse en el servicio? (Por ejemplo: soap faults, xml, texto, entre otros.)
Qué tipo de notificación deberá ser aplicada al generarse una excepción de disponibilidad del servicios (timeout, no disponible, entre otros). Por ejemplo: sms, correo electrónico.
Quien será el responsable o gestor de servicio? (Por ejemplo: nombre, correo electrónico, teléfono, entre otros)
El servicio requiere algún tipo de transformación (mapeo) o utilización de alguna expresión de salida?
Cuáles son los datos que pueden ser provistos por el servicio?
El servicio requiere algún componente transaccional?
Se debe aplicar alguna estrategia de cache en el servicio?
Como se gestionará la auditoria y logging del comportamiento del servicio en tiempo de ejecución?
Cual será el Service Level agreement del servicio? (Por ejemplo: timeresponse minimo)
Cual será la disponibilidad del Servicio?
Cuentan con un formato para especificar los servicios proveedores?
Cuál es el grado de complejidad del servicios?
Cuál es el tiempo estimado para su desarrollo?
Que recursos son necesarios para desarrollar los servicios?

Saludos;

Proyecto Challenge DevFactory

Desde hace un año y no con la frecuencia que quisiera, he estado involucrando a niños, estudiantes y profesionales para que aprendan técnicas y métodos para el desarrollo de software basado en el pensamiento de diseño. El desafió, ninguna de las personas tiene ningún tipo de conocimiento en ingeniería de software. Aquí algunas imágenes que transmiten por si solas.

Los invito a revisar las técnicas del pensamiento de diseño e incorporarlas en sus áreas de competencia!!

Pueden los jovenes apreder a desarrollar software sin una formacion formal?, que piensan ustedes!!!!;

Recomendaciones para abordar un proyecto BPM con Bonita BPM (Entrenamiento Bonita Open Solution BPM y API)

Hace algunas semanas desarrolle un programa de formación SOA/BPM que incluyo un entrenamiento intensivo en el modelado y automatización de procesos mediante la solución Bonita Open Solution. Durante esta transferencia de conocimiento y experiencias registre un conjunto de recomendaciones que fue enriquecido con los participantes y sus distintas contribuciones; el cual quisimos compartir con la comunidad con el objeto de incentivar no las herramientas tecnológicas sino las consideraciones metodológicas y políticas que deben establecerse.

Recomendaciones para abordar proyectos BPM con Bonita Open Solution

La actividad de análisis y modelado de procesos debe realizarse de forma multidisciplinaria. Los procesos no se modelan en un solo día y con una solo perspectiva.
Los procesos pueden ser modelados por coreografía u orquestación, sin embargo para iniciar les recomiendo adoptar la orquestación.
Las tecnologías BPM no son herramienta de desarrollo, por ende se debe evitar en la medida de lo posible escribir código bajo sus diferentes características.
El proceso debe ser tratado como un prototipo, por ende debe pasar por diversas revisiones para ir dividiendo las responsabilidades por ejemplo: identificar procesos utilitarios e invocarlos mediante actividades de llamada, o la utilización de timers y contadores para la gestión de acuerdos de servicios.
La gestión de excepciones debe siempre incluirse en los procesos, para asegurar que las instancias no se interrumpan durante excepciones en la disponibilidad de un conector o servicio.
Se recomienda que la mayoría de la lógica de integración, de datos o de reglas resida en servicios web que pueden ser invocados desde conectores o scripts groovy.
Los procesos pueden utilizar formularios, sin embargo existe la posibilidad de utilizar formar externas que invoquen procesos mediante el api de servicios REST de bonita. Con esta aproximación existe mayor control de la interfaces. Otra opción es generar los formularios con bonita y modificarlos según las necesidades.
Utilice procesos utilitarios para notificaciones, cambio de estatus de documentos, escalamiento, entre otros.
Cuando modele utilice como máximo tres procesos por diagrama.
Utilice patrones para la gestión de errores en la invocación de servicios web, con el objeto de evitar que el ciclo de vida del proceso sea interrumpido por la falta de disponibilidad de un servicio.

Saludos;

From Mijao Blog

4 lenguajes de programación (PHP, PYTHON, JAVA, GROOVY) y un Web Services – Programa BPM/SOA

Hace algunas semanas realice un programa de formación BPM/SOA, donde se abordaron diversas técnicas y métodos para el desarrollo de servicios de datos y decisión (reglas). El equipo técnico al cual impartí el entrenamiento contaba con una experiencia relevante en diversos lenguajes; lo cual enriqueció la actividad. Durante el entrenamiento, el equipo me plateo crear varios consumidores de servicios web bajo SOAP en diferentes lenguajes, lo cual me pareció una excelente práctica para ver los diferentes modelos de implementación para consumir servicios web.

En este post, podremos observar varias formas de consumir servicios web con diversos lenguajes:

PHP - NUSOAP

@include_once("nusoap/nusoap.php");
$oSoapClient = new nusoap_client('http://10.100.14.232:9763/services/tramiteCRUD?wsdl');
$respuesta = $oSoapClient->call("select_with_key_tramite_operation",array("tramite_id" => 2 ));
print_r($respuesta);
?>

PYTHON

from suds.client import Client
url = 'http://127.0.0.1:9764/services/tramiteWSS?wsdl'
client = Client(url)
print client.service.obtenerIdTramitesParIDs('1')

JAVA

package ve.gob.tramites.services.mppi.client;
import org.apache.axis2.AxisFault;
import ve.gob.tramites.services.mppi.TramiteCRUDStub;
import ve.gob.tramites.services.mppi.TramiteCRUDStub.Insert_tramite_operation;

public class Consumidor{
 public static void main(String[] args) {
  try {
   TramiteCRUDStub stub =new TramiteCRUDStub();
   Insert_tramite_operation objTramiteInsert=new Insert_tramite_operation();
   objTramiteInsert.setTramite_id(20);
   objTramiteInsert.setEstatus("ESTATUS PRUEBA");
   objTramiteInsert.setOrigen("ORIGEN PRUEBA");
  stub.insert_tramite_operation(objTramiteInsert);
  } catch (AxisFault e) {
   System.out.println("Ha ocurrido una Axis exception");
  } catch (Exception e) {
   System.out.println("Ha ocurrido una excepcion.");
  }
 }
}

PHP5 - SoapClient

$parametros['id']=2;
$client = new SoapClient("http://10.100.16.65:9763/services/tramiteidWS?wsdl",$parametros);
$respuesta = $client->selectId($parametros);
print_r($respuesta);
?>

Groovy

import wslite.soap.*
def client = new SOAPClient('http://localhost:1021/orden')
def response = client.send(SOAPAction: '') {
    body 
    { 
        'bam:createOrden'('xmlns:bam':'http://bam.service/') 
        { 
             'orden'('xmlns:bam':'http://bam.service/') 
             {  
                      campo1('I');
                      campo2('S');
                      campo3('A'); 
                      campo4('B');
             }             
        } 
    }
}
println response.envelope.Body.createOrdenResponse.return;

Felicitaciones al equipo por su alto nivel técnico, su proactividad, trabajo en equipo y su disposición a compartir con la comunidad su conocimiento. Este post es de ustedes!!!!

From Mijao Blog

12/13/2012

Business Process Management (BPM) Reflexiones y Recomendaciones

Actualmente existen diversos enfoques de gestión organizacional; uno de los más comunes en el funcional, el cual sigue prevaleciendo sobre modelos de última generación más efectivos, eficientes y agiles. En este sentido, el enfoque orientado en procesos se ha convertido en la opción urgente para mejorar el desempeño organizacional; para resumir, una organización funcional no tiene la capacidad de medir, mejorar y optimizar sus acciones porque no realiza énfasis en los procesos, solo en sus actividades. Una organización BPM se comparta como un carro de carrera en fórmula 1, con un equipo que mide todas las variables necesarias para ganar.

En todas las organizaciones donde he realizado asesorías y consultorías BPM han persistido los siguientes hallazgos:

No existe una clara definición y caracterización de procesos.
No se entiende la diferencia entre un proceso y un procedimiento.
Los procesos no están alineados y vinculados a un objetivo organizacional.
Los procesos no están alineados y vinculados a un producto o servicio.
Los procesos no tiene asociados acuerdos de servicios.
Los procesos no tiene asociados indicadores.
Los procesos no pueden ser monitoreados y medidos.
La mayoría de los procesos no son transversales, solo se ven los árboles y no el bosque.
Los procesos no tiene asociadas políticas.
Los procesos no tiene asociados procedimientos.
El levantamiento de procesos no se realiza sobre un enfoque participativo y multidisciplinario.
El levantamiento de procesos se realiza sin métodos y técnicas que faciliten su especificación.
El levantamiento de procesos no se basa en la comprensión profunda de modelos y prácticas que evitaran modelar el desastre.
Los procesos no son categorizados o clasificados.
No existe una notación estándar para el modelado de procesos.

Establecer acciones para cerrar cada una de estas brechas sería muy extenso para describirlas en este blog, sin embargo comparto algunas recomendaciones que contribuirán con ejercicios de mayor valor en esta materia.

Recomendaciones

Describa y caracterice un proceso para estandarizar y homologar el lenguaje antes de iniciar cualquier iniciativa.
Comunique de forma clara y concisa la diferencia entre una actividad, un proceso y un procedimiento a su equipo. Es diversas asesorías en las que he participado he encontrado inconsistencias, procesos que son actividades y viceversa.
Evalué el nivel de profundidad en la descripción de sus procesos que requiere. Comience con descripciones generales y luego vaya realizando una inmersión mayor de forma iterativa.
Recuerde que cada proceso debe estar asociado a la entrega de un producto o servicio.
Recuerde que cada proceso debe estar asociado al cumplimiento de un objetivo organizacional.
Evalué y seleccione la herramienta de modelado de procesos que más se adapte a sus necesidades.
Establezca una categorización de procesos: macroprocesos, procesos, subprocesos. Es importante establecer una organización mínima de sus procesos para posteriormente mapearlos.
Defina los indicadores de desempeño y resultado de sus procesos para medirlos, mejorarlos y optimizarlos antes de ir a la automatización.
La actividad de modelado de procesos requiere de técnicas y métodos no tradicionales.
Realice énfasis en la descripción de políticas (normas y directrices), son ellas las que establecen las fronteras y condiciones de sus procesos.
Modele primero la ruta de éxito y luego enriquezca.

Saludos;

Entrenamiento Mule ESB en Banco Central de Venezuela

Hace algunos meses tuve la experiencia de dictar un entrenamiento de Mule ESB en el Banco Central de Venezuela para un proyecto integración de gran envergadura. Durante el intercambio de experiencias en el campo de integración, el equipo de trabajo enriqueció muchos conceptos, que quisimos compartir con la comunidad. Mule ESB es una plataforma de integración ligera basada en Java que permite conectar aplicaciones de forma rápida y sencilla, actuando como un sistema de transporte e intercambio de datos. En líneas generales se utiliza un bus de servicios cuando se requiere:

La creación y alojamiento de servicios web reutilizables en un contenedor de servicios ligero.
El enrutamiento de mensajes, para enrutar, filtrar, agregar, y redirigir mensajes entrantes o salientes basados en su contenido o en reglas.
La transformación e intercambio de datos a través de distintos formatos y protocolos de transporte.
Servicios de mediación para el manejo de formatos, mensaje y protocolos, además de lógicas de integración.

Cuando debemos utilizar un ESB?

Cuando se requiere la integración de 3 o más aplicaciones o servicios.
Cuando se requiere conectar más aplicaciones en un futuro.
Cuando es necesario utilizar más de un tipo de protocolo de comunicación.
Cuando se requiere capacidades de enrutamiento de mensajes, tales como bifurcación y agregación de flujos de mensajes, o enrutamiento basado en contenido.
Cuando es necesario publicar los servicios destinados al consumo de otras aplicaciones

Recomendaciones para el uso de Mule ESB

El patrón de intercambio seleccionado para un flow o flujo incide en el número de hilos que mule utiliza para la ejecución de servicios de integración. Si el patrón es Request-Response, este se desarrolla sobre un solo hilo; si el patrón es Onew-Way se desarrolla sobre un pool de hilos (inbound, core y outbount). Es necesario considerar esta política durante el diseño de los servicios.
Por defecto Mule ESB solo gestiona 16 hilos, por ende, es importante monitorear el número de hilos y aumentarlo según la demanda de un servicio de integración específico.
Mule ESB proporciona patrones de configuración, que están optimizados para casos comunes de procesamiento de mensajes. Los cuatro patrones de configuración incluidos en Mule son: Servicio simple (componente que expone servicios web SOAP/ JAX-WS , beans, REST/JAX-RS, JAXB, XML y el contenido de simples componentes POJO), Web Service Proxy ( Proxies de servicios web remotos que pueden realizar transformaciones), Bridge ( establecen un canal de comunicación directo entre un endpoint de entrada y uno de salida), por ultimo Validador (Valida los mensajes entrantes contra un filtro de aceptación definido. Devuelve una respuesta ACK o NACK sincrónica y envía mensajes válidos de forma asíncrona).
Utilice el Scope Pool para ajustar el desempeño de un servicio de integración mediante pool de objetos.
Utilice wiretap para realizar auditorías en los flows o flujos de servicios.
Si requiere utilizar multiples entradas en un mismo flow utilice composite source.
Si requiere establecer rutas alternativas al fallar una rama de ejecución utilice first successfull.
Si requiere reorganizar la secuencia de mensajes utilice un resequencer.
Si va a realizar mapeo recomiendo utilizar smooks y dozer.
La información del header de un mensaje en el inbound no se propaga al siguiente flow, solo de outbound a inboud, considere esta característica cuando diseñe sus servicios.

Agradezco al equipo que con su participacion y observaciones enriquecieron los talleres.

Ejemplo: Como enviar un mensaje a multiples destinos.

Ejemplo: Como realizar el procesamiento de una coleccion de datos.

Ejemplo: Como exponer un servicio web implementado en un POJO.

Ejemplo: Como filtrar el mensaje entrante de un servicio.

Ejemplo: Como realizar auditorias a un servicios de integracion:

Saludos;

7/15/2012

WSO2 e Interoperabilidad, una Plataforma Middleware en Panamá

Hace algunas semanas realice un taller sobre la plataforma middleware empresarial WSO2 en Panamá dentro de un proyecto de Interoperabilidad y Gobierno Electronico de alta escala que se esta desarrollando actualmente. WSO2 esta conformada por un amplio numero de componentes con nivel de madurez suficiente para ser considerado como modelo para introducir las disciplinas SOA, ESB y BRE en una organizacion. En este post, voy a compartir algunas apreciaciones relacionadas con el despliegue de estos componente. Para comenzar una pequeña introducción.

WSO2 Carbon es una plataforma middleware empresarial, 100% OpenSource y basada en estándares empresariales, que permite a desarrolladores orquestar procesos de negocio, crear aplicaciones y desarrollar servicios; utilizando WSO2 Carbon Studio y una amplia gama de servicios empresariales y técnicos que se integran con legados, paquetes y aplicaciones de software como servicio (SaaS). La plataforma WSO2 Carbon es una colección de componentes totalmente independientes que pueden ser agregados o eliminados de una solución dinámicamente. Este comportamiento se logra mediante el uso del marco de trabajo denominado Open Services Gateway Initiative (OSGi).

WSO2 Data Services
WSO2 permite la creacion de servicios de datos, conocidos como "Data Services" con un amplio espectro de posibilidades de conexion con diversas fuertes de datos como hojas de calculo, base de datos, entre otros. Con este componente podemos desplegar servicios SOAP y REST de una forma sencilla y elegante, sin grandes esfuerzos de desarrollo, sin embargo cuando requerimos implementar servicios de generación de UUID o correo electrónico; esta no es la mejor opcion.

WSO2 Rule Services
De igual forma, provee desde mi punto de vista unos de los mejores componentes que son los "WSO2 rules Services", conocidos como "Rule Services" o servicios de decision, una forma muy sencilla y elegante de tomar reglas de negocio elaboradad mediante Drools y exponerlas como servicios de decisión. Drools es un motor de reglas de negocio que permite la gestion de reglas en un entorno multi usuario de manera controlada a traves de interfaces de usuarios amigables. WSO2 Business Rules Server ofrece la gestión de reglas de negocio para un entorno SOA sobre la base de una sólida plataforma de alojamiento de reglas de negocio. WSO2 Business Rules Server permite que las reglas de negocio sean encapsuladas en un lenguaje sencillo y directo, el cual es más familiar para los analistas de negocio.

WSO2 Governance Registry
Otro componente que recomiendo es la utilización del WSO2 gobernent que proporciona el nivel adecuado para soportar la gobernabilidad SOA (es obtener el máximo rendimiento del entorno SOA y asegurarse de crear servicios de alta calidad). Con este componentes, podemos: crear y mantener un conjunto de políticas SOA, permitir la aplicación de estas políticas en tiempo de diseño y permitir la aplicación de estas políticas en tiempo de ejecución.

Por ultimo, recomiendo la evaluación de la plataforma WSO2 por la sencillez y elegancia de gestión, la cual puede ser utilizada para acelerar una implementacion SOA organizacional.

Saludos;

Ley de Interoperabilidad Venezolana, una ley innovadora, creativa y actual

Actualmente, los intercambios de información entre las instituciones publicas de muchos países se están desarrollando sobre una amplia variedad de formatos, tipos e interacciones, lo cual ha impulsado el crecimiento y proliferación de practicas no estandarizadas que han contribuido con la desarticulación de los organismos responsables en la prestación de servicios al ciudadano.

En este sentido, el estado venezolano ha reconocido la responsabilidad de prestar servicios de interoperabilidad para garantizar la prestación de servicios públicos integrados mas eficientes para los ciudadanos. Esta ley garantizara la articulación de las instituciones publicas para responder a las necesidades de los ciudadanos, instituciones y el estado utilizando las tecnologías de informacion como principal medio.

En esencia, la ley garantizara el desarrollo de servicios de información adaptados a las necesidades de los ciudadanos y a los procesos institucionales, disminuyendo las dificultades de integración entre los sistemas de información presentes en el sector publico y privado.

En la Gaceta Oficial N °39.945 de fecha 15 de junio de 2012, fue publicado el Decreto N°9.051 mediante el cual se dicta el Decreto con Rango, Valor y Fuerza de Ley sobre el Acceso e Intercambio Electrónico de Datos, Información y Documentos entre los Órganos y Entes del Estado. El presente Decreto con Rango, Valor y Fuerza de Ley, tiene por objeto establecer las bases y principios que regirá el acceso e intercambio electrónico de datos, información y documentos entre órganos y entes del Estado, con el fin de garantizar la implementación de un estándar de interoperabilidad.

Desde este link se puede tener acceso a la ley:
http://www.cnti.gob.ve/images/stories/documentos_pdf/go_interoperabilidad.pdf

Como venezolano he aportado mi granito de arena en la conformación de esta ley, integrando en ella conceptos asociados a las disciplinas y estilos de arquitectura SOA, ESB y BPM. Entre los elementos de mayor importancia:

La Ley incorpora diversas disciplinas y estilos de arquitectura de TI en su contenido.
La ley incorpora el concepto de servicio.
La ley incorpora conceptos relacionados con Gobernabilidad SOA.
La ley incorpora conceptos relacionados con Bus de Servicios.
La ley incorpora conceptos relacionados con Web Semántica y Nube de datos.

Saludos y felicitaciones al personal técnico y gerencial del Centro Nacional de Tecnologías de Informacion y al Centro Nacional de Innovación Tecnológica por la iniciativa y la contribución que han realizado por mejorar los servicios públicos en el Estado Venezolano. Una iniciativa creativa, innovadora y de valor!!!

Intalio y Bonita BPM en el Ecuador

Hace algunas semanas estuve de nuevo en Ecuador impulsado la utilización de las disciplinas BPM, SOA, ESB y BRE para la creación de organizaciones gestionadas por procesos. En esta oportunidad el Organismo de Acreditación Ecuatoriano (OAE) esta desarrollando los primeros pasos para cambiar su modelo de gestión funcional a uno orientado a la medición en tiempo real de indicadores que puedan mejorar sustancialmente sus procesos de decisión. El marco de arquitectura propuesto esta conformado por un conjunto de tecnologías que de forma integral permitirán que la institución pueda conformar un marco de interoperabilidad robusto, escalable y fiable.

De la experiencia obtenida en dicha consultoria, quise compartir con la comunidad algunas recomendaciones que pueden ser utilizadas en implementaciones a gran escala de proyectos BPM-SOA organizacionales; estas recomendaciones pueden ayudarlo a facilitar su comprensión.

Algunas recomendaciones para utilizar Bonita BPM e Intalio.

Evite modelar los procesos sobre la premisa que el motor de procesos debe exponer servicios web. El motor de procesos debe orquestar servicios, pero no es recomendable utilizarlo como una plataforma para la creacion de servicios, como decimos en Venezuela "zapatero a su zapato".
Utilice Data Services como medios para exponer servicios web relacionados con medios persistentes como base de datos, hojas de cálculos, archivos, entre otros.
Utilice servicios "Rule Services" para gestionar sus reglas de negocio. Los Rule Services también son conocidos como servicios de decisión.
Utilice un bus de servicios para integrar sus servicios de datos, reglas, integración o procesos mediante un enfoque de proxys.
Es importante establecer una diferencia entre servicios de datos e integración. Los últimos generalmente son implementados en un bus de servicios.
Establezca los "Process Services", servicios web que son expuestos por un motor de procesos como Bonita BPM o Intalio.
Utilice correlaciones en sus procesos para tener control de las instancias que requiere ejecutar, sin embargo, recomiendo utilizar como maximo dos correlaciones por diagrama, esto evitara que los diagramas de procesos se extiendan en una sola representación, contribuyendo con una mejor comprensión.
Divide y vencerás. tome los procesos y separelos en subprocesos independientes.
Importe los procesos, con esta opciones no tendrá problemas con el acceso a fuentes de datos; como xml schemas.
Defina mensajes Request y Response separados para cada mensaje.
Utilice el poder de la API REST de Bonita o la correlaciones de BPEL para controlar las tareas asociadas a los procesos y el orden de ejecución.
Utilice lienzos para plasmar las ideas y conceptos durante los talleres de análisis de procesos:

Saludos;