lunes, 24 de octubre de 2011

Proceso MecaPlus: Descubrimiento de servicios

A continuación presentamos los entregables de Ecosistema y Portafolio de Servicios para el nuevo proceso MecaPlus.

Para este trabajo se aplicó un enfoque vertical, aplicando el patrón de descubrimiento Top-Down encaminado a Atributos. Esto es porque para expresar nuevo proceso, requerimos realizar seguimiento de los negocios, a nivel de características de los negocios, como entidades, y también capacidades de estos negocios. Los entregables también se basan en ejercicios de creación de un modelo de atribución y un árbol de decisión.

También se practicó el patrón Top-Down encaminado a Procesos de Negocio, para verificar en manejo de repuestos, cómo se realiza este proceso ya existente.

Lista de capacidades del proceso


Portafolio de Servicios


Ecosistema de Servicios

sábado, 22 de octubre de 2011

¿Qué patrón aplicamos hoy?

Downward, Top-Down, procesos, atributos, interfaces, productos de legado, etc. Estamos ahí, en una mesa grande, con colegas, escribiendo notas, devorando documentos, referencias, de empresas, departamentos, trabajos de investigación, casos de éxito,en busca de una idea, no de cualquiera, sino de la más, la más factible, la más económica, la que de  más y mejores resultados en poco tiempo, una idea para encontrar capacidades, o cosas que pueda hacer un producto, un sistema, y además que todos en el mundo puedan usar por la Web, tomarla de ahí, cuando la necesiten, ya sea, transferir dinero de Bogotá a Singapur, o una boleta para la gira de U2, o conseguir la maquinaria para ser fabricante de un coche de marca europeo.

El trabajo de Michael Bell, de SOA Modeling Patterns, no es otro trabajo académico, en la oscuridad de una universidad clásica, para estudiosos. No en vano, está en Amazon, tiendas importantes, referenciado en muchas investigaciones importantes, como un gran estudio para modelar, hacer de procesos, los productos deseados por empresas, empresarios, para satisfacer sus necesidades. Me encontré viendo referencias, en busca de complementos, sumarios de las lecturas. El trabajo de Bell es extenso, las lecturas son extensas, y aunque  so una gran guía, se necesita tiempo, y algo más, habilidades, competencias, para diseñar y construir productos de calidad, desde el arte de encontrar servicios, capacidad, lo que puede disponer un sistema para el resto del mundo.

En mi caso, no he trabajado con Unisys, o Amazon, menos con Oracle, EC2, y reconozco que no sé de Web Services más que escribir uno y arrancarlo en un servidor casero. Por eso, tal vez, puedo hacerme a la idea, o ideas generales, del propósito de cada enfoque, modelo, o patrón dado el caso. Puedo hacer las asociaciones siguientes: Enfoque vertical para ir al corazón y los detalles de los procesos para encontrar servicios. Modelo Top-Down para a partir del nivel macro, las imperaciones y los proceso de negocio, encontrar los servicios simples. Patrón Encaminado a Procesos de Negocio, para investigar y conocer íntimamente los proceso que ya existen, Patrón Encaminado a Atributos para hallar las características de los procesos en general, Front-2-Back para procesos nuevos de monitoreo y manejo de información en tiempo real, Back-2-Front para procesos de informes gerenciales y analítica visual, Patrón Bottom-Up para servicios desde sistemas de legado, etc.; y desde ahí, ser curioso, saber cómo más aplicar los patrones, aplicarlos a VehiAlpes, y a los negocios de ejemplo.

Pues, tal vez sea una idea general, fácil, con más experiencia se puede advertir más aplicaciones de los patrones, cómo aplicarlos hábilmente, etc. Pero sí hay una idea, una sensación, que vale la pena adquirir, con o sin experiencia, y es cómo aplica, a diseñar soluciones, más allá de la parte técnica, o pragmática, rgeresando alas primeras sesiones del curso de Patrones, y es la de conseguir soluciones, acercándose a la estética, la elegancia, productos, que más que servir, funcionar, trasmitan sensaciones de gusto, comfort, placer, al hacer uso de ellas. Esto lo consigue SOA, a través de su filosofía, sus principios de bajo acoplamiento, reutilización de servicios, y sus patrones de descubrimiento de servicios; de forma que el diseñar, descubrir servicios, sea más que estar en la mesa, devorando documentos, sea un momento de crear, hacerlo con inspiración, abstraerse en la forma, las cualidades. Por eso también, más que saber los enfoques, o patrones para encontrar servicios, se necesita también cierto toque, cierto desenvolvimiento para decir, esto que ocurre en el proceso, lo puedo hacer una capacidad de este servicio.

En este trabajo vale la pena también echar un ojo a la introducción del libro, el sentido de éste, más allá de la descripción formal de los patrones. También, como complemento, practicar Web Services, verlos, como ir a la excursión, o a la fábrica, y ser curioso de cómo encontrar eso que vemos funcionar en el computador. Para el caso de VehiAlpes, en mi caso, aplicaría hoy Top-Down encaminado a atributos, y algo de Bottom-Up, para nuestro enfoque de poderes

lunes, 17 de octubre de 2011

Diseño de patrones de integración

Tecnología a utilizar
La herramienta de Mule nos parecio el mejor softwate para el manejo de la mensajería, ya que es un excelente gestor de objetos escalable y distribuible que puede manejar interacciones con servicios y aplicaciones que usan distintas tecnologías de transporte y mensajes.
Además que Mule es un framework muy liviano y fácilmente de embeber en aplicaciones Java, y se puede integrar con frameworks como spring, hivemind y plexus y soporta muchos componentes de transporte y servicio como JMS, SOAP, JBI, BPEL, EJB, AS/400, HTTP, JDBC, TCP, UDP, SMTP, FILE, FTP y más. Adicionalmente una extensión beta de Mule es Mule estudio, la cual facilita aún más la implementación grafica de la aplicación con respecto a la mensajería, pero fundamentalmente Mule es una herramienta que posee un gran soporte ya que es la herramienta más utilizada de integración en el mercado, lo que permite una mejor retroalimentación de la comunidad a la hora de solucionar problemas.

Solicitud servicio grúas
Patrones SOA implantados

Comunicación Asincrónica
“Un servicio puede requerir que los consumidores se comunican con él de forma asíncrona y proporcionar una dirección de devolución de llamada para que el servicio pueda enviar mensajes de respuesta.”
Este patrón se utiliza al solicitar el servicio de grúa, a un conjuntos de aplicaciones diferentes de grúas que atienden solicitudes ya sea de manera asincrónica, ya que necesitan procesar primero  las solicitudes en Batch y luego si dar una respuesta.


Transformación del formato de la información.
“Intermediario formato de datos lógica de transformación debe ser introducido con el fin de convertir dinámicamente un formato de datos a otro.”
Para poder comunicarse con las aplicaciones de las grúas se debe hacer una transformación de la información y/o de los datos para que dependiendo de la aplicación de la grúas, esta pueda procesar la información de manera adecuada






Diseño completo de solicitud 



lunes, 10 de octubre de 2011

Patrón BPM Reclamación

Ilustración


Borrador


Motivación

Cubrir de manera formal y única le proceso de reclamos y devolución de productos o servicios.


Problema

El proceso de reclamos y devolución se aplica en las compañías para cada caso, de manera particular, sujeto a reglas, directrices e intereses por parte de la compañía que maneja este proceso. Por tanto, al realizar modelado de procesos, nos encontramos con que este proceso debe modelarse de manera particular, rehaciendo nuevamente subprocesos, tareas y elemento gráficos que pueden ser innecesarios.


Solución

Se propone para este proceso un patrón de modelado que cubre los elementos "estándar" en el proceso, bajo la perspectiva también de un proceso formal, ordenado, aplicable a cualquier entorno. En éste, entran en escena 4 actores que son: Cliente, Vendedor, Proveedor y Contratista. Y se manejan los casos de reparación y devolución del producto adquirido que desea ser reclamado por garantía.

Un ESB, muchos buses.

Basado en el libro, donde se dice que el mejor esquema de integración es aquel basado en mensajería, o al menos es el que mas problemas puede resolver, puedo decir desde mi experiencia personal que es completamente cierto.
Es cierto que cada problema es diferente y en cada situación, las necesidades de integración pueden atacarse de maneras distintas dependiento de la naturaleza del problema, con un esquema basado en mensajería se resuelven la mayoría de los retos que se plantean en una necesidad de integración.
Hoy en día las herramientas para proveer este tiopo de soluciones. Por necesidades laborales, llevo algún tiempo trabajando con la suite de herramientas de IBM y quiero compartir mi experiencia sobre ello.
IBM cuenta principalmente con 3 productos que actuan como ESB.
  • WebSphere ESB el cual es totalmente basado en tecnología Java y esta soportodado (dependiente) en el servidor de aplicacion WAS. Esta es quizas la mejor opción cuando se trata de integrar aplicaciones escritas en el mismo lenguaje(java) y que su esquema de su formato de mensajería este basado en estandares SOAP, WS, XML, y tecnologías relacionadas.

  • WebSphere Message Broker Es el mas apropiado cuando se trata de integrar aplicaciones en tecnologias heterogéneas. Tiene muchas facilidades para convertir mensajes de un formato a otro y convertir tambien protocolos heterogeneos. Es el apropiado para implementar patrones de integración complejos.

  • WebSphere DataPower Es el mas poderoso en cuanto a desempeño se trata. WebSphere DP es un appliance (Hardware) donde se pueden definir transformaciones de XML y tambien conversión de protocolos de comunicación. Dado su alto poder de procesamiento es el preferido cuando se requiere minimizar la latencia adicionando una capa de integración. En general es recomendable implementar patrones simples en esta tecnología.



  • Por fortuna, he tenido la oportunidad de trabajar con las 3 herramientas y es importante saber escoger cual usar en cada momento.
    Espero sea de ayuda la información aca expuesta.

    BPMN 2.0 = Holy Grail?

    El libro BPMN 2.0 de Thomas Allweyer, provee de una concienzuda exploración al estándar BPMN 2.0, su semántica y aplicación en el diseño de procesos de negocio. Luego de la lectura de sus capítulos me quedo una impresión general del poder expresivo de la notación y su semántica. Así mismo, los comentarios de diseño del autor, son en mi opinión enriquecedores, particularmente en lo que respecta a los problemas a los que uno se enfrentara un diseñador durante su uso. Luego de la lectura me inquietaron algunos puntos respecto a BPMN 2.0.

    En primera medida, creo que la notación ofrece un lenguaje visual altamente rico, pero a su vez complejo. En este sentido me cuestiono si al modelar un proceso típico, es empleado todo el abanico de elementos que este ofrece. Por otro lado, un mayor número de elementos de la notación puede finalmente entrar en conflicto con una de sus filosofías, el ser lingua franca para la representación de modelos de negocio. Creo que BPMN 2.0 puede ser de difícil acceso (y comprensión) para el público en general -si uno peca por ser muy detallista en sus modelos, lo cual puede ser muy probable. Lo anterior representa una debilidad en mi opinión, pues toda la responsabilidad en este sentido recae sobre el modelador, pues BPMN 2.0 aporta poco en términos de restricciones sobre el modelaje los procesos de negocio.

    Ahora con respecto a los modelos ejecutables, la semántica de BPMN 2.0 y su potencial expresivo, sin duda es muy alto, pero considero que las notaciones simplificadas como los eventos de inicio y final, así como los gateways implícitos, hacen más complejo entender el detalle del comportamiento de un proceso, pensado para ejecución. En este sentido, entiendo el ánimo de BPMN 2.0 de ofrecer expresiones que son visualmente más simples (y accesibles para quienes es presentado el proceso), pero en mi opinión pueden terminar confundiendo a quien tiene interés en el detalle del proceso y su consistencia.

    domingo, 9 de octubre de 2011

    Patrones de Integración

    Integración en Aplicaciones (Bernarnd y Laurent)



    El libro ilustra y es escrito de manera clara asumiendo un conocimiento inicial básico. Es un libro muy completo, que va más allá de patrones de integración presentando al lector una amplia gama de temas y de comparaciones entre los diferentes estilos, también se proporciona conocimiento y propone  formas de uso de la mensajería para solucionar diferentes problemas de manera efectiva, y proporciona una manera clara por medio de pasos para poder tener éxito en la implantación de las técnicas de integración. Me gusta especialmente la forma en que Bernard y Laurent diseña cada modelo usando el lenguaje y los estilos visuales para delimitar las secciones de forma natural del patrón, esto aumenta significativamente la legibilidad y el entendimiento de la idea de integración.
    El libro es muy independiente de la tecnología, ya que se enfoca más hacia la generalización de la idea, ilustrando las ideas de los patrones y maneras de integración sin tener que ligarse con una tecnología o herramienta, lo que permite una generalización del conocimiento para poder aplicarlo a cualquier tecnología si ésta lo permite.
    El problema por menor que le vi al libro es que eran muy largos sus capítulos,  lo que hacía que me perdiera el hilo, pero en general el lenguaje utilizado era bastante entendible, lo que si puede mejorase es  en ser más concreto y resaltar las características más importantes, ya que se pueden quedar en medio de las frase históricas, preguntas, etc.